Verification-maxxing

For decades the industry quietly believed that writing code was the slow part of building software. It wasn't. Give an experienced engineer a clear specification and the implementation was usually the straightforward part — testing and deployment had working automation years ago. The drag lived upstream: deciding what to build, agreeing on requirements, and surviving the design rituals where weeks vanished into workshops and "back to the drawing board." Mohamed Hassan puts it bluntly: the hardest part of building software was never the coding, it was deciding what to build in the first place.

This matters because it tells you exactly which constraint generative AI relaxed. AI didn't just make implementation faster — it hit the front of the lifecycle, the part that was always slowest, by turning rough goals into draft requirements, user flows, and a testable prototype in an afternoon. The output stops being another document nobody reads and becomes something users can touch. The feedback loop tightens. You learn faster.

But relaxing the upstream constraint exposes a new one. Once an agent can produce roughly 80% of a feature in minutes, the scarce resource is no longer typing speed or algorithmic recall. It is judgment: knowing what to ask for, and knowing whether what came back is actually right. The syntax tax — the price you paid to compress human intent into something a parser would accept — is collapsing. A verification tax took its place, and the rest of this piece is about how to pay it without going broke.

Andrej Karpathy coined "vibe coding" in February 2025 and by early 2026 was already calling it passé, proposing "agentic engineering" at Sequoia's AI Ascent. The rename wasn't marketing. "Vibe" had become a suitcase word stuffed with everything from a weekend hack to a disciplined, agent-driven production workflow — and, as Osmani notes, telling a CTO you're "vibe engineering" their payment system tends to produce a visible flinch.

The useful way to read the landscape is as a spectrum of how much structure surrounds the model's output. Vibe coding is an attitude toward verification: optional. Agentic engineering puts the model inside a scaffold of specs, tests, and feedback loops. Crucially, you can do either with the exact same agent and model — the difference is the discipline around it, not the tool.

The trap is treating speed as a free upgrade. Vibe coding is the right gear for exploration and the wrong gear for production — and teams that keep the boundary blurry end up shipping prototypes by accident.

There is a strong temptation, when adopting AI tooling, to treat the model as the system. A newer model arrives and the agent gets smarter; an older one and it gets worse. The model becomes the explanation for everything. That intuition leads to the wrong investments.

The whitepaper's framing is cleaner: the model is one input into a running agent. Everything else — the prompts, the tools, the rule files, the test runners, the observability layer — is the scaffold (the paper also calls it the harness): the machinery that gives the model state, feedback, and constraints.

How much does the scaffold actually move the needle? Public benchmarks make it concrete. On Terminal Bench 2.0, one team moved a coding agent from outside the top 30 into the top 5 by changing only the scaffold — no model change. A LangChain study lifted an agent's benchmark score by 13.7 points by tweaking only the system prompt and middleware around a fixed model. Examined honestly, most agent failures are scaffold-configuration failures wearing a model's clothes.

A practical scaffold starts as a single rule file at the project root. It is not prompting — it's operating instructions, written once, paid forward into every future session:

The developer who writes this spends about an hour. Every subsequent agent interaction in that project inherits the hour. It compounds — which is exactly the property the model alone does not give you.

Prompt engineering asks: how do I phrase this question to get a smarter answer from the model? It optimizes a single turn. Context engineering asks a different question: what would a new team member need to know to contribute correctly to this project, and how do I encode that in a form the AI can use? It optimizes the whole session — and when context persists across sessions, every future session too.

Six kinds of context matter in any agentic workflow:

The practical heuristic, hard-won: a rule should be short, specific, and paired with a concrete example of the behaviour you want. Rule files that are too broad don't help; rule files too verbose don't fit efficiently. And there's a cost dimension most people miss — the distinction between static and dynamic context is an architectural decision, not a detail.

Static context (rule files, system instructions) is always loaded: every token is paid on every model call, relevant or not. Dynamic context (tool results, retrieved docs, windowed history) loads on demand and costs only when the information is actually needed. The most effective pattern for managing the dynamic side is portable, structured packages of procedural knowledge — "skills" — that the agent loads only when a task matches: lightweight metadata at startup, full instructions on match, deep reference material only when explicitly needed.

Velocity — how fast can we write code? — is the wrong metric for a leader. The right one is total cost of ownership, and in the AI era a large share of that cost is dictated by the token economy. Reframed as capital versus operating expenditure, the two ends of the spectrum invert each other.

