The short answer
Yes. AI has made writing code cheap, which leaves judgement as the expensive part: knowing what to build, spotting the plausible answer that is subtly wrong, and owning the system when it is live. Hire engineers who can aim these tools and catch their mistakes, not people who simply operate them.
A founder told me recently they were rethinking their next engineering hire.
“The tooling is so good now. Do I even need someone senior, or can a couple of capable people and Claude Code get us there?”
It is a fair question, and more founders are asking it. The output you can get from a small team using modern AI assistants genuinely would have taken a much larger team two years ago. If you are watching your runway, it is sensible to ask whether the shape of your team should change.
Here is what I would gently push back on, based on the engineers I actually speak to every week.
Do the Best Engineers Avoid AI?
There is a lazy version of this debate where AI tools are something only junior or lazy developers lean on. That is not what I see.
The strong engineers use these tools constantly. They use them for code review, for explaining unfamiliar code, for generating boilerplate, for drafting tests, for working through an approach before they commit to it. Asking whether you want someone who uses AI is the wrong question. Almost all the good ones do.
So if AI use is not the dividing line, what is?
What Will a Strong Engineer Not Let AI Do?
The most revealing thing I hear is where capable engineers draw the line.
Again and again, they tell me a version of the same thing. They use AI freely for support, but they will not let it generate whole features unchecked, and they are wary of it touching anything security sensitive or anything where the data model really matters. Their reasoning is always maintainability and risk. They have seen what happens six months later when nobody actually understood the code that got shipped.
That instinct is the thing you are hiring. Not the typing. The judgement about what is safe to automate, what needs a human eye, and what happens when something the model produced quietly breaks once real customers depend on it.
A junior who prompts their way to a working demo without understanding it has not saved you time. They have moved the cost to later, when something fails and nobody can explain why. A strong engineer who uses the same tools has done the opposite. They have used the speed and kept the understanding.
Is Using AI Well a Skill in Its Own Right?
There is a craft to this that does not show up on a CV, and it is worth screening for directly.
The engineers who get real leverage from these tools are the ones who put guardrails around them. They do not let the model loose on the codebase. They keep it inside tests, type checking, linting and review, so anything it produces has to clear the same gates a human’s code would. They scope what it is allowed to touch, keep it well away from secrets and production data, and treat its output as a draft to be checked rather than an answer to be trusted.
They also understand the tools at a practical level. They know that as you cram more and more into a model’s context window the quality quietly drops and the cost climbs, so they feed it the right slice of the problem rather than the entire repository. They break work into pieces the model can actually reason about. They know when a fresh, tight prompt will beat a bloated thread that has been running all afternoon, and they keep an eye on token use rather than letting it run away. None of that is glamorous, but it is the difference between AI that speeds a good engineer up and AI that buries a weaker one in plausible nonsense.
This is exactly the sort of thing to probe in an interview. Ask how they keep AI inside guardrails. Ask how they manage context and cost on a real codebase. Ask where the tools have burned them and what they changed afterwards. The strong answers are specific and a little battle-scarred. The weak ones are vague enthusiasm.
Does AI Reduce the Value of Senior Judgement?
This is the part the “do we still need senior people” question gets backwards.
When writing code was the slow, expensive part, you were partly paying for throughput. Now that a lot of throughput is cheap, what is left is the harder, more valuable thing. Knowing what to build. Knowing what good looks like. Spotting the plausible-looking answer that is subtly wrong. Owning the system when it is live and load bearing.
AI has not made that judgement less important. By making everything faster, it has made the consequences of poor judgement arrive faster too. A small team shipping quickly with no one exercising that judgement does not fail slowly. It fails at speed.
That does not mean every hire has to be expensive. It means whoever you bring in needs to be able to aim the tools and catch their mistakes, not just operate them.
What Should You Change About How You Hire?
If you take one thing from this, let it be how you interview rather than who you interview.
Stop testing syntax recall. The tools handle that now. Test judgement, ideally against a shared interview scorecard so every interviewer is marking the same thing. Give a candidate a piece of AI-generated code with a subtle flaw and see if they catch it. Ask them where they use AI and, more tellingly, where they refuse to. Worth remembering that they are screening your AI habits at the same time. Ask how they would keep a fast-moving, AI-assisted codebase understandable a year from now. Their answers will separate the people who use these tools well from the people who are merely fast.
That is what the AI engineering search I ran for a healthtech startup came down to. The founders getting this right are not choosing between AI and good engineers. They are hiring the engineers who know exactly how to point AI at a problem, and exactly when not to.
That skill is rarer than raw output, and right now it is undervalued. Which, if you are hiring, is good news.
Questions this search answers
Do startups still need senior engineers now that AI writes code?
Yes. AI has made throughput cheap, so what you are paying for is judgement: knowing what to build, knowing what good looks like, spotting the plausible answer that is subtly wrong, and owning a live system. Faster shipping makes poor judgement arrive faster, not less often.
Should I avoid hiring engineers who use AI tools?
No, and you would be filtering out most of the strong ones. Capable engineers use these tools constantly for review, boilerplate, tests and working through an approach. Whether someone uses AI is the wrong question. How they use it, and where they refuse to, is the real signal.
Where do good engineers refuse to use AI?
Generating whole features unchecked, anything security sensitive, and anything where the data model really matters. The reasoning is always maintainability and risk. They have seen what happens six months later when nobody actually understood the code that shipped.
How do I test AI judgement in an interview?
Give a candidate a piece of AI-generated code with a subtle flaw and see whether they catch it. Ask where they use AI and where they refuse to. Ask how they would keep a fast-moving, AI-assisted codebase understandable a year from now. Strong answers are specific and a little battle-scarred.
Can a junior engineer with AI replace a senior hire?
Not safely. A junior who prompts their way to a working demo without understanding it has not saved you time, they have moved the cost to later, when something fails and nobody can explain why. A strong engineer using the same tools keeps the speed and the understanding.
If you are weighing up the shape of your next engineering hire and want a second view on what to actually screen for, that is the conversation I have with founders every week.
Arjun Gillard
Founder, AG Talent
agtalent.co.uk
