Volume Is Free Now. Judgment Is the Whole Game.

For eight years I was the most prolific engineer at a company I helped build. I'm now convinced that was a failure, not an achievement — and it taught me where engineering value actually lives.

By Jason Waldrip, with Claude Opus 4.8

By the time I left, I’d written something like one in five commits in the company’s entire history. Eight years, the most of anyone, by a wide margin. For a long time I wore that like a badge. I’ve since decided it was the clearest symptom of a problem I should have fixed years earlier. And the problem is about to get a lot more common, because the thing I was good at just became free.

There was no hour of the clock that didn’t have my name on a commit. Better than a quarter of them landed after 7pm; plenty at 2 and 3 in the morning. I touched nearly every part of the codebase: the app, the libraries, the infrastructure, the build system, the deploy path. If something broke at 11pm, I fixed it before standup. I told myself this was dedication. What it actually was, was a bus factor of one dressed up as a work ethic.

The volume trap

Here’s the trap, and I walked straight into it: output feels like value. Commits, lines, features shipped, fires put out at midnight. All of it is visible, countable, and deeply satisfying. So you optimize for it. You become the person who can produce the most, fastest, across the most surface area. And because you can, you do, and the org happily lets you, because why wouldn’t it.

The problem is that you’ve made yourself the load-bearing wall. The more you produce, the more the system depends on you specifically, and the less anyone else needs to understand. Your productivity becomes the org’s fragility. I was a fifth of the company’s commits not because I was five times better than anyone, but because the system had quietly arranged itself so that the foundation ran through one person. That’s not a win. That’s a single point of failure with a green contribution graph.

I was a fifth of the company’s commits. That’s not a trophy. It’s a single point of failure with good PR.

And then the floor moved

For my entire career, producing code was the bottleneck. Hiring was about adding hands. Velocity was a headcount problem. The whole industry was organized around the scarcity of people who could write working software fast.

That scarcity is gone. An agent will write you a few dozen well-formatted, plausible commits a day, all day, without coffee or ego. The thing I spent a decade getting elite at, producing a lot of correct code quickly, is now something you rent by the token. Volume has been commoditized. If your value, or your company’s, is measured in output, you’re now competing with a machine that out-produces you and never sleeps, and you will lose that race.

Judgment is the moat

What an agent can’t do, yet, and I’d argue structurally, is hold the map. It can’t tell you which problem is a “move fast and break things” problem and which one is a “slow down, this is load-bearing” problem. It goes fast at both. It doesn’t know which clean-looking diff is quietly wrong, because it has no model of why the system is the way it is. It will confidently pave a road straight off a cliff and report success.

That discernment (knowing what’s worth building, what’s dangerous to touch, what “done” actually means, when the plausible answer is wrong) is judgment, and judgment is the thing that didn’t get commoditized. It got more valuable, because now it’s the scarce input. The engineer’s job just moved from producing to directing: fewer people, each steering a fleet of tireless producers, each responsible not for how much they typed but for what they caught and what they refused to ship.

This is the part people get wrong about AI and engineering. It doesn’t replace the person with the map. It’s a force multiplier on judgment, and a multiplier is only as good as what you multiply. Multiply great judgment by a fleet of agents and you get something genuinely new. Multiply no judgment by the same fleet and you get a beautifully formatted disaster, faster. Anything times zero is still zero.

The train can only go as fast as its tracks

I’ve said this so many times my team could finish the sentence: the train can only move as fast as the tracks it’s built on. In the agent era it’s not a nice metaphor anymore, it’s the whole strategy. Agents are a faster engine. Dramatically faster. But a faster engine on bad track doesn’t get you there sooner. It derails sooner.

The faster you can generate code, the more load your foundation has to bear: your tests, your CI, your deploy path, your guardrails, your ability to verify that a thing actually works. Cheap generation doesn’t reduce the need for a strong foundation. It’s the single biggest argument for one. The companies that win the next decade won’t be the ones generating the most code. They’ll be the ones whose tracks can survive the new speed.

How it actually fails: not with a bang

The failure mode I’d warn every leader about isn’t dramatic. Nobody dies in an outage. You die by entropy. The agents keep the lights on. The demos work. The line on the dashboard stays up. But quarter over quarter the code drifts further from anyone’s actual understanding. Decisions get made by whoever’s least wrong in the room. And one day a “simple” change takes three weeks, because nobody alive knows why the thing was built the way it was, and the only one who did was a person (or a model) nobody bothered to ask the right questions of.

It’s invisible right up until it’s expensive. Which is exactly why it’s the one to design against now, while it’s cheap.

So what do you actually do

If output is commoditized and judgment is the moat, the work reorganizes around that. In priority order, not on a timeline, because the sequence matters more than the calendar:

1. Get the map out of people’s heads. The cross-system context that lives in one senior engineer’s skull is your biggest risk and your most valuable asset. Externalize it: architecture docs, decision records, runbooks, written intent. The infrastructure you need to survive losing someone is the infrastructure that lets agents be useful in the first place. Build it before you need it.
2. Make agents the volume layer and humans the judgment layer — on purpose. Stop measuring engineers on output; the machine wins that and the metric is now meaningless. Measure them on what they catch, what they decompose, and what they have the taste to reject.
3. Kill every bus-factor-of-one. No system gets exactly one person who understands it. Two humans know it, or it’s documented well enough that a mid-level engineer and an agent can own it together. That, precisely, is what surviving any departure means.
4. Overinvest in the tracks. Tests, CI, deploy, verification. This is the line item everyone underfunds and the one that decides whether speed helps you or kills you. A faster engine makes a strong foundation more important, not less.
5. Make verification the core competency. When generation is free, the scarce, valuable skill is proof: does this actually work, end to end, the way a real user will hit it? Not “the tests are green.” Knowing what’s true is the whole job now.

The optimistic part, and I mean it

This sounds like a eulogy for the engineer. It’s the opposite. This era is more forgiving than the one it replaced, if you orient to it correctly. A small, judgment-dense team pointing agents at the right problems will outrun a large team of people typing, every time. The winners won’t be the orgs with the most engineers. They’ll be the ones that figured out the job changed: from how much you can produce to how well you can direct, verify, and decide.

And the personal version of the same truth is the one I keep coming back to: judgment travels with the person who has it. The map lives in a head, not a repository. Whatever I build next, that’s the asset I’m bringing, and unlike a fifth of someone’s commit history, it’s portable.

I spent eight years proving I could be the engine. The lesson I’m taking forward is that the engine was never the hard part. Build the tracks.