Agentic Coding: Building Software With AI Agents in the Loop

Agentic coding is the practice that sits underneath all the talk about AI writing software: an engineer directs an AI agent through real work, and the agent plans, edits, runs a check, reads the result, and tries again until it passes. You set the goal and review the diff. It does the typing and the trial-and-error. That is the whole shift, and it is more useful and more demanding than either the hype or the backlash suggests. This guide covers what agentic coding actually means, how the loop runs, what changes in your day when you work this way, where agents earn their keep versus where they spin, and the guardrails that keep all of it shippable, including in a codebase where a mistake has consequences. We build with agents in the loop on every project, so this is the practitioner's view.

What agentic coding means

Agentic coding is building software by directing an AI agent that operates in a loop (reading your code, proposing a plan, making changes, running a check it can read, and iterating until the check passes) while a human sets the direction and reviews what ships. An AI agent is a language model placed in that loop with tools it can call and a goal to work toward; that one sentence is all the definition this article needs, because the interesting part here is not what an agent is but how you point one at a real engineering problem.

The fastest way to understand agentic coding is to place it against the two things it gets confused with.

• Versus autocomplete. Autocomplete finishes the line or block you are already typing. You read every character, and the change never leaves the file you are in. It is a faster keyboard, not a different way of working.
• Versus vibe coding. Vibe coding is the mode where you describe what you want and accept the result by whether it runs, without reading the code. It is fast and fine for throwaway prototypes, and a liability the moment something has to ship and be maintained.

Agentic coding lives between the two, and the distinction is the entire point. The agent has real autonomy: it decides which files to touch, in what order, and how many steps to take. But a human reviews the plan before it acts and the diff before it merges. You get the payoff of handing off a whole task, without giving up the understanding that makes the result safe to put in production. Vibe coding throws away the review; agentic coding keeps it and lets the agent do the work in between.

Vibe coding is letting the agent own the code. Agentic coding is letting the agent do the work while you own the code. The gap between those two sentences is where production software lives.

This is not a future capability. As of mid-2026, agentic coding is how a large share of professional development gets done: the 2025 DORA report found 90% of technology professionals now use AI at work, and the more capable tools are squarely agentic rather than autocomplete. The question for an engineering team is no longer whether to work this way. It is how to do it without shipping the instability that the same DORA report warns comes with it.

How an agentic coding loop works

The engine of agentic coding is a loop with four phases (explore, plan, act, review) that repeats until the work is done or you stop it. This is not a vendor's marketing diagram. It is the workflow Anthropic's own Claude Code documentation recommends, and the shape holds across coding agents in general.

Walk through one pass:

1. Explore. The agent reads the files that matter and answers questions about how the code works, without changing anything. The goal is to load the right context before it commits to an approach. As the docs put it, "letting Claude jump straight to coding can produce code that solves the wrong problem."
2. Plan. The agent proposes what it intends to do: which files change, what the sequence is, what the tricky parts are. You read the plan, push back, and adjust it before a single line is written. This is the cheapest place to catch a wrong approach, because nothing has been built yet.
3. Act. The agent implements the change and runs a check it can read: a test suite, a build, a linter, a script that diffs output against a fixture. The check is what closes the loop: the agent "does the work, runs the check, reads the result, and iterates until the check passes."
4. Review. A human reads the diff and decides whether it merges. For longer or riskier work, a second agent reviews the change in a fresh context first, seeing only the diff and the criteria, so the thing that wrote the code is not the only thing grading it.

The single most important property of the whole loop is the check in the act phase. Without something that returns a pass or fail, "looks done" is the only signal the agent has, and you become the verification step for every mistake. With a runnable check (tests, a build exit code, a screenshot compared against a design) the loop self-corrects, and an agent can grind through a task while you do something else. The Claude Code docs are blunt about it: "If you can't verify it, don't ship it." Everything good about agentic coding follows from a check the agent can run; everything that goes wrong tends to trace back to its absence.

Two practical mechanics make the loop reliable. First, context is the constraint. An agent reasons only about what it can see, and its context window fills fast and degrades as it does. The tools that work best on real codebases are the ones that can read the whole repo, and the practice that works best is feeding the agent your conventions and architecture up front rather than one isolated prompt. Second, scope each pass small. One coherent change, verified, then the next. Not the whole feature in one shot, which produces a tangle too big to review and too entangled to debug.

What changes in your workflow

The day-to-day job shifts from writing code to setting direction and reviewing results. You spend less time typing implementation and more time on the two things the agent cannot do for you: deciding what should be built and judging whether what got built is right.

