The Verifier’s Dilemma II: The End of Coding

Writing code has long been a visible cost of software engineering. The bricklaying analogy is useful: a design still has to be built. But typing was never the only constraint. Understanding the problem, choosing the structure, and checking the result all take time.

The release of GPT-4 made the change in code generation difficult to ignore.

Tools like Supabase and Vercel supply much of the infrastructure. AI agents can generate glue code, connectors, and application logic quickly. That reduces some of the work of construction. It does not remove the work of engineering.

You can build a convincing prototype in an afternoon. Whether anyone should depend on it is a different question.

In my previous research, I introduced Verifier's Law: AI is easier to deploy responsibly when its output is easier to verify. It is a working heuristic, not a mathematical law.

I find this heuristic particularly useful in software engineering.

The Trap: Dark Technical Debt

As argued in the original Verifier's Dilemma, when the cost of generating content approaches zero, the cost of verifying it remains stubbornly high.

Suppose an AI agent generates a large module in seconds. The engineer faces a choice. They can spend time checking its assumptions and behavior, or they can glance at it, see that it "looks right," and merge it.

The pressure to take the second path is real.

I think of this as mispricing risk. In software, I call it Dark Technical Debt. By skipping verification to maintain velocity, we risk building systems faster than we can understand them. Less friction in creation can leave more debt in verification.

The Solution: Defensive Orchestration

How do we escape the Dilemma?

The default response has been "prompting better." But prompting alone is not an enforcement boundary. Critical systems require covenants, telemetry, and the ability to survive errors.

We collaborate by containment. I find Defensive Orchestration useful here: three disciplines for treating the agent as a bounded subsystem whose failures we must anticipate.

Discipline 1: The Principle of Prior Constraint

The Failure Mode: Without clear constraints, a model can produce plausible code that misses the requirement. It may fill gaps with assumptions the engineer never intended.

The Fix: Write the constraints first. Do not stop at "Build a login page." Provide tests for the required behavior, including rejection cases and access controls.

The Effect: The agent has a more concrete target. The tests help define it, but their coverage still needs review.

Discipline 2: The Principle of Observable Failure

The Failure Mode: Humans are weak verifiers at scale. We glaze over boilerplate. Inspection does not scale; instrumentation does.

The Fix: Operational observability. Alongside "Is this code correct?" ask, "Which failures will the monitoring system detect, and what will happen when it does?"

Concrete Example: If an agent writes a SQL query, enforce a database statement timeout and suitable result limits. These can bound some failures. A row limit alone does not bound computation, and a database timeout cannot stop an infinite loop elsewhere in the application.

Discipline 3: The Law of Total Liability

The Failure Mode: Diffusion of responsibility. When an agent writes the code, engineers feel like "babysitters" rather than owners, leading to a "check-the-box" review mentality.

The Fix: Authority and responsibility should remain aligned. The team deploying the system must own the decision and its consequences. Using an agent does not transfer that responsibility.

Concrete Example: Restrict the agent to a review branch. Require an authorized human approval before production release. The permission boundary makes responsibility explicit; the quality of the review still matters.

The New 10x: From Laborer to Allocator

For the last decade, Silicon Valley has worshipped the "10x Engineer" - the mythical creature who could type ten times faster and hold ten times more context in their head.

AI makes generation speed a less useful measure of engineering value. When code can be produced much faster than it can be reviewed, the scarce skill is deciding what should be built and whether it can be trusted.

So, what is the new 10x?

The 10x Engineer of the AI Age is not a super-writer. They are a Super-Verifier.

They understand that their job includes both creation and governance. The number of PRs merged matters less than the assumptions checked, the failure modes understood, and the controls built to contain them.

This transition asks something of engineers who enjoy the flow of writing code. I do not think we need to abandon that work. We need to give verification the same attention we give construction.

The constraint shifts from how quickly we can produce code to how clearly we can specify, inspect, and operate it.

Build quickly. Verify deliberately.