AI Coding Assistants: What They Actually Change

Three years ago an AI coding tool meant a smarter autocomplete. Today it means an agent that reads your repository, plans a change across a dozen files, runs the tests, and opens a pull request while you're in a meeting. The shift from suggesting lines to completing tasks is the real story, and it changes what a developer's day looks like far more than the early demos implied.

From autocomplete to agents

The first wave — GitHub Copilot's 2021 preview, built on OpenAI's Codex — predicted the next few tokens from the code around your cursor. It was useful for boilerplate and forgettable for anything else. The second wave added chat: you could ask a model to explain a function, write a test, or refactor a block. The current wave is agentic. Tools such as Claude Code, Cursor, GitHub Copilot's coding agent and Codex CLI take a goal in natural language, explore the codebase with search and file-reading tools, execute commands, observe the results and iterate until the task is done.

What made this possible was not one breakthrough but several stacking up: much larger context windows (whole repositories now fit), reliable tool use, models trained specifically on the loop of edit → run → read error → fix, and a sharp drop in inference cost that makes long autonomous runs affordable.

Where it genuinely helps

• The blank page. Scaffolding a service, a migration, a CLI or a test harness is now minutes of describing rather than an hour of typing.
• Unfamiliar territory. Working in a language, framework or legacy module you don't know well. The model has read more of it than you ever will.
• Tedious breadth. Renaming a concept across 80 files, adding logging to every handler, writing the fifteenth nearly-identical test case.
• Explaining code. "What does this do and why might it be slow?" against a 400-line function is a superpower for onboarding and code archaeology.
• Review at scale. AI reviewers catch the boring bugs — null checks, off-by-ones, inconsistent error handling — so human reviewers can spend attention on design.

Where it quietly creates risk

The failure modes are subtle precisely because the output looks competent.

• Confident wrongness. Generated code compiles and passes the tests it also generated, while missing the requirement that mattered. The tests prove the code does what the model thought you meant.
• Security debt. Studies of AI-generated code consistently find higher rates of classic weaknesses — injection, hard-coded secrets, permissive CORS — when the prompt doesn't ask for security explicitly. Models reproduce the average of their training data, and the average is not secure.
• Dependency hallucination. Models occasionally import packages that don't exist. Attackers have registered those names on public registries ("slopsquatting") so the hallucinated import becomes a real, malicious download.
• Skill atrophy and review fatigue. When most code arrives pre-written, engineers read more and write less. Reading carefully is harder than writing carefully, and reviewers approve large AI diffs faster than they should.
• Licence and IP questions. Who owns generated code, and whether it reproduces licensed snippets, remains legally unsettled in several jurisdictions. Most vendors now offer indemnity, which tells you the risk is real.

Working with an AI coding assistant well

Teams that get durable productivity gains tend to converge on the same habits:

• Write the spec, not the code. The quality of output tracks the quality of the task description. State constraints, interfaces and what "done" looks like.
• Keep the human on the design. Let the agent implement; you decide the architecture, the data model and the boundaries.
• Make the loop verifiable. Agents are only as good as the feedback they get. Fast tests, linters, type checkers and CI turn "looks right" into "is right".
• Small, reviewable changes. A 2,000-line AI pull request will be rubber-stamped. Five 200-line ones will be reviewed.
• Treat generated code as untrusted input. Same scanning, same secret detection, same dependency review as anything else that enters the repo.
• Add project context files. A short document describing conventions, commands and gotchas (most tools read one automatically) improves every subsequent interaction.

The developer's job is shifting from writing code to specifying, reviewing and owning it. The typing was never the hard part.

What comes next

The trajectory is towards longer autonomy: agents that own a ticket end to end, run in the background across many tasks in parallel, and escalate to a human only when blocked. That raises organisational questions more than technical ones — how you review work you didn't watch happen, how you attribute responsibility for a defect, how junior engineers learn when the routine work that used to train them is automated. None of those have settled answers yet, and teams that think about them deliberately will do better than teams that discover them in an incident review.