Last reviewed: 14 October 2026 ·
Agentic coding is the practice of directing AI agents to plan, write, test and revise code autonomously across multi-step tasks, with an engineer steering intent and reviewing outputs rather than typing every line. The agent holds context across a whole feature or refactor, calls tools like linters and test runners, and loops until it satisfies a defined condition. The engineer's job shifts from writing syntax to setting constraints, reviewing results and knowing when to override.
Quick facts
- Agentic coding is not autocomplete: the agent executes multi-step plans, not single-line suggestions.
- The engineer remains the decision-maker; the agent is the executor.
- Agents call real tools: terminals, test runners, linters, file systems and APIs.
- Code still needs human review before it ships, agentic coding multiplies output, it doesn't remove accountability.
- Lean before agents applies: automating a broken process with an agent produces broken code faster.
- Small engineering teams gain the most: one senior engineer directing agents can cover ground that previously needed three.
How does agentic coding differ from GitHub Copilot or standard AI autocomplete?
Autocomplete predicts the next token. Copilot suggests the next line or block. Both wait for the engineer to type, accept, reject and move on. Agentic coding works the other way: you describe a goal, and the agent breaks it into a plan, executes each step, checks the result, and iterates.
A concrete example. Ask an autocomplete tool to "add input validation to the checkout form". It suggests code. You copy it, check it, wire it in. Ask an agentic coding tool the same thing and it reads the existing form components, writes the validation logic, runs the test suite, spots a failing test, revises the code, re-runs, and hands you a diff when it's confident the tests pass. You review the diff. You decide what ships.
That difference in loop size is what matters. Autocomplete shortens a keystroke. Agentic coding shortens a sprint.
What does an agentic coding session actually look like?
The engineer opens a task: "Refactor the booking confirmation emails to use the new template system. Don't change the plain-text fallback." The agent reads the relevant files, identifies every place the old template is called, drafts replacements, runs the existing tests, flags two tests that now fail, proposes fixes for both, and surfaces a summary. The engineer reviews the summary, checks the two edge cases the agent flagged, approves or adjusts, and commits.
What the engineer didn't do: navigate eight files manually, write boilerplate, remember which tests covered email formatting, or spend twenty minutes on a diff that could be ten seconds of reading.
What the engineer still did: set the constraint ("don't change the plain-text fallback"), review the output, and decide whether the agent's fix for the failing tests was correct or a workaround that hid a real problem.
That last part is where experience still matters. An agent will satisfy a test condition. A senior engineer asks whether the test was testing the right thing in the first place.
What is strategic programming, and why does it matter here?
Strategic programming is a framing I use to describe what the engineer's role becomes in an agentic setup. The agent handles tactical execution: write this function, fix this lint error, update this dependency. The engineer handles strategy: what should this system do, what are the invariants, what does "done" actually mean.
This maps directly to how I think about team shape. I use a framework called Knowledge, Skills, Wisdom (KSW). Knowledge is facts the agent can hold. Skills are tasks the agent can execute. Wisdom is judgement about when the plan is wrong, when a passing test is a lie, and when the right answer is to stop and redesign. Wisdom stays human.
Strategic programming means the engineer spends their hours on the decisions that require wisdom, not on the execution that requires only knowledge and skills. The agent covers the latter. The engineer keeps the former.
If you want a weekly read on what's actually working in agentic engineering, join the Friday agent log, I write what ran, what broke and what I changed that week.
Does agentic coding work for small engineering teams?
Small teams gain the most from it, and I say that from direct experience. When you have two or three engineers, you can't afford to have a senior spend a day on a refactor that an agent can scaffold in an hour. The senior reviews and steers. The agent executes. You get senior-quality output on more tasks simultaneously.
The frame I use at Toro's agentic engineering practice is "seniors multiplied, not staff replaced". The agent doesn't replace an engineer; it removes the parts of engineering work that don't need a human brain. Boilerplate, test scaffolding, dependency updates, initial draft implementations. The engineer's time goes on architecture, review, and decisions that require context the agent doesn't have.
There's a related concept I apply to team adoption: ZPD for teams. ZPD stands for Zone of Proximal Development, borrowed from learning theory. It means introducing agentic tools at the point where a junior engineer can do more with agent support than without it, while a senior can review agent output faster than they could write from scratch. Push too fast and the team ships code nobody understands. Move too slowly and you've paid for a tool that sits idle.
What breaks when teams adopt agentic coding badly?
Three failure patterns come up repeatedly.
Vibe coding. The engineer accepts agent output without reviewing it because it looked right. Tests pass. It ships. Three weeks later a bug surfaces that the tests didn't cover and nobody can explain the code because nobody actually read it. This is the single most common failure. It's not an agent problem; it's a review process problem.
Automating a broken process. This is the principle I call lean before agents. If your pull request process is chaotic, your test coverage is poor, and your codebase has no clear module boundaries, an agent will write code that reflects all of that chaos, faster. You need to fix the process before you accelerate it. I applied this thinking before I ever touched an AI tool; it comes from lean manufacturing, where the rule is that you remove waste before you automate the remaining steps.
No human in the loop at the right point. Agents are good at satisfying conditions you give them. They're not good at telling you the condition was wrong. If you define "done" as "all tests pass" and your test suite has gaps, the agent will find a way to pass the tests. The engineer's job is to define conditions that can't be gamed by a technically-correct-but-wrong implementation.
The agentic engineering work we do with clients usually starts by identifying which of these three is already present before we change any tooling.
How does this connect to real product work?
We run agentic workflows across our own platforms, including Campercation, which runs a live searchable map that currently shows 25,000+ stopovers as at 14 October 2026. The content pipeline that keeps that data current, enriched and structured runs with minimal manual input. The engineering work behind it was built using the same agentic coding practices I've described here: agents scaffolded the integration code, engineers reviewed and set the constraints, and the loop runs without someone manually pushing updates.
That's the point. Agentic coding isn't a development-only productivity trick. It shapes what you can build and maintain with a small team. A three-person engineering team with agentic practices can own a product surface that would have needed six people writing every line by hand.
If you want to know whether your codebase is in shape to introduce agentic coding without hitting the failure patterns above, a codebase review is the right starting point.
Frequently asked questions
What is agentic coding?
Agentic coding is the practice of directing an AI agent to plan, write, test and revise code across multi-step tasks. Unlike autocomplete tools that suggest the next line, an agentic coding agent holds context across a whole feature, calls tools like test runners and linters, and loops until it meets a defined condition. The engineer sets intent, reviews output and decides what ships.
Is agentic coding the same as vibe coding?
No. Vibe coding means accepting AI-generated code without reviewing it because it looks plausible. Agentic coding is a disciplined practice where the engineer sets constraints, the agent executes, and the engineer reviews the diff before anything ships. Vibe coding skips the review step and is the most common failure mode when teams adopt agentic tools without a clear process.
Does agentic coding replace software engineers?
No. It changes what engineers spend their time on. The agent handles tactical execution: writing boilerplate, scaffolding tests, updating dependencies. The engineer handles strategy: setting constraints, reviewing outputs, making architectural decisions and applying judgement the agent can't replicate. The frame is seniors multiplied, not staff replaced. Teams that understand this distinction get the most from it.
What tools are used for agentic coding?
The category includes tools like Cursor, Claude Code and GitHub Copilot Workspace, among others. What makes a tool agentic rather than autocomplete is whether it can execute a multi-step plan, call external tools like terminals and test runners, and iterate based on the output. Toro only discusses tools it has used directly on its own codebases and client work.
What should a small engineering team do before adopting agentic coding?
Apply lean before agents: remove process waste before you accelerate it. If your codebase has no clear module boundaries, poor test coverage or a chaotic PR process, an agent will reflect that chaos faster. Fix the underlying process first. Then introduce agentic tools at the point where engineers can review output faster than they could write from scratch, that's the zone where the productivity gain is real.
How do you review AI-generated code in an agentic coding workflow?
The same way you review any code: read the diff, check that tests cover real behaviour not just pass conditions, and ask whether the implementation satisfies the original intent or just the stated condition. The difference is that with agentic coding you're reviewing a complete draft rather than incremental lines. This makes a clear definition of 'done' and good test coverage more important, not less.
