Skip to content
All articles

AI Coding Agents

Five ways to code with AI, five different risks

Autocomplete, chat, interactive agents, asynchronous agents and agentic workflows differ in what they can touch and how they fail. Choose by reversibility and consequence, not by maturity.

· 4 min read

Table of five AI coding modes. Completion: text suggestion only, risk of a plausible local error. Chat assistant: usually read-only, risk of missing repo context. Interactive agent: files and chosen commands, risk of a wrong multi-file edit. Async agent: throwaway environment and branch, risk of unsupervised drift. Agentic workflow: policy-run automation, risk of a bad rule at scale.

"We use AI for coding" covers at least five different arrangements, and they fail in different ways. Before picking one, it helps to be precise about what a coding agent is.

A coding agent is a software system that uses a generative model to choose and sequence repository tools toward an engineering goal, while an external runtime controls what it can see, change, run and report. The model proposes. The harness supplies files, search, shell commands and patches. Policies decide whether an action is allowed. Tests and reviewers decide whether the result is acceptable.

The five modes

ModeUnit of workTypical authorityMain risk
Completionthe next tokens or linea text suggestion onlya plausible local error
Chat assistantan explanation or snippetusually read-onlymissing repository context
Interactive coding agenta bounded repository changefiles and selected commandsan incorrect multi-file change
Asynchronous coding agentan issue, pull request or maintenance joba disposable environment and branchunsupervised drift
Agentic workflowa repeatable delivery processpolicy-controlled automationa bad rule applied at scale

Not a maturity ladder

It is tempting to read the table top to bottom as a path from beginner to expert. It is not. A low-risk refactor across fifty files may suit an asynchronous agent that opens a pull request overnight. A production incident may call for an interactive agent with a senior engineer watching every step. The right mode follows from how reversible the change is, how uncertain the task is, and what a mistake would cost.

One session, several systems

Here is an interactive session from the course. A developer asks an agent to fix a duplicate payment retry. The model does not get the whole repository: the harness first gives it the project instructions and search tools. It searches for the timeout error, reads the retry policy and its integration test, and proposes a plan touching three files. Policy allows edits in the workspace and local tests, and denies network and secret access. The model patches the retry key, runs a focused test, hits a contract failure, inspects the checkout response type, revises the patch, and runs the wider payment suite. A human reviews the diff, and CI reruns every required check independently.

Count the systems in that story: a model that proposes, a harness that executes, a sandbox that limits reach, a repository that holds local truth, a CI system that produces independent evidence, and a reviewer who grants authority.

Engineering Insight

Calling all of that "the AI" hides the boundaries engineers have to design. Most incidents with coding agents happen at one of those boundaries: a permission set too wide, a test that was not run, a review that was skipped.

Get one diagram a week

A short article built around one engineering diagram, from the same library as these courses.

One diagram-led article a week on AI and systems engineering. We email you once to confirm, and every newsletter has an unsubscribe link. Privacy policy