AI in engineering companies · Coding agents

Coding agents need experienced engineers

Catherine Ives-YimPublished 27 September 2026 · 5 min read

A coding agent will write code for anyone. That is both its great promise and its great danger. In the hands of an experienced engineer, it is the most productive tool I have used in my career. In the hands of someone without the experience to judge its output, it produces systems that appear to work, until they do not.

This article is about why experience matters more with coding agents, not less, what goes wrong when it is missing, and how organisations should think about the people who use them.

What the experienced engineer brings

In Vibe coding is just another level of abstraction, I argued that each new level of abstraction benefits most the people who understand the level below. With coding agents, what the experienced engineer brings is specific.

A model of the system. How data flows, where state lives, what depends on what, what happens when something fails. That model is what allows them to give an agent precise instructions and to recognise when its output does not fit.

Knowledge of how things go wrong. Race conditions, resource exhaustion, security boundaries, the edge case that only appears in the field. Experienced engineers have seen these failures, which is why they look for them in code that appears correct.

Judgement about what matters. Which parts of a system must be carefully engineered and which can be quick and simple. An agent treats everything with the same confidence.

The ability to reach below the abstraction. When the generated code misbehaves, someone has to understand it at the level of what it actually does, not what it was asked to do.

Taste. Knowing what maintainable, readable, well-structured code looks like, so that the system is still workable in two years' time.

What goes wrong without it

When code is produced with coding agents by people without the experience to judge the output, the problems are consistent.

It works, until it does not. The code handles the cases that were tested and fails on the ones that were not, often under load, with unusual input, or when something else fails first.

Nobody understands it. The person who produced it cannot explain how it works, because they did not write it and could not have. When it breaks, there is nobody who can fix it without starting again.

Security holes nobody saw. Missing authorisation checks, secrets in the code, unsafe handling of input. These are invisible to someone who does not know to look for them. I cover the typical issues in The security of AI-written code.

Incoherent systems. Each feature added by asking the agent for it, with no design holding them together. The result grows harder to change with every addition, until it cannot be changed safely at all.

Tests that prove nothing. Tests written by the agent to pass, testing what the code does rather than what it should do, and sometimes altered to pass when they failed.

Invented dependencies installed without question. Packages suggested by the agent and installed because it suggested them, a route attackers now exploit, as described in The AI supply chain.

None of these is a failure of the agent. They are failures of review, and review requires experience.

The inexperienced engineer is not the problem

I want to be careful here. This is not an argument that junior engineers should be kept away from coding agents. It is an argument about how they use them, and how organisations support them.

Used well, coding agents are an extraordinary teaching tool. A junior engineer can ask an agent to explain unfamiliar code, to describe the trade-offs between approaches, to point out what could go wrong with a design, and to review their own code. That accelerates learning.

Used badly, they prevent learning. An engineer who accepts whatever the agent produces never builds the mental model that would let them judge it. The risk is a generation of engineers who can produce code but cannot reason about systems, and an industry that has quietly stopped growing the senior engineers it depends on.

How organisations should work with them

Experienced engineers specify and review. Senior engineers set the architecture, break work into well-defined tasks, and review what the agents produce. That is where their time is most valuable.

Every line has an owner. As I argued in AI drafts, engineers decide, the AI drafts and the engineer decides. Code that ships is the responsibility of a named engineer who can explain it.

Review is real work. Reviewing agent output is not a formality. It takes time, and the time must be allowed for. The volume of code agents produce can overwhelm review capacity, and when it does, quality falls silently.

Juniors learn with agents, under supervision. Pair junior engineers with agents and with senior reviewers. Expect them to be able to explain every change they submit.

Protect the tests. Tests are the specification. Changes to tests deserve more scrutiny than changes to code, not less.

Measure what matters. Not lines of code produced, but defects found later, time to understand and change the code, and incidents in the field.

The career question

If coding agents take on much of the work that junior engineers used to learn on, how do the next generation of senior engineers develop? This is a real question for the industry, and I do not think it has been answered.

My view is that the skills that matter are shifting towards system design, specification and critical review, and that those can be taught deliberately, with agents as a tool for learning rather than a substitute for it. Organisations that invest in that will have the experienced engineers they need. Those that simply replace junior work with agents may find, in a few years, that nobody left understands their systems.

Four things worth taking seriously

For engineering leaders: coding agents multiply the judgement of the person using them. Put them in the hands of people with judgement, and make sure everyone else is developing it.

For senior engineers: your role is shifting to specification and review. Both are skills worth investing in deliberately.

For junior engineers: use agents to understand, not to avoid understanding. Be able to explain every line you submit.

For everyone: the danger is not the agent. It is code that nobody in the organisation understands.

I would be interested to hear how your organisation is bringing on junior engineers now that agents do much of the work they used to learn on.