A few weeks ago I went to quantify a trend I had already clocked: our test-writing had climbed, and kept climbing. Where a typical month once brought a handful of new tests, last month brought 436.
That is not a counting quirk. Whichever way I look at it, the picture is the same. We write far more tests than we used to, close to two thousand across the half-year, but the raw count is the least of it. More of every change is now test code. More of it gets a proper review before it ships. Less of it comes back to bite us later. And the tests are landing where they matter most. The critical paths through Cloud 66 were always well covered; what is new is that the awkward, expensive corners, the integration-heavy flows and the rare failure modes, are finally getting the same care. We are not writing tests to move a number. We are closing the gaps that were always the most stubborn to close.
None of this arrived as one heroic month, and nobody flipped a switch or sent a memo. It has been building since January, month on month, until the numbers looked like they belonged to a different team. All that really happened is that engineers kept choosing the thorough option, one change at a time, for long enough that it became the way we work.
The Tax We Could Never Afford
At Cloud 66, we are a right-sized team: everything a full engineering organisation does, run lean. We punch far above our weight. We always have. And we maintain a large, evolved codebase, the kind that has lived through multiple major framework versions and carries a decade of hard-won decisions inside it. Around it sits a sprawl of open source projects and a pile of internal tooling, each written in whatever language and framework made sense at the time (yes, we have regrets; looking at you, Vue.js). Anyway, the net combination is that we have “a lot of stuff”.
For a team like ours, thoroughness competes with shipping. Every hour you spend writing tests, mapping what a change will touch, or reviewing a migration from four different angles is an hour you are not shipping the thing the customer asked for or the market demands you provide. On a large team that tension is spread across people: the person planning the work is different to the person writing the test, is different to the one shipping the feature. On a team our size, it is often the same engineer (who naturally has greater appetite for some parts of that flow than others).
So you prioritise, and you prioritise hard. Never carelessly. The critical paths are the last thing you compromise. But you have to be honest about where the hours that remain can go.
Every startup and smaller company runs on some polite version of ship it and find out. It is a real strength, the thing that lets a small team move fast enough to matter. Its cost is quieter: the parts of the system that are expensive to test and rarely break are the ones that wait longest for the coverage they deserve. That was the trade-off we lived with. It never touched the core, which we protected.
The thing I did not expect is that the trade-off is dissolving. We now get the thoroughness without paying the velocity tax, and once that tax disappears, you stop deferring the awkward corner, because the only reason you ever deferred it was the cost.
That is what those test numbers actually are. They are not a box-ticking campaign. They are what happens when covering even the hard, expensive gaps stops costing what it used to.
The Functions We Never Hired For
A large engineering organisation does not run on individual discipline for any of this. It hires for it. There is a QA function with people in it. There is a code review culture deep enough that someone qualified is always free to look. There is a release engineer. There is, somewhere, a person whose actual job is to keep the runbook honest… and that is to name only a few.
We never had those as dedicated roles. On a team like ours; engineers wore a second hat, doing the review and the QA and the release work between everything else. They did it well. But they did it with hours borrowed from shipping, not with a department's bandwidth. Not through any failure. Through arithmetic.
What changed is not who wears the hats. What changed is how far an hour inside one of those hats now stretches.
The reviewer.
Not long ago the team shipped a change to a self-healing path in Cloud 66's infrastructure, the kind of code that is genuinely hard to review well, because it is tedious to reason about and only runs in the rare moment something has already gone wrong.
The engineer reviewing it did what none of us ever had the hours to do: put the change in front of a panel of independent AI reviewers, each looking from a different angle, none of them coordinating, and then sat in judgement of what came back.
Some of it was noise. One finding was not: a way the system could drift into an inconsistent state during a backfill, for some customers, on one specific operation. That is the kind of subtle issue you would normally only find in a postmortem. The engineer confirmed it was real, and fixed it in the pull request, before it ever reached a customer.
The one who maps the blast radius.
A couple of months ago I wrote about shipping cascading replication, and why a capability the database had supported for over a decade took us longer to ship than we would have liked. The thing I focused on there was the tedious work of untangling a decade of assumptions before you can touch the foundation.
What I did not dwell on is how carefully that work actually got done. The riskiest part; the change to the data model underneath everything, went through a gauntlet of audits, 15+ independent and aggressive reviewers, before it landed, and its follow-up fixes came straight out of what those audits found.
We do not have that many reviewers on call; almost nobody does. What we had was a couple of engineers who could now summon that gauntlet whenever they needed it, and who spent their time weighing its findings instead of hunting for them.
The QA engineer.
We recently moved a core authentication library to a new major version. That is the sort of change that breaks in quiet, dangerous ways, so the engineer doing it wanted regression tests in place first, as a safety net, before touching anything. Wanting them was never the hard part; finding a spare week to write them was. Which is exactly why this kind of pre-emptive, invisible work got squeezed when time was tight. Now the bulk of that suite gets drafted in hours and reviewed like any other code, so the safety net actually gets built.
The one who does the unglamorous cleanup.
Last month we cleared out a dead class and some unused configuration keys; the kind of housekeeping every evolving codebase accumulates and one that sneakily makes future changes harder to reason about. Nobody gets promoted for it. It is the purest form of the boring work, and the easiest to keep deferring when there is always something more urgent. Deciding what is safe to delete still takes an engineer. Proving that nothing anywhere still depends on it no longer takes their afternoon. So it just gets done.
None of this is the clever part of engineering. The clever part stayed exactly where it was: with the people. That is the whole point.
Thoroughness Stopped Being a Luxury
Technical debt, for a team like ours, was never a failure of discipline. It was triage, rational every single time: the debt was survivable and not shipping was not. The problem is that those trades compound, and enough of them quietly raise the price of everything you do next.
What changed is not that we became more disciplined. We were always disciplined about what mattered. It is that the triage math moved. Applying that same rigour everywhere, including the expensive corners where it never used to pay for itself, stopped being a luxury reserved for well-resourced teams.
The common story about AI is that it makes you faster. That is the boring story, and the evidence for it is messier than most people think. The more interesting thing is that it raised the floor.
A team our size can now run a full development lifecycle end to end: tests, review, careful migrations, debt actually paid down, at a depth that used to require people we did not have. It is not about doing the same work faster. It is about extending the care we always gave the critical paths to every last corner of the system.
The Team of One
If this is true for a team our size, it is more true for a team of one.
The single founder is the extreme case of everything above. Every supporting function a real company staffs, they have none of. Not because they do not know those functions matter, but because they cannot hire for them, and often could never have hired for them, for want of budget or access or the network to find the right people.
For that person, AI is the biggest enabler I have seen. It is the first time a single founder can build a product the correct way, with an actual development lifecycle around it, without depending on people they were never going to be able to bring in. The judgement still has to be theirs, every call of it. But judgement was always the one thing a founder had to bring; the rest is what they could never hire.
What AI Is Not
I want to be careful here, because there is a lot of nonsense in the air about what these tools can and cannot do.
The AI is not doing the clever part. It is not as good at design as a good senior engineer; not even close. Left alone, it writes code with the judgement of an enthusiastic junior who has no taste and infinite energy. It does not know which of two correct designs is the one you will not regret in a year. Every genuinely important decision in everything I described above was made by a person.
It is not even clear these tools make existing work faster. The trials that show a speed-up mostly measured junior developers or work built from scratch. The best-known study of the setting this essay is about, a randomised trial METR ran in early 2025 with experienced engineers on large, mature codebases, found them 19% slower with AI assistance, and convinced of the opposite.
But that was the tooling of a year and a half ago, and when METR re-ran the experiment this year, the slowdown had largely gone. The tools change faster than the studies measuring them. Which is fine, because speed on existing work was never my claim. The claim is that work which was never going to happen now does: the awkward coverage, the extra review, the cleanup. You cannot time a task nobody was going to do.
What it is, consistently, is thorough. It is thorough in the way a tired engineer at 4pm on a Friday is not. It will read every caller. It will check the boring path. It will write the test that never quite justified the time before. The value is not cleverness. It is patience that does not run out, and it turns out that most of the process work a big team hires for is patience, not brilliance.
The same drop in cost that lets you pay down debt also lets you generate far more of it, far faster, than you ever could before. The AI tool makes thoroughness affordable. It does not make it automatic. If you spend the surplus on volume instead of on quality, you will simply manufacture the next mess faster than anyone before you. The floor went up. Whether you stand on it is still a choice.
Go and Look at Your Own History
If you run a lean team on an evolved codebase, do what I did: go and look at what you have actually been committing.
You may find, as I did, that something changed without anyone announcing it. And if it has not changed yet, the more useful realisation is that it now can. There is always a list of things you meant to get to and never had the hours for: the coverage of the awkward paths, the cleanup, the careful migration, the extra review. The only thing still in the way is realising that none of it takes people you do not have.
The leverage here is not evenly distributed. It is bigger the smaller you are. For a large organisation the AI tool mostly makes functions it already staffs a little faster. For ours, it extends the reach of the people already doing that work into territory we could never have staffed for. That is why the same tool is worth so much more to a team our size than to one of three hundred.
Which, if you follow it far enough, leads somewhere uncomfortable. If AI technology is worth the most to the teams with the least money, and the least to the ones who can most easily pay, that is a strange and unstable thing to try to put a price on. I will address that in a follow-up post.
For as long as anyone can remember, thoroughness and speed were things a team like ours had to choose between. That is not true any more. You might find the corner you have long deferred is one you can finally afford to close.