Engineering is the new enterprise core
Engineering the shift: What change actually looks like
August 2026
Continuing the Future of Engineering series
Readers of prior parts in the Future of Engineering series will be familiar with the argument to be presented in this article. Engineering has become something fundamentally different from what it was even two or three years ago. It is no longer a service function that takes requirements from the business and ships features on a timeline. It is the enterprise's defining core, the thing that either compounds in value over time or quietly limits everything else.
The previous article in this series labeled this environment "unconstrained engineering," and discussed potential future software engineering functional scenarios. It posited that the most likely destination for software engineering is a self-driving engineering core, where autonomous AI agents run most of the build-and-run life cycle and humans do the work that actually requires judgment.
This article focuses on what major companies are actually doing now, the environment for engineers who work inside a system that has made the shift, and where leaders should focus their energy first. That last sequencing question matters more than most strategy conversations touch on.
One corollary: Organizations that move the most are not always the ones with the boldest vision statements or the largest AI budgets. Instead, they are the ones that picked a strong starting point, built around it, and let their next move reveal itself. The starting point many organizations are choosing sounds deceptively simple but is very powerful: They stop optimizing for handoffs and start optimizing for outcomes.
Key takeaways
- Engineering is becoming the enterprise core, reshaping operating models around shared product, data, and ownership.
- Flywheel engineering replaces handoff optimization, improving speed, learning, and business outcomes via tighter feedback loops.
- Engineering leaders should build talent that is business fluent, collaborative, and AI-fluent.
- AI agents scale best when foundational technology, processes, and human responsibilities evolve together.
- Accountability must remain explicit as agent authority grows, with governance tailored to risk and context.
The operating model shift: From human handoffs to flywheel engineering
A central question is how a customer problem or need becomes a working product—and how many times does it change hands before it ships?
For many large enterprises, the answer is uncomfortable. Typically, a project advances in steps from strategy to product to engineering to quality assurance (QA) to operations, with each team working with different goals but the same intent. Most issues aren’t people problems; they’re structural and entrenched into years or even decades of organizational design that was optimized for scale and control, not for rapid value generation and constant learning.
Agentic systems are automating much of the handoff and coordination work in the software development life cycle (SDLC)
- Some of those tasks move to earlier in the process, or “to the left,” into strategy and design. Engineering teams use AI to help shape the architecture and aid in decision-making before coding starts.
- Other tasks move to later in the process, or “to the right,” into production and measurement. Here, engineering teams use AI to check whether the product really improved the business metric it was meant to.
As AI takes over more of this handoff and coordination tasks in the SDLC, the traditional gap between product and engineering shrinks. Not because of a culture initiative or a new organization chart, but because the delivery middle ground of tasks that had kept them apart now largely runs agentically, autonomously. What is left is a choice about how to reorient the workers on either side of the automation.
The real change isn’t simply that the organization has new tools. It’s that product and engineering start to function in unison because the repetitive delivery tasks no longer need as much human coordination.
For decades, organizations have optimized software engineering for efficient handoffs, clean boundaries, clear workstreams and formal transitions between teams. That model made sense when the execution process of the product software delivery cycle was expensive and manual. However, it loses its purpose when the coordination is increasingly taking place inside an automated system that does not recognize organizational boundaries.
So, to succeed in this new landscape, organizations should consider a new operating model that optimizes not for handoffs but for outcomes. The operating model that makes this possible is flywheel engineering: Not working harder or faster, but completely redesigning the delivery flow.
In the flywheel engineering model, each team member from both the product development and engineering teams shares a single information and feedback loop. Signals from development and production then continuously feed the subsequent iterations, and every iteration compounds value.
How the flywheel works
A mature flywheel passes through four phases, with each phase feeding the next one:
Flywheel engineering is not a technology initiative; it is an operating model. Agents can accelerate it dramatically, but first the flywheel has to be built. If the delivery system that underpins agentic AI still operates with phases, gates, and handoffs between them, agents can still produce real gains but those gains will be linear. The compounding starts when flywheel engineering closes the information loop and every iteration feeds the next one.
Where to start with flywheel engineering: Quality
The starting point in the SDLC for implementing the flywheel engineering model is quality engineering. Agents that operate in the quality engineering process are lower risk by nature: They surface signals; they do not control outcomes. They write and run tests, flag fragility, identify vulnerabilities, and reveal issues before they leave the cycle, all without operating in the critical release pathway. That allows organizations to expand agent authority within quality engineering well before doing so in code generation or deployment.
But the more important reason to start with quality engineering is the capability it produces as a byproduct. When quality becomes continuous and generative, telemetry begins informing design decisions earlier in the lifecycle. Fragility that previously accumulated through the build cycle and surfaced only in production, where remediation is most costly, begins to appear as an actionable signal early enough to address. The system becomes observable in a way that it was not previously.
And that observability is what enables broader expansion. When organizations can see what agents are doing and why, expanding their authority over time becomes a rational decision rather than an act of assumption. Agents are probabilistic by nature, which means the more precisely that organizations define and measure desired outcomes, the more reliably those outcomes can be achieved.
Quality engineering is where that capability is developed, and it compounds as organizations scale. Trust in the system is not primarily a cultural or attitudinal issue. It is an engineering outcome, and quality engineering is where it is established.
Scaling agents up and down the product/software delivery life cycle
Quality engineering is where organizations build the confidence to expand further. Once agent performance is visible and results are consistent enough to trust, the question shifts from whether to expand to where and in what order. Before that expansion, organizations must build pillars to form a solid base.
The talent imperative
The technology and process changes described above are, in relative terms, more straightforward to address. They are tangible and respond well to investment. The talent challenge runs deeper because it is not primarily about traditional skills gaps. It is about a fundamental change in what engineering work actually is.
For most of the last two decades, engineering careers were built around specialty area depth. Progress came through deeper specialization in a domain, a language, a platform. Seniority meant mastery. That model is not disappearing, but it is no longer sufficient on its own. As agents absorb more of the task execution, the humans working alongside them are increasingly valued for their range—which is the ability to move across contexts, connect technical decisions to business outcomes, and exercise judgment in situations that do not have clear answers.
The shift becomes visible in concrete ways for individual engineers. An engineer who previously would have been paged at 2 a.m. to restart a service is now the one who is designing the agent that restarts it, monitors whether the fix was effective, and decides when a recurring pattern warrants a permanent architectural change.
Engineers are no longer measured by how fast they can respond to an incident; instead, they are evaluated on how effectively they designed a system that rarely requires human intervention. That is a fundamentally different job, and it calls for a fundamentally different talent strategy.
Traditionally, talent strategies were built around hiring specialists and keeping them up to date on the technology and trends that drove their specialty. That talent model made sense when an engineer’s job was predictable enough to specialize in. What organizations need now, however, is a materially different profile: engineers who can operate across the full lifecycle, who understand the business well enough to define intent clearly, and who are comfortable supervising work they did not personally produce.
That profile warrants explicit definition. An engineer in the AI era is not a quality engineer, a DevOps specialist, or a pure software developer in the traditional sense. Instead, they function as what many organizations now refer to as applied AI engineers. An applied AI engineer is a multifaceted professional who sits at the intersection of business and technology, takes ownership of delivery outcomes rather than individual task execution, and who spends less time doing task work themself and more time building the agents that do it.
Organizations will still need a few deep engineering specialists to handle unusual exceptions or serious problems, but the engineers most needed now are the ones who can move fluidly across the full life cycle, speak the language of the business, and build systems that work rather than features that ship.
The organizations making the fastest progress are not waiting for that profile to emerge from the hiring market. They are deliberately building it from within, redesigning how engineers grow, what they are exposed to early in their careers, and what effective professional development looks like in a world where the most valuable skill is knowing how to work with systems that are smarter and faster than any individual human contributor.
Accountability in a world where agents do the work
As agents take on more of the actual work, one question surfaces faster than most organizations expect: When something goes wrong, who owns it?
Accountability does not lie with the agent but instead resides with the humans who created the operating conditions for the agent. A human (or humans) designed the system, set the boundaries and decided what authority to give the agent. That is a meaningful shift for leaders who are used to accountability residing with who performs the actual work.
The following client journey shows how two organizations made different governance and accountability choices as they introduced agents into software engineering. Two leading banks are taking different approaches to implementing agentic AI, and both are worth examining.
What comes next
Most organizations are at different stages of this journey, and few begin with a fully defined blueprint. The organizations making the most meaningful progress have established a clear starting point, advanced deliberately, and allowed the results of each decision, rather than traditional practices, to inform the next.
The opportunity facing engineering leaders is exciting, but it also presents significant execution challenges. The organizations making the strongest progress avoid broad experimentation without clear commitment or follow-through.
Instead, they invest early in the technology foundations required for scaled adoption, they prepare proactively for the talent implications, even when some changes will materialize over a longer horizon, and they define accountability explicitly at the outset. The competitive gap between organizations that move with intent and those that remain in experimentation mode is already emerging and may over time become increasingly difficult to close.
Here are three questions organizations can ask of themselves to clarify whether they can benefit from implementing the flywheel engineering model:
Opens in new window
The organizations already confronting these questions are likely to define the pace of their markets.
This article is part of Deloitte’s Future of engineering series, a collection of perspectives on how organizations are reimagining engineering to deliver impact at scale. Together, the series explores how leaders can combine AI and agentic ways of working with strong foundations—across architecture, talent, quality and governance—to drive lasting business outcomes.
