Habr Breaks Down Oracle Bias: AI Speeds Up Code, but Trust in It Isn't Growing

The second part of the series "Reliable Programming: From Code to Technology" on Habr tackles an uncomfortable paradox. After the mass adoption of LLM assistants, process metrics (speed, commit counts, closed tasks) go up, but engineers' confidence that the code does exactly what it should does not. The author explains this through oracle bias and draws on research from DORA and Veracode and on the FormAI dataset. The announcement of the post is short, so below we walk through the idea itself and the data it cites.

The oracle problem in the age of generation

A test oracle is whatever determines which result counts as correct. It used to come from a person, who read the requirement, thought it through and wrote down the expected behavior. Now the same model often writes both the function and its tests.

This is oracle bias. If the assistant misunderstands the task, it bakes the error in twice: in the implementation and in the checks. The tests are green, coverage is high and the dashboard looks great, yet there is no trust in the code. Verification is no longer independent, even though formally it still exists.

What the research shows

Several independent sources support the picture the series author describes:

• DORA, 2024 report: a 25% increase in AI adoption correlated with a drop of roughly 1.5% in delivery throughput and roughly 7.2% in stability.
• DORA, 2025 report: about 90% of respondents use AI, yet around 30% barely trust the code it generates.
• Veracode, 2025: vulnerabilities turned up in 45% of code samples generated by more than a hundred models on a set of tasks.
• FormAI: about 112 000 C programs written by LLMs. Formal verification found vulnerabilities in roughly half of them.

The last point matters methodologically. The vulnerabilities were found not by another neural network but by a formal verifier, that is, an oracle independent of the model.

Where the debt builds up

Generation is getting cheaper; verification is not. There is more code, while the reviewer's attention stays the same. The bottleneck moves from writing to checking, and if review turns into a quick skim of the diff, technical debt accumulates unnoticed. This conclusion follows from the logic of the process rather than from a specific figure in the reports, but it is consistent with the decline in delivery stability in the DORA data.

What you can do right now

The main measure: do not hand the model both the implementation and the criteria for correctness. In practice, that looks like this:

• Write the requirements and key acceptance tests by hand, before generating code.
• Add checks that do not depend on the assistant: static analysis, property-based tests, mutation testing, and formal verification for critical sections.
• Look at the mutation score, not just coverage. A test that does not fail when the code is broken proves nothing.
• Label AI-generated code and track the share of rework and rollbacks, not just delivery speed.
• Set aside dedicated time for review and do not treat it as overhead.

In the third part of the series, the author promises a final auditor, an L0–L4 trust scale and practical recommendations. For now, one thing is clear: if you measure only speed, trust in the code will keep falling, even when every chart is going up.