I have been thinking a lot recently about how software delivery is going to evolve over the next few years, and I increasingly believe that we are approaching a much deeper transformation than the one we usually describe when we talk about AI in software engineering. Most of the current discussion still focuses on developer productivity: how AI can help us write code faster, generate tests, explain an unfamiliar codebase, or produce a first version of a pull request. Those capabilities are already useful, and they will obviously continue to improve, but I do not think they represent the most important change ahead of us.
The real transformation begins when we stop thinking about AI as a coding assistant and start thinking about agents as active participants in the entire software delivery lifecycle.
When you look at the way software is delivered in a large organization today, a significant part of the work has very little to do with writing code. A developer receives a Jira issue, tries to understand what was actually requested, reads several comments to recover some context, searches through documentation that may or may not be up to date, asks a few people who remember how the application works, explores the codebase, identifies dependencies with other systems, makes the change, creates a merge request, waits for a review, updates tests, checks the pipeline, and perhaps updates some documentation before moving on to the next topic.
We have become so familiar with this way of working that we often forget how much of it is essentially information retrieval, coordination, context reconstruction and manual translation between systems.
That is exactly the kind of environment where agentic workflows can fundamentally change the way we operate.
Imagine an agent connected through MCP or similar mechanisms to Jira, GitLab, application repositories, architecture documentation, observability platforms and internal knowledge bases. When a new issue arrives, the agent does not simply generate code from the description. It first retrieves the wider context. It looks at related Jira issues, previous decisions, historical merge requests, the structure of the application, existing tests, architectural constraints and potentially even previous production incidents related to the same capability.
From there, it can propose a modification, identify which parts of the codebase are impacted, implement a first version, run tests and create a merge request. Another agent could review the proposed change from a code quality perspective. A different one could look specifically at security implications. Another could verify architectural consistency, while another determines whether documentation, runbooks or operational procedures need to be updated.
At that point, we are no longer talking about AI-assisted coding. We are talking about a delivery system in which humans and agents work together across the complete lifecycle.
That distinction is important because it also changes the role of the software engineer.
The Software Engineer as an Orchestrator
One of the most interesting consequences of this evolution is that software engineers may gradually become managers, although not necessarily in the traditional sense of managing people. They will increasingly manage and orchestrate agents.
An engineer could work with a set of specialized agents, each with a specific role and context. One may understand the application codebase in depth. Another may specialize in testing. Another may focus on security, observability, documentation or architecture. Some agents may be deeply specialized in a particular application, while others may operate at the level of an entire information system and understand relationships between multiple platforms.
The engineer’s role in that environment becomes less about manually executing every single step and more about ensuring that the overall system of work is producing the right result.
That means defining the problem properly, providing the right context, determining constraints, validating assumptions, challenging proposed solutions and recognizing when an apparently correct technical answer is actually wrong from a business or architectural perspective.
This is why I do not believe the future of software engineering is simply about fewer engineers doing more coding with AI. I think the role itself will evolve toward orchestration, judgment and problem solving.
In many ways, this may actually bring software engineering closer to what engineering should have always been.
The ability to write code remains important, but code is only one implementation mechanism. The real objective is to understand a problem, understand the constraints around it, design an appropriate solution and ensure that the solution produces value.
The Real Bottleneck May Move Upstream
The more I think about this, the more I believe that the most important impact of AI will not be on coding itself. It will be on everything that happens before coding starts.
In many organizations, we have gradually accepted a model where a business request can be expressed in one or two lines and then handed over to a software team with the expectation that the team will somehow reconstruct the actual need behind it.
“We need a new status.”
“We need this information exposed.”
“We need a new screen.”
“We need another field.”
“We need this integration.”
The delivery process then begins from a statement that is already framed as a solution, even though the underlying problem may not have been properly understood.
The software team starts asking questions, usually asynchronously and often across several organizational boundaries. People interpret the request differently. Assumptions are made. A backlog is created. Development starts. Several weeks or months later, the solution is delivered and somebody realizes that the original requirement did not actually address the real business problem.
AI does not automatically fix this.
In fact, I think AI will make this weakness much more visible.
If implementation becomes dramatically faster, then unclear problem definition becomes the new bottleneck. There is little value in being able to implement the wrong solution in two days instead of two months.
This is why I believe software engineers will need to spend more time with the business, not less.
They will need to understand how the business process actually works, where the friction exists, what decisions people are trying to make, what information is missing and what outcome the organization is really trying to achieve.
The quality of the problem statement will become one of the most important inputs into the entire agentic delivery system.
From Requirements to Business Problems
I can imagine a future software delivery lifecycle that starts very differently from the one we know today.
Instead of beginning with a technical request such as “add a new field to Application X”, the process begins with a business problem.
For example, a supply chain team might say that they are losing visibility at a certain point in the fulfillment process, creating manual work, delaying decisions and increasing the risk of inventory inconsistencies.
That is a much richer starting point.
From there, humans and agents can work together to understand the current environment. Which applications are involved? Where does the relevant information originate? How is it transformed? Which teams own the different systems? Which business rules apply? Are there existing capabilities elsewhere in the organization that already solve part of the problem? Is the issue really technical, or is it partly caused by the way the current process has been designed?
An agent that has access to the architecture of the information system, application documentation, code repositories and business process descriptions could then analyze the situation end to end.
Instead of immediately producing a backlog, it might propose several scenarios.
One scenario could involve relatively small changes to two existing applications and provide a fast implementation, but create additional coupling between systems.
Another might introduce a new shared capability that requires more initial effort but creates a cleaner architecture over time.
A third could reuse an existing enterprise capability while requiring a change in the current business process.
This is where I think human involvement becomes particularly valuable.
The business can evaluate the scenarios based on expected value, speed, operational impact and cost. Architects can evaluate long-term consequences. Engineers can challenge feasibility and complexity. Together, they can make an informed decision before implementation begins.
Once a scenario is selected, much of the downstream delivery process becomes easier to automate.
The system could identify the applications that need to change, determine ownership, create the necessary epics and backlog items in Jira, map dependencies between teams and provide each application-specific agent with the relevant piece of work and context.
The important point is that the automation begins after the problem has been properly understood and the direction has been chosen.
That is very different from simply asking an AI agent to implement whatever happened to be written in a ticket.
Application-Specific Agents and End-to-End Delivery
I also believe that software organizations will increasingly create agents that are specialized in specific applications or domains.
Today, a large amount of application knowledge is accumulated informally over time by the people who work on a system. They know why certain design decisions were made, which components are fragile, which dependencies are poorly documented, which tests are reliable and which operational behaviors are normal.
An application-specific agent could gradually accumulate and maintain much of that context.
It could understand the repositories associated with the application, its architecture, coding standards, APIs, dependencies, deployment model, historical incidents and previous technical decisions.
When a new piece of work is assigned, the agent would not begin from zero. It would already understand the environment in which the change needs to be made.
This creates the possibility of a much more continuous delivery process.
A business decision made at the beginning of the lifecycle could eventually flow through architecture analysis, backlog creation, implementation, testing, code review, documentation and deployment with much less manual translation between each stage.
Humans would still be involved, but their involvement would increasingly focus on decisions rather than repetitive coordination.
That is where I see the real potential for significant acceleration.
Not because an individual developer can generate code 30 percent faster, but because the amount of friction between the stages of software delivery can be reduced dramatically.
Documentation Becomes Part of the Product
One of the areas where I think this evolution could have the biggest long-term impact is documentation.
Documentation has been one of the most persistent problems in software organizations for decades. Everyone agrees that good documentation matters, but in practice it is often treated as secondary to delivery.
The feature has to ship.
The incident has to be fixed.
The migration has to happen.
The release date cannot move.
Documentation is therefore updated later, inconsistently or not at all.
Over time, more and more knowledge moves outside the formal system and into people’s heads. Someone remembers why a particular integration works in a strange way. Someone knows the hidden operational dependency. Someone remembers a decision made during a migration three years ago. Someone knows that one configuration value must never be changed.
Eventually, that person changes role or leaves the organization, and the knowledge disappears with them.
Agentic software delivery creates a strong incentive to address this problem because agents require reliable context.
If we expect agents to understand applications and make useful decisions, then architecture, ownership, business rules, operational procedures and design decisions need to exist as structured, maintainable knowledge.
Documentation can no longer be something separate from software delivery. It has to become one of the artifacts produced and maintained by the delivery process.
I think we should eventually treat documentation in much the same way we treat software artifacts.
A Docker image has a version.
A Helm chart has a version.
An API has a version.
A deployed application corresponds to a specific commit or release.
The documentation describing that application should follow the same principle.
If version 4.8 of an application is deployed in production, there should be a version of the documentation that accurately reflects version 4.8.
This could include architecture diagrams, API documentation, operational runbooks, business rules, data flows and major architectural decisions.
When a change is merged, agents could identify which knowledge artifacts are impacted and propose the appropriate modifications as part of the same delivery workflow.
Documentation would stop being something that people are periodically reminded to update and become part of the definition of the product itself.
That could also significantly reduce our dependence on tribal knowledge.
Not because people suddenly become more disciplined about writing documentation, but because knowledge maintenance becomes systemic.
Toward a Living Model of the Information System
If this idea is pushed further, I think we may eventually create something close to a living digital representation of the information system.
Today, most large organizations have fragments of this information spread across many places.
Architecture diagrams exist somewhere.
Application inventories exist somewhere else.
Source code is in Git.
APIs are documented in another tool.
Business processes may be described in PowerPoint or Visio.
Operational knowledge is in a wiki.
Incidents are in ServiceNow.
Ownership is sometimes in people’s heads.
The information system exists, but our representation of it is fragmented.
An agentic environment creates pressure to connect those pieces.
If agents can understand application architecture, dependencies, APIs, ownership, runtime information, business capabilities and operational history, they can begin to reason about the information system as a whole.
An engineer could ask a question such as:
“What would need to change if we introduced this new capability into our order fulfillment process?”
Instead of spending weeks identifying the right applications and teams, the system could analyze the existing landscape and provide a first end-to-end impact assessment.
It could identify the relevant applications, interfaces, dependencies and ownership boundaries, then propose possible implementation strategies.
This does not eliminate the need for architecture or engineering expertise.
It makes that expertise much more effective because engineers spend less time reconstructing information that should already be available.
Knowledge Has to Be Federated and Interoperable
There is, however, an important condition for this to work. I do not think the answer is to create one enormous central knowledge repository and expect a central team to maintain everything.
That would probably recreate exactly the kind of bottleneck we are trying to remove.
The model has to be federated.
Each team should remain responsible for the knowledge associated with the applications, services and capabilities it owns. The people closest to a system are usually the best positioned to maintain its context, its architecture, its operational knowledge and the reasoning behind its evolution.
But ownership of knowledge cannot mean isolation of knowledge.
The key principle should be that knowledge produced by one team must be consumable by another team, or by another agent, without requiring a manual interaction every time someone needs access to it.
In other words, knowledge has to become interoperable.
If an agent analyzing an end-to-end business process needs to understand an application owned by another team, it should not have to open a ticket, schedule a meeting, ask someone to export a document or wait for somebody to manually validate every request.
Assuming the appropriate access rights have already been granted, the knowledge should simply be available through a standard interface.
I think there is an interesting parallel here with the API-first principles that have shaped modern software architecture.
The famous API mandate often associated with Jeff Bezos was based on a relatively simple idea: teams should expose their capabilities through well-defined service interfaces rather than depending on private implementation details or informal coordination between teams.
The same philosophy should increasingly apply to knowledge.
Every team should own its knowledge, but every team’s knowledge should also be accessible as a service to the rest of the organization.
That does not necessarily mean that everything has to be exposed through a traditional REST API. The interface could be an API, an MCP server, a knowledge graph, structured documentation, searchable repositories or whatever mechanisms emerge over time.
The technology itself is less important than the principle.
A consuming team or agent should not need to understand where the knowledge physically lives.
It should not need to know whether one team uses Markdown, another uses a wiki and another generates documentation from code.
It should simply be able to ask for the information through a common, interoperable interface and receive a reliable answer.
This also changes the way I think about autonomy.
True team autonomy cannot simply mean that each team can build whatever it wants independently.
It should also mean that teams can consume the capabilities and knowledge of other teams independently.
If every interaction requires another team to manually intervene, then the organization is not really autonomous. It has simply distributed its dependencies across organizational boundaries.
The same principle that applies to software services applies to organizational knowledge: dependency is acceptable, unnecessary coordination is not.
This federated model also avoids another common trap in large organizations, where a central documentation or architecture function gradually becomes responsible for maintaining knowledge about systems it does not actually operate.
That almost always creates a lag between reality and documentation.
Instead, knowledge should remain close to the source, owned by the teams that create and change the systems, while standards make that knowledge discoverable and usable across the enterprise.
In an agentic environment, this becomes even more important because the quality of an agent’s decisions will depend heavily on the quality and accessibility of the context it can retrieve.
An enterprise with hundreds of highly capable agents but fragmented, inaccessible knowledge will still spend enormous amounts of time rediscovering the same information.
An enterprise where knowledge is federated, structured and interoperable creates something much more powerful: every team can improve its own context while automatically contributing to a larger understanding of the information system.
That, to me, is one of the foundations required for agentic software delivery to work at scale.
We Should Not Simply Automate Today’s SDLC
One of the biggest mistakes we could make is to take our existing software delivery lifecycle and simply put an AI agent into every step.
An AI agent writes the requirements.
Another writes the code.
Another performs testing.
Another writes documentation.
Another handles deployment.
The same process continues, just with more automation.
That would certainly create productivity improvements, but it would miss the larger opportunity.
Many of the processes we use today exist because of the limitations of human coordination.
We create tickets because work needs to be passed between people.
We create handoffs because teams operate in separate contexts.
We create detailed workflows because information is fragmented.
We schedule meetings because the right people do not have the same information at the same time.
When agents can continuously access and reason across much of that context, we should question whether the process itself still makes sense.
Why should a business request pass through several organizational layers before reaching the people who understand the application?
Why do engineers repeatedly rediscover application dependencies?
Why is documentation treated as a separate activity?
Why do we manually translate one business decision into dozens of Jira items?
Why do teams spend so much time figuring out who owns a system?
Why do developers spend hours searching for information that already exists somewhere else in the organization?
The opportunity is not simply to make those activities faster.
The opportunity is to remove some of them entirely.
The Engineer of Tomorrow
All of this changes what I believe will make a software engineer valuable.
Technical skills will still matter. Understanding software architecture, distributed systems, APIs, databases, cloud infrastructure and security will not suddenly become irrelevant.
But pure implementation ability will become less differentiating as agents become better at producing code.
What becomes more valuable is the ability to understand a complex environment and make good decisions within it.
An engineer needs to understand the application, but also why the application exists.
They need to understand the business process it supports.
They need to understand how the system interacts with the rest of the enterprise.
They need to understand which constraints matter and which ones are historical accidents.
They need to be able to recognize when a proposed solution is technically elegant but solves the wrong problem.
This is why I think domain knowledge will become increasingly important.
An engineer working in supply chain should understand supply chain.
An engineer working in manufacturing should understand manufacturing.
An engineer working in finance should understand finance.
Not because engineers need to become business analysts, but because solving the right problem requires understanding the environment in which that problem exists.
The future engineer, in my view, will combine technical depth, business understanding, problem-solving ability and the capacity to orchestrate increasingly sophisticated agents.
That is a very different role from simply receiving a Jira ticket and implementing what is written inside it.
Long Live Software Engineering
So when people say that AI could eventually kill software engineering, I think they may be both right and wrong.
A certain version of software engineering may indeed disappear.
The model where developers spend most of their time manually translating tickets into code, navigating fragmented documentation, searching for context, coordinating handoffs and maintaining repetitive delivery processes is likely to change significantly.
I do not think we should be nostalgic about that.
What may emerge instead is a version of software engineering that places much more emphasis on understanding problems, designing systems, making trade-offs and working directly with the business to create value.
Engineers may write less code themselves, but they may have much greater responsibility for the systems that produce that code and for the decisions behind it.
They may manage fewer individual implementation tasks and spend more time orchestrating agents, validating solutions and understanding complex end-to-end processes.
In that sense, software engineering is not disappearing.
It is moving up the value chain.
And perhaps the best way to describe what is happening is exactly this:
Software engineering is dead. Long live software engineering.