Your engineers are almost certainly using AI to write code. In Google's 2025 DORA research, based on nearly 5,000 technology professionals, 90% said they use AI at work. More than 80% said it made them more productive.
The same research found something less comfortable. AI adoption is now linked to faster software delivery, but it is still linked to less stable delivery. Teams ship more change, and more of it breaks.
DORA's explanation is simple. AI does not fix a team. It amplifies what is already there. Strong engineering systems get stronger, and weak ones fail faster.
This guide covers where the pressure lands when code gets cheaper to write architecture, review and testing, delivery of pipelines and legacy systems. It ends with five questions to answer before you scale AI coding tools across your teams.
AI Made Writing Code Faster. That Was Never the Whole Job
Writing code is one step in delivering software. Before it comes decisions about what to build and how it should fit together. After review, testing, integration, release and operation. When one step speeds up and the others do not, work piles up at the next one.
That is what the DORA data shows. Without strong automated testing, mature version control, and fast feedback loops, more change simply means more instability. Teams working in loosely coupled systems saw gains. Teams held back by tightly coupled systems and slow processes saw little or no benefit.
Trust is the other half of the problem. DORA found that 30% of respondents have little or no trust in AI-generated code. Someone still has to check it, and that work does not get faster on its own.
The pressure lands in four places.
| Area | What AI Changes | What Breaks Without a Plan |
|---|---|---|
| Architecture and Standards | Code is produced faster, by more people | Inconsistent patterns and duplicated logic build up |
| Review and Testing | The volume of change rises | Reviews become the bottleneck, or get rushed |
| Delivery Pipelines | Releases come faster and more often | Change failures and rework increase |
| Legacy Systems | Old code becomes easier to read | Teams translate code they still do not understand |
Architecture Decides Whether Speed Compounds or Collapses
AI writes code one request at a time. It sees the file in front of it, not the system around it. Ask it to solve a problem and it will usually solve it locally, even when the same logic already exists somewhere else.
At scale, that pattern shows up in the codebase. GitClear's analysis of 211 million changed lines found an eightfold rise in duplicated code blocks during 2024. That year, copied lines outnumbered moved lines, the usual sign of refactoring work that pulls logic into reusable parts. Duplicated logic runs fine until it needs to change. Then every copy has to be found and fixed.
The answer is not to slow AI down. It is to give it a structure to work within.
- Clear Architecture First: Agreed service boundaries, data ownership and integration patterns, so new code has an obvious place to go.
- Standards the Tools Can Follow: Coding conventions, approved libraries and reference implementations, given AI tools as context rather than left in a wiki.
- Loosely Coupled Systems: DORA found loosely coupled architectures gained from AI while tightly coupled ones saw little benefit. Decoupling is now a productivity investment as well as a technical one.
- A Sharper Build Decision: When building gets cheaper, it is tempting to build everything. The better question is which systems set the business apart and deserve custom code, and which should be bought.
This is the thinking behind our product engineering work. Architecture and standards come before the build, so AI speed adds instead of piling up.
Review and Testing Become the Control System
DORA's analysis of feedback from 1,110 Google engineers names the tradeoff directly. Time saved writing code is often spent again checking it. One engineer can now produce a large change in minutes, but the reviewer still must read every line.
Review becomes the bottleneck. Under pressure, it either slows delivery down or gets rushed. Neither is acceptable for systems the business depends on.
Teams that handle this well treat quality as a system, not a final gate.
- Small Changes: Large AI-generated changes are split into units a person can review and test properly. DORA calls working in small batches as a critical countermeasure.
- Automated Checks Before Human Review: Tests, static analysis and standards checks run on every change. People then review logic and intent, not formatting and obvious errors.
- Feedback While the Code is Written: AI review tools are most useful when they flag issues to the author, before the change reaches a reviewer.
- Human Review Where the Risk Is: Payments, security, data handling and regulated logic get senior review every time. Low-risk changes move faster.
- Tests that Keep Pace: AI can help write tests as quickly as it writes code. The test suite has to grow with the codebase, or it stops protecting it.
Quality engineering used to be a phase near the end of delivery. With AI in the loop, it is the control system that makes the speed safe. That is how we approach software quality assurance.
Delivery Pipelines Must Keep Pace
More code means more releases, and every release is a chance for something to break. DORA tracks this through instability measures such as change failure rate and deployment rework rate. These are the numbers that rise when speed outruns the system.
The pipeline is where speed is either made safe or made expensive. DORA's 2025 research found a direct link between a high-quality internal platform and an organization's ability to get value from AI. In the survey, 90% of organizations had already adopted at least one.
A pipeline built for AI-assisted delivery has a few clear features.
- One Path for Every Change: Build, test, security scanning and deployment are automated and identical, whoever or whatever wrote the code.
- Small, Reversible Releases: Feature flags, gradual rollouts and fast rollback limit the damage any single mistake can do.
- Monitoring From Day One: Teams see a release's effect on errors, performance and users within minutes, not days.
- Metrics That Measure Impact: Lines of code and commit counts say little when AI can inflate both. Lead time, change failure rate, rework and recovery time show whether delivery is actually improving.
That last point matters most to leaders. If the dashboard counts output, AI will make it look excellent while quality slips. Our DevOps engineering work ties each delivery metric to a business measure the company already tracks.
Legacy Code is Where AI May Help Most
There is a more encouraging side to this story. AI is very good at reading and explaining code. Legacy systems are full of code that nobody fully understands anymore.
Morgan Stanley has modernized more than 17 million lines of COBOL, Natural and Perl with an in-house generative AI platform, CIO Dive reports. The bank says it has saved developers more than a million hours. Its platform reverse engineers old code into a clear design before anything is migrated, with human oversight throughout.
The same report carries a warning. Gartner expects more than 70% of mainframe migrations started this year to fail, largely because leaders overestimate what generative AI can do. A Gartner analyst described legacy modernization as an unsolved business problem rather than a technical one.
Both points lead to the same approach.
- Understand Before You Change: Use AI to generate documentation, map dependencies and recover the business rules buried in the code.
- Build the Safety Net First: Use AI to help create tests that capture how the system behaves today, so any rewrite can be checked against them.
- Decide System by System: Some code should be rewritten, some wrapped behind an API and some left alone. AI makes the analysis cheaper. It does not make a decision.
- Keep People Accountable for the Result: Translated code still needs engineers who know what it must do.
Translating code without understanding it just moves the mess into a newer language. Our legacy modernization work starts by mapping what exists, so every change is made on purpose.
What Engineering that Uses AI Well Looks Like
The teams that gain most from AI are not the ones using it most. They are the ones whose engineering system was ready to absorb the speed. That readiness comes from decisions made before the code changes.
Every Fulcronix Build & Transform engagement runs on The Pivot. Each stage does a specific job when AI is part of the delivery team.
| Stage | What Happens | Why It Matters with AI in the Loop |
|---|---|---|
| Discover | Map the codebase, infrastructure and technical debt as they stand today | AI is most useful here, reading and documenting what already exists |
| Define | Agree on priorities, scope and the standard every release must meet | AI-generated code gets a clear bar to clear |
| Design | Set the architecture and migration path before any code changes | New code has an obvious place to go |
| Build | Ship in iterations, with automated tests running on every change | Changes stay small enough to verify |
| Launch | Deploy through automated pipelines, with monitoring from day one | Instability is caught before customers notice it |
| Evolve | Tune cost, performance and reliability as usage grows | Speed gains do not turn into tomorrow's debt |
We practice what this article describes. AI runs inside our own engineering, testing and operations, not only in what we build for clients. That is why the guardrails above are part of how we work, not an extra. And because we build capability inside client teams, the system keeps working after we hand it over.
Five questions to answer before you scale AI coding tools
Rolling AI tools out across every team is easy. Getting value from them is not. These five questions help engineering and business leaders decide whether the system around the tools is ready.
- Are we measuring impact or output?
Lead time, change failure rate, rework and recovery time tell you more than lines of code or tickets closed. Each should link to a business measure.
- Does new code have an obvious place to go?
Clear architecture, service boundaries and coding standards stop AI from filling the codebase with duplicate logic.
- Can review and testing keep up with the volume of change?
If every change is not tested automatically and reviewed in small batches, more code will mean more incidents.
- Where does a senior engineer always review?
Payments, security, personal data and regulated logic need named owners and a clear review rule.
- How will our people keep building real expertise?
DORA warns that AI can let engineers skip the hands-on problem solving that builds deep skill. Pairing and deliberate practice still matters.
If any answer is unclear, fix that before buying more licenses. The return on AI tools depends far more on the system around them than on the tools themselves.
Speed is Only An Advantage If It Holds
AI has made code cheaper to write. It has not made software cheaper to own. The organizations pulling ahead pair AI speed with the architecture, quality and delivery discipline that let them keep it.
The goal is not to move faster everywhere. It is to move faster where the system can take it, and to fix the system where it cannot.
If your teams are shipping more but trusting it less, or you are planning to scale AI tools across engineering, see how we approach engineering work. We will start by mapping what you have today.
