What to hire for when everyone ships fast
Shipping speed has stopped being a differentiator between engineers because it stopped being scarce. The job description that still leads with it is selecting for the one input that got cheap.
Look at almost any engineering job advert written in the last year. Somewhere near the top it will say the team ships fast, and somewhere near the middle it will ask for someone who can deliver quickly in a fast-paced environment.
Both halves are now close to meaningless, because with roughly 41 percent of production code AI-generated by early 2026, everyone ships fast. Speed of production is not a property that distinguishes one candidate from another any more than typing speed did.
My position: hire for the inputs that did not get cheaper. There are three, they are hireable, and almost nobody screens for them explicitly.
The three things that stayed expensive
Deciding what should exist. Generation collapsed the cost of building a thing. It did nothing to the cost of being wrong about which thing. The gap between “we can build this in a day” and “we should not build this at all” has widened, and the person who can close it is worth more now than they were two years ago, not less.
Establishing that something is correct. Verification did not get cheaper at anything like the same rate. LinearB’s 2026 benchmarks put median review duration up over 400 percent on agentic pull requests, with pickup time roughly 5.3 times longer. Whatever else that means, it means the expensive stage is downstream of production.
Holding the system. The ability to say “this contradicts the decision we took in the payments rewrite” is not a research skill. It comes from having a coherent model of a specific codebase, and it is the thing agents most reliably lack, which is why context blindness produces output that is internally coherent and incompatible with the repository it lands in.
What the advert asks for
- Ships quickly
- Strong in language X
- Comfortable in a fast-paced environment
- Delivers features end to end
What is actually scarce
- Decides what should not be built
- Establishes correctness without trusting the author
- Holds a system model and detects contradiction
- Writes down what done means, precisely
The one nobody screens for
Of those, the capacity I would put first is the least glamorous: can this person write down what “done” means in terms that something other than themselves can evaluate.
That sounds like a documentation skill and it is not. It is the ability to take a vague intent, notice the four places where it is ambiguous, and resolve them before anything is built. Controlled studies have found human-refined specifications cutting errors by up to 50 percent, which is a larger effect than most tooling decisions you will make this year, and it comes from a skill that appears on no ladder and in no interview loop I have seen.
It is also observable in twenty minutes. Give a candidate a two-line feature request and ask what they would need to know before starting. Weak answers restate the request or ask about the stack. Strong answers find the ambiguity that would have caused a rework cycle, and they find it without being told there is one.
Hire for the ability to be usefully unconvinced
The second capacity worth naming separately is scepticism that terminates.
Developer trust in AI output fell from around 40 percent to 29 percent in Stack Overflow’s 2025 survey. Trust went down; usage did not. So the working condition for most engineers now is doing a great deal of work with material they do not fully believe, which requires a specific temperament: doubt that produces a check rather than doubt that produces paralysis or resignation.
I have seen both failure modes hire well on paper. The engineer who accepts plausible output because arguing with the volume is exhausting, and the engineer who rejects everything generated on principle and becomes a bottleneck with opinions. What you want is someone whose reaction to a suspicious diff is to go and find out, cheaply, in ten minutes, and then move.
Accepts, no check
Ships fast, creates debt at machine speed, looks productive on every dashboard you have.
Rejects, no check
Blocks the queue on instinct, cannot say what would change their mind, exhausting to work with.
Checks everything
Correct and unusable. Verification cost scales with volume and volume is now unbounded.
Checks by blast radius
Cheap probes on low-risk paths, real scrutiny where the damage would be. The hire you want.
What to stop asking for
Two things, and I would drop both this quarter.
Language and framework requirements as gating criteria. The cost of producing unfamiliar syntax has fallen further than any other cost in the pipeline. The cost of judging whether unfamiliar output is right has not, but that judgement comes from depth in something, not from depth in your particular something.
And portfolio volume. Shipped-a-lot was a reasonable proxy for capability when shipping was expensive. It is now a proxy for having had access to good tools and an environment with few gates, and it selects mildly against people who worked somewhere careful.
Where this breaks down
Stack knowledge still matters in specific domains. If you write embedded firmware, low-latency trading systems or anything where the failure mode is physical, the person who has not done it before will produce plausible code and miss the thing that matters. I have written as though depth is transferable and in some places it flatly is not.
“Hire for judgement” is the most abused phrase in hiring. It is regularly used to justify decisions made on impression, and impression-based hiring imports every bias the structured loop was built to suppress. If the capacities I have listed are not written into a rubric with observable behaviours, this advice makes your hiring worse, not better.
Some of these are hard to assess in an hour. System-holding in particular is a property of a person in a context, and no candidate holds your system on the day they interview. The best I can offer is a proxy, and proxies are what got us into the shipping-speed problem in the first place.
The 41% figure describes an aggregate, not your team. If your organisation generates very little of its code, the input that got cheap has not got cheap for you, and hiring for production capability remains rational. Check your own numbers before rewriting your loop on the strength of an industry average.
And people can be trained into some of this. I have framed these as things to select for, which is convenient for a hiring manager and slightly defeatist. Specification precision in particular responds well to being taught, and a team that trains it may do better than one that hunts for it.
The takeaway
When production stops being scarce, hiring on production capability stops being informative. What remains expensive is deciding what should exist, establishing that it is correct without trusting the author, and holding enough of the system to notice contradiction.
The most under-screened of those is the plainest: can the person state what done means, precisely enough that something else can check it.
If you take one thing into next week: open your current job advert and count the lines that select on speed of production. Then replace the first one with a line about specification, and add the twenty-minute ambiguity exercise to the loop. It is the cheapest change with the largest signal I know of.