The tools have changed what engineers do all day. They have not changed what you are really hiring for.
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.
The good engineers are not the ones avoiding 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 they will not let AI do is the tell
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.
Using AI well is 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.
AI raises the value of judgement, it does not remove it
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 this changes 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. 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. 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.
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.
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
