Last week we hosted our annual conference, EVOLVE, where global engineering leaders came to talk through the realities of building AI-native SDLCs.
When asked to name the biggest friction point in their software lifecycle, attendees gave telling answers: ‘reviewing changes’ took 36 percent, ‘measuring impact’ took 35, and ‘building’ drew zero votes. Even though many companies have rolled out coding agents to only part of their organizations, none of them named writing code as the bottleneck. The constraint has already moved downstream to reviewing, securing, owning, and measuring everything the tools now produce.
Enterprises are in the opening stretch of putting AI to work across the SDLC, wrestling with how to move faster with coding agents without losing control of cost and quality. Access to the models is the easy part. Safely adopting them across an organization is where the true work begins.
The change in focus from AI code generation to the organization around it was the story of EVOLVE 2026. This article recaps the themes we heard all day: the questions engineering leaders are grappling with as AI reshapes the SDLC.
Code is no longer the bottleneck
Throughout the day, speakers described the same problem from different angles: teams are writing more code and understanding less of it, the path from requirements to production is turning into a black box, incidents and security issues climb even as raw output rises. More code is not the win it appears to be if the organization cannot review, secure, and stand behind it.
The answer we heard was governance, built into the path rather than bolted onto the end of it. Defining a standard once, evaluating it continuously as work moves through the system, and enforcing it at the boundary keeps the guardrails traveling alongside the work.
Most enterprises are early, and the biggest gap is change management
Model capability and organizational maturity are separate variables: putting capable coding agents in every engineer's hands does not make a company mature enough to use them well. AI amplifies whatever system it enters, speeding up good practices and bad ones alike, so maturity has to be built, not bought.
This work is harder in the enterprise. Enterprises operate under constraints most startups do not: far more sensitive data, binding compliance and audit obligations, a larger attack surface, downtime costs that can be catastrophic, and finite AI budgets. Under those conditions even human-steered coding agents introduce meaningful risk, and every step toward greater autonomy is a cultural change that needs leadership sponsorship and an honest reading of where the organization stands.
The payoff also arrives on a curve: value often dips before it climbs, as teams work through a learning curve and rebuild their pipelines around AI, and getting past that trough depends on leaders who fund the work and protect their teams from burnout while the numbers look worse before they get better. A single agent-driven team can demonstrate what is possible; an organization realizes the benefit only when many teams operate at a consistent standard.
Who builds software is changing
The engineer's job is moving up a level. Less of it is writing code line by line, and more of it is specifying, directing, and reviewing what the tools produce. Leaders at EVOLVE kept circling the questions this raises: which skills matter most now, how to evaluate people whose main output is judgment, and how to keep engineers close enough to the code to catch what the tools get wrong.
The group producing code is widening at the same time. Agents now open pull requests and handle work that used to belong to engineers, and AI is drawing in non-technical colleagues who want to solve a problem without becoming full-time engineers. For an engineering leader, that turns ownership and standards into the pressing problem: deciding who is accountable for code an agent wrote, and holding a widening set of contributors to the same bar without slowing any of them down.
Measure the organization, and earn the trust to move faster
If the model is a commodity and the organization is the differentiator, the organization is also the right unit of measurement. Counting whether one engineer opened more pull requests this quarter says little about whether the organization is getting better at delivering value, and when an agent can produce a week of pull requests in an afternoon, output-based metrics stop telling leaders anything useful.
The question worth asking is operational: how effective is the engineering organization at turning customer needs into reliable software, and is it improving? Answering it takes a shared set of signals, reviewed on a regular cadence, that reads at the level of the organization instead of the individual. See our DRIVE framework for more on this topic.
Measurement of this kind is how trust gets built. Even in a room full of leaders using AI regularly, trust in its output was far from universal, with concerns clustered around risk, security, and ownership. Each concern is a roadmap item that an organization can build and measure.
Operational excellence is the differentiator
The through-line of EVOLVE 2026 was that abundant model capability does not, on its own, produce a better engineering organization. Producing code is cheap, while reviewing it, securing it, owning it, and proving it created value have become the work that matters. The organizations that treat operational excellence in the AI-native SDLC as a continuous discipline are the ones positioned to pull ahead over the coming years.
Full session recordings are coming soon, but for readers who want to put these ideas into practice now, download the DRIVE framework to get started.
To stay up to date about EVOLVE 2027, sign up here.
