AI-written code is shipping faster. What does that do to release stability?
By the Keel team · Last checked · 5 min read
Short answer
Google's 2025 DORA report found that AI adoption now has a positive relationship with software delivery throughput but still a negative relationship with delivery stability. In practice, teams ship more change, and without strong automated testing, review and fast feedback, more of it breaks. The answer is not less AI. It is stronger release safety nets.
What did the 2025 DORA report find about AI and delivery stability?
The 2025 DORA report, titled State of AI-assisted Software Development, describes AI as an amplifier: it magnifies an organisation's existing strengths and weaknesses.
Google's announcement of the report says AI adoption now has a positive relationship with software delivery throughput and product performance, but continues to have a negative relationship with software delivery stability.
The report's explanation is direct: without robust control systems, like strong automated testing, mature version control practices and fast feedback loops, an increase in change volume leads to instability.
Why does more code lead to less stable releases?
More code leads to less stable releases when review, tests and release checks do not scale with the extra change, so bigger pull requests and untested edge cases reach production.
- Bigger pull requests are harder to review properly.
- Generated code can look right and still miss edge cases your tests do not cover.
- More releases means more chances for a bad one, unless each is checked the same way.
- Infrastructure and migrations written quickly can be destructive in ways a code review misses.
None of this is unique to AI. It is what happens whenever change volume rises faster than the checks around it.
What safety nets keep releases stable as AI speeds up delivery?
The safety nets that scale with change volume are automated tests, small reviewed pull requests, visible infrastructure plans, health checks, automatic rollback and policy checks on risky actions.
| Safety net | What it catches | Where to start |
|---|---|---|
| Automated tests in CI | Logic regressions | Tests on the paths that make money |
| Small pull requests and review | Changes nobody understood | A size limit and one reviewer |
| Infrastructure plans in review | Destructive infra changes | Terraform plan posted on every PR |
| Health checks and smoke tests | Releases that cannot serve requests | See deployment health checks |
| Automatic rollback | Broken releases in production | See ECS automatic rollback |
| Policy checks on risky actions | Deletes, access and DNS changes | Require a person and written approval |
Should AI agents be allowed to change AWS infrastructure?
AI agents can safely do a lot of operational legwork if their permissions are tiered.
Read-only work, such as cost scans, backup checks and log summaries, can run on its own. Routine changes can be drafted by an agent as a pull request and approved by an engineer. Risky actions, such as deleting data or changing access or DNS, should be done by people only, with explicit approval.
That is the model Keel uses, and it maps closely to the DORA finding: the speed comes from AI, the stability comes from the review and the checks around it.
What should a small team do about AI and release stability this quarter?
This quarter, measure your change failure rate, turn on automatic rollback, test the flows customers pay for, review infrastructure plans and write down what AI tools may do alone.
- Measure your change failure rate: how many deploys needed a rollback or a fix.
- Turn on automatic rollback for every service.
- Add tests to the two or three flows customers pay for.
- Require review for infrastructure changes, with the plan visible.
- Write down which actions an AI tool may take alone, and which need a person.
For the wider release setup, see how small SaaS teams ship on AWS without breaking production.
Are your safety nets keeping up with AI-assisted delivery?
Tick each item that is true today.
- You know your change failure rate for the last month.
- Tests cover the flows customers pay for.
- Large pull requests are split before review.
- Infrastructure plans are visible in every pull request.
- Failed deploys roll back automatically.
- There is a written list of actions AI tools may not take alone.
Decision point: Four or more ticks: you can ship more without losing stability. Three or fewer: add the missing nets before increasing change volume further.
Which infrastructure changes should never be left to an AI tool alone?
Anything that is hard to undo: deleting data or backups, changing who has access, editing DNS, rotating production secrets and making destructive infrastructure changes.
These should need a person and explicit written approval every time, whoever or whatever drafted the change. Keeping that list short and written down makes it easy to enforce in review and in permissions.
Does AI-written code need different code review?
It needs the same review, done properly. The risk with generated code is that it reads fluently and gets approved quickly.
Reviewers should ask the same questions as always: is this change small enough to understand, is it tested, what happens if it fails, and does it touch data, access or infrastructure. Large generated changes should be split before review, not after.
How do you measure whether release stability is getting worse?
Track two of the DORA measures that are easy for a small team: change failure rate, the share of deploys that needed a rollback or a hotfix, and recovery time, how long it took to restore service when something broke.
Count them monthly from your deploy logs and incidents. If change failure rate rises as you ship more, your safety nets are not keeping up.
Does release stability mean small teams should use less AI?
No. The DORA findings point to the system around AI, not AI itself.
Teams with strong automated testing, small batches and fast feedback get the speed without as much instability. For a small SaaS team, investing in those safety nets is usually cheaper than slowing down.
Sources
Keep reading
Keel is an AWS release and recovery operations service for SaaS teams of 3 to 15 developers, provided by Bargainn Services Ltd, a UK company registered at Companies House (16497746). Registered office: 3rd Floor, 86-90 Paul Street, London, EC2A 4NE, United Kingdom.