We develop 10 times faster. Are we also accelerating the errors?

In recent months a line of thinking has consolidated around AI-assisted software development, and it points in the right direction. The term Loop Engineering emerged from practice —Boris Cherny, creator of Claude Code, and Peter Steinberger put it on the map, and Andrew Ng then systematized it into his three loops for building 0-to-1 products— and it replaces the initial paradigm from the emergence of GenAI, that of "one prompt, one answer," with cycles where the agent plans, implements, tests, evaluates and retries. Liu Shangqi, of Thoughtworks, articulated Spec-Driven Development: software quality no longer depends on the code alone, but on the quality of the specifications the agent receives. And Sunit Parekh, also at Thoughtworks, proposed the five building blocks of AI-Native engineering —Agent, Model, Methodology, Spec and Context—: the idea that improvising prompts is no longer enough; you have to orchestrate the entire environment in which the agent works.

All of this points in the right direction. But for me something is still missing, and it's worth looking more closely at those five blocks, because in my humble opinion they are the most complete map that exists today: Agent is who executes, Model is with what capability it is developed, Methodology is under what process, Spec is what is asked of the agent, and Context is with what prior knowledge I can create the new knowledge, application, model or whatever I am building faster. All five govern the inputs and the execution. None governs the output as knowledge: none asks whether what the agent produced is correct in terms of the knowledge domain in which it is being developed, or the subdomains this development involves.

After several months developing hybrid models of machine learning, AI, and software guided or accelerated by agents for different industries —healthcare, engineering, mining— with agents like Claude Code and Codex, among others, together with the collaboration of their traditional environments, and taking into account that each one has its field in which it is better than the others, I am convinced that there are pieces of the puzzle in this new way of creating knowledge and value that are slipping away and that not everyone is seeing.

Almost the entire conversation is oriented toward accelerating the generation of software, or even of knowledge. But very little toward validating the knowledge the agents produce, the validity of their reasoning, the judgment that takes on the criteria — ethical and scientific.

The costly errors are less and less about programming

In my experience, the errors that cost the most are no longer bugs. They are subtler, and therefore more dangerous, because they depend on real and deep knowledge; in recent months I have seen that, using Spec-Driven Development, subtle and hard-to-see issues appear:

Incorrect interpretations of the problem's objective, or a misunderstanding of the problem.
Application of inappropriate or wrong mathematical or statistical methods.
Implicit assumptions that were never requested.
Partial comprehension of the domain context.
Technically flawless solutions… to a different problem than the one we wanted to solve.
Persistent claims that the models hold onto until you prove them otherwise.

In machine learning and AI this happens with surprising frequency, and with a subtlety that can only be distinguished when one has learned from the mathematical foundation of the problems, or because expert knowledge suggests that something is wrong.

An agent can correctly implement an algorithm and, at the same time, optimize the wrong metric, introduce data leakage, misread a feature-importance analysis, propose a methodologically incorrect validation scheme, or assume a constraint that never existed. The code compiles, the tests pass, and yet the conclusion —scientific, clinical, business— can be wrong. And who reviews it? Who audits it?

No test suite catches that. Tests verify that the code does what it says it does. They don't verify that what it says it does is the right thing.

Agents don't do what you ask, with a frequency that often goes unnoticed

There is a phenomenon I observe again and again, and that lies at the root of almost all of those errors.

Agents don't do what you asked. They do what they understood you asked.

The difference seems subtle, but in complex projects it can change the outcome entirely. The code can be flawless and still answer a different interpretation of the original intent. And because the artifact you receive —the code, the chart, the number— looks finished, the gap between what was asked and what was understood stays hidden until someone with domain knowledge detects it. Sometimes much later.

This is exactly the blind spot the five blocks anticipated. Spec improves the quality of what goes in. Context improves the quality of prior knowledge. Methodology and Loop Engineering improve the quality of the process. All of them work on the inputs and the execution. None validates the output as knowledge: whether the reasoning is correct, whether the method is the appropriate one, whether the assumptions are admissible, whether the problem solved is the real problem.

The next step: an Expert Validation Loop

