Last updated: October 2026
The short answer: beyond the code assistant in your editor, the AI tools that save developers the most time work on review, tests, debugging, prose and dependency triage. If your code lives on GitHub, two are already within reach: Copilot code review, which comments on pull requests and, by default, does not count towards required approvals; and Dependabot alerts, which flag vulnerable dependencies but, by GitHub’s own account, cannot catch every security issue. Below is where each kind of tool helps, where it fails, and what a review actually costs on GitHub’s published pricing, checked on 16 October 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.
GitHub’s own documentation for Copilot code review is unusually frank about this, and worth reading before you switch it on. It states that “Copilot is not guaranteed to spot all problems or issues in a pull request”; that by default its reviews do not count towards required approvals (an option to let it approve is in public preview, and pushing new commits dismisses that approval); that unless configured to review every push, it reviews a pull request only once; and that dependency manifests, log files and SVG files are excluded from review. Those defaults match the right way to use it — as the first reader, never the last.
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.
The scanner’s side of the bargain is well documented. GitHub describes Dependabot alerts as helping you “find and fix vulnerable dependencies before they become security risks”, with each alert linking the affected file, the vulnerability’s details and severity, and a fixed version where one exists. Its documentation does not claim to check whether your code actually reaches the vulnerable function, and it says plainly that “Alerts can’t catch every security issue.” The gap between “this package has an advisory” and “this advisory affects us” is the reading job worth handing to a model, with a person signing off the answer.
Infrastructure, Config and the Things With No Autocomplete
Configuration languages are where these tools quietly earn their subscription. Nobody memorises the syntax for a cron schedule, an nginx location block, a systemd unit, a CI matrix or an IAM policy, because nobody writes them often enough to remember. They are exactly the sort of thing you look up every single time.
The risk profile is different here and worth stating plainly. A generated function that is wrong usually fails loudly. A generated permissions policy that is wrong may work perfectly and simply be broader than you intended, and nothing will tell you. For anything that grants access, generate the draft and then read it as if a stranger wrote it — because one did.
