Five Things To Look For In Engineers Now That AI Writes The Code

A few years ago, a screening process mostly had to answer one question: can this person write good code? That question is close to settled now. Many of the engineers we place haven’t written code by hand in months.

We screen every senior engineer who wants to join Remgu’s talent network, and over the last couple of years, that process has changed. Typing speed and syntax barely matter anymore. What matters is everything the model can’t do for them.

When AI writes the code, the engineer’s job is deciding what gets built and noticing when the output is wrong.

When a model produces the code, the engineer’s real output is decisions: the spec, the trade-off explained to a product manager, the message that explains why something will take two weeks instead of two days. A prompt is writing too. Vague thinking gives a vague prompt, and the model will confidently build the wrong thing.

Communication also means managing expectations. Managers and clients now assume that with AI everything takes a day. Often it does, but not always, and a good engineer says early when something will take longer, and why.

It also means working with the team. An engineer can now spend a whole day with an agent and barely talk to anyone. Good engineers still check in with the product manager, the designer and the other engineers, and senior engineers often talk to the stakeholders directly as well.

Everyone’s code looks good now. The difference is in the decisions. There is usually more than one way to build something, and each choice affects the product: how fast it is, what it costs, how hard it is to change later. A good engineer knows the options, picks one for a reason, and thinks about how that choice will hold up a year from now. More on this in How To Hire Engineers When AI Makes Everyone’s Code Look Good.

A model will explain a full table scan or a double charge perfectly if someone asks. The engineer’s job is knowing to ask, and recognizing when the model’s confident fix is wrong.

Take a problem with Node’s event loop: two engineers using AI will both fix it. The one who understands it fixes it faster and spends fewer tokens. The other describes the symptom and lets the model search, and AI providers love that engineer, because every extra round of guessing is billed. Engineers who understand the system also know more of the codebase than the model sees at once, so they spot the same problem in another file.

Ask an AI agent to add versioning to file uploads, and if nobody points it to the existing code, it will happily build a new upload handler, new signed links and a new CDN setup, even though the codebase already has all three. The model only sees what it’s shown. An engineer who knows the codebase points it to what’s already there.

Breadth and depth both help. Engineers who have worked across frontend, backend, databases and infrastructure see trade-offs that specialists miss. Deep knowledge transfers too: someone who knows Python inside out will often do better in Node than a junior Node developer, because the concepts carry over and AI fills in the syntax.

AI made building cheap, and that changes how teams should treat mistakes. A prototype that costs an afternoon can be thrown away, so it makes sense to try more ideas and learn from the ones that fail. The mistakes still worth avoiding are the ones that are expensive to undo: anything that reaches customers, their data or their money. Good engineers know which kind of decision they are making. They ask what problem a feature solves, who it is for and how anyone will know it worked, and they suggest a smaller version first. Knowing the goal also makes them better at steering the AI.

They need to know the business, too. Models know the generic version of almost everything, but not your industry’s rules or the regulation that makes the obvious solution the wrong one. For clients in specialized industries, we look for people who have worked in that space before, not only in the same tech stack.

Ask a model to integrate Stripe and it does well, because it has seen thousands of examples. Ask it to integrate a less common payment provider with little public documentation, and it will still say the job is done, while edge cases are missing, the flow isn’t secure, or it doesn’t work at all. Someone who knows the domain has to guide it.

And they need to be in the discussion. On AI projects it can feel like nobody is fully on top of things, because nobody is hands-on in the old way. Engineers who only pick up tickets make that worse.

Traditional programming is precise: the same code does the same thing every time. AI works on probabilities. Its output is usually right, and it always looks right, so the mistakes don’t stand out. Good engineers keep raising the odds that the output is good and never treat it as finished just because the tests pass.

Testing is a bigger part of the job again, including the manual kind: clicking through the feature, trying edge cases, checking what data an endpoint returns, and reading the tests to see whether they test anything. AI-made changes can also reach further than the ticket, so good engineers know the platform beyond the part they were asked to change.

One of our engineers had a test that passed on the build server but failed locally, because two records came back from the database in a different order. The AI’s fix was to loosen the test so it passed either way. The real bug was in the code: the function was supposed to sort by date and didn’t. One added sort fixed it.

Whoever ships the code owns it. Not every line needs to be understood: boilerplate and quick prototypes are fine. But once a feature is in production, the engineer who shipped it can’t shrug off a bug because the AI wrote the code. They need to understand the crucial parts and the overall flow, so they know where to look, or how to point the AI at the problem.

More and more of the work is running the process that produces the code. Advanced teams already turn an error report into a proposed fix automatically, and a meeting transcript into tickets an agent can pick up. Someone has to design that machine, give the model the right context, decide where the checks go, and keep improving it.

Day to day, that means many small decisions: what to build now and what to park, what to ask a designer, how to keep the agents from waiting on you. It also takes organization. A team can now get through a third of a project in one sprint, and AI can help keep track, but it won’t do it for you.

None of this comes with a manual. AI takes over old problems and brings new ones, and the best engineers treat those as the next problems to solve. They keep learning, even if that means letting AI build something in an unfamiliar language and working out how it did it. A good way to hear all of this in an interview: ask how they would bring AI into the workflow for a specific product, and which tools they would use.

Few engineers think about this yet. A feature that calls a model works beautifully in a demo, but every call costs money, adds latency, and depends on a provider that can change its model or its pricing. Something that works for ten users can burn money at ten thousand.

Then there is data. Every prompt sends data somewhere. Paste customer records, a client’s code or an API key into a public model, and it has left the company, often without anyone noticing. Good engineers know what may go into which tool and keep sensitive data out.

1. 01 - Communication

   Can they explain a decision simply, and say early when something will take longer than people expect?

2. 02 - Technical judgment

   Can they lay out the options and the trade-offs, and explain why they picked one?

3. 03 - Product and domain understanding

   Do they ask what a feature is for, and know the rules of your industry?

4. 04 - Checking the work

   How do they make sure AI-generated work is actually right before it ships?

5. 05 - Systems thinking

   Can they keep a fast-moving project organized and the agents unblocked?

6. Bonus - The cost of AI

   Do they know what AI costs to run, and which data must never go into it?

Engineering judgment is now most of the job.

The tools will keep getting better at writing code, and the engineer around them will matter more for it. Hire for the five things the model can’t do, and AI will make that person even better.