What is agentic coding?
An agent reads files, runs commands, edits code, checks the result and repeats. That loop is the whole difference. Autocomplete predicts your next line. A chatbot returns a snippet you paste. An agent takes an objective and works against your actual repository until it believes it is done, which means it can also be wrong for a long time without telling you.
Everything downstream of that follows from one property: the agent can verify its own work if you give it a way to. A task with a test attached is a task the agent can iterate on alone. A task where "correct" is a matter of taste is a task you will arbitrate ten times.
Your repository became an interface
The most underrated shift is that files an agent reads before acting are now load-bearing. Conventions that used to be social, held in a team's head and enforced at review, now have to be written down somewhere the agent will actually look.
Three things carry disproportionate weight:
- The project instruction file (
CLAUDE.md,AGENTS.md, whatever your tool reads). This is where conventions, constraints and prohibitions live. Prohibitions matter more than instructions, because the default failure is doing too much. - The test suite, which is the only mechanism that turns "done" from an opinion into a fact.
- Naming and structure, because an agent finds context by searching. A well-named module is discoverable; a clever one is not.
A warning from running this at scale: verify that your instruction file is actually being loaded, by testing it rather than by looking at it. We spent real time on a bug where instruction imports were silently ignored because the imported path sat outside the working directory. There was no error and no log line. The file existed, the import line was right there in the file, and none of it reached the agent. The only reliable check was to put a distinctive phrase in the imported file and ask the agent to quote it back.
Small diffs beat correct diffs
Once generation is cheap, the constraint is how much change a human can genuinely absorb. A 600-line diff that is correct is worth less than a 60-line diff that is correct, because you will actually read the second one. Approving work you did not really review is the mechanism by which agentic coding produces its worst outcomes, and it does not feel like a mistake at the time. It feels like moving fast.
The practical rules that follow are unglamorous. One concern per task. Ask for the change, not the change plus cleanup. Reject diffs that wander outside the stated scope, including improvements, because an unreviewed improvement is just an unreviewed change with better branding.
Concurrency, and the failure that looks like corruption
Two agents in one working tree will destroy each other's work. The reason it deserves a warning is that the symptom does not look like a conflict. It looks like a broken build referencing files that should exist, or a test failing on code nobody touched. We have hit this repeatedly and the diagnosis is always slower than it should be, because the mental model says "my code is wrong" rather than "something else deleted my output mid-run".
Use isolated checkouts. Push each commit immediately rather than batching at the end of a session, because a rebase in a parallel session can drop an unpushed commit and the loss is silent.
What to delegate and what to keep
A rough division that has held up:
- Delegate freely: well-specified changes with test coverage, mechanical refactors, test writing itself, migrations across many files, and exploration ("where does X happen in this codebase").
- Delegate carefully: anything touching auth, money, data deletion or schema. Not because agents are worse at it, but because the cost of a confident error is unbounded and review needs to be genuinely adversarial.
- Keep: deciding what to build, deciding what a bug actually is, and anything where the specification is the hard part. An agent cannot rescue a task nobody has thought through, and it will produce something plausible from an underspecified brief rather than stopping to ask.
The part that is genuinely uncomfortable
The skill this rewards most is evaluating whether a change is right, and that skill is built by writing code yourself and being wrong in public. Agentic coding makes the tasks that build it economically unattractive to hand to a person. This is a real structural problem, not a talking point, and no team has convincingly solved it. It is worth naming rather than pretending the transition is free.
Related reading
The operating discipline around this sits at agentic engineering. For the tools themselves, see AI coding agents, and for what changes when nobody is supervising, autonomous coding agents. Our own setup notes for individual tools are at Claude Code, Codex CLI and OpenCode. If you want the counter-argument first, read when not to use AI agents and technical debt in the AI era.
Outside our own writing, the two most useful primary sources are Anthropic's engineering notes on agentic coding practice and METR's randomised trial on experienced developer productivity, which is the rare measurement in a field mostly running on anecdote.