A team we work with wanted to release faster. Fair ambition, and the usual instinct is to buy something that helps developers write code quicker.
So before changing anything, we mapped where a change actually spent its life, from first commit to running in production. Most of that life was waiting. Waiting for a reviewer with time, because everyone senior enough to review was busy with their own work. Waiting for tests, which tended to get written after review instead of before. Waiting for the next release window, because releasing was manual enough that it had to be scheduled.
The writing was never the slow part. The queue was.
What we changed
Once you see it as a queueing problem, the shopping list writes itself: put help where work waits, and leave the keyboard alone.
GitHub Copilot in the editor was already there, and honestly it's the least interesting part of this story. It makes the writing quicker, and the writing was already quick.
Claude reviews every pull request first. This is the change that paid for everything else. The moment a pull request opens, Claude Fable reads the diff and leaves comments: the unhandled null, the swallowed exception, the function that got copied and half-edited. It approves nothing. By the time a human reviewer opens the pull request, that layer has already been dealt with, so they can start where their judgement matters, at the design. Reviewing went from a chore people postponed to a short job they fit between other things, and the queue in front of it shrank accordingly.
Playwright tests drafted from the diff. The test suite was thinnest exactly where the product changed most, which is how it usually goes. Now the diff and the team's spec conventions go to a model when a pull request opens, and it drafts Playwright tests for the paths that changed. Plenty get edited before merge and some get thrown away. That's fine. Drafting was the part nobody wanted to do, and it now costs nothing, so coverage grows wherever the product moves. Regressions get caught in CI instead of in a support ticket.
Dependabot and CodeQL, switched on in an afternoon. Native GitHub, no new vendor, no glamour. A faster pipeline ships mistakes faster too, and these two catch a whole category of them without anyone needing to be sharp-eyed on a Friday.
GitHub Actions runs the release. Builds used to live in Azure DevOps, and the team was consolidating on GitHub anyway. With review, tests, scanning and deployment in one place there's a single audit trail. That trail matters more once a model participates, because you want to answer precisely what ran and which person approved it.
Keep the merge human
A model here can write code, review code and draft tests. It can't approve a pull request and it can't deploy. That's enforced as a repository permission, so it doesn't depend on anyone's discipline during a busy week.
Everything before the merge is a draft, and drafts are cheap to get wrong. Everything after the merge is production. Holding the boundary there means the speed lands where mistakes are recoverable, and every release still traces back to a named engineer who said yes. When security or an auditor asks who signed off, there's a name.
The result
Releases stopped being events. They went from a scheduled occasion to something that happens several times a week, when a change is ready rather than when the calendar says so.
Quality moved in the same direction, which surprised the people expecting a trade-off. More regressions die in CI because the tests now exist, and rollbacks have become rare.
And the change nobody predicted: reviewing stopped being the job everyone saved for the end of the day. Shorter, more interesting work gets picked up sooner. A decent share of the cadence gain is probably just that.
How to get started
Measure where a change waits before buying anything. If review latency is your bottleneck, faster typing won't touch it. Start with AI review, because it's cheap to try, easy to switch off, and a person reads its output anyway. Let a model draft your tests, and treat the drafts as drafts. And make the merge a human permission from day one, because that boundary is what lets you say yes to everything else.
There's no one-size-fits-all approach to the cloud. That's why we meet you where you are.
