Here's a definition worth being strict about: judgment is the ability to be right about things that cannot be checked yet.
Not knowledge — knowledge is checkable. Not skill, which shows up in the artifact. Judgment is what you have left when the feedback loop is six months long and somebody has to decide today anyway.
That definition does the work in this whole argument, because it explains exactly which parts of engineering got cheap. Everything with a fast feedback loop is either automated already or shortly will be. What's left is the part where being wrong doesn't announce itself.
Why would cheap code make judgment more valuable rather than less?
The intuition runs the other way, so it's worth being explicit. If implementation is cheap, surely mistakes are cheap too — you just regenerate. That holds for a class of mistake and completely fails for another.
It holds for anything local and reversible. A badly named function, an awkward loop, a component structured wrong: cheap to fix before, cheaper now. Nobody's judgment was ever the constraint there.
It fails for anything that propagates. A data model that encodes a wrong assumption, an API contract three teams now depend on, a service boundary drawn along the wrong seam. Those get more expensive over time regardless of how fast you can type, and generation speed does nothing to the cost curve. If anything it steepens it, because more code accumulates on top of the wrong decision before anyone notices. XenGrowth, who work on the commercial side of this writes about senior engineers as an operating problem rather than a build problem.
Cheap implementation doesn't make bad architecture cheaper to fix. It makes bad architecture faster to build on top of.
Decision type | Feedback latency | Effect of cheap generation |
|---|---|---|
Function structure, naming, local style | Minutes — review catches it | Genuinely cheaper. Judgment was never the constraint |
Library or framework choice | Weeks to months | Neutral. Cheaper to try, no cheaper to be wrong about |
Data model and schema | Months to years | Worse. More code depends on the wrong shape, sooner |
Service boundaries and ownership | Years | Worse. The seam is now crossed by code nobody wrote by hand |
What to build at all | Quarters, if ever measured | Much worse. You now build the wrong thing faster and in volume |
The pattern down that table is the whole argument. Cheap generation helps exactly where feedback is fast, and hurts where it is slow — and judgment is defined as the skill that operates where feedback is slow.
Is there evidence, or is this just a nice theory?
DORA's 2025 data is the closest thing to a direct measurement. AI adoption now correlates with higher delivery throughput and, at the same time, higher delivery instability. In 2024 both numbers were negative; the throughput sign flipped and stability did not recover.
Read that as a statement about decisions rather than about code. Throughput up means more decisions reaching production per unit time. Stability down means a larger share of them were wrong in ways nobody caught. That is precisely what you would predict if decision volume rose while the examination applied to each decision fell. The XenGrowth resource library approaches this from the the operations side of this side.
Veracode's benchmark shows the same thing at the level of a single function: 45% of generated code introduced an OWASP Top 10 vulnerability, with cross-site scripting failing 86% of the time, and larger models were no better. The reason bigger models don't help is that whether a line is safe depends on a trust boundary that isn't in the file. That's not a knowledge problem. It's a judgment problem about context, and it doesn't scale away.
And GitClear's numbers — refactoring down from 24.1% to 9.5% of changed lines while copy/paste rose from 8.3% to 12.3% — measure judgment leaving codebases directly. Refactoring is the purest expression of it: no user-visible payoff, undertaken because somebody understood the whole and thought it should be shaped differently. XenGrowth on AI agents and marketing automation approaches this from the AI agents and marketing automation side.
One objection is worth taking seriously here, because it is the strongest one available: none of these studies isolates judgment. DORA is correlational, Veracode tests generated code in isolation rather than code that a competent reviewer has been through, and GitClear measures the shape of diffs rather than whether the resulting software was good. A determined sceptic can dismiss any one of them. What is harder to dismiss is that four independent measurements, using different methods on different units of analysis, all point at the same gap between local correctness and global coherence — and that gap is exactly the territory judgment operates in.
What actually distinguishes judgment from experience?
Calibration. And the most useful thing in the METR study is the evidence that seniority does not supply it automatically.
Those sixteen developers were experts working on repositories they knew intimately. They predicted a 24% speedup, then estimated a 20% speedup after doing the work, and were measured 19% slower. Roughly 39 percentage points of error, in the flattering direction, by exactly the people you'd expect to know better.
That is what uncalibrated experience looks like. They had the domain knowledge. What they didn't have was a habit of checking their beliefs against outcomes, because nobody had ever scored them.
Experience is exposure to outcomes. Judgment is exposure to outcomes plus a record of what you predicted beforehand
The record is the entire difference, and it is the part almost nobody keeps. Without it you remember your correct calls vividly and your wrong ones as bad luck
This is why ten years at a company where nothing shipped produces less judgment than three years somewhere that shipped weekly and measured it
It is also why the fastest available improvement is embarrassingly cheap: write down what you expect before the change, read it back afterwards
What does this look like on a Tuesday?
Abstract arguments about judgment are cheap, so here is the concrete version. These are the moments where the calibrated engineer and the merely experienced one visibly diverge, and none of them involve writing code.
Situation | The tenure answer | The judgment answer |
|---|---|---|
A generated PR passes CI and looks clean | Approve it — tests are green | Ask which trust boundary the new input crosses, because CI has never tested for the Veracode categories |
A service is slow and one query is obviously the culprit | Add the index | Ask what the index costs the write path under peak load, and whether the query is a symptom of the wrong data model |
A stakeholder wants a feature that is technically easy | Build it, it's a day's work | Ask what it commits you to supporting for five years, because cheap to build and cheap to own are different questions |
Two designs, one clearly more elegant | Pick the elegant one | Ask which is cheaper to be wrong about, then pick that one instead |
An incident is traced to a single bad commit | Write the postmortem, name the cause | Keep going — Cook's point is that one fault was never sufficient, so stopping here guarantees a repeat |
The team is shipping visibly faster with new tooling | Celebrate, expand the rollout | Pull the change-failure rate alongside throughput, because DORA found those two decoupling |
What every right-hand column has in common is that it costs time now against a benefit that may never be visible, and that nobody will thank you for. That is the actual texture of judgment, and it is why it does not survive in organisations that only measure output. It looks like slowness right up until the moment it looks like foresight.
It is also, notably, the column that no amount of generation speed produces. Every entry is a question, and the model was not asked it.
Where does this leave the profession?
Somewhere uncomfortable, and it's worth stating rather than closing on an upbeat note.
Judgment is manufactured from supervised mistakes. You develop it by making decisions with real consequences while someone more calibrated watches, and then living long enough with the result to find out. That process has a name — apprenticeship — and it is exactly the thing SignalFire observes companies cutting, with entry-level hiring at the tech majors down 65% since 2019. XenGrowth on AI search, GEO and discovery goes further into AI search, GEO and discovery.
So the demand for judgment is rising while the mechanism that produces it is being switched off. Companies preferring experienced individual contributors are each behaving sensibly and collectively drawing down a stock nobody is replenishing. That resolves in roughly five years, which is how long it takes to make a senior engineer, and it resolves badly.
Start recording predictions this week. One line before any non-trivial change: what you expect to break, what you expect to get faster, what you expect to be surprised by. Read them back monthly. This is the cheapest calibration instrument that exists
Sort decisions by reversibility before you sort them by importance. Cheap-to-reverse should be decided fast and often wrongly; expensive-to-reverse deserves the deliberation you were spreading evenly
Measure your team's throughput and change-failure rate together, not separately. DORA's finding only shows up when you look at both, and looking at throughput alone will tell you things are going well
Write down the reasoning, not the conclusion. A decision record that says what you were worried about is worth more than one that says what you chose, because the next person needs to know whether your worry still applies
If you manage people, treat mentorship as staffed time. Judgment does not transfer through documentation. It transfers through someone watching you decide and asking why
The optimistic reading is that this is a great time to be an engineer with calibrated judgment, and that's true. The less comfortable reading is that being one is now largely a matter of having started before the ladder was pulled up.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth, who work on the commercial side of this covers the go-to-market side of senior engineers, which this piece deliberately leaves alone.
Five questions about calibration rather than experience. The distinction matters because the market is short of one and not the other, and years served is a poor proxy for which one you have.
