AI didn’t break coding. It broke code review.
Contents
Most conversations about agentic AI coding assume two things: the bottleneck is generating the code, and developers are the ones picking which tools to use. After a year of running OpenRewrite and Moderne across tens of thousands of repositories at Morgan Stanley, Dov Katz and Khalid Elsawaf told a different story at this year’s Code Remix Summit. AI didn’t break coding so much as it broke everything downstream of it. Code review has become the new constraint. And the developer is no longer the integration layer. The AI agent is.
Speakers
- Dov Katz, Managing Director and Distinguished Engineer, Developer Experience, Morgan Stanley
- Khalid Elsawaf, Executive Director and Domain Architect, Secured Finance Technology, Morgan Stanley
Adoption at scale takes more than a great tool
Rolling out internal tooling at scale is hard for reasons that have nothing to do with the tooling. After a year of program work at Morgan Stanley, the technical lift turned out to be the easy part. Driving developers to actually use the platform, and to keep using it once newer tools showed up to compete for their attention, took marketing campaigns, training cycles, leadership cascades, a year-end developer challenge, and a sustained internal evangelism effort.
The result is real adoption across the firm. Thousands of developers are onboarded. A community-contributed recipe marketplace has grown into the hundreds, written by employees across many divisions and used to solve everything from common transformation patterns to bootstrapping AI context files into shared repositories. But the lesson Katz emphasized was that adoption like this does not happen passively. Stop pushing, and a shinier tool earns the attention instead.
The harder problem is that adoption itself is no longer enough. Once thousands of developers can run large-scale changes on demand, the problem moves somewhere else.
AI didn’t break coding. It broke code review.
The bottleneck moved downstream. As AI coding tools and large-scale refactoring platforms made it dramatically easier to generate change, the constraint shifted from writing code to reviewing it. The reviewers are the most senior engineers in the building, the same people AI was supposed to free up.
“In the time that Dov and I have been speaking, you probably could have produced a thousand-file, 10,000-line PR on the back of just a simple prompt. No human here is going to review that.”
— Khalid Elsawaf, Morgan Stanley
Elsawaf walked through the parallel: this is the third time the industry has faced this pattern. Quality assurance used to be a separate team that received binaries from developers and returned long bug reports. Developers were given the tools to validate their own changes, and QA analysts shifted from producing bug reports to helping design test cases. The same thing happened with DevSecOps. Security scanning moved from an external team into the CI/CD pipeline, run by developers as part of their normal work.
Both transformations shared two properties. The work moved from a scarce resource to an abundant one. And it shifted left, earlier in the delivery process. Code review has done the opposite. Review has shifted right, toward the most senior engineers, who are scarcer than ever now that AI handles more of the routine coding. That is why, Elsawaf argued, the review bottleneck feels different from the ones the industry has solved before. The forces that fixed QA and security are pushing in the wrong direction here.
The downstream effects are familiar to anyone running an enterprise platform team. Pull requests rot on the vine. Developers stop trusting the fixes coming from a central source. A growing backlog of changes never lands in production. As Katz put it, just because something is fixed doesn’t mean it is merged. And until it is merged, the fix is worth nothing.
Match scrutiny to the risk of the change
The fix is not more reviewers. It is treating different changes differently.
A minor version bump on a stable third-party dependency carries almost no risk. A large-scale refactor or a change to the security profile of an application carries a lot. Today, both flow through the same review pipeline, with the same scrutiny applied to changes that don’t all warrant it. Risk-based PR routing flips the model: low-risk changes move through a fast path, higher-risk changes get deeper review, and the level of attention matches the level of risk in the change.
Morgan Stanley has done this before. Several years ago, their DevOps transformation faced a structurally similar problem: as developers were encouraged to push smaller, more frequent changes, the manual change-approval ticket process became the bottleneck. The team responded by replacing human risk assessment with a Data-Driven Risk Assessment (DDRA), a quantitative score derived from system profile, change history, and incident data. Changes below the threshold flow through systematic approval. Changes above it get the manual process that existed before. Elsawaf and his colleagues are now applying that same pattern to PR review.
Morgan Stanley is not doing this alone. Through the firm’s involvement with the Fintech Open Source Foundation (FINOS), the SDLC Governance Working Group is bringing together Deutsche Bank, Kosli, Morgan Stanley, and others to establish a common set of SDLC controls and a common way of evidencing them. The aim is to make risk-based, AI-scale review an industry pattern, not a single-firm experiment.
Confidence is the prerequisite for scale
Every part of the model above depends on a single condition: confidence in the change.
“Confidence is an absolute prerequisite to being able to operate at scale.”
— Khalid Elsawaf, Morgan Stanley
For years, confidence was built the same way: small, predictable changes, deterministic CI/CD pipelines, and a reliable test suite. Same input, same output. Failures were reproducible. Validation was repeatable. AI changes both halves of that equation. Volume goes up. Reproducibility goes down. The same prompt run twice can produce different code. Failures are harder to investigate. The mechanisms that used to manufacture confidence are not equipped for the new rate or the new variability.
Which means the question for any team trying to scale AI is not how to generate more change. It is how to generate trustworthy change. Predictability, testing, and traceability are the load-bearing parts. Scaling AI means scaling confidence at the same time, or the new throughput never makes it to production.
AI plans. Deterministic tools execute.
The pattern that emerges is one Katz and Elsawaf described as the way forward. AI is the right tool for exploration, planning, and orchestration. Deterministic tools are the right tool for execution at scale. Used together, AI can do the parts a deterministic system can’t (reason about novel situations, generate plans, write recipes on the fly) while deterministic systems do the parts AI can’t do reliably (apply the same change consistently across thousands of repositories, produce auditable outputs, scale predictably).
“Don’t give the user a readme. Teach AI what all the tools are and how to use them.”
— Dov Katz, Morgan Stanley
This is the lesson that follows from accepting AI as the new integration layer. The user is no longer reading the documentation. The agent is. So the question is not whether the docs are well-written for humans; it is whether the agent that the developer is already talking to can use them to pick the right tool and run it.
What this looks like in practice: a real AssertJ upgrade where the dependency jump was large enough to risk breaking deprecated APIs. Rather than blindly shipping a PR, the AI agent was asked to research the change log, identify the deprecated method patterns, and generate an OpenRewrite recipe to detect any code touching those patterns. Crucially, the generated recipe was search-only. No actual code change. The recipe ran across the codebase as a deterministic scan in seconds and returned a precise list of affected files, giving the team a complete blast-radius map before any change was committed. Zero risk. AI generated the plan and wrote the safety check. The deterministic system executed it.
The same pattern showed up at larger scale during a Java build cache rollout. AI orchestrated the run across hundreds of repositories over a weekend. The platform executed the change deterministically. The agent then watched the PR build for each repository, triaged the CI logs, marked any failed builds as draft, and auto-undrafted the ones where the failure was pre-existing and unrelated to the change. By Monday morning, what landed in developers’ inboxes were not fire-and-forget PRs. They were PRs the system had already triple-checked, with the citation to the build log attached.
As Katz put it: AI needs determinism to scale.
The Moderne agent tools angle
The five lessons converge on a single architectural implication. The systems AI agents need most are the ones built for another piece of software to operate on. Deterministic. Evolving. Designed for automation. That is the bet Moderne is making with the Agent Tools category.
It is also the bet Jonathan Schneider, Moderne’s CEO and Co-founder, has been making publicly. As Schneider put it on LinkedIn: “Using a coding agent unimproved by CPU-based tools is like using an incandescent lightbulb rather than an LED. Sure it lights the room, nobody denies that. But just like that GPU, the incandescent lightbulb is a really good heater.” Pairing agents with the right deterministic tools is the difference between burning compute and producing trustworthy change.
The Morgan Stanley results are the proof. When agents plan and deterministic tools execute, hundreds of repositories can be migrated over a weekend, with verification, triage, and auditability all running unattended. What used to require a dedicated team of people running upgrades full-time is now a service the platform runs.
Join Dov and Khalid for Code Remix Summer on August 14 for the virtual replay and live Q&A.
Related posts
