The Future of Software Engineering, Part I: From Builder to Orchestrator

The Future of Software Engineering, Part I: From Builder to Orchestrator

Why AI coding agents mark a deeper shift in how we design, deliver, and define software itself.

The capability question on AI in software engineering is largely settled. Current models write code, generate tests, refactor across files, and increasingly deploy what they produce. What is not settled is whether engineering organizations are structured to do anything useful with that capability, and most are not.

Capability has moved faster than organizational readiness, which is now the binding constraint on what AI actually delivers inside engineering teams. The teams using these tools still mostly operate as if the model is a faster autocomplete, because their codebases, review processes, observability, and incentive structures were all designed for a workflow where humans write every meaningful line. The gap between what the tools can do and what teams are getting from them is an architectural and cultural problem more than a model problem.

The economic shift is the real story

The strategic framing matters because the addressable market has changed. Global SaaS revenue estimates for 2025 range from roughly $316 billion using narrower definitions to $408 billion using broader ones, depending on the research firm. Place either figure next to U.S. compensation of employees, which reached $15.0 trillion in 2024 according to BEA national income accounts, and the asymmetry is the point. Traditional SaaS digitized paperwork and sold tools that humans used to do work. AI systems are starting to do the work directly, which means the line vendors are competing for is no longer the customer's tooling budget, it is the budget for the function itself.

Customer support, parts of legal review, marketing operations, basic analytics, all of these are increasingly being sold as outcomes rather than seats. The unit economics of that model are still being worked out, and most vendors claiming outcome-based pricing today are running heavy services attached to thin software to make the numbers land. The direction of travel is clear even if current execution is messy, and engineering teams building inside this shift are no longer shipping a system that helps a human do a job. They are shipping a system that does the job, which changes how reliability, accountability, observability, and pricing are reasoned about in ways most engineering organizations have not internalized.

The orchestrator framing, half right

When the model writes the implementation, the human's work moves toward defining what to build, supplying the model with the right context, and validating what comes back. Anyone who has spent serious time pairing with a coding agent on a non-trivial codebase recognizes this immediately. Those three activities, intent definition, context engineering, and output validation, describe a real and growing portion of senior engineering work today.

What the orchestrator narrative tends to understate is that those activities are themselves targets for automation. Intent extraction from product conversations, context retrieval from large repositories, automated review for security and style, all of this is being worked on, and parts of it function today. The senior engineer's role gets pushed up the stack at the same time the stack itself is rising, which makes the orchestrator framing comforting in ways the underlying dynamics do not fully support. The honest version of the argument is that the work surface keeps shifting upward, and the engineers who remain valuable will be the ones who can keep moving with it, which requires comfort with ambiguity, systems thinking, and an acceptance that the floor under any specific activity is unstable.

The lifecycle effects are real but uneven. Requirements analysis benefits less than people claim, because the bottleneck there has rarely been writing user stories, it has been getting stakeholders to agree on what they want. Architecture proposals from models are useful as starting points and dangerous as endpoints, since the model has no visibility into your team's operational reality. Implementation is where current tools earn their cost. Testing benefits significantly, particularly for the integration and edge case coverage humans tend to skip. Deployment and operations have produced smaller early payoffs than the marketing suggests, because production systems fail in ways that depend on context the model does not have. Maintenance is the underrated win, since legacy refactoring, documentation drift, and dependency upgrades are precisely the long tail of unglamorous work that engineering teams chronically defer.

What this means for leaders

The democratization narrative needs to be read carefully. More people can now produce working software, and product managers prototyping their own ideas is a meaningful change in how products get built. The implication is not that engineering is being commoditized. The line between a working prototype and a system you can run in production at enterprise scale is now more visible, because more people are running into it. Governance, security review, data handling, integration with systems of record, incident response, the things that distinguish a prototype from production software, are now the actual job of the engineering function rather than incidental to it.

The leaders who get this right will not be the ones who pick the right tools first, because the tools will churn. They will be the ones who restructure how engineering work is defined, reviewed, and measured. Lines of code was always a bad metric and is now actively misleading. The replacement is not obvious, but the organizations that figure out their own version of validated outcomes per unit of engineering input, measured over a meaningful time horizon, will compound a structural advantage rather than a tooling advantage.

Part II will look at the cultural and identity shifts this forces on engineering teams, including what happens to junior engineers who grow up in an environment where they have rarely had to write difficult code from scratch.

References

• Fortune Business Insights, Software as a Service (SaaS) Market Size, Global Report, 2034: 2025 global SaaS market valued at $315.68 billion. https://www.fortunebusinessinsights.com/software-as-a-service-saas-market-102222

• Precedence Research, Software As A Service (SaaS) Market Size to Surpass USD 1,367.68 Bn by 2035: 2025 global SaaS market estimated at $408.21 billion. https://www.precedenceresearch.com/software-as-a-service-market

• U.S. Bureau of Economic Analysis, National Income: Compensation of Employees (series A033RC1A027NBEA), via FRED: $15,019.9 billion in 2024. https://fred.stlouisfed.org/series/A033RC1A027NBEA