Coding agents write a lot of code now. A competent engineer with a good agent can produce a working feature in an afternoon that would have taken a week three years ago. That is good news for every team that ships software.
It also changes what you are hiring for.
When code was expensive, you hired people who could produce it. Now that it is cheap, you need people who can tell good code from bad. They notice when a generated solution is quietly wrong. They decide what should be built at all. That skill comes from writing, reading and debugging a lot of code by hand.
What we mean and what we don't
It isn't about age or years of experience. An Engineer who learnt to program properly, wrote their own parsers, spent time reading docs for fun and can explain why their code works a certain way or their last bug happened is better than a developer who glues solution together without proper context of what they are working on.
It makes it difficult for the latter to truly understand where certain bugs are coming from and losses context of the entier application. This especially in the age of agents leads to producing a boat-load of code which as we all know doesn't mean right or most efficient solution.
What we mean is fundamentals. That is a working model of how the machine, the language and the system behave. You only build it by doing the work yourself. Agents amplify that model. Without it they amplify guesswork.
Why it matters more now
Review is the new bottleneck
On a team that uses agents well, engineers spend more time reading code than writing it. Every pull request an agent drafts still needs someone to review it. That person has to spot the off-by-one error, the missing index, the race condition and the security hole the tests didn't cover. Reviewing is harder than writing. You have to find the problem without being told it exists.
Agents are confident when they are wrong
A generated answer reads as fluent whether it is right or not. Engineers who have debugged things the slow way recognise the smell of a plausible mistake. Engineers who haven't tend to trust the fluency.
Someone still owns the system
When production breaks at 2am, the agent isn't on call. You need people who can hold the architecture in their heads. They read a stack trace cold and reason about what changed. That knowledge doesn't arrive by prompting.
Taste decides what gets built
The most expensive code is the code you didn't need. Choosing the simpler design takes judgement. So does saying no to a feature or deleting a module. Only experience gives you that.
How to spot it in a profile
Don't hire based on a CV, it tells you almost nothing about the person you are hiring. They are written to get past keyword filters. They list titles and dates, not how someone actually works. What you want is the person's own account of their work. You can learn a lot from it before you send a single message.
- Look for depth in the experience descriptions. Favour someone who writes a good technical description of their work. They name the tools, frameworks and languages they used. They explain how they approached the problem, even in the age of agents. That tells you far more than a generic "improved performance by 40%".
- Look at projects they built for themselves. Side projects, tools, libraries and contributions show curiosity and the habit of finishing things.
- Check skill levels against years. On Katara, engineers rate each skill and add the years they've used it. An expert rating with seven years behind it is a stronger signal than a long list of tags.
- Read how they write. Clear writing about technical work usually means clear thinking about it.
Every profile on Katara is written by the engineer. None are generated from a scraped CV. What you read is how the person describes their own work.
How to test for it in an interview
Swap some of the algorithm puzzles for exercises that reflect the job as it is now.
- Give them code to review. Hand over a short pull request with two or three real problems in it. Ideally an agent wrote it. Ask what they would change and why.
- Ask for a debugging story. "Tell me about the hardest bug you've fixed" separates people who understood the fix from people who got lucky. Follow up on the details.
- Let them use their tools, then ask about the output. Using an agent in a take-home exercise is fine. Ask them to walk through every line and explain the trade-offs.
- Change the requirements halfway. Engineers with a real model of the system adapt calmly. Engineers relying on generated code often have to start again.
Write down what you saw in a scorecard straight after the interview. Do it while it is fresh. It keeps the decision about evidence, not impressions.
How agents fit into your hiring
None of this is an argument against agents. The best engineers we talk to use them every day. Agents are a multiplier. A multiplier needs something to multiply.
It is also why we built Katara without AI screening. A keyword matcher can't tell a thoughtful engineer from a well-optimised CV. An AI screener is a poor judge of exactly the skills that now matter most. We would rather you read real profiles and make the call yourself.
If you're hiring across EMEA or Japan, browse engineers on Katara and read their work in their own words.