Vibe coding is low CapEx, high OpEx. The barrier to entry is essentially zero — a subscription and a few prompts. But the operating cost compounds: a token burn rate from dumping unstructured files into context and repeatedly asking the model to fix its own unverified mistakes (an expensive prompting loop with low first-pass success); a maintenance tax when a bug surfaces six months later in code nobody structured; and security remediation, where rapid generation without an evaluation harness means rapid generation of vulnerabilities.

Agentic engineering is high CapEx, low OpEx. You pay upfront — designing API schemas, building deterministic test suites, structuring the agent's context — before a line of production code is generated. In return, the marginal cost of shipping and maintaining each feature drops, because the agent operates inside a governed factory and its output is structurally sound, pre-tested, and aligned with your standards.

This reframes context engineering as a financial lever, not just a craft skill. LLMs charge for every token you send; passing an entire 100,000-token repository into every prompt is financially unviable at scale. A dense, high-signal payload — a precise rule file plus architectural guardrails — raises first-pass success and kills the trial-and-error loops that quietly drain the budget.

The same logic powers intelligent model routing. Vibe coding leans on a single frontier model for everything — paying premium token prices to fix a typo or generate a basic unit test. A well-designed factory routes complex work (requirements, architecture, initial implementation) to large models, and deterministic, low-complexity work (test generation, code review, CI monitoring) to smaller, cheaper, faster ones. Orchestrating a multi-model ecosystem holds output quality while systematically driving operating cost down.

The fair criticism of AI tools was never that they produce bad code. It's that experienced developers using early tools were, under controlled conditions, measurably slower on complex tasks. In July 2025, METR found that sixteen seasoned open-source contributors — working on repos averaging 22,000 stars — took 19% longer with AI tools, while estimating they'd been 20% faster. The gap between perception and reality wasn't a rounding error. It was a full reversal of sign.

Resist the urge to over-read it in either direction. METR's February 2026 follow-up complicated its own finding: heavy AI adopters had systematically refused to participate in the no-AI control condition, even at $50/hour, biasing the sample. Their revised, refreshingly honest conclusion: "We do not know if AI makes developers more productive."

This is the verification tax made measurable. Unstructured AI assistance was slower because it added verification overhead without removing specification overhead. Agentic engineering earns its keep only when the upfront investment in spec, scaffold, and tests means the AI's implementation replaces genuinely slower human implementation rather than piling on top of it. The payoff arrives in the second sprint, not the first — which is precisely why teams under deadline pressure find it counterintuitive and skip it.

The mental model that ties this together is the factory. A factory manager doesn't assemble each widget by hand; they design the assembly line and own quality control. In the new SDLC the developer's primary output is not code — it's the system that produces code: the specs, the agent configurations, the test suites, the feedback loops, the guardrails. Within that frame, the work splits into two modes most developers move between in a single day.

The orchestrator mode is where the leverage is, but it's also where the trap is. You cannot delegate an implementation you haven't specified. Treat AI tooling as a shortcut to avoid specification work and you produce, once again, prototypes that ship by accident.

None of this requires a platform purchase. It requires a change in where you spend attention.

Step back far enough and the pattern predates every modern framework. In the 1950s the bottleneck was hardware; in the 1970s, languages; in the 1990s, networking; in the 2010s, infrastructure. At each transition the skills that mattered most shifted, and a new, larger population gained the ability to build what had needed a smaller, more specialized group.

Every abstraction layer made the skills below it less central. Writing assembly mattered less once C arrived; knowing TCP/IP details mattered less once frameworks abstracted the network. And in every case, the engineers who treated the new abstraction as a threat were right that their specific skills would matter less — and wrong that they would matter less. The abstraction raised the ceiling on what a skilled engineer could build, every single time.

We're at that inflection again. The syntax tax isn't fully gone, but it's low enough that the verification tax is now the dominant cost. The bottleneck is no longer implementation capacity; it's specification quality, architectural judgment, and the ability to evaluate whether a system that can generate enormous volumes of code is generating the right enormous volumes of code.

So the honest summary is narrow and useful: the factory model, the conductor–orchestrator split, context engineering — these are not replacements for engineering skill. They're the next abstraction layer, and the developers who learn to work at it will build things the ones who stay below it simply cannot. Generation is solved. Verification, judgment, and direction are the new craft — and learning to pay the verification tax deliberately, rather than letting it accrue as debt, is the whole game.