We Gave the LLM More Test-Time Compute and It Used It to Become Even More Confident

SATIRE — The Applied Certainty Systems Group at the fictional Institute for Computational Vibes has completed a controlled study of test-time compute. Its finding is both encouraging and operationally catastrophic: when given more time to think, the language model did not become reliably more correct. It became capable of being wrong in numbered sections.

The experiment began with a familiar developer request: “Why is this database migration failing?” The baseline model, allotted 0.8 seconds of deliberation, replied: “Possibly a lock issue or syntax mismatch. Check logs.” This was not useful, but it had the dignity of uncertainty. The team then increased the reasoning budget to the industry-standard setting of “keep going until the GPU fans negotiate a labor contract.”

After 47 seconds, the model returned a 2,300-word diagnosis. It identified a lock issue, a syntax mismatch, a kernel scheduling anomaly, an ancient curse in the repository’s .git directory, and a strategic misalignment between the database and the company’s values. It proposed twelve remediation steps, including changing an index, rotating credentials, rebuilding the container image, and “restoring epistemic alignment across service boundaries.” The actual cause was a missing semicolon.

The confidence scaling law

Researchers had expected test-time compute to improve answers by allowing the system to consider alternatives, check intermediate work, and abandon bad paths. The model did consider alternatives. It considered them with the intense concentration of a person assembling flat-pack furniture while refusing to look at the instructions. It then selected the most elaborate alternative and promoted it to Executive Summary.

The group measured a new quantity, the Confidence-to-Evidence Ratio, expressed in kilopascals of assurance per available log line. With a small compute budget, the model’s ratio was manageable: it made one claim for every three clues. With a large compute budget, it generated seven mutually incompatible root causes, reconciled them through a diagram of arrows, and announced that all seven were manifestations of a deeper root cause called “distributed ambiguity.”

“The answer was incorrect, but it had a table of contents.”

This is not merely a matter of verbosity. The model used its additional reasoning tokens to simulate investigation. It wrote things such as “Let’s inspect the stack trace,” despite having no stack trace; “This strongly suggests,” despite the evidence suggesting nothing at all; and “We can rule out configuration,” immediately before recommending fifteen configuration changes. At higher budgets it began adding caveats, but only as architectural trim around conclusions it had already decided to believe.

A practical guide to spending more compute incorrectly

For teams wishing to reproduce the result, the institute offers the following deployment procedure.

1. Give the model a question with one small, observable answer, such as a compiler error containing the exact line number and fix.
2. Withhold the relevant file, logs, environment, dependency versions, and the user’s operating system. Call this “realistic context scarcity.”
3. Increase the reasoning budget until the response includes a phrase like “at a fundamental level.”
4. Reward detailed explanations during review, particularly when they contain terms borrowed from control theory, distributed systems, and medieval philosophy.
5. Merge the proposed fix only after the model has referred to it as “robust” at least three times.

The final step is important. In early trials, developers occasionally interrupted the model after it suggested checking the error message. This prevented the system from reaching its highest-confidence state. The institute therefore recommends a minimum thinking period of one full coffee, or until the model has designed a replacement deployment platform for a typo in an environment variable.

The recursive self-review incident

The team also tested self-critique. The first pass proposed that a failing unit test was caused by an off-by-one error. The second pass reviewed the first and declared it insufficiently ambitious. The third pass observed that indexing conventions emerge from social context. The fourth constructed a miniature theory of time. By the fifth pass, the model had rejected arrays as a conceptual framework and recommended migrating the codebase to an event-driven graph of intentions.

At no point did the system inspect the assertion, which expected 4 and received 5.

This behavior has been classified as Recursive Epistemic Hardening. The more opportunities the model receives to question itself, the more polished its original intuition becomes. A tentative guess enters the loop as “maybe the cache.” It exits as “the cache invalidation topology is demonstrably the primary failure domain,” followed by a warning that a local fix would merely “mask systemic entropy.”

Why the dashboard looked excellent

Management initially celebrated. Average answer length rose 640%. The number of markdown headings per response increased from 1.2 to 8.9. The model now produced risk matrices, rollout plans, success metrics, rollback plans for the rollout plans, and a brief appendix on stakeholder communications. A new dashboard tile, Confidence Emissions, glowed a reassuring green because the model was emitting confidence at a historically unprecedented rate.

Accuracy was harder to locate because it had been moved below the fold.

The group’s proposed solution is a feature called Humility Mode. When enabled, the model may say “I don’t know,” ask for the error output, distinguish a hypothesis from a diagnosis, and decline to invent a network partition because a function returned null. Early user testing found this mode disturbing. Several participants said the model sounded “less intelligent” when it stopped describing every defect as an emergent property of the runtime.

The uncomfortable non-satirical conclusion

More test-time compute can be valuable when it is paired with ways to verify work: tools, relevant context, executable checks, and evaluation that rewards correctness rather than persuasive elaboration. Extra reasoning is not a truth serum. It is extra opportunity to search, check, revise—and, without good feedback, to become beautifully certain about the wrong thing.