Hey everyone.
Picture this. You ask a coding agent for a small feature. Ten minutes later you’ve got a tidy pull request, tests green, diff polished enough that it almost feels rude to question it. You merge. Ship. Coffee’s still hot.
Then, two weeks later, someone asks why billing now reads the ledger database directly instead of going through the API you all agreed on last quarter. The change “worked.” The tests never saw the boundary. Nobody fully owned the rationale. Welcome to the bill you didn’t see on the receipt.
That bill has a name lately: the verification tax.
Generation got cheap. Trust didn’t.
Coding agents (tools that can plan, edit across files, run tests, and open PRs) are having a moment in late 2026. Assistants waited for your next prompt. Agents will happily keep looping. Useful? Absolutely. A replacement for software engineers? Not even close.
Software engineering was never “type until it compiles.” It’s designing solutions under constraints: correctness, security, operability, cost, team conventions. AI is one powerful tool in that toolbox, like a very fast junior teammate who never gets tired and occasionally invents an API that doesn’t exist.
The economics flipped. Producing lines of code is cheaper than it’s ever been. Understanding those lines, checking them against the system you meant to build, and keeping the architecture honest still costs human attention. That leftover cost (review, debugging, “wait, should this even be structured this way?”) is the verification tax.
DORA’s research on AI-assisted software delivery has been pointing at the same shape for a while: more AI use can raise throughput and delivery instability if the rest of the pipeline doesn’t grow up with it. Their later ROI framing even lists the verification tax as one reason teams hit a temporary J-curve dip before value shows up. Generation accelerates; merge queues and review capacity don’t magically expand.
Green CI is not a personality test
Here’s the analogy I use with students.
Ordering pizza is easy. Eating it is easy. Deciding whether that pizza belongs on the table at a formal dinner, with the right plates, guests, and allergies accounted for, is the judgment call.
Tests ask: does this behavior match what we asserted? Great question. Incomplete question.
An agent can satisfy every unit test you gave it and still:
- duplicate an abstraction you already had three modules over
- punch through a layer boundary nobody encoded as a machine-checkable rule
- handle the happy path fluently and shrug at the failure mode you’ll meet at 2 a.m.
- leave behind code nobody on the team can explain with confidence
I’ve been teaching and building long enough (closing in on two decades) to remember when “it compiles” was the joke milestone. “The agent’s tests passed” is the new version of that joke. Local correctness is not the same as system intent.
Practitioner write-ups on the verification tax make this concrete: architectural drift often arrives as a series of individually reasonable diffs. Each one looks fine. Together they quietly rewrite how your system is supposed to be shaped, because the important constraints lived in a wiki, a Slack thread, or someone’s head, not in anything the pipeline could reject.
What actually reduces the tax (without banning the tools)
Andrew Ng’s recent note on using coding agents effectively matches what I see in the classroom and in practice: the winning loop still looks a lot like engineering (plan and spec, execute with calibrated autonomy, verify, deploy, monitor), with humans spending more energy on what to build and whether the output is right. Social media loves the “let it cook for six hours and burn a mountain of tokens” story. The practical wins are usually iterative, supervised, and judgment-heavy.
If you want a concrete playbook that scales from beginner labs to production teams:
1. Spec before you sprint the agent.
Ambiguous prompts are expensive. Write the contract: what must happen, what must never happen, how you’ll know (tests, examples, resource limits). Vague intent leads to confident wrong code. That’s not the model “being evil.” That’s you outsourcing judgment without writing it down.
2. Make verification match the risk.
Toy script? Light touch. Auth, money, data deletion, production config? Human eyes, plus automated gates that don’t care how persuasive the commit message sounds. Separate “worker” from “verifier” when you can. Don’t let the same agent grade its own homework.
3. Encode architecture where machines can see it.
Linters and unit tests catch a slice. The expensive slice is intent: allowed dependency directions, “this service talks to that one only via X,” secrets never in logs. Turn the decisions that hurt when violated into checks that fail the change before the PR becomes a social negotiation.
4. Prefer small, verifiable increments.
Agents thrash less when the task is bite-sized and the done-condition is executable. Big open-ended missions invite context drift and repair loops that eat the time you thought you saved.
5. Keep your fundamentals sharp.
Debugging, reading diffs, designing tests, reasoning about failure modes: these skills get more valuable when output volume explodes. If you can’t tell good structure from Lego dumped on the floor, the agent will happily help you build a taller pile.
For beginners and for people who’ve shipped for years
If you’re learning: use agents as a tutor and a pair, not as a substitute brain. Ask them to explain. Re-implement the hard parts yourself. Treat every accepted suggestion as something you should be able to defend in office hours.
If you’re senior: your leverage moved upstream. Architecture, specs, review standards, harness rules, and teaching the team what “done” means. That’s the work agents amplify. The tax isn’t an argument against AI. It’s a signal to invest in the layer that makes speed sustainable.
Programming is a skill. Software engineering is solving real problems with software under real constraints. AI sits in the toolbox. The engineer still owns the outcome.
Wrap-up
Hi, I’m Robert Massey, software engineer and computer science professor. If this framing helped, or if you’ve got a war story about a “perfect” agent PR that wasn’t, drop it in the comments. I share more practical engineering-with-AI talk on AttuneIT. Support the shenanigans on Patreon or buy me a coffee, and follow AttuneIT on YouTube, X, and Facebook. Let’s make tech less scary and more awesome.
Keep building carefully.