For most of the history of software development, writing code meant sitting in front of a computer and directly manipulating the system. A programmer read requirements, opened files, wrote functions, ran commands, examined errors, changed the implementation and repeated the process until the software worked. Tools became increasingly sophisticated, but the fundamental relationship remained the same: the human was the engineer, and the computer was the instrument.
Artificial intelligence changed that relationship first through autocomplete and then through conversational coding assistants. A developer could ask a model to explain an error, generate a function or suggest a refactoring without leaving the editor. That was a significant improvement, but the human still had to coordinate the work. The AI could produce code; the engineer remained responsible for deciding what to inspect, what to run and what to change next.
That distinction is now beginning to disappear.
A new generation of systems known as agentic software engineering treats an AI model less like an autocomplete engine and more like a software teammate. Give the agent a GitHub issue, a feature request or a bug description, and it can inspect the repository, develop a plan, edit multiple files, execute shell commands, run tests, interpret failures and continue working until it has produced a candidate solution.
The important development is therefore not simply that AI has become better at writing code. AI is acquiring the ability to participate in the software-development process itself.
From Copilot to Coworker
The easiest way to understand the transition is to compare three generations of software development.
The first was traditional software engineering. Humans wrote the code, compiled it, tested it, debugged it and deployed it. Automation handled repetitive processes such as builds and continuous integration, but the engineer remained firmly in control of the entire loop.
The second generation introduced AI assistants. Tools could autocomplete lines, generate functions, explain unfamiliar code and answer questions about a repository. This dramatically reduced the amount of typing required, but the workflow remained fundamentally human-driven. The developer decided which files to open, which commands to execute and which suggestions to accept.
Agentic software engineering changes the unit of work.
Instead of asking an AI to write a function, a developer might say: “Implement this feature, add the necessary tests and open a pull request.” The agent then determines which files matter, investigates the existing architecture, modifies the code and validates the result.
The human has moved one level higher—from writing individual instructions for a machine to defining an outcome for an autonomous system.
A 2026 paper published in the ACM Transactions on Software Engineering and Methodology describes this emerging direction as Software Engineering 3.0, an AI-native model built around intent-centric development and AI teammates rather than conventional task-oriented copilots.
The terminology is still evolving, but the underlying change is already visible in real software repositories.
The Agent Has to Do More Than Generate Code
A powerful coding model by itself does not create an autonomous software engineer.
The difficult part is connecting the model to an environment in which it can actually perform engineering work. That environment is sometimes called an agent harness: the collection of tools, context systems, execution environments, permissions and feedback loops surrounding the model.
First, the agent needs to understand the repository. Large software projects can contain millions of lines of code, thousands of files and years of accumulated architectural decisions. An agent cannot simply stuff the entire repository into its context window every time it receives a task. It needs mechanisms for finding relevant files, searching symbols, following dependencies and understanding relationships between components.
That is why modern coding agents increasingly rely on repository indexing, semantic search, abstract syntax trees, code graphs and project-level instructions. Files such as AGENTS.md and other repository rules can provide additional information about architecture, coding standards, testing procedures and operational constraints.
Then comes planning.
A request such as "add multi-factor authentication" is not one coding operation. It can involve database changes, API endpoints, authentication flows, frontend components, configuration, tests and deployment considerations. An agent has to turn the broad request into a sequence of smaller decisions before it starts changing the repository.
This is one of the major differences between an assistant and an agent.
An assistant responds.
An agent pursues an objective.
The Terminal Is Where the Real Test Begins
Generating plausible code is relatively easy. Producing software that actually works is considerably harder.
That is why terminal access has become such an important capability for coding agents. Once an AI can run the project's build system, execute tests, inspect logs and interact with development tools, it receives something a chatbot does not have: feedback from the real environment.
The agent writes a change. The compiler rejects it.
The agent reads the error.
It modifies the code.
A test fails.
It examines the stack trace, identifies a likely cause, changes the implementation and runs the test again.
This loop can continue for dozens of iterations without a human manually directing each step.
That feedback mechanism is one reason modern software-engineering benchmarks have moved beyond simple code-generation tests. SWE-bench, for example, gives an agent real GitHub issues and repositories and evaluates whether the resulting patch actually resolves the issue. SWE-bench Verified is a human-validated subset of 500 problems designed to make those evaluations more reliable.
The progress has been substantial. The official SWE-bench leaderboard now records coding-agent systems resolving a large majority of its verified tasks under some evaluation configurations, a dramatic change from the benchmark's early days.
But benchmark success should not be confused with autonomous engineering competence.
A passing test is evidence.
It is not proof that the software is correct.
The Verification Problem
This may become the defining problem of agentic software engineering.
AI can generate code extremely quickly. Verification cannot necessarily keep up.
An agent might modify ten files in a few minutes and produce a patch that passes the existing unit tests. But those tests may not cover the new edge cases. The change might introduce a subtle security problem, break an undocumented business rule or create technical debt that will only appear months later.
The result is a dangerous asymmetry: generation is becoming cheap while verification remains expensive.
Traditional software development already has this problem, but agents amplify it because they can dramatically increase the volume of changes entering a codebase.
The answer cannot simply be to ask another AI whether the first AI's code looks good.
That creates what could become an AI version of an echo chamber.
A coding agent may confidently produce a flawed implementation. A second model may confidently approve it because both systems share similar assumptions or because the flaw is outside the tests available to either system.
The strongest agentic workflows therefore need independent verification: deterministic tests, static analysis, security scanning, integration tests and, where appropriate, human review.
The role of the engineer does not disappear.
It moves toward building the system that determines whether the agent is allowed to be trusted.
The Rise of the AI Pull Request
This shift is already visible in open-source development.
Researchers studying AI coding agents have built large datasets of pull requests generated by systems including Codex, Devin, GitHub Copilot, Cursor and Claude Code. The original AIDev dataset contained more than 930,000 agent-authored pull requests across more than 116,000 repositories, demonstrating that autonomous coding activity is no longer confined to laboratory demonstrations.
The dataset has since expanded substantially. Its current version tracks millions of pull requests across hundreds of thousands of repositories and includes contributions from several major coding agents.
This changes the meaning of a pull request.
Traditionally, a pull request was evidence of a human developer's work. The reviewer knew there was a person behind the patch who had investigated the problem, made decisions and could explain the reasoning.
An AI-generated pull request changes that assumption.
The reviewer may now be evaluating a change produced by an agent that explored the repository for an hour, executed hundreds of commands and generated thousands of intermediate reasoning steps that never appear in the final diff.
The visible artifact is the same—a pull request—but the process behind it is fundamentally different.
The Code Diff Is No Longer Enough
That raises an important question: what should an AI-generated pull request contain?
A traditional review focuses heavily on the diff. What changed? Does it look correct? Are there tests?
Agentic development may require a richer evidence package.
A serious autonomous change could include the tests it executed, the failures it encountered, the relevant files it inspected, the security checks it passed and an explanation of why the implementation fits the existing architecture.
The objective should not be to dump the agent's entire internal trajectory on the reviewer. That would create another problem: overwhelming humans with tens of thousands of tokens of machine-generated reasoning.
Instead, the useful information is evidence.
Which tests passed?
Which new tests were added?
Which edge cases were considered?
Which files were changed?
Which architectural assumptions does the patch depend on?
Which checks were not possible?
The best AI-generated pull request may therefore look less like a transcript and more like an engineering evidence report.
The Agent Needs a Sandbox
There is another difference between an AI assistant and an autonomous coding agent that is easy to underestimate: an agent can execute commands.
That is extremely powerful.
It is also dangerous.
A system that can modify files, execute shell commands, install packages, access networks and interact with external services effectively has operational authority over the environment in which it runs.
A malicious instruction hidden in an issue, README file or dependency could potentially manipulate an agent into performing actions its developer never intended. An agent may also make an honest mistake—deleting files, modifying configuration or exposing credentials while attempting to complete an otherwise legitimate task.
This is why serious agentic engineering systems increasingly depend on sandboxing and explicit permission boundaries.
The model should not automatically have unrestricted access to everything the human developer can access.
Instead, its environment can be isolated, its filesystem access restricted, network connections controlled and sensitive operations placed behind approval gates.
This becomes even more important as agents interact with external tools through systems such as the Model Context Protocol.
The more capable the agent becomes, the more important its security boundary becomes.
Multiple Agents May Become the New Team Structure
Another emerging direction is the use of multiple specialized agents rather than asking one model to perform every stage of development.
One agent might investigate the issue and produce a plan. Another could implement the change. A third could generate tests. A fourth could review the resulting patch for security or architectural problems.
This resembles the structure of a software team.
The advantage is specialization. A planning agent can focus on understanding the repository without filling its context with implementation details. A testing agent can approach the change from a different perspective. A security agent can be explicitly instructed to look for vulnerabilities rather than simply asking whether the code appears correct.
But multi-agent systems also create another problem: coordination.
More agents do not automatically produce better software. They can misunderstand one another, duplicate work or reinforce the same incorrect assumption. The challenge is therefore not simply creating more autonomous workers. It is designing a workflow in which their outputs can be independently evaluated.
The Human Engineer Is Moving Up the Stack
The biggest misunderstanding about agentic software engineering is that it makes programmers unnecessary.
In the near term, the more likely change is that it makes some forms of programming less central to the job.
If an agent can reliably implement a well-specified feature, the engineer spends less time manually writing routine CRUD logic. If an agent can migrate a dependency across hundreds of files, the human does not need to edit every file. If an agent can investigate a straightforward bug and produce a tested patch, the engineer can concentrate on more complicated problems.
That shifts the value of the human engineer upward.
Architecture becomes more important.
Specifications become more important.
Testing becomes more important.
Understanding the business rules becomes more important.
Security boundaries become more important.
The engineer increasingly becomes the person who defines what the system should do, what constraints it must obey and what evidence is sufficient to trust the result.
In that sense, the transition resembles what happened in other engineering disciplines when automation became more capable. The engineer did not disappear. The engineer became responsible for designing and supervising a more powerful system.
The New Bottleneck Is Context
There is another reason agentic software engineering is different from traditional coding assistants: the scarce resource is no longer simply typing speed.
It is context.
An AI can generate thousands of lines of code quickly. But if it misunderstands why the system was designed a certain way, those thousands of lines can make the software worse.
Good agentic development therefore depends heavily on context engineering.
Repositories need clear architecture. Instructions need to be explicit. Tests need to communicate expected behavior. Dependencies need to be understandable. Documentation needs to remain current.
In other words, organizations may discover that AI exposes the quality of their software engineering practices.
A clean, modular repository with good tests and clear documentation gives an agent a much better environment in which to work.
A poorly documented monolith with hidden dependencies and fragile tests gives the agent a maze.
The AI does not eliminate technical debt.
It can make the consequences of technical debt arrive faster.
From Coding Assistants to Software Factories
If agentic systems continue to improve, the long-term change may be larger than individual developer productivity.
Software organizations could eventually operate fleets of agents continuously working through engineering backlogs.
One agent might upgrade dependencies overnight. Another could migrate deprecated APIs. Another could analyze production errors and propose patches. Others could write tests, improve documentation, refactor legacy code or review pull requests.
Humans would establish priorities and intervene at important architectural decisions while machines handle a growing share of implementation and maintenance.
This would effectively turn the software organization into a kind of AI-assisted software factory.
The economics could be significant. A team that previously spent weeks on a large migration might be able to delegate much of the mechanical work to agents while engineers focus on the difficult parts. Legacy systems that were previously too expensive to modernize could become economically viable targets.
But the factory would only work if its quality-control system worked.
A factory that produces software ten times faster but introduces defects ten times faster has not solved the problem.
The Real Test Is Not Whether AI Can Code
Agentic software engineering is therefore entering a more interesting phase.
The industry's question is no longer simply whether a model can generate a function. Models have already demonstrated that capability. The more consequential question is whether autonomous systems can consistently navigate the messy reality of software development: incomplete specifications, undocumented assumptions, contradictory requirements, security constraints, legacy code and changing environments.
That is a much harder problem.
The best evidence so far is encouraging. Modern coding agents can solve increasingly complex real-world repository tasks, and datasets such as AIDev show that autonomous contributions are already appearing at significant scale.
But software engineering is not merely the production of code.
It is the production of correct software under constraints.
That distinction will determine whether agentic engineering becomes a genuine transformation or simply a faster way to generate technical debt.
SE 3.0 Will Be About Trust
The next era of software engineering will therefore be defined by a paradox.
The better AI agents become at writing code, the less important raw code generation becomes.
What matters increasingly is whether humans can construct environments in which those agents can be trusted.
That means better tests, stronger sandboxes, clearer specifications, better repository architecture, more rigorous review and stronger evidence for every autonomous change. It means treating an AI coding agent not as a chatbot with access to a terminal, but as a new kind of software-engineering worker that needs permissions, supervision and measurable accountability.
The programmer of the future may spend less time asking, “What code should I type?”
The harder question will be:
“What should I delegate, what should I verify, and what should I never allow an agent to decide on its own?”
That is the real transition from AI-assisted programming to agentic software engineering.
The code is becoming increasingly easy to generate.
Knowing when to trust it is becoming the real engineering skill.