In practice the work redistributes:

• More time specifying. The quality of the output tracks the quality of the instruction. A precise task (which file, which scenario, what "done" looks like, what to avoid) gets a usable result in one pass; a vague one gets plausible code that misses the point. The Claude Code docs frame the upgrade plainly: instead of "add tests for foo.py," you say "write a test for foo.py covering the edge case where the user is logged out, avoid mocks." The specifying is now part of the engineering.
• More time reviewing. Reading a diff you did not write is a distinct skill, and it is the one that separates senior agent use from junior. You are checking for the SQL injection the agent cheerfully introduced, the edge case it skipped, the three working things it rewrote to fix one. This is the same discipline that makes pairing with AI work for senior engineers: the human stays the reviewer of record.
• Less time on the keystrokes. The mechanical part (scaffolding, boilerplate, the fourth near-identical handler, the migration across forty files) is where the agent is genuinely fast, and where handing it off is pure gain.

There is a real risk in this shift, and it is worth naming. When the agent does the typing, it is easy to stop building the mental model of the system that writing the code used to give you for free. The engineers who stay effective treat the plan and the review as where their understanding lives now. They read the plan closely enough to catch a wrong approach, and the diff closely enough to stand behind it. Skip both and you are vibe coding with extra steps, inheriting a codebase nobody understands at the speed of an agent.

The correction loop changes too. The best results come from interrupting the agent the moment it goes off track rather than letting a bad run play out, and from resetting context when a task is going in circles rather than piling more corrections onto a polluted conversation. The Claude Code docs put a number on the instinct: "after two failed corrections," start fresh with a better prompt. Tight feedback beats long sessions, the same way it does with a junior engineer.

Where agents earn their keep versus where they thrash

Agents earn their keep on tasks that are well-scoped, verifiable, and self-contained, and they thrash on tasks that need context they cannot see or have no runnable check. That single distinction predicts most of the value and most of the frustration.

The work where agentic coding reliably pays off:

• Writing tests against existing behavior, where the code is the spec and the test runner is the check.
• Mechanical refactors and migrations: renaming across a codebase, moving a pattern from one framework to another, applying the same change to many files. Bounded, repetitive, verifiable.
• Scaffolding and boilerplate: new endpoints, components, and CRUD that follow an established pattern the agent can be pointed at.
• Fixing a failing build or a reproducible bug. Give the agent the error and a failing test, and the loop has a clear target to close on.
• Exploring an unfamiliar codebase. Asking an agent how logging works or where a behavior lives is faster than grepping, and it is read-only, so the blast radius is zero.

The work where agents thrash:

• Changes deep in a system whose constraints live in someone's head. This is the failure the data is clearest on. A 2025 METR randomized controlled trial put 16 experienced developers on 246 real tasks in large repositories they maintained (averaging over 22,000 GitHub stars and a million-plus lines of code) and found AI made them 19% slower, even though they had predicted a 24% speedup and still believed afterward that it had sped them up. The context the agent needed was in their heads and the implicit standards of the project, not anywhere it could read.
• Problems with no check the agent can run. If "done" cannot be expressed as a test, a build, or a comparable output, the loop has nothing to close on and the agent guesses.
• Vague tasks. "Make it better" gives the agent nothing to aim at. Without a clear success condition you cannot steer, and neither can it.
• Anything where one wrong step is catastrophic and irreversible. The loop tolerates mistakes by re-running; tasks that do not tolerate mistakes break the premise.

Read the METR result honestly and it is not "AI does not work." It is that AI helps least exactly where a senior engineer's tacit knowledge is doing the heavy lifting, and most where the task is legible enough to hand off. Matching the agent to the right tasks is the skill. The teams getting value are not the ones pointing an agent at everything; they are the ones who know which half of the work to hand over.

Guardrails in a real codebase

The guardrails for agentic coding are the same discipline as good engineering, tightened around the fact that an autonomous process is now making changes. Four of them carry the weight, and skipping any one is how a fast demo becomes a slow incident.

A verification target the agent can run. This is the load-bearing guardrail, the one the whole loop depends on. Every task gets a check the agent reads in the conversation: a test, a build, a linter, a script that diffs against a fixture. The Claude Code docs describe several ways to enforce it, from asking the agent to run the check in the same prompt, to a stop condition a separate model re-checks every turn, to a deterministic gate that blocks the work from ending until the check passes. Pick the strength that fits the stakes, but never run the loop without one.

