The single most common complaint from working developers in 2025 was not that AI is useless. It was that 66% of them run into “AI solutions that are almost right, but not quite” — and 45.2% find debugging AI-generated code more time-consuming than writing it. That gap between almost-right and right is where engineering work has relocated. Which means the thing you are hiring for has changed shape, and the entry-level candidate you were about to write off is the one most people are mispricing.
Key takeaways
- Production of code is no longer the bottleneck. Validation is — and 30% of developers report little to no trust in AI-generated code.
- The cost is measurable in the codebase: duplicated blocks of five or more lines rose eightfold in 2024, while refactoring fell.
- Early-career workers in the most AI-exposed occupations have seen a 16% relative employment decline. That is a market fact, not a verdict on capability.
- Judgment is observable in weeks, not years — if you test it with a real task in a real repository instead of a puzzle interview.
The bottleneck moved, and the metrics show where
Google’s 2025 DORA research is unambiguous about the trade. 90% of technology professionals now use AI at work and over 80% believe it has increased their productivity — while 30% report little to no trust in the code it generates, and higher adoption correlates with both higher delivery throughput and higher delivery instability. One engineer in the research put it plainly: “I feel somewhat more productive, but it’s at a cost. While I end up spending less time writing code, I spend more time babysitting the AI and reviewing what it is trying to do.”
The residue shows up in the repository. GitClear’s analysis of 211 million changed lines of code found that blocks with five or more duplicated lines increased eightfold during 2024, that 2024 was the first year on record where copy/pasted lines exceeded moved lines, and that moved lines — the signature of refactoring — fell 39.9%. Assistants make inserting a new block trivial and reusing an existing one unlikely. Nobody on your team wakes up wanting more duplication; it accumulates because writing got cheap and reviewing did not.
So the scarce resource on a fifteen-person team is no longer keystrokes. It is attention that can look at a plausible diff and say this is wrong, and here is why. That is a judgment role, and it is the one you should be recruiting into.
The “freshers are disqualified” argument, and where it breaks
There is a confident version of this thesis circulating that ends somewhere darker: if judgment is what’s being bought, and judgment comes from production scars, then entry-level candidates have nothing to sell. The labour market is behaving as though that is true. Brynjolfsson, Chandar and Chen, using administrative payroll data from the largest US payroll provider, found a 16% relative decline in employment for early-career workers aged 22–25 in the most AI-exposed occupations, with declines concentrated where AI automates rather than augments, while employment for more experienced workers in the same occupations held up.
That is real, and it is worth taking seriously. But notice what it measures: hiring behaviour under uncertainty, in occupations where the work was automatable. It does not establish that a second-year engineering student cannot exercise judgment. It establishes that employers have no cheap way to tell which ones can — so they stop buying the category. A market that stops pricing something correctly is a market with an opening in it.
The logical flaw in the harder version of the argument is treating scars as the only source of judgment. Scars are a delivery mechanism — consequence attached to a decision, fast enough to learn from. There is nothing sacred about acquiring them over six years at a large company. They can be manufactured deliberately, in compressed form, if someone gives a student real work with real consequences and then documents what happened when it went wrong.
What judgment looks like when you can actually see it
Abstracted, judgment sounds unhirable. Operationalised, it is a short list of behaviours you can watch for in ordinary work: noticing that output is wrong before being able to articulate why; choosing the boring, legible option when the clever one is unsupportable; asking one clarifying question before writing 400 lines against a misread ticket; escalating at hour two instead of silently guessing until Friday; deleting their own code when the requirement changed. None of these requires a decade. All of them are visible in a pull request and its comment thread.
What is not visible is anything a candidate asserts about themselves. In 2026 the entire self-reported proof stack — the polished README with a tradeoffs section, the architecture diagram, the confident cost analysis, the metric in the headline — is generatable in an afternoon. If your process asks a founder to take those artifacts on faith, it is measuring prompt quality. The related failure in interviews, and how to redesign around it rather than police it, is covered in our piece on evaluating AI-assisted code in interviews.
A six-week protocol for testing judgment
- Pick a task you genuinely want done. Real ticket, real repository, real users downstream. Synthetic exercises test compliance; consequence tests judgment.
- Under-specify it slightly, on purpose. Leave one ambiguity in the ticket. Whether they ask about it, and how, is the highest-signal moment in the whole trial.
- Say AI tools are allowed, and that you will ask about every line. This removes the incentive to hide usage and reinstates the only thing you care about — whether they can defend the output.
- Review the pull request exactly as you would a teammate’s. Do not soften it. How someone absorbs a blunt review comment tells you more than the diff does.
- Watch time-to-escalation, not time-to-first-commit. The failure mode that costs you money is silent guessing. Log how long they sat on a blocker before raising it.
- Run a two-minute walkthrough at the end. Problem, approach, what they rejected and why, what they would do with another week. Cheap to administer, very hard to fake live.
- Introduce one real change of direction mid-trial. Requirements move in every startup. Watching someone delete their own work without sulking is a hiring signal in itself.
- Write the scars down. One paragraph on what broke, what they did, what they would change. That artifact is the compressed experience — and it travels with them.
- Decide at week six, and mean it. A fixed end date is what makes both sides honest. The structure is laid out in full in our six-week work trial guide.
Why this is worth doing rather than waiting
Because trials convert. NACE’s 2026 Internship & Co-op Survey found the average intern conversion rate hit 63.1% for 2024–25 interns, the highest in five years, with an 88.3% acceptance rate. Six weeks of scoped work is not a favour to a student; it is the cheapest evaluation instrument available to a small team, and it produces a hire you have already watched work.
The remaining problem is the one that makes founders skip this entirely: sourcing. That is what Tierones does — an invite-only network of verified second-year developers from India’s IITs, NITs and IIITs, where Tier Rank is built from merged commits, code reviews and shipped projects rather than self-reported claims, and every profile is tied to a confirmed institute email. Verification instead of faith, which is precisely the thing the artifact stack stopped providing. Free while the network grows.
FAQ
If AI writes junior-level code, why hire a junior at all?
Because the constraint has moved from producing code to validating it. Stack Overflow’s 2025 survey found 66% of developers cite “AI solutions that are almost right, but not quite” as their top frustration, and 45.2% say debugging AI-generated code takes more time. Someone has to close that gap, and senior review capacity is the scarcest thing on a small team.
Doesn’t judgment require years of production experience?
Some of it does, but not the part you can hire on. Judgment as a working skill means noticing that output is wrong before you can explain why, choosing the boring option under pressure, and escalating early instead of silently guessing. Those behaviours are observable in a few weeks of real work with real consequences. What experience buys is breadth of pattern — which your codebase and your review comments supply.
What is the fastest way to test judgment rather than recall?
Give the candidate a real, scoped task in your actual repository and review the pull request as you would any other. Then ask them to walk through one decision they made and one they rejected, in about two minutes. Puzzle interviews test recall, which AI has commoditised; a pull request plus a walkthrough tests the reasoning behind the code, which it has not.
Hiring remote engineering help this quarter? Tell us what you need — we’ll show you the right 40, not the loudest 4,000.