The old shorthand for a strong engineer, someone who could turn out clean, working code at speed, is losing its grip. AI can now do that part of the job in a fraction of the time.
What’s worth paying for now is deciding what should get built, spotting where a generated solution will cause trouble later, and owning the call once it ships.
Why does cheaper code change what makes a strong engineering hire?
The job of a senior engineer is tilting away from producing code and towards vetting it, and that changes what a strong hire looks like on paper and in the room.
For years, a job ad could lean on proxies like years of experience with a language, speed through a coding test, or volume of commits, and get a reasonable read on capability.
Those proxies are weakening, because an engineer with AI tools can generate a plausible-looking solution to almost anything in minutes.
What a hiring manager now needs to assess is whether a candidate can tell when code is wrong, risky, or solving the wrong problem.
That has knock-on effects for team structure too. What a team needs more of is people capable of reviewing widely across a codebase, holding the architecture in their head, and saying no to a feature that looks easy to generate but expensive to maintain.
Hiring for that layer is different from hiring for output, and assuming judgement develops on its own once someone has been in a role long enough is a risky bet.
How do you start hiring and assessing for engineering judgement?
There are a few structural changes worth making to how engineering judgement gets assessed and rewarded, beyond a single interview exercise.
1. Rewrite the technical interview brief. If the scorecard still weights “wrote a working solution” heavily, it is measuring something AI has made cheap. Weight it instead towards how a candidate explains trade-offs, flags risk, and justifies a decision not to build something.
2. Build review and architecture conversations into hiring at every seniority level, not only for staff or principal roles. A mid-level engineer who can reason clearly about a system’s failure modes is a better bet than a senior title holder who can only produce output quickly.
3. Check how your current team spends its time. If most hours still go into writing first-draft code rather than reviewing, testing and challenging it, raise that in a retro. It suggests the team hasn’t adjusted its workflow to where the value has moved.
4. Revisit how performance gets measured once someone is hired. Lines of code, pull requests merged and tickets closed are weak signals when generating them is nearly free.
5. Be honest in job ads about what you’re hiring for. If the role is genuinely about judgement, architecture and risk calls, say so directly rather than listing a stack of tools and years of experience, which attracts people optimised for the wrong thing.
Decisions that held up, incidents avoided, and systems that stayed maintainable are stronger signals than any of the above, even though they’re harder to count.
What should you look for in CVs and interviews to spot judgement?
On a CV or portfolio, look for evidence of decisions rather than deliverables. A line that says “recommended against rebuilding X and here’s why” tells you more than a list of frameworks.
Look too for signs someone has worked across a system’s lifecycle rather than shipping a feature and moving on. Judgement tends to show up in how someone handles what happens after launch.
In an interview, a few questions test for this directly:
– Ask a candidate to describe a technical decision they made that traded short-term speed for long-term maintainability, and how they knew it was the right call.
– Ask about a time they chose not to build something, even though it was technically possible and someone wanted it. How they describe that conversation tells you whether they can hold a position under pressure.
– Ask how they’d review a pull request from a teammate who is clearly relying heavily on an AI tool, and what they’d be checking for specifically. Vague answers about “code quality” are weaker than specific answers about security assumptions, data handling or long-term maintainability.
– Ask what kind of software problem they would now be reluctant to hand entirely to an AI tool, and why. People who have thought about the limits of the tools they use tend to have thought harder about their own judgement too.
When does code-writing speed still matter more than judgement?
This framing does not mean code-writing ability stops mattering. A candidate who cannot read or reason about code at all will struggle to judge anything an AI produces, so fluency is still a prerequisite.
It is also worth being careful with junior hiring. Early-career engineers build judgement partly by writing a lot of code themselves and living with the consequences.
That reps-building period cannot be skipped over by hiring for maturity a graduate hasn’t had the chance to earn yet.
Leaning entirely on judgement-based assessment for a graduate role risks screening out people who haven’t had the reps yet, and it misreads what the role is for at that stage of someone’s career.
For some roles, output speed genuinely is still most of the job, such as high-volume, low-risk internal tooling where the cost of a wrong call is small and easily reversed. Treating every hire as a judgement hire, when the role doesn’t call for it, adds friction without adding value.
Ready to talk about your next engineering hire? Get in touch.
Liam
Technology & Software Engineering Recruitment
Last updated: October 2026