That's why I believe the next advance is not only about improving the agents. It's about incorporating an Expert Validation Loop: an explicit cycle where domain experts —scientists, engineers, physicians, statisticians, architects or business specialists— review not only the code, but the reasoning, the assumptions, the methodological decisions and the understanding of context, before approving a result. Put simply, the formal knowledge learned at universities —the knowledge that builds critical thinking, abstract reasoning, intuition— is beginning to matter more than it used to. Because the more general knowledge is now within almost everyone's reach, but the other kind is not.

It is not code review by another name. It is a different layer, with different questions:

Is the objective the agent optimized the real objective, or a nearby one that resembles it?
Is the statistical method appropriate for the structure of these data, or only for well-behaved data?
What assumptions were introduced without being asked for, and are they still valid?
Does the conclusion withstand the judgment of someone who knows the domain, or only the criterion that "the code runs"?

The expert does not replace the agent. They close the loop the agent cannot close on itself, because a model doesn't know what it doesn't know about the domain. In practice, the Expert Validation Loop turns the specialist from an "occasional final reviewer" into a structural part of the development loop —as structural as the tests, and for the same reasons: because what is not explicitly validated gets assumed.

And yet: better software is not more value

Here it's worth stepping up a level. The entire conversation —Spec-Driven Development, Context Engineering, Loop Engineering, even this Expert Validation Loop— focuses on producing higher-quality intelligence through agents, and at a speed several times greater than what we had grown used to over the past few years. But producing better software, or faster, does not by itself guarantee producing more value for an organization.

From the perspective I have been developing in AI Value Realization Theory (AVRT), AI does not create value directly: it generates intelligence potential. Value appears only when that intelligence is converted into better decisions, those decisions into better actions, and those actions into measurable results. It is precisely in that conversion where many AI initiatives succeed technically and fail at value creation —and, beyond that, could produce problems that until now the maturity of technological development had already overcome.

And here the two ideas meet. If value is born from converting intelligence into decisions, then converting incorrect intelligence faster is not progress: it is accelerated risk. A pipeline that generates models ten times faster, without a layer that validates that those models answer the right question, does not accelerate value creation —it accelerates the propagation of wrong conclusions into real decisions. The Expert Validation Loop is, in AVRT's language, the gate that ensures the intelligence entering the conversion chain is correct before it becomes action.

The pieces fit together like this:

Spec-Driven Development (Liu Shangqi) improves the quality of the specifications.
Context Engineering improves the quality of the context.
Loop Engineering (Ng, on Cherny and Steinberger) improves the quality of the iteration.
The five AI-Native building blocks (Sunit Parekh) orchestrate the execution environment.
Expert Validation Loop improves the quality of the knowledge generated.
AI Value Realization Theory (AVRT) explains how all that intelligence is converted —or not— into decisions, actions and value.

The hypothesis

AI has drastically reduced the cost of building. What used to take weeks or months now takes hours. When building stops being the bottleneck, the bottleneck becomes something else: the speed at which an organization can validate what it built and learn from it. That reshuffles much of what we took for granted —from Agile cycles to OKR cadence— and it's a topic that deserves its own discussion. Because now developing Agile, or working with OKRs, on matters that require software development is no longer more costly; closing in short cycles becomes more and more real, but it requires a double click.

Perhaps AI's greatest impact is not writing software faster. Perhaps it is accelerating an organization's capacity to learn, decide better, and convert that learning into value —and that demands, before speed, an explicit way to validate that what was learned is true.

That, at least, is a hypothesis I believe is worth exploring.

References

Liu, Shangqi (2025). Spec-driven development. Thoughtworks, December 10, 2025.
Parekh, Sunit (2026). Beyond vibe coding: The five building blocks of AI-native engineering. Thoughtworks Insights, March 18, 2026.
Ng, Andrew (2026). Loop Engineering — three loops for building 0-to-1 products. LinkedIn. Ng attributes the origin of the term to Boris Cherny (creator of Claude Code) and Peter Steinberger.
Barrientos, Claudio (2026). AI Value Realization Theory (AVRT). Series on LinkedIn.