AI coding assistants: what they are good at and where they bite

An AI coding assistant is fastest where the work is shaped like translation: you know what you want, the language is unfamiliar or tedious, and correctness is easy to confirm. Boilerplate, test scaffolding, a regular expression, a build file, a first pass at a language you touch twice a year, an explanation of somebody else's function. It is slowest, and sometimes negative, where the work is shaped like judgment: concurrency, permissions, money, anything where the code compiles, passes the obvious test, and is still wrong. The tool does not know the difference between those two situations, so knowing it is your job.

What these tools actually do well

Start with the honest wins, because they are real and they are not small.

Boilerplate and glue. Data classes, mappers, argument parsers, configuration, the fiftieth endpoint that looks like the other forty nine. This is code you were going to write from memory anyway, and a wrong answer announces itself immediately.

Tests for code that exists. Given a function, a model will produce a reasonable set of cases faster than most people will, including the empty input and the off by one you meant to get around to. It will not tell you the function is testing the wrong thing.

Unfamiliar syntax. Shell, awk, a query language, a build tool, cloud configuration. The saving here is largest for the competent generalist who knows exactly what the outcome should look like and has forgotten the incantation.

Explaining code you did not write. Paste an inherited function and ask what it does, or ask what a stack trace probably means. This is the use with the best risk profile in the whole list, because you check the explanation against the code in front of you.

The first draft of a refactor. Renaming, extracting, mechanical changes across a file. A diff is easy to review, which is what makes this safe.

Where they bite

Four failure modes cause most of the trouble, and they all share one property: the output looks right.

Invented interfaces. The model produces a function, flag or parameter that does not exist, because it fits the pattern of the library. It is the same mechanism behind why an AI makes things up, and in code you are lucky, because an invented method usually fails loudly at build time. The unlucky version is a real method with subtly different behavior.

Outdated patterns. Models learn from a corpus with a cutoff date, weighted toward whatever was common for years. So you get the deprecated authentication call, the old async idiom, the library version that had the vulnerability. The code often still runs, which is precisely the problem.

Security sensitive code. Input validation, authorization checks, cryptography, file paths, anything constructing a query from user data. Generated code tends toward the tutorial version, and tutorials optimize for fitting on one screen. The missing authorization check is the classic: the endpoint works perfectly for the developer testing it as themselves.

Subtle logic. Boundary conditions, time zones, currency rounding, retries that are not idempotent, error paths nobody exercises. These are the bugs that pass review and surface in production a month later.

The review tax

Generation is close to free. Review is not, and review of code you did not write is harder than review of code you did, because you are reconstructing intent from the result. This is the cost that decides whether an assistant is a gain, and it scales badly: a twelve line function is a pleasure to check, a four hundred line change across six files is where people start skimming and approving.

A few consequences follow. Ask for small units, not whole features. Say what you want before you generate, so you are checking against a specification rather than deciding whether you like what appeared. Never accept code you cannot explain to somebody else, because if you cannot explain it you cannot maintain it, and the next person to touch it will be you in March. If you have to read the generated code three times, you would have been quicker writing it yourself, and that is normal for the harder half of the table above. The general shape of this trade off, across every kind of work, is laid out in where AI actually saves time at work.

Licensing, provenance and secrets

Three governance questions come up in every serious adoption, and none of them are settled by enthusiasm.

Where the code came from. Models are trained on public repositories, including copyleft licensed ones. Short, ordinary code is unlikely to reproduce anything protectable, but long distinctive blocks can resemble training material more closely. Most business tools now offer a filter that suppresses output matching public code, and some offer an indemnity. The open questions about training and output are the same ones covered in AI and copyright, and the cautious position is to enable the filter and keep an eye on unusually long generated blocks.

Where your code goes. Your prompt usually includes surrounding files, which may include credentials, customer data or unreleased work. Whether that leaves your network, how long it is kept and whether it trains anything depends on the plan you are on, which is why what happens to a prompt after you press send is worth reading before a rollout, and why the retention and training clauses in an AI vendor contract matter more than the feature list.

Secrets. Keys pasted into a chat are disclosed keys. Assume the worst and rotate rather than reason about it. Repository level secret scanning catches what discipline will not.

There is a fourth item for agent style tools that read your repository and run commands. Anything they read can contain instructions aimed at them: a crafted issue, a comment in a dependency, a readme. That is prompt injection, and the defense is the same as everywhere else, which is to limit what the tool can reach and to keep a human approval on anything that commits, pushes or installs.

What it does to a junior developer

The concern here is often stated badly, as though juniors will simply stop learning. The sharper version: the assistant is best at exactly the tasks people used to learn on. Wiring up a form, writing the first tests, fixing a small bug in an unfamiliar file. That work was slow and much of the slowness was the learning.

The observable symptom is not ignorance, it is a gap between fluency and debugging. Someone produces a working feature quickly and then cannot make progress when it breaks, because they never built the model of the system that debugging depends on. Confidence and understanding come apart.

What helps is not a ban. Ask for the explanation before the acceptance: what does this line do, what happens if the input is empty, why this approach instead of the other one. Have juniors write the test by hand and generate the implementation, which keeps the thinking on the side that defines correct. Pair review on generated code more than on handwritten code, since the author has less context to offer than usual.

Review habits that hold

1. Write the intent before you generate. One sentence about behavior and edge cases is enough, and it gives you something to check against.
2. Keep generated units small enough to hold in your head. If the diff does not fit on a screen or two, split the request.
3. Read the whole diff, including the parts you did not ask about. Assistants edit adjacent lines more often than people expect.
4. Run it, then run it on the input you would not have thought of: empty, enormous, wrong type, hostile.
5. Check every external name against the actual documentation. Package, function, flag, argument order.
6. Route anything touching authentication, permissions, payments or personal data through a human who owns that area, regardless of who or what drafted it.
7. Say so in review. A one line note that a change was largely generated tells your reviewer where to spend their attention, and it belongs in the written policy alongside the rules on which tools and which data are allowed.

The teams that get the most out of these tools are not the ones that generate the most code. They are the ones that kept their standards exactly where they were and simply arrived at them faster.