FredrinAn AI coding agent is a language model wired to three things a chat window does not have: tools that read and write files and run commands, a real checkout to work in, and a stopping condition that decides when it is done. You give it a goal; it works the repository itself, and keeps going until the check passes.
The word is on the box of nearly every developer tool shipped since 2024, which is exactly why it is worth pinning down. What follows is the definition that survives contact with a repository: what agents do well and badly today, what running one looks like, and what changes the moment you start a second one.
What is an AI coding agent?
An AI coding agent acts on your codebase instead of answering questions about it. It decides which files to open, edits them, runs your build or your tests, reads what comes back, and tries again. That loop — act, observe, correct — is the entire difference. Everything else is packaging.
Anthropic's documentation puts it in one sentence: Claude Code is "an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools". Read the verbs rather than the adjectives. Every one of them is a capability the previous generation of tools did not have, and none of them is a claim about the model being cleverer.
Three parts have to be present before the word means anything:
- Tools. A way to read and write files and execute commands — not a text box that emits code for you to copy. Without tools there is no action, only suggestion.
- A workspace. A real checkout with your dependencies installed and your test command working. A sandboxed snippet is not a workspace; the agent's advantage comes from being able to run the thing.
- A stopping condition. Something that returns pass or fail, so "done" is a fact rather than an impression. This is the part people leave out, and it is the part that decides whether you can walk away.
Miss any one of the three and you have something else. Tools without a workspace is a demo. A workspace without a stopping condition is a machine that halts at "looks right" and quietly hands the verification job back to you.
The day-to-day practice built on top of all this — how the working style differs, and why the harness matters more than the model — is agentic coding. This post is about the thing itself.
Agent vs assistant vs autocomplete
Autocomplete finishes the line you are typing. An assistant answers a question and hands you text to paste. An agent is given a task and a working tree, and then acts on its own judgement — opening files you did not name and running commands you did not type. The difference is autonomy, and autonomy has a blast radius.
| Autocomplete | Assistant | Agent | |
|---|---|---|---|
| Triggered by | Your cursor | Your question | Your task description |
| Reads | The open file | What you paste in | Whatever it decides to open |
| Writes | The line you accept | Nothing | Files, directly |
| Runs commands | No | No | Yes |
| Sees its own result | No | No | Yes — that is the loop |
| Stops when | You keep typing | The answer ends | A check passes, or a budget runs out |
| Blast radius | One line | Your clipboard | Your working tree |
| Leaves you | Accepting or rejecting | Integrating | Reviewing a diff you did not write |
The bottom row is the one that matters. Autocomplete and assistants leave you as the author with a faster keyboard. An agent makes you the reviewer of work you did not write, which is a different job with a different skill, and nobody hands you that skill when you install the tool.
Almost every product now ships all three modes behind one brand, so the category on the marketing page tells you close to nothing. Judge by what the tool does when you leave the room for twenty minutes. Our survey of the tool landscape sorts the current field by shape rather than by claim.
What agents can and cannot do today
They are reliably good at bounded work in a repository that already has a test command: fixing a failing test, threading a parameter through, migrating a call site, writing the tests nobody got round to. They are unreliable at anything whose correctness cannot be checked, and at anything whose diff is too large for a human to read.
Benchmark numbers need a caveat before you plan around them. SWE-bench Verified — the leaderboard the field measures itself on — draws its tasks from real issues in real repositories, and every instance ships with the test that proves the fix. Your Tuesday does not. Read those scores as an upper bound, because the hardest input, the stopping condition, was handed over with the task.
Where they hold up well:
- Work with an existing verification loop. If
pnpm testorcargo buildalready tells the truth about your repository, an agent can iterate against it without you. - Mechanical change at scale. Renames, codemods, dependency bumps, adding a field through six layers — tedious, checkable, and exactly what a loop is for.
- Unfamiliar code. Not having to learn a codebase before touching it is a genuine advantage, and it is largest on the code you know least.
Where they do not:
- Anything with no test. No stopping condition means the agent stops when the output looks finished, which is precisely when a reviewer is most needed and least prepared.
- Judgement calls with no right answer. Architecture, naming that has to survive five years, whether a feature should exist. An agent will produce a confident choice and no reasoning you can audit.
- Wide, cross-cutting change. Forty files across three subsystems does not get reviewed. It gets skimmed, approved, and understood a week later when something breaks.
What running one actually looks like
You write a task, decide how much autonomy to grant, then read a stream of tool calls until it stops. Most of the skill sits in the two decisions either side of the run — what you asked for, and whether you accept the diff. The middle is mostly waiting, which is the part nobody warns you about.
Three shapes are on offer, and they differ in where the code runs more than in what the model does:
- A terminal agent runs on your machine in your own checkout, with your environment variables and your dependencies. Fastest feedback, most trust required, and it is your working tree at stake — how to set one up and point it at a task is a walkthrough in itself.
- An editor agent lives in the IDE and shares its context — open files, selection, language server. Convenient, and easy to mistake for autocomplete until it runs something.
- A cloud agent runs somewhere else and returns a branch. GitHub's Copilot cloud agent, for example, "has access to its own ephemeral development environment, powered by GitHub Actions", and its documented ceilings are worth knowing before you build a workflow on it: a session has "a maximum execution time of 59 minutes", and it "can only work on one branch at a time and can open exactly one pull request to address each task".
The other dial is permissions, and it deserves a decision rather than a default. Claude Code's documented tiers are a fair model of the category: read-only tools need no approval inside the working directory, Bash commands do "except a built-in set of read-only commands", and file modification always does. Modes run from plan, where the agent "reads files and runs read-only shell commands to explore but doesn't edit your source files", up to bypassPermissions, which the same docs tell you to "only use ... in isolated environments like containers or VMs where Claude Code can't cause damage".
The realistic failure is not dramatic. It is habituation: around the tenth approval prompt you stop reading them, and from there the allowlist you configured is the only boundary still doing anything. Set it deliberately, while you still care.
Where AI coding agents fail
Three places, in rising order of cost: no stopping condition, an unreviewable diff, and confident wrongness that reads exactly like competence. The third is the expensive one, because nothing in the output distinguishes a correct change from a plausible one — that is the reviewer's job, and it does not get easier with practice.
The first two are scoping problems and they are yours, not the model's. Name the check before you write the prompt. Keep the task small enough that you can describe the expected diff in two sentences; if you cannot, split it before you start rather than after.
The third has been measured. In a randomised controlled trial, METR had experienced open-source developers work real issues in their own mature repositories with and without AI tooling. They were 19% slower with it — and afterwards still believed they had been about 20% faster. The tooling was early-2025 and has moved since; the perception gap is the durable finding, and it does not close on its own. Our guide to the practice covers that study, and the harness argument around it, in more detail.
What changes when you run more than one
Nothing about the agent changes. What changes is that your working tree can only be in one state, your attention can only be in one place, and diffs start arriving faster than you can read them. The constraint moves off the model — where it was never really binding — and onto isolation and review.
Isolation is the easy half and it is a solved problem. Git worktrees give each run its own directory and branch off one repository, so two agents can work at once without fighting over your checkout; Claude Code now ships a --worktree flag that does the bookkeeping for you. Budget a minute for what a fresh checkout does not carry: your .env, your installed dependencies, a free port.
Review is the hard half, and it is the reason the arithmetic stops working. Generation capacity went up by a large multiple. Review capacity went up by roughly nothing. Every extra agent adds a diff that some human has to understand well enough to defend in a month, and the review bots triage that queue without ever closing it — none of them will take responsibility for a merge.
This is the problem we built Fredrin around, so weigh the next sentence accordingly: the useful response is to make review cheap and structured, not to make generation faster still. One branch per task, a check that already ran, a diff small enough to read in full, and a stated reason when something goes back. Two runs you review properly beat six you skim.
FAQ
Is an AI coding agent the same as an AI coding assistant? No. An assistant answers and waits; an agent acts and observes the result. The practical test is whether the tool can run a command and change its own next move based on the output. If it cannot, it is an assistant with good marketing.
Do I need a paid tool to try one? No. A terminal agent pointed at a git repository with a working test command is enough, and it is the cheapest way to find out whether the loop suits your work. Tooling starts to matter when you want more than one run going at once.
How autonomous should I let it be? As autonomous as your isolation justifies. Full-permission modes are defensible in a container or a throwaway worktree and reckless in your main checkout. Decide once, in settings, rather than under pressure at the tenth approval prompt.
How many agents can one person run? As many as they can review, which is a fact about you and your codebase rather than about the tool. Anyone quoting a universal number is selling something. Add one at a time and stop when your diff reading gets shallow.
Does an agent replace code review? It does the opposite. Review stops being a step at the end and becomes the main event, because it is the only station in the pipeline that did not get faster.
Fredrin is a desktop kanban for running many coding agents in parallel — every ticket gets its own branch, worktree, and agent session, and lands as a pull request you review. Free on macOS and Windows, on the AI subscription you already pay for: fredrin.com.
