FredrinAgentic coding is when you hand an AI a goal instead of a line, and it works your repository the way you would — reading files, editing them, running commands, reading what comes back, and trying again until some check passes. The term has been stretched to cover anything with a chat box in it, which is exactly why it is worth pinning down.
This guide defines it, separates it from the two things it keeps getting confused with, and is honest about where it fails. One argument runs underneath all of it, stated up front so you can disagree early: the model is no longer the interesting variable. The harness around it is.
What is agentic coding?
Agentic coding is a loop, not a feature. You state an outcome; an AI coding agent — a model with tool access — reads your code, writes changes, executes commands, reads the results, and repeats until a condition holds. The defining property is that feedback loop — the model observes the consequences of its own edits and corrects them without you in the middle.
Three things have to be true before the word applies. The model needs tools — a way to read and write files and run commands, not just emit text. It needs a workspace — a real checkout, with your dependencies and your test command, not a sandboxed snippet. And it needs a stopping condition — something that returns pass or fail, so "done" is a fact rather than a vibe.
Anthropic's own documentation draws the line in the first sentence: Claude Code is "an agentic coding environment", and unlike "a chatbot that answers questions and waits", it "can read your files, run commands, make changes, and autonomously work through problems". That is the distinction, and it is a distinction about capability, not about interface. Getting it installed and pointed at a task takes about five minutes; the loop it then runs is the subject of this post.
Agents vs autocomplete vs chat-assisted coding
Autocomplete predicts the next few tokens at your cursor. Chat-assisted coding answers a question and hands you something to paste. An agent is given a task and a workspace, and then it acts — deciding what to read, what to change, and what to run. Each changes a different unit of work, and each moves your effort somewhere else.
| Autocomplete | Chat-assisted | Agentic | |
|---|---|---|---|
| You supply | A cursor position | A question | A goal and a repo |
| It supplies | The next tokens | An answer to paste | A diff, and the commands it ran |
| Sees its own results | No | No | Yes — that is the loop |
| Unit of work | A line | A snippet | A task |
| Your job | Accept or reject | Integrate it | Review it and ship it |
Read the bottom row twice, because it is the whole argument. Autocomplete and chat both leave you as the author; the AI is a faster keyboard. An agent makes you the reviewer of work you did not write. That is a genuinely different job, with a different failure mode, and nobody hands you the skill for it when you install the tool.
Most products now do all three, which is why the categories blur in marketing copy. Judge a tool by what it does when you walk away for twenty minutes, not by what its landing page calls itself. Our survey of the tool landscape sorts the current crop by shape rather than by claim.
Why the harness matters more than the model
A harness is everything wrapped around the model: the tools it can call, the context it is handed, the isolation it works inside, and the check that decides when it is finished. Frontier vendors now ship broadly comparable coding capability, so the harness is what separates a run that lands from a run that thrashes for an hour.
You do not have to take that on faith. Open the SWE-bench Verified leaderboard — the benchmark the field measures itself on — and judge for yourself how much daylight is left between the leading entries, and how much of each entry is scaffolding rather than model. Then notice what the vendors themselves write about. Anthropic's best-practices guide for Claude Code is almost entirely a harness document. Its strongest piece of advice is not a prompting trick — it is "Give Claude a way to verify its work", because "Claude stops when the work looks done" and "without a check it can run, 'looks done' is the only signal available".
Four parts of the harness do most of the work:
- Context. The model's context window is the scarce resource, and performance degrades as it fills. What you put in it — and what you keep out — matters more than which model reads it.
- Tools and permissions. What the agent may run decides what it can finish unattended. Too tight and you approve every command; too loose and you are trusting a machine with your shell.
- Isolation. Git worktrees give each run its own working directory and branch off one repository. Anthropic's worktree guide puts the reason plainly: "edits in one session never touch files in another, so one session can build a feature while a second fixes a bug".
- Verification. A command that exits zero or non-zero is the difference between a session you watch and one you walk away from.
Swap the model under a good harness and the outcome usually survives. Swap the harness under a good model and it often does not. That asymmetry is the practical content of "the models have converged" — and it is why the interesting engineering has moved outward, into the thing holding the model.
What actually changes in your day
Your hands leave the keyboard and your attention moves to a queue. You spend the day writing task descriptions, watching checks go green or red, reading diffs, and deciding what ships. Typing stops being the constraint. Reading becomes it — and reading does not get faster just because generation did.
The arithmetic is not subtle. The moment one task can run unattended for twenty minutes, standing over it is waste, so you start a second. Then a third. Every one of them eventually produces a diff that a human has to understand well enough to defend. Generation capacity went up by a large multiple; review capacity went up by roughly nothing. The queue backs up at the only station that did not get faster — and the reviewer bots, plus the failure modes they miss, are what that station actually looks like today.
This is the part we built Fredrin around, so treat the next sentence with appropriate suspicion: the useful response is to make review cheap and structured, not to make generation faster still. Small diffs, one branch per task, a check that already ran, and a stated reason when something goes back. The review-side habits are in shipping AI-generated code a client will accept; the case for the board shape is in cmux solved spawning; Fredrin solves shipping.
Where it breaks down
It breaks in three places: when there is nothing to verify against, when the task is big enough that its diff is not reviewable, and when you feel fast without being fast. The third one is the dangerous one, because the feeling is real, it is pleasant, and it does not track the clock.
That last failure has been measured. In a randomised controlled trial, METR had 16 experienced open-source developers work 246 real issues from their own repositories, with AI tools allowed on half of them. The developers expected a 24% speed-up. They were 19% slower. Afterwards, having just been slowed down, they still believed the tools had sped them up by 20%.
Two honest caveats, because the study gets over-quoted in both directions. It used early-2025 tooling, and the harnesses have changed a great deal since. And it used developers with deep familiarity with large, mature repositories — close to the worst case for a tool whose main advantage is not having to learn the codebase first. But the perception gap is the durable finding, and no amount of tooling progress makes it go away on its own. If you are judging agentic coding by how it feels, you are not judging it.
The other two failures are more tractable. No check means no stopping condition, so the agent halts at "looks plausible" and hands you the verification job it was supposed to do. An unreviewable diff is an unshippable diff: 40 files touched across three subsystems does not get reviewed, it gets skimmed and approved, and the defect it carries surfaces a week later with nobody able to say why the code is like that. Both are scoping problems, and both are yours to fix, not the model's.
Getting started without rebuilding your workflow
Pick one repository whose test command already works. Take a task you would hand a competent new hire. Write down the check that proves it is done before you write the prompt. Run it once, read the entire diff, and only then think about running a second one alongside it.
- Name the check first. "The build passes and
pnpm testexits zero" is a stopping condition. "Make the dashboard better" is not. - Give it its own worktree.
git worktree add ../repo-task-a -b task-acosts one command and buys you a run that cannot corrupt your working tree. Budget an extra minute for what a fresh checkout does not carry with it — your.env, your dependencies, a free port. - Keep the task reviewable. If you cannot describe the expected diff in two sentences, split it before you start rather than after.
- Read the whole diff. Every line. The first time you approve one you did not read is the moment the whole approach starts costing you.
- Only then go parallel. Two runs you review properly beat six you skim. The limit is your review throughput, and you will find it faster than you expect.
Nothing on that list requires new software. It requires a check, a branch, and the discipline to keep reading.
FAQ
Is agentic coding the same as vibe coding? No. Vibe coding describes an attitude to the output — you describe what you want and accept the result without closely reading it. Agentic coding describes a mechanism: a model with tools, a workspace, and a stopping condition. You can run one under rigorous review, and most people should.
Do I need a new tool to try it? No. A terminal agent in a git repository is enough, and that 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, because that is when isolation and review become the constraints.
Does it replace code review? The opposite. Review stops being a step at the end and becomes the main event — it is the step that did not get faster, so it is the one that sets your throughput.
How many agents can one person actually run? As many as they can review, which is a number about you and your codebase rather than about the tool. Anyone quoting you a universal figure is selling something. Find yours by adding one at a time and stopping when your diff reading gets shallow.
Is it safe to let an agent run commands? It is as safe as the boundary you give it. Permission allowlists, OS-level sandboxing and per-task worktrees are the standard controls, and every serious agent ships some combination. The unsafe configuration is the one where you approve everything unread — which is what happens after about the tenth prompt.
Fredrin is a desktop kanban for running many coding agents at once: every ticket gets its own branch, worktree and agent session, and lands as a pull request you review. Closed alpha on macOS, on the AI subscription you already pay for — fredrin.com.
