What AI coding agents are good at, and what they're not

Written 5 August 2026. This one touches fast-moving tooling. The tradeoffs should hold; check anything version-specific against current documentation before relying on it.

I use coding agents every working day. They have genuinely changed how much one person can ship. They have also produced the two most expensive mistakes I have had to unpick this year. Both things are true.

Where they earn their keep

• Work with an obvious right answer. A CRUD endpoint, a form with validation, a migration, a config file. Shapes that exist a million times over.
• Mechanical change across many files. Renaming a concept in sixty places. Tedious and error-prone by hand; a machine does it exactly.
• Getting oriented in unfamiliar code. "Where does this request get authorised?" answered in seconds rather than an afternoon of grepping.
• Test data and fixtures. Realistic, varied, in bulk, instantly.
• The first draft of anything. Editing something mediocre is faster than starting at a blank file.

The three places they cost you

1. Confidently wrong code that reads fine

This is the big one. Broken code announces itself. Subtly wrong code does not. An authorisation check that is slightly too permissive, an edge case in a refund path, an off-by-one in a date range — all of these read perfectly well at a glance, and a glance is exactly what they tend to get.

Which is why the rule here is that no line goes live unread. Not skimmed. Read.

2. Plausible-looking architecture

Ask for a feature and you will get one, built the most common way that feature is built on the internet. That is often right. It is wrong precisely when your business has the quirk that made a custom build necessary in the first place — and it will flatten that quirk without mentioning it.

3. Volume that hides the absence of thinking

A four-hundred-line pull request feels like progress. Sometimes it is eighty lines of thinking and three hundred of scaffolding nobody needed. The cost is not writing it; it is that someone maintains it for years.

The scarce resource stopped being typing. It is judgement about what should exist at all.

How I actually work with them

The data model, anything touching money, authentication or personal data, and any decision about what to build — those I do myself, slowly. Everything downstream of those decisions is fair game, reviewed line by line.

The practical test I apply: if this is wrong, how will I find out? If the answer is "it fails immediately and loudly", let the machine write it. If the answer is "a customer tells me in three months", I write it.

What it means if you are paying for software

Ask whoever is building for you how they use these tools. "We don't" is a slightly worrying answer in 2026. So is "the AI writes it and we ship it". The answer you want describes a line: what the machine does, what a person does, and who reads the result before it reaches you.

A worked example of confidently wrong

The abstract warning is easy to nod along to, so here is the shape of a real one. Ask for an endpoint that lets a user fetch their own orders. You will reliably get something that reads the user id from the request, queries orders for that id, and returns them. It looks correct. It has tests. The tests pass.

The problem is where the user id came from. If it was taken from a parameter the client sends rather than from the verified session, then any logged-in customer can read any other customer's orders by changing a number in the URL. The code is not broken — it does exactly what it says. It is just answering the wrong question about who is asking.

This class of bug does not announce itself. Nothing crashes, no test fails, and the feature works perfectly in every manual check you would think to do. It is found by someone reading the code and asking where each value came from — or by a customer, later, which is considerably worse.

How to review AI-written code quickly

Reading every line sounds slow. In practice it is fast if you know what you are looking for, because the failure modes cluster.

1. Follow the untrusted input. Anything from the browser is a claim, not a fact. Where does it get checked?
2. Check the authorisation, not the authentication. “Is this a real user” is usually right. “Is this user allowed this particular record” is where it goes wrong.
3. Look at the error paths. Happy paths are nearly always fine. What happens when the payment provider times out halfway?
4. Question anything clever. Unusual constructs are where a model has pattern-matched onto something from a different context.
5. Read the tests as claims. A test asserting the wrong behaviour is worse than no test, because it makes the wrong behaviour official.

What it means for how long things take

The honest accounting is less dramatic than the marketing. Writing code is perhaps thirty per cent of building software. The rest is deciding what to build, understanding the existing system, testing, fixing, deploying and explaining.

So even a tool that made typing instantaneous would not make projects three times faster. What it does is shift where the time goes: less on mechanical production, more on judgement and review. My estimates have not halved. They have become more reliable, because the boring parts no longer vary much.

There is a second-order effect that matters more. Because scaffolding is nearly free, it is now cheap to build a rough version of something and find out it was the wrong idea. Being wrong sooner is worth more than typing faster.

Where this is heading, carefully

These tools improve quickly and any specific claim I make about their limits will age. What seems durable is the shape of the problem: systems that generate plausible output need someone accountable for whether it is correct, and that accountability is not a technical problem that a better model dissolves.

So the question to ask a studio is not whether they use AI. It is who answers the phone when the thing it wrote breaks at 11pm, and whether that person understands why the code is shaped the way it is.