My Engineers Don't Hate Building Software. They Hate Testing It.

If you have run an engineering org, you know the line is true before you finish reading it. Nobody got into this work to write software. They got into it to build things. Building is the part with leverage, momentum, the satisfaction of watching an idea become a running system. Testing is the tax. It is the part where progress stops feeling like progress and starts feeling like proving a negative to an audience of skeptics, most of whom are your own future selves at 2 a.m.

So engineers do what humans do with a tax they resent. They minimize it. They write the happy-path test, skip the messy integration case, mark the flaky suite as "known flaky," and ship. Not because they are reckless. Because the validation work is structurally worse than the building work: slower, less creative, less rewarded, and never done. The codebase grows linearly. The space of things that could break grows combinatorially. The gap between what you built and what you can vouch for widens with every release.

That gap is the real bottleneck. Not velocity. Not headcount. The distance between "it's built" and "I can prove it's safe to ship."

For a long time you could paper over this with discipline. A strong testing culture, a respected QA function, a release manager who said no. Those mitigations assumed something that is no longer true: that a human wrote most of the code and could, in principle, reason about it.

That assumption is gone. Roughly 41% of codebases are now AI-generated. Code arrives faster than any team can read it, let alone reason about its second-order effects. And it arrives carrying risk: industry research puts the share of AI coding tasks that introduce a critical flaw or security issue near 45%. Generation got nearly free. Validation did not get cheaper at all. If anything it got harder, because the thing you are validating was authored by a system that does not understand your threat model, your data boundaries, or how a change to one service ripples through forty others.

So the resentment my CTO friend described is no longer a culture problem you can fix with a brown-bag talk about test coverage. It is a structural mismatch. You have machine-speed authorship feeding into human-speed validation, and the queue between them grows without bound. The cost of poor software quality is estimated at around $2.41 trillion. That number is not abstract. It is the aggregate of every incident, breach, and rework cycle that flows from shipping changes nobody could fully vouch for.

Here is the part that turned a complaint into a conviction. When validation is friction without leverage, people route around it. Roughly 80% of developers bypass policy or guardrails. Read that as the verdict, not the crime.

A guardrail that gets skipped four times out of five is not a guardrail. It is theater that produces a paper trail and a false sense of safety. And the standard response to that finding is exactly wrong: add another scanner, another gate, another required check. Each one adds friction. None adds leverage. You are taxing the part of the job your engineers already hate, and acting surprised when they evade the tax more aggressively.

The engineers are not the problem. The architecture of validation is the problem. We bolted controls onto the outside of the work, made them slow and noisy, and disconnected them from any understanding of what a given change actually touches. Of course they get bypassed. They were designed, accidentally, to be bypassable.

Sit with the original complaint long enough and it inverts. Engineers don't hate testing. They hate the version of testing we built for them:

What engineers actually want is the opposite. They want validation that keeps pace with the system, scopes itself to what changed, and hands them a defensible answer instead of another inbox. They want the tax to become infrastructure. That reframing is the whole thesis: the missing piece is not a better model or another point tool. It is a control layer that owns the question of what is allowed to ship, and answers it with evidence. That is the case I make in detail in why AI is missing a control layer, not more models.

If the failure mode is human-speed validation behind machine-speed authorship, the fix is to make validation itself a governed, continuous system rather than a manual chore. Concretely, that means a few capabilities most stacks have never had in one place.

The mechanism that ties these together is a closed loop: understand the system, test against it, reproduce what fails, remediate under governance, verify the fix held. Run that loop continuously and the thing engineers hated stops being a manual tax. It becomes a property of the platform they build on.

There is a sharp, measurable version of this leverage. Reachability-based prioritization, asking whether a flagged vulnerability is actually reachable in your system, can mean 70 to 90% less exploitable exposure to triage. But reachability is only as good as your map. A scanner without system context guesses. A control layer that already maintains a live dependency graph answers reachability as a native query and carries that judgment into the release decision. The smartest validation gets smarter on shared context.

You do not need to rip out your stack to start. You need to change what owns the part your engineers hate.

Consider a hypothetical fintech team merging forty AI-assisted PRs a day across tangled services. A sixth scanner gives them a sixth queue and a sixth thing to bypass. A control layer above the stack gives them one scoped answer per release, with a signed record of the call. That is the difference between taxing the work they hate and removing it.