At EVOLVE, Cortex’s annual engineering leadership conference, Nathen Harvey (Google Cloud’s DORA lead) asked the audience to name the biggest friction point in their software delivery lifecycle. Of 69 people who voted, none picked “building”. Reviewing changes and measuring impact nearly tied for first.
Risk, security, ownership, and trust topped the EVOLVE audience's list of what keeps AI-built software out of production, and all four are platform problems. AI amplifies whatever an engineering organization already is, good and bad, so those weak spots now surface faster and at higher volume. Harvey's talk laid out which guardrails to build first, who the platform now serves, and what leaders should expect before the payoff arrives.
AI's two biggest effects pull in opposite directions
DORA's 2025 survey found that 90% of respondents use AI at work, and most believe it helps. 85% say it raised their individual productivity, and 59% say it improved their code quality.
DORA's model complicates that picture. When the researchers simulated higher AI adoption across teams, individual effectiveness rose more than any other outcome. The second-largest effect was a rise in software delivery instability, which DORA measures by how often teams roll back changes and how many deployments are unplanned rework. Throughput barely moved.
Cortex's 2026 Benchmark report found the same split. Pull requests per author rose 20% year over year, while incidents per pull request rose 23.5% and change failure rates rose roughly 30%.
Harvey traced the same pattern to factories more than a century ago. Owners swapped steam engines for electric motors, kept the layout, and ran the same processes harder. Redesigning the factory around electricity took years.
Plenty of engineering organizations moved to the cloud the same way. Developers still filed a ticket and waited, now for an instance rather than a server, while the bill moved from CapEx to OpEx. Harvey argues most organizations are doing the same with AI today, adding it to their existing SDLC instead of redesigning the SDLC around it.
The room's fears = the platform backlog
AI has widened who builds. People in marketing, finance, and sales now produce working applications. Harvey asked the room of engineering leaders what stops them from taking something Joanne in accounting built last week and YOLO'ing it into production.
One respondent summed it up well: the same things that stopped us before. Another notable answer read "utterly terrified of Joanne in accounting," which is its own kind of governance requirement.
Trust is the surprise on that list, because the same room trusts AI output. In a separate poll, 59% of 72 respondents said they trust it a lot or a great deal, and nobody chose not at all. The difference is whose output it is: the poll asked about AI output in their own work, and the word cloud asked about shipping something someone else built. Engineers trust what they’ve reviewed themselves, and extending that trust to code nobody on the team has read is the platform’s job.
Harvey's advice was to read the word cloud as a roadmap. Each fear names a guardrail the platform doesn't have yet, and nearly all of them predate AI. He sorted the work into two kinds of mechanisms:
Feed-forward mechanisms shape a change before it exists: golden paths, standards built in as defaults, and the context an agent needs to produce code that fits the organization.
Feedback mechanisms check a change after it exists: tests, policy checks, and observability that shows within minutes whether production got worse.
To decide what to build first, Harvey pointed to DORA's AI capabilities model, which names seven capabilities that, combined with AI adoption, predict better outcomes. Pick the outcome you care about and work backward: a team that wants better product performance needs AI-accessible internal data, small batches, and a clear AI stance. Run that exercise against the word cloud and the backlog sorts itself: the fears tied to the outcome leadership cares about most get built first.
The platform has three kinds of customers now
Platform teams have always run the platform as a product for one customer: other engineers. Harvey's list now has three, and each one changes what belongs on the roadmap.
Agents are the easiest addition, because they need what new hires need: current documentation, consistent conventions, and context they can look up without asking anyone. That gives platform teams a cheap test. Point an agent at the golden path for a new service and watch where it stalls. Anywhere the agent needs a human to fill a gap, a new hire does too, and closing that gap pays off for both.
The third customer is harder to design for. Harvey calls them solvers: non-engineers that hit the same friction every week and want it gone. Solvers know their own workflow better than anyone in engineering does, and many have no interest in building tools to fix it.
A roadmap that assumes everyone will build ends up shipping sandboxes to people who never open them. Platform leaders get more from treating solvers' friction as intake. Send a platform engineer to spend an afternoon with finance or support, find the step people redo by hand, and fix it with them on the same golden paths and guardrails engineers use, so the fix reaches production with an owner and the checks it needs.
Budget for the dip and protect the team that shortens it
Every major technology shift, from steam to electricity to the cloud, followed a J-curve, and Harvey expects AI to do the same: productivity dips before it climbs. He traced the AI dip to three costs:
The learning curve
The verification tax of checking AI output
The work of adapting delivery pipelines
Platform teams can shrink all three, so pulling platform engineers onto feature work to chase a 10x target makes the dip deeper and longer.
Here's how leaders can make the dip shallower:
Put it in the rollout plan before the licenses go out, so a flat quarter of delivery metrics is a forecast leadership already approved.
Point AI at review early: reviewing changes topped the room's friction poll, and review is where the verification tax runs highest.
Track the dip in rollbacks, owner coverage, and readiness pass rates. Token leaderboards only measure how much AI a team uses, and leadership needs to see whether that output reaches production safely.
Harvey closed with W. Edwards Deming: "A bad system will beat a good person every time." AI didn't change that. It amplified it. Protecting platform capacity through the dip is how leaders fix the system before it wears down the people inside it.
