Hire the Engineer Who Fires the Agents

Hey everyone, Neil here. You're reading High-Signal Hiring. Hiring systems from 20+ years of global recruitment experience and 500+ technical hires. Zero noise and instantly actionable.

Last week I argued your hiring bar had drifted into fantasy, that founders were filtering hard for AI theatre and turning away the engineers who'd do the actual job. Fluency with the tools, I said, is table stakes now. Closer to knowing Git than a superpower.

This week is about the other half of that skill. Everyone is hiring for how well a candidate drives AI. Almost nobody is hiring for whether they know when to stop it.

That second thing is rarer, it's much harder to fake, and it's the difference between an engineer who saves you six months and one who quietly sets fire to your codebase while looking busy the whole way through.

You'll learn why restraint is the skill that protects you, why a candidate can't easily fake it, and how to test for it in the interview in about ten minutes.

Not a subscriber yet? Sign up here

In April 2026 a small SaaS company called PocketOS handed a coding agent a routine maintenance job on its live database. The agent decided, on its own, that the cleanest way to resolve an issue was to delete the production database. Then it worked through the backups and deleted those too. The whole thing took nine seconds. The log it wrote afterwards ended with a line no founder wants to read about their own systems. "I violated every principle I was given." The full account is here, and it's worth ten minutes of your time.

It would be comforting to file that under one careless team having a bad day. It isn't. Security researchers at Adversa counted nine publicly documented cases between June 2025 and July 2026 where a coding agent destroyed real data. Git repositories, personal drives, a live AWS service, production databases. Roughly half of them happened with the guardrails switched on.

I'm not telling you agents are dangerous and you should keep them away from anything that matters. I don't believe that and neither should you. The point is narrower and more useful. The person sitting between the agent and your production environment is now one of the most consequential hires you'll make, and their core qualification is a kind of judgment that doesn't show up anywhere on a CV.

People are bad at knowing when AI is hurting them, and that is the whole problem.

METR ran a controlled trial in 2025 that I mentioned last week and will happily repeat, because it's the most important number in this debate. Experienced developers working on code they knew well were 19% slower with AI tools. They believed they'd been 20% faster. If seasoned engineers can't feel a slowdown while it's happening to them, you can see how someone weaker lets an agent run three days in the wrong direction and files it under progress.

Agents make this harder because they never sound unsure. A good engineer will tell you "I'm not confident about this part, let me check it." An agent hands you the broken state transition and the subtle security hole in exactly the same confident tone as the code that works perfectly. Catching that means someone has to be good enough to know it's wrong before anything flags it as wrong. That instinct is the skill. It does not surface when you ask a candidate which models they like.

So test for it directly. Two ways, and neither takes long.

First, give them a mess and watch when they stop. Hand the candidate an agent transcript, or run a live session, where the output is drifting off the real requirement in a way that looks reasonable on the surface. Then say nothing. Do they notice? How many steps in? Do they pull it back and take the work over by hand, or do they keep feeding the loop because the code looks confident and the agent sounds sure? The engineer who says "this is heading the wrong way, I'd stop here and do this part myself" just showed you the judgment that would have saved PocketOS. That's worth more than an hour of tool talk.

Second, ask them straight. Tell me about a time you decided not to use AI for something. A strong engineer has a real answer and it's specific. The critical path was too risky to hand over. The problem needed context the model didn't have. They'll tell you about a piece of retry logic or a bit of core business logic they didn't trust to a generator, and why. Someone who can't think of a single time they held back is telling you they've never made the call. That's precisely the call you're hiring them to make.

Back in Issue 15 I made the case for hiring the AI sceptic. This is not that, and it matters that you don't muddle the two.

You are not looking for someone cautious, someone who drags their feet on AI or treats every agent as a threat. That person is as much of a liability as the one who trusts the machine blindly, just in the opposite direction. They'll cost you all the speed you're paying for and call it diligence.

What you want is someone who uses agents heavily, ships fast with them, and carries a clear, well-worn sense of the line where they take the wheel back. Heavy user and hard brake, in the same person. Enthusiasm with no judgment wrecks your database. Judgment with no enthusiasm loses you the reason you adopted the tools in the first place. The hire is the one who has both, and that combination is a lot less common than a slick demo makes it look.

Every founder right now is interviewing for the accelerator. Who ships the most, who moves fastest, who runs the slickest agent in the room. That's the easy thing to see, and it's the wrong thing to weigh on its own. The engineer who protects you is the one reaching for the off switch a beat before anyone else has noticed there's a problem. Hire for the brake.

Cheers
Neil