Scope limits. A task should touch a bounded set of files, and the agent's permissions should be constrained to what the task needs. Unscoped investigations are a known failure mode. The docs call it "the infinite exploration," where an agent reads hundreds of files and fills its context with noise. You scope the task narrowly, restrict which commands and paths the agent can touch, and for unattended runs let a classifier block anything that looks like scope escalation. An agent with real tools and no scope limits is a process that can change more than you intended in a loop you did not fully predict.

Human review of every diff. Nothing merges that a person has not read and understood. This is the one rule that turns agentic coding from a liability into a tool, and it does not bend. For substantial changes, add an adversarial pass: a second agent reviews the diff in a fresh context, seeing only the change and the criteria, then reports gaps to the engineer. A reviewer with no memory of the reasoning that produced the code catches things the author (human or agent) is blind to. The standing caution from the docs is to tell that reviewer to flag only real correctness or requirement gaps, because an agent asked to find problems will always find some, and chasing all of them leads to over-engineering.

The same gate every change clears. Agentic coding does not get a lighter path to production. The diff still goes through tests, security scanning, and review against an architecture a human owns. This is where the DORA finding becomes operational rather than abstract: AI raises delivery throughput, but "without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability." The agent increases the change volume. The control systems are what keep that from turning into breakage. You do not relax the gate because an agent wrote the code; if anything you lean on it harder, because more code is moving through it.

The pattern across all four: the agent generates and iterates fast, and the guardrails make sure a human still understands and stands behind what ships. The acceleration is real, and it lasts precisely because the team kept the parts that pure vibe coding throws away. Where the agent connects to your actual systems (your database, your docs, your internal services) the Model Context Protocol is increasingly how that connection is made through a standard interface, and teaching an agent your stack once through reusable Claude Code skills is how you keep its output fitting your conventions instead of fighting them. Both extend the same principle: give the agent the context and the constraints, and the loop does honest work.

Agentic coding in a regulated codebase

In regulated work, agentic coding is not off the table. The guardrails get tighter, not looser, and the speed comes from the agent drafting while the compliance comes from a gate that does not move. This is the part that decides whether AI-native delivery is a marketing line or something you can defend in an audit, and it is where we spend the most care.

The principle is simple: the agent accelerates the build, and the controls that make the work compliant sit exactly where they always did. A change to code touching payments, personal data, or anything irreversible still passes human review, still runs through automated tests and security scanning, and still leaves an auditable trail of who approved what and why. The agent makes the first draft faster. It does not get to be the thing that vouched for the change.

Three adjustments matter when the stakes are regulatory rather than just functional:

• Scope agent permissions narrowly. The riskier the surface, the tighter the leash. An agent working near authentication or financial logic gets read access to the context it needs and a constrained set of actions, with writes to sensitive paths gated. The blast radius is bounded by design, not by hoping the agent behaves.
• Keep irreversible and high-stakes actions behind human approval. The loop is safe because it re-runs cheaply; anything that cannot be cheaply undone (a migration on production data, a release, a permission change) needs a person in front of it. You decide which actions an agent may take autonomously and which require a hand on the switch.
• Never let the agent be the only reviewer. An adversarial agent review is a useful first pass, but in regulated code a human is always the last signature. The trail of why (the commit messages, the review, the test that pins the behavior) is what makes the system maintainable and auditable years later, when the people who built it have moved on.

This is exactly how we work. We have built production software where the bar is high: an eIDAS-qualified e-signature platform, a digital-banking platform, supply-chain systems carrying real money and real liability. The AI-native method holds up there because the gate holds up there. Across our engagements, the senior-engineers-plus-agents model runs a roughly 42% shorter cycle time than a non-AI baseline, and it does that without cutting review, because the cycle gets shorter in the drafting and stays exactly as rigorous at the gate. That is the operating model we are compounding toward 2028. AI-accelerated delivery clients can feel, with the discipline regulated work demands kept fully intact.

The reason this matters beyond compliance is that it is the honest answer to the whole agentic coding question. The technology is real and the speed is not a lie, and the failures (the thrash, the instability, the code nobody understands) are just as real. The teams that come out ahead are not the ones who hand the most to agents or the least. They are the ones who let agents do the work where it is cheap to be wrong, and keep the boring discipline exactly where being wrong is expensive. That judgment (knowing which mode the moment calls for and where the gate cannot bend) is the craft of the modern AI software engineer, and it is the kind of engineer we hire.