Last updated: September 2026
Almost every article with this title is really a list of coding assistants. Copilot, Cursor, one or two challengers, a table, done. We have that comparison already and it is a separate page: the assistants themselves, compared. This piece is deliberately about everything else — the nine-tenths of a working week that happens outside the editor, where the tooling is less discussed and, in our experience, where the time actually goes.
The framing matters because the autocomplete is the easy part. Generating a function was solved years ago and every serious editor now does it. What is not solved is the work either side of that function: deciding it should exist, reviewing it, testing it, explaining it to the next person, and finding out at 2am why it stopped working. Those are the jobs worth pointing AI at now, and they are also the jobs where the failure modes are least obvious.
The Second Reader on a Pull Request
Code review is the highest-value place to add a machine, for a boring reason: reviewers are tired and inconsistent, and the things they miss are systematic rather than random. Nobody catches the missing null check on the eleventh file of a large diff. A model reading the same diff has no fatigue and no diff-length bias.
What it is genuinely good at: naming the change you did not intend to make, spotting an error path with no handler, flagging a variable that shadows another, and noticing that a function's behaviour no longer matches its docstring. What it is not good at: knowing whether the change is the right change. Architecture, product intent and the question "should this exist at all" remain entirely human, and any tool that claims otherwise is selling you a summary rather than a review.
Use it as a first pass that clears the mechanical objections before a colleague reads it, so their attention lands on the judgement calls. Use it as the only review and you have replaced a slow careful reader with a fast careless one.
Tests: The Part Nobody Volunteers For
Test generation is the clearest win in the whole toolchain, because the economics are unusual. Writing tests is dull, skipped under deadline, and the cost of skipping them arrives months later on somebody else's shift. A model will write the tedious cases — empty input, one element, the boundary, the wrong type — without complaint, and it will write them at 4pm on a Friday.
The discipline that makes this safe is simple and frequently ignored: read the assertions, not just the pass count. A generated test suite that passes tells you nothing until you have checked what it asserts. The characteristic failure is a test that reimplements the bug — the model reads your function, infers the intended behaviour from the code rather than from the requirement, and writes a test that faithfully locks in whatever the function currently does, including the mistake. A green suite then certifies the defect.
The way round it is to describe the behaviour you want in prose first and let the tests be generated from that description, not from the implementation. If your prose and your code disagree, the failing test is the point.
Debugging, Which Is Mostly Reading
Debugging is where the "rubber duck" comparison stops being a joke. Most of the time spent on a bug is spent reading — a stack trace, a log, a diff, an unfamiliar library's source. That is a comprehension task, and comprehension is what these models are best at.
Two patterns work well. The first is pasting a trace with the relevant code and asking not "fix this" but "list the ways this could produce this trace, most likely first." You get a hypothesis list to test rather than a confident wrong answer to adopt. The second is asking for an explanation of code you did not write: an unfamiliar dependency's internals, a colleague's clever one-liner, a config file inherited from someone who left.
The limit is honest and important: a model cannot see your running system. It has no access to state, timing, load, the actual contents of the database or the one environment variable that is set differently in production. It reasons about the text you gave it. Every hypothesis it produces still has to be tested against the real thing.
Documentation, Commit Messages and the Rest of the Prose
Developers write far more prose than the job description implies: commit messages, pull request descriptions, README files, changelogs, incident write-ups, the paragraph in Slack explaining what broke. All of it is real work and most of it is done badly under time pressure.
This is the safest category on the list, because a wrong sentence in a README is cheap and visible, while a wrong line in a payment handler is neither. Drafting here is close to free. The one rule worth keeping is that the draft must be about a diff you can see — give the tool the change, not a description of the change, or you get plausible documentation of something that did not happen.
Dependency and Security Triage
The volume problem in security tooling is not detection, it is triage. A scanner reports a long list of advisories against your dependency tree; most are irrelevant to how you actually use the package, and working out which is which is slow, dull and requires reading the advisory alongside your own call sites.
That specific comparison — "here is the advisory, here is how we call this library, does the vulnerable path apply to us" — is a good use of a model, and it is a question a scanner cannot answer because the scanner does not read your code. Treat the output as a first sort into "look at this now" and "look at this later", never as a clearance. Nothing here should be the last word on whether you are exposed.
