Code is Cheap. Trust is Expensive.

For thirty years, code was the scarce resource.

The economic structure of our entire profession was built on that single assumption. Almost every argument we have had as a discipline since the 1990s has been an argument about how to produce code more efficiently, more cheaply, or with fewer humans. Whether the topic was engineering hiring, offshoring decisions, productivity tooling, IDE wars, or methodology debates, the shape of the conversation was always the same. Making the code was the expensive part.

That equation is now inverted.

Agents produce code in seconds. Over a weekend, a working codebase can materialize. A non-trivial feature can be delivered before lunch. The marginal cost of code is approaching the marginal cost of tokens and electricity. This is not a forecast. It is what is happening right now, on the teams that have already absorbed it.

When the cost of producing something collapses, the bottleneck always moves to whatever was next in the value chain. That is not a tech observation. That is economic physics.

So what is next in the value chain?

The expensive thing now

Trust. Specifically, the justified confidence that what the agent produced is what you actually wanted.

The agent’s output compiles. It passes the tests the agent also wrote. Neither of those facts tells you whether the code does the thing the business asked for, under the conditions the business cares about, in a way the next engineer can maintain. That is a different question entirely, and nothing in the agent’s output answers it.

“Trust is a word you seldom hear from us, hustlers we don’t sleep we rest one eye up.”

The hustler’s posture is the right posture for this moment. One eye up. Trust is scarce, and the people who treat it as scarce build differently than the people who treat it as free.

Why trust is structurally expensive

There are three reasons, and each of them carries weight.

Trust requires a referent. You can only verify something against something else. If the specification of what you wanted lives in someone’s head, or in a Teams thread, or in an ADO backlog item written at 4 PM on a Friday, there is nothing to verify against. The agent’s output becomes the only artifact in the room, and an artifact cannot verify itself. The team reading the pull request is not reviewing the work. They are reviewing the code. Those are not the same thing, and the difference is exactly where trust goes to die.

Trust requires precision. Vague specifications produce code that technically satisfies them and practically does not. I have watched this failure mode survive every methodology our profession has thrown at it. The clearest version of it came out of the globally distributed development era, and I saw it from a particular angle. I spent years being brought in as a turnaround specialist to right the ship after an offshoring engagement had gone sideways. The pattern was almost always the same. The agency had delivered, in good faith, precisely what the requirements documents said. The customer had rejected the work because it was not what they actually wanted. The agency ate the cost of correction. Sometimes they ate it twice. Sometimes the customer was lost regardless. I wrote about the broader fidelity problem in 2009 in Architectural Fidelity with Globally Distributed Software Development Teams, focused there on how vision and architecture get lost in the handoff to distributed teams. The deeper pattern beneath that piece is the one I keep coming back to: intent gets lost in the gap between what the human wanted and what the executor produced. That gap did not close. Agents have not closed it either. They have industrialized it.

Trust requires a closing mechanism. This is the part most teams have not yet internalized. Specification alone does not close the loop. You need an artifact that converts the specification into something that can be evaluated against the agent’s output. Without that conversion, the specification is decoration and the verification is vibes. A PRD is not a closing mechanism. A user story is not a closing mechanism. Acceptance criteria written in narrative prose at the bottom of a ticket are not a closing mechanism. They are input to a closing mechanism that most teams have never built.

What blockchain learned the hard way

If you want to see what happens to a discipline when the specification is sloppy and the executor is unforgiving, look at smart contracts.

Back when I was writing Ethereum smart contracts, I had to be acutely aware of the spec. Real money was on the line. The wrong code was a gateway for the internet to rob you. Hackers, or merely industrious engineers, would read the code, remember that code is law, and decipher exactly how to leverage weaknesses to enrich themselves at your expense. Imprecision was not a quality problem. It was a theft vector.

The most consequential demonstration of that fact happened in 2016. An attacker exploited a recursive-call vulnerability in The DAO, a high-profile smart-contract investment vehicle on Ethereum, and drained roughly 3.6 million ETH, about $60 million at the time. The community split over what to do. The purists argued that the attacker had done nothing wrong: the contract’s own logic permitted the withdrawal, code is law, and the executor had executed exactly what was specified. The pragmatists argued for a hard fork to reverse the theft. The fork happened. The chain that reversed it became Ethereum. The chain that refused to alter history became Ethereum Classic.

That story is the cleanest case study our industry has of what happens when the code is the spec.

Some people argue that AI-augmented engineering should work that way. Let the agent produce the code, then read the code to understand the intent. The DAO is the counterargument. The code did exactly what it said. What it said was not what the humans wanted. The reason this failure mode exists, and will continue to exist, is that code is optimized for machine understanding and natural language is optimized for human understanding. The spec has to live in a medium where the humans can read it, argue about it, and agree on it before the machine ever runs.

This is where structured natural language earns its keep. But that is the argument for a later article. The point here is more narrow. The executor will execute exactly what you specified. The cost of imprecision falls on the human, not the machine. That was true on Ethereum in 2016. It is true on every team running agents in 2026.

The trust loop

Here is the line that the rest of this series will defend.

The loop closes when the specification of intent is also the verification of output.

The loop closes when the artifact that says what the agent should do is the same artifact that tests whether the agent did it. That happens only when intent and verification are the same document.

Most teams already have half of this loop. They write user stories. They write acceptance criteria. They sometimes write them well. What almost no team does is convert those criteria into executable specifications before the agent ever runs. The criteria sit in the backlog. The agent writes the code. A human reviews the code. The criteria are consulted, if at all, as advisory documents. The loop never closes.

That is the gap. That is where trust gets expensive. And that is the gap a closing mechanism fills.

What this means on Monday

The team that figured this out a year ago is already pulling ahead. The team that figures it out this year will be fine. The team still measuring shipped features per sprint as the leading indicator of engineering productivity is going to wake up in eighteen months wondering why their codebase tripled in size while their reliability halved.

Three shifts are coming, whether the industry names them or not.

• Shipped features per sprint will be repriced as a vanity metric. The leading indicator that matters is how much of what we shipped can we actually verify.
• Pull-request review will be repriced from a code-quality activity to an intent-verification activity. The question on the reviewer’s mind is no longer is this code well-written. It is is this code what we asked for, and how do I know.
• The artifacts that close the trust loop will be repriced from QA-team concerns to load-bearing engineering deliverables. The team that owns the closing mechanism will be the team that owns the trust.

The agent will give you exactly what you specified.

The cost of imprecision falls on the human, not the machine.

This article argued that trust is now the expensive thing. The next article argues why the disciplines that produce trust, the craftsmanship disciplines most of the industry has been quietly deprioritizing for a decade, are about to be repriced harder than anything else in this profession.

Further reading: ”Architectural Fidelity with Globally Distributed Software Development Teams.” Walter Pinson, 2009. Article 1 of this series, ”Gherkin May Be the Most Consequential Language of the AI-Augmented Era.” Article 3, ”The Progression Nobody Finished.”