Agentic Software Engineering: What Changes When Agents Do the Implementation

Agentic software engineering is what changes when an AI system doesn't just suggest code but runs the loop itself: reading a task, writing the implementation, running it, checking the result, and deciding what to do next, with a person setting the boundaries instead of typing every line. As of September 2026, the shift isn't about the model getting smarter. It's about four jobs moving to a different owner: the spec has to be precise enough for a machine to execute without asking a follow-up question, someone has to orchestrate which agent does what and in what order, verification has to happen on code nobody personally wrote, and accountability for what ships still has to land on a person, not the tool that typed it.

What is agentic software engineering?

Agentic software engineering is the practice of building software where an AI system runs an autonomous loop, deciding an action, executing it, checking the result, and repeating, to implement code rather than only suggesting it one line at a time. A person still defines the task, the constraints, and what counts as done.

The clearest definition I've found for what actually counts as "agentic" comes from Simon Willison, a developer well known for tracking this space closely: an agent is a system that runs a loop of deciding an action, taking it, and checking the result, repeating until the job is done or it gives up. That loop, not the size of the model behind it, is what separates an agentic coding tool from an autocomplete-flavored assistant. Tools like GitHub Copilot started on the assistant end of that line, finishing a line you were already typing. Tools like Cursor and Claude Code can sit further along it, taking a task, editing multiple files, running the tests, and iterating on the failures without you approving every intermediate step. This is the mechanism behind the shift I wrote about in Will AI Replace Software Engineers in 2026?: it's not that a smarter model replaces the engineer, it's that the loop moves from human-typed to agent-run, and the job becomes running that loop well.

How is agentic software engineering different from AI-assisted development?

AI-assisted development keeps a person driving: they write most of the code and use AI for suggestions, boilerplate, or explanations, staying in the editor the whole time. Agentic software engineering hands the driving to the agent for a bounded task, and the person's job moves to setting up that task and checking the result.

Here's the comparison I actually walk a team through when someone asks whether we're "doing AI" or "doing agents," because the two get treated as the same thing and they aren't:

Neither column is the "better" way to build software. In my experience, most real work still sits in the assisted column, and it should: a lot of engineering is small, contextual, and faster to just type than to specify. The agentic column earns its keep on bounded, well-defined tasks, a migration script, a test suite for an existing module, a defined feature with a clear spec, where the cost of writing a precise task description is lower than the cost of typing the implementation by hand.

What changes about specification when an agent writes the implementation?

A spec written for a human engineer can lean on shared context and a follow-up conversation to fill gaps. A spec handed to an agent has to state the acceptance criteria, edge cases, and constraints up front, because the agent will execute exactly what's written rather than pause to ask a clarifying question the way a teammate would.

I've watched this go wrong the same way more than once: a task description that would have been perfectly fine handed to a mid-level engineer, because that engineer would ask "wait, what should happen if the input is empty?" before writing a line, produces confidently wrong code from an agent that just picks an answer and moves on. The gap isn't intelligence. It's that a person absorbs a hallway conversation's worth of unstated context, and an agent only has what's in the prompt and the repository in front of it. The honest fix is unglamorous: write down the edge cases, the acceptance criteria, and the definition of done before the agent starts, the same discipline behind test-first and behavior-first specification, just enforced earlier and more literally than it used to be.

Who orchestrates the work once an agent is doing the typing?

Orchestration becomes a named job once agents do the implementation: someone has to decide which task goes to which agent, in what order, and what happens when one agent's output feeds the next step. That job used to live implicitly in whoever picked up the ticket; with agents it has to be explicit or the work stalls or duplicates.

One thing nobody talks about enough: a single agent working one task at a time doesn't need much orchestration, you just wait for it to finish. The job shows up the moment more than one task is in flight, because agents don't naturally know that the database migration another agent is writing needs to land before the feature branch that depends on it. On a small team, this can be one person's judgment call, made explicitly instead of assumed. On a larger one, it starts to look like planning work that used to be distributed across a team's shared understanding of the codebase, now concentrated into whoever is sequencing the agents. The same bounded-pilot discipline I laid out in an AI adoption framework, start small, prove workflow fit, then scale, is the safest way I've found to hand a team its first orchestration job instead of turning every agent loose on the backlog at once.

How do you verify code that no person on the team actually wrote?

You verify it the same way you'd verify code from a contractor you've never met: tests that actually exercise the behavior, a human review focused on the decisions rather than the syntax, and running it against real data before it reaches production. The agent's confidence in its own output is not evidence; the tests and the review are.

The honest answer is that this shifts what review time is for. Reviewing a human teammate's pull request, you're often catching style, naming, and small logic slips, because you trust they understood the problem the way the team understands it. Reviewing an agent's diff, the style is usually fine and consistent; what needs checking is whether it solved the right problem, handled the edge cases the spec actually named, and didn't quietly change behavior somewhere the diff doesn't draw your eye to. That's a different skill than line-by-line code review, closer to auditing a decision than proofreading a paragraph.

Who is accountable when an agentic system ships a bug?

The person who approved the change is accountable, the same as if they had merged a junior engineer's pull request without reading it. An agent can draft the fix, but a name has to be attached to the decision to ship it, or accountability quietly disappears the moment something breaks in production.

I spent years leading engineering through acquisitions inside a regulated clinical research organization, where "who approved this and on what evidence" wasn't a philosophical question, it was an audit question with a real answer expected. That habit is the one I'd bring into agentic work before any other: the agent can write the code, but the merge, the deploy, and the decision to trust the tests still belong to a person whose name is on the approval. It depends, but in every version I've seen work, the team that kept a clear, boring answer to "who approved this" was the one that could actually use agents for more of the implementation over time, not less, because nobody was quietly hoping the tool would absorb the blame if something went wrong.