AI removed the execution bottleneck. The differentiator is no longer building fast. It is knowing what to build, when to stop, and whether the output matters.
The other 9 worked. They passed tests, cleared code review, deployed without errors. They just didn't matter. Nobody used them. Nobody needed them. They were well-executed answers to questions nobody asked.
That 25% hit rate wasn't a productivity problem. It was a judgment problem.
For a decade, the constraint was building. Could you write the code? Could you write it fast enough? Could you ship before the market moved?
AI coding agents dissolved that constraint. Code generation, testing, debugging, code review. All automatable. A single builder with the right systems produces output that matches a mid-size team.
Old bottleneck: execution
Can you write this code?
Can you write it fast enough?
Can you test it thoroughly?
Can you ship before the deadline?
New bottleneck: judgment
Should you build this at all?
Is this output actually correct?
Does this solve the real problem?
When should you stop and ship?
The shift is structural, not about particular tools getting better. The economics of execution changed permanently. Code is approaching commodity. Judgment isn't.
What Replaced It
When building is cheap, the cost of building the wrong thing drops to near zero in effort. But the cost stays high in every other dimension: user confusion, maintenance burden, architectural debt, opportunity cost.
The bottleneck moved from "can you build it?" to three harder questions:
1. Should you build it?
Every feature has a carrying cost. It lives in the codebase, needs tests, interacts with other features, creates expectations. When execution was expensive, the cost of building acted as a natural filter. If something took two weeks, you thought carefully about whether it was worth two weeks.
When execution takes two hours, that filter disappears. Everything feels worth trying. The result: you ship 12 features instead of 3, and the 9 you should have skipped are now live, consuming attention, creating bugs, and diluting the product.
2. Is this output actually good?
AI agents produce plausible output. That's the whole problem. The code compiles, the tests pass, the feature appears to work. But plausible isn't correct, robust, or what the user needed.
Evaluating plausible output is harder than evaluating obviously broken output. Broken code announces itself. Subtly wrong code ships to production and fails quietly, three months later, in an edge case nobody tested, under load nobody simulated.
3. When should you stop?
Infinite execution capacity makes "just one more feature" the default. There's always something to add. The agent is ready. The marginal cost is low. The temptation is constant.
The discipline to stop, to declare a scope complete and resist the pull of one more improvement, is a judgment call that no automated system makes for you.
Automated Bad Judgment
Scale execution without scaling taste and you automate your worst instincts.
Without a judgment layer between "idea" and "agent," every half-formed thought becomes a shipped feature. The pipeline has no filter. The agent doesn't push back, doesn't ask "is this worth building?" It implements faithfully, including the bad ideas.
The data backs this up. Research from early 2026 shows that AI-generated code produces 2.74x more security vulnerabilities than human-written code. Not because the AI writes worse syntax, but because the humans directing it skip the evaluation step. They accept output without reviewing it critically. They trust plausibility over correctness.
That's not a tooling problem. It's a judgment problem.
The pattern scales beyond security. Move fast, skip review, ship everything the agent produces, and you get:
Features nobody asked for, now requiring maintenance
Architectural decisions made by momentum, not analysis
Technical debt compounding at the speed of generation, not the speed of understanding
Products that grow wider but not deeper
Velocity without judgment is just organized waste.
The Spec Is the Product
When execution is cheap, the spec becomes the highest-leverage artifact.
A spec isn't a planning document. It's a judgment artifact. It captures decisions: what you're building, what you're not building, what "done" means, and what would make this feature not worth building.
Without specs
Idea goes straight to implementation
Scope discovered during coding
Done means 'the agent stopped'
No kill criteria—everything ships
Judgment happens retroactively (or never)
With specs
Judgment captured before code exists
Scope defined with acceptance criteria
Done means 'ACs pass and gates are green'
Kill criteria defined upfront
Judgment is reviewable, challengeable, improvable
The spec forces you to answer the hard questions before the agent starts. That's its entire value. Not planning, filtering.
A good spec includes kill criteria: conditions under which you abandon the feature. "If this requires more than N database migrations, it's not worth the complexity." "If the API response time exceeds Xms, the approach is wrong." These are judgment calls, written down, before the sunk cost of implementation makes them harder to make.
Without kill criteria, everything ships. With them, the 9 useless features get caught before they consume a month of carrying cost.
Coding speed, how fast you produce code, is now the agent's job. Review speed, how fast you evaluate whether that code is correct and necessary and good, is your job. And it's the actual constraint on quality.
Skill
Who Handles It
Bottleneck?
Code generation
Agent
No
Test writing
Agent
No
Debugging
Agent
No
Code review (syntax, patterns)
Agent
No
Deciding what to build
Human
Yes
Evaluating correctness
Human
Yes
Recognizing "good enough"
Human
Yes
Killing bad ideas early
Human
Yes
Review speed is trainable. It compounds with experience, not typing speed or tool mastery, but the accumulated ability to look at output and know whether it's right. Whether it handles the edge case that will surface at 3x scale. Whether the abstraction will hold when requirements shift.
The builders who compound are the ones who evaluate faster and more accurately. Not the ones who ship more.
How to Build Judgment
Judgment isn't a personality trait. It's an operational practice. Specific mechanisms make it concrete:
1. Specs With Kill Criteria
Every feature starts with a spec that includes conditions for abandonment. Not just what you're building, but what would make it not worth building. Write these before the agent starts. Sunk cost bias is real, and it hits harder when the cost was only two hours instead of two weeks.
2. Review Loops, Not Review Gates
A single review at the end catches syntax. Continuous review during implementation catches judgment errors. Build review into the loop: implement, evaluate, adjust. The question at each cycle isn't "does this work?" but "should this exist?"
3. Shipped-vs-Useful Tracking
Measure the ratio. How many features shipped in a given month? How many are actively used? If the hit rate is below 50%, the problem isn't execution, it's selection. Track it honestly. The number is usually uncomfortable, and that discomfort is the starting point.
4. Pre-mortems Before Implementation
Before building, ask: "If this feature fails to get adoption, why?" The answer is usually obvious in advance. The use case is too narrow, the problem isn't painful enough, the workflow is already good enough. A five-minute pre-mortem saves days of wasted execution.
5. Scope Boundaries That Resist Expansion
Define the boundary explicitly. "This feature does X and doesn't do Y." When the agent surfaces an opportunity to extend into Y, the answer is no. Not because Y is bad, but because expanding scope is the default failure mode when execution is cheap. Say no to scope creep as a policy, not a decision.
The Job Description Changed
The shift from execution bottleneck to judgment bottleneck changes what it means to build software.
The old job: understand the problem, write the code, test it, ship it. The rate limiter was implementation speed.
The new job: define what to build (specs), determine whether the output is correct (review), decide when to stop (scope), and know when to abandon (kill criteria). The rate limiter is judgment quality.
Three of the four steps are human judgment. One is delegated execution. The proportions flipped.
That's not a downgrade, it's a concentration. The hard parts of building, understanding what matters, recognizing when something is wrong, knowing when enough is enough, were always the valuable parts. They used to be buried under the mechanical work of implementation.
Now they are exposed. And they are the whole job.
Trade-offs
This framing has real limits:
Judgment is slow to build. Unlike coding skills that transfer across languages and frameworks, judgment is domain-specific. Knowing what to build for a developer tools audience doesn't help you know what to build for healthcare. There are no shortcuts. The 25% hit rate improves through reps, not through reading about it.
Over-filtering kills momentum. The opposite failure mode: so much judgment overhead that nothing ships. Kill criteria become excuses for inaction. Specs become bureaucracy. The sweet spot is between "ship everything" and "ship nothing," and finding it requires judgment about judgment.
Some waste is productive. Not every shipped feature needs to succeed. Some of the 9 useless features taught lessons that informed the 3 useful ones. The goal isn't a 100% hit rate. It's awareness of the ratio and deliberate improvement over time.
The Builder's Real Job
I shipped 12 features. 3 were useful. The post about it resonated because everyone recognizes the ratio.
The uncomfortable truth: AI didn't create this problem. Builders have always shipped more than necessary. AI just removed the friction that used to throttle the output, making the judgment gap visible.
The execution bottleneck is gone. What remains is harder: deciding what to build, evaluating whether it's good, and having the discipline to stop.
That's the job now. Not coding. Not prompting. Judging.
Systems beat heroics. And the most important system is the one that filters your own ideas before they become code.
More on building systems that compound in the Building category.
