The definition, briefly
Agentic coding is the mode where you describe an outcome and a tool works through it in a loop: reading files, editing, running tests, reacting to the failures, continuing. That loop is the difference from autocomplete. Autocomplete finishes your line. An agent finishes your afternoon, sometimes in a direction you did not intend.
Claude Code, Cursor, and Codex all work this way now. The differences between them matter less than whether your team has adjusted anything about how it works.
What actually breaks first
Not code quality. Review capacity.
An engineer who used to open two pull requests a day opens five. The reviewers are the same people with the same hours. Within about three weeks you can watch the approval latency climb and the review depth fall, and eventually someone approves an 800-line agent-written change with "LGTM" because the queue is eleven deep.
Other things that break in a predictable order:
- Codebase consistency. Three engineers with three agents produce three patterns for the same problem in the same week, and each one looks reasonable in isolation.
- Understanding. Six weeks later nobody can explain a module because nobody wrote it, and the person who prompted it read it once.
- Test suites, which grow fast and get shallow. Agents write tests that pass. Passing is not the same as covering.
- Onboarding. New joiners learn a codebase by writing in it. Remove that and they learn slower, not faster.
Adapting to agentic coding without losing the plot
Three changes carry most of the benefit, and none of them are tool configuration.
First, cap pull request size and hold the line. An agent will happily produce a 40-file change. Nobody reviews a 40-file change; they skim it. Small changes are worth more now than before, because the volume went up.
Second, write your conventions into a repo instructions file, at the root, in version control. Not a wiki nobody opens. The agent reads the file. The wiki does not exist as far as it is concerned. Include the things you would tell a contractor: which layer owns what, which patterns you have rejected, what the agent should never touch.
Third, make the agent run your checks before you look. If your test command works from a clean clone with no arguments, the agent can close its own loop:
npm test && npm run lint && npm run typecheck
An agent that can verify itself is a different tool from one that cannot. Teams that fix their test ergonomics get more out of the same models than teams that spend the same week comparing tools.
The honest limits
Agents are strong on well-specified work in a codebase with clear patterns. They are weak where the requirements are half-formed, which is where most real engineering time goes. They will produce a confident, plausible implementation of a misunderstanding, and it will pass the tests it wrote.
They also do not tell you when a task should not be done at all. That judgement stays with people, and it is the part of the job that just became a larger fraction of it.
What to do next
Measure one number this month: median time from pull request open to first substantive review comment. If it has grown since your team started using agents, your constraint is review, and no amount of prompting technique will fix it. Cap change size, write the instructions file, and get your test command working from a clean clone. Those three, in that order.