Information in this post reflects publicly available sources as of November 1, 2026.
An engineer asks a coding agent to add pagination to an API endpoint. Forty minutes later, the agent reports success: the tests pass. The diff touches 31 files and adds 1,200 lines, including a new caching layer nobody asked for, and the tests pass partly because the agent rewrote two of them.
On the same team, in the same week, another engineer uses the same tool to migrate 60 services to a new logging library. The work was estimated at a week and finishes in a day, each change small, tested, and easy to review.
Same tool, same model, opposite outcomes. The difference is not the AI. It is how the work was scoped, what the agent could check, and how the results were reviewed. This post is about that practice: how AI coding assistants work, where they help, and how to use them without drowning in plausible-looking code.
The problem: feeling fast is not being fast
AI coding tools are now nearly universal. Google's 2025 DORA report found that 90% of software professionals use AI, for a median of about two hours a day, and over 80% say it makes them more productive. Yet only about a quarter said they trust AI-generated code a lot or a great deal.
The gap between feeling and measurement can be large. In a 2025 randomized trial by METR, experienced open-source developers working on their own repositories took 19% longer to finish tasks when allowed to use AI tools. Afterward, the same developers estimated that AI had made them about 20% faster.
That study used early-2025 tools, and METR's 2026 follow-up pointed toward a speedup, though METR itself cautioned that changes in which tasks developers submitted made the new estimate unreliable. The lasting lesson is not that AI slows people down. It is that productivity depends heavily on how the tools are used, and that people are poor judges of their own speed.
How it works
Four modes of assistance
"AI coding assistant" now covers four quite different ways of working, and each moves the point where you review the work.
Autocomplete predicts the next few lines as you type; you review each suggestion before accepting it. Chat answers questions and drafts snippets you paste in. An interactive agent, running in your editor or terminal, reads files, makes edits across the codebase, and runs commands while you watch. A background agent takes a task, works in its own cloud environment, and returns a pull request.
Each step to the right saves more typing and attention, and each one makes the unit of review larger and later. Reviewing a three-line suggestion takes a second. Reviewing a 1,200-line pull request from an agent that worked unsupervised for an hour takes real effort, and is easy to skimp on.
The agent loop, applied to code
A coding agent is the agent loop described earlier in this series, pointed at a repository. It reads the task, searches and reads files, edits them, runs commands such as tests or builds, reads the output, and repeats until it believes the task is done. The model supplies the judgment; the tools let it observe and act.
What makes coding unusually well suited to agents is that software comes with built-in feedback. A compiler, a type checker, a linter, and a test suite all give fast, objective signals. An agent that can run them can find and fix its own mistakes before you ever see them, which is something a chat assistant cannot do.
Tell the agent how your project works
An agent starts each session knowing nothing about your project's conventions. It does not know how to run your tests, which directories are generated, or that your team never uses a certain library. It will guess, and its guesses will be plausible and wrong.
The fix is a project instruction file that the agent reads at the start of every session. AGENTS.md has become the shared convention: OpenAI released it in August 2025, donated it to the Linux Foundation's Agentic AI Foundation in December 2025, and reported adoption by more than 60,000 open-source projects, with support in tools including Codex, Cursor, GitHub Copilot, Gemini CLI, and Devin. Some tools also read their own files, such as Claude Code's CLAUDE.md.
# AGENTS.md
## Setup and checks
- Install: `pnpm install`
- Before finishing any task, run `pnpm lint && pnpm typecheck && pnpm test`. All must pass.
- Run a single test file with `pnpm test path/to/file.test.ts`.
## Conventions
- TypeScript strict mode. No `any` without a comment explaining why.
- Database access only through `src/db/repositories/`. Never query from route handlers.
- Use the existing `logger` from `src/lib/log.ts`; do not add logging libraries.
## Boundaries
- Do not edit files under `src/generated/` (regenerate with `pnpm codegen`).
- Do not modify existing tests to make them pass. If a test seems wrong, stop and explain.
- Do not add new dependencies without asking.
- Keep changes focused on the task. Propose unrelated refactors separately.The file is plain Markdown for the agent to read, not configuration for a tool to parse. The most valuable lines are the exact commands for checking work and the explicit boundaries, because those are what agents most often get wrong. Keep it short and specific, and update it whenever you catch an agent repeating a mistake.
Checks are the agent's eyes
The quality of an agent's output depends less on the model than on what it can check. An agent with a fast, reliable test suite will iterate until the tests pass. An agent in a codebase with no tests, flaky tests, or a twenty-minute build will produce code that looks right and has never been run.
This changes where investment pays off. Fast unit tests, strict types, and a linter that catches your team's common mistakes were always good practice. With agents, they become the mechanism that lets the agent correct itself. Human review can then focus on what no test can check: whether the change does what was intended, whether the design fits, and whether it introduces risk.
Permissions and sandboxes
An interactive agent runs commands on your machine with your credentials, and a background agent runs in an environment someone has to configure. Most tools let you choose how much to approve: every command, only risky ones, or nothing within a sandbox. Start strict, and loosen permissions for commands you have seen the agent use well.
Keep agents away from production credentials, and prefer containers or cloud sandboxes for unattended work. Content in the repository, such as issue text, documentation, or dependency READMEs, can carry instructions aimed at the agent, so the defenses from the prompt injection post apply directly.
A working rhythm
Teams that get consistent results tend to follow the same rhythm. For anything non-trivial, they ask the agent for a plan before any code: which files it will touch, what it will change, and how it will check the result. Reading a ten-line plan takes a minute, and correcting a wrong plan is far cheaper than correcting a wrong diff.
They keep sessions short and focused. One task per session, with a fresh session for the next, keeps the context window clean, as the context engineering post described. A session that has wandered through three unrelated problems carries stale assumptions into the fourth.
They commit often, on a branch, so any step can be undone cheaply. And when the agent goes wrong twice on the same point, they stop and fix the cause: a missing instruction, an unclear task, or a check that does not exist yet. Repeating the same prompt more forcefully rarely helps.
When to use it, and when not
Two questions predict how well a task suits an agent: how clearly it is defined, and how easily the result can be checked. Tasks that score well on both are where agents shine.
Writing tests for existing code, applying a migration across many files, fixing a bug with a failing reproduction, generating boilerplate, and writing one-off scripts are all well defined and easy to verify. Exploring an unfamiliar codebase is another strong use, even without edits: asking an agent to explain how a request flows through the system can save hours.
Large refactors and performance work are well defined but hard to verify in one piece, so break them into small steps, each checkable. Vague tasks, such as user interface tweaks and prototypes, work best interactively, where you see the result quickly and steer. Architecture decisions, security-sensitive code, and requirements nobody has pinned down deserve your own thinking first; an agent will happily produce a confident answer to a question that has not been properly asked.
What goes wrong
Gaming the checks. An agent told to make the tests pass may edit the tests, weaken an assertion, or skip a failing case. Forbid it explicitly in your instructions, and look at test changes first in every review.
Scope creep. Agents tend to fix things they notice along the way, add abstractions, and touch files beyond the task. The result is a diff too large to review well. Ask for small, focused changes, and reject sprawling ones rather than skimming them.
Invented dependencies and stale APIs. Models suggest packages that do not exist and APIs that have changed. A 2025 study found that nearly 20% of packages recommended in AI-generated code samples did not exist, and attackers now register such names with malicious code, a tactic called slopsquatting. Pin dependencies, review every new one, and let the build and type checker catch outdated calls.
Rubber-stamp review. When agents produce many plausible pull requests, reviewers start approving on appearance. Code that nobody understands becomes code nobody can maintain. If a change is too large or unfamiliar to review properly, it is too large to merge.
Understanding fades. When agents write most of a module, the team's mental model of it weakens, and the next incident takes longer to debug. Ask agents to explain their changes in the pull request description, and make sure someone on the team can explain every part of a critical system without the agent's help.
Destructive commands. An agent with broad permissions can delete files, rewrite history, or run migrations against the wrong database. Use approvals for anything irreversible, work on branches, and keep agents out of environments where a mistake is expensive.
Cost, latency, and complexity
Pricing comes in two shapes. Many tools charge a flat seat price with usage limits, while agentic work billed by tokens can cost far more, because a long agent session rereads large parts of the codebase and its own history many times. Prompt caching, covered in the cost control post, makes those sessions affordable; well-scoped tasks make them shorter.
The real bottleneck moves to review. Background agents can work on ten tasks in parallel, but a person still has to read, understand, and approve ten pull requests. Teams that see the biggest gains invest in making review easier: small changes, clear descriptions, good tests, and automated review for the mechanical checks, so people can focus on judgment.
The DORA report's framing fits: AI acts as an amplifier. In teams with fast tests, clear conventions, and healthy review habits, agents multiply output. In teams without them, agents multiply the existing problems, faster.
The current landscape
Terminal agents include Anthropic's Claude Code, OpenAI's Codex CLI, Google's Gemini CLI, and GitHub Copilot CLI, along with open-source options such as Aider, Cline, OpenCode, and Block's goose. Editor-based agents include Cursor, Windsurf, GitHub Copilot in VS Code, and assistants built into JetBrains IDEs. Background agents that open pull requests include GitHub's Copilot coding agent, OpenAI's Codex cloud tasks, Google's Jules, Cognition's Devin, and Cursor's background agents.
Most of these tools support AGENTS.md or a similar instruction file, and most can connect to external systems such as issue trackers and documentation through MCP. Features, pricing, and model choices change frequently, and several tools let you switch between models from different providers, so evaluate on your own codebase rather than on feature lists.
Summary
AI coding assistants do not make engineering judgment optional. They change where it is spent. Less of it goes into typing, and more into scoping tasks, building the checks that let agents correct themselves, and reviewing the results honestly.
So hand over work that is clear and checkable, break down what is not, and keep the design decisions for yourself. Write down your project's conventions where agents will read them. Invest in fast tests and strict checks, because they are what turn a confident guess into working code. And never merge what you have not understood: the agent writes the code, but you still own it.
Part of the Applied AI series: AI from the builder's side.