The Tracks Were Never the Speed Limit

For most of my career I avoided writing tests. I now write more of them than I ever have, and it has nothing to do with discipline. A note on what changed underneath the metaphor I've been repeating since before it was true.

By Jason Waldrip, with Claude August 25, 2026 07:15

For most of my career, I did not write tests. Not as a principled position, and not proudly. I wrote them when a reviewer made me, and I wrote them thoroughly on the things I was scared of, and the rest of the time I shipped and watched. I was fast enough and close enough to the code that I could hold the whole shape of it in my head, and a test felt like paying to be told something I already knew.

I now write more tests than at any point in twenty years. My opinion of tests did not change. What changed is that I am no longer the one typing.

the line I have been saying since before it was true

Ask anyone who has worked for me and they can finish this sentence: the train can only move as fast as the tracks it’s built on. It is on my about page. I have said it in architecture reviews, in board updates, and in more than one argument about why the release path deserved a quarter of the roadmap when nobody was asking for it.

At CommercialTribe I meant it literally. We had a release cadence measured in weeks, and I spent the first stretch of that job on GCP, Kubernetes, automated testing and deploys, until releases took hours. Nobody asked for that. What it bought was not features, it was the difference between a team that learns and a team that guesses. At GigSmart I did it in the other order and built the dev experience and the release path before we had much of a product to release on it, because I already knew what the alternative cost.

Both of those were the same argument: your foundation sets a ceiling, and if you want to go faster you raise the ceiling. That is what the metaphor says. Track quality determines top speed.

For twenty years that was a useful thing to believe, because the thing pressing against the ceiling was people. You wanted more throughput, you hired, and the tracks decided how much of that hiring turned into shipped software instead of incidents. The engine was expensive and slow and predictable, and the track was the constraint worth arguing about.

the engine got replaced while I was still making the argument

The part I keep having to say out loud, because it still sounds like marketing: generation is not the bottleneck anymore. I wrote a whole piece on that and I will not re-run it here. The short version is that the thing I spent a decade getting elite at, producing a lot of correct code quickly, is now something you rent.

Here is what I did not expect. When you point a fleet at a codebase, the first thing that breaks is not the code. It is everything downstream of the code.

I am not the only one seeing it. The 2024 DORA report found that AI adoption raised individual productivity and flow, and at the same time correlated with worse delivery stability and throughput at the team level. Read that twice. Every individual got faster and the system got worse. That is not a story about bad code. It is a story about a lot more change arriving at a pipeline, a review process, and a verification story that were all sized for the old rate.

Which means the ceiling framing has quietly stopped describing anything. Nobody is pressing against a ceiling. The generation layer will produce more change than your foundation can absorb, today, on a Tuesday, and it will do it whether or not you raised the ceiling first.

so what is the track actually for

Here is the reframe I have landed on, and I have had to correct myself in front of people who heard me say the old version for years.

The track was never the speed limit. The track is what keeps the train on the ground, and the ground just got a lot further away.

That sounds like the same sentence with the emphasis moved. It is not, and the difference shows up in every funding decision you make about infrastructure. If the track is a ceiling, then track work is an investment in going faster, it competes with features, and you do it when you want more velocity. If the track is what keeps you on the rails at a speed you did not choose and cannot give back, then track work stops competing with anything. It becomes the price of having turned the fleet on, and you either paid it or you are going to.

The old track was steel rail. You maintained it, and if you maintained it well the train went faster. A maglev does not have a faster version of that track. It has a different one, and running the new train on the old rails is not slow, it is a wreck.

Three things change, in the order I would fix them.

A person in the deploy path is a rate limiter attached to something that no longer has a rate. This is the least interesting of the three because it is the oldest argument, and I have written it up already as the deploy path being a product. What is new is only that the cost of ignoring it compounds faster now. If a human has to be awake for a release, the fleet’s output queues behind that human, and you have built a very expensive way to generate a backlog.

Tests stopped being a discipline and became structure. This is the one I got wrong personally, so I trust it most. When I wrote the code, the tests were a second opinion on something I already understood. When a fleet writes it, the tests are the only encoding of intent that exists. The agent will produce something plausible and confident and shaped exactly like working software, and the test suite is the thing that has an opinion about whether it does what you meant. I stopped writing tests because I was disciplined and started writing them because they are load bearing. Nobody talked me into it. The speed took the choice away.

The track has to repair itself. This is the newest, the least settled, and the one I would push back on hardest if someone else said it to me. A pipeline that goes red and waits for a person is still a pipeline gated on a person, just at a less convenient hour. What I am building instead is a loop that closes: a check fails, an agent picks up the failure with the context to understand it, and lands the fix as a reviewed change rather than a page. At Phoneware that looks like agent guides that live in the repo, a workboard the fleet actually tracks, canary targeting so a bad change is contained instead of discovered, and Terraform and GitOps under all of it so the state of the system is a file rather than a memory. It is real, it works, and I would not yet tell you it is finished.

the part I am not handing over

The whole reason the track can be automated is that a track is a system with a definition of correct. Green or red, drifted or converged, canary healthy or not. That is exactly the kind of question a machine should be answering at three in the morning instead of you.

What does not have a definition of correct is which parts of your system are load bearing. Whether this change is a ship-it-and-learn or a slow-down-and-get-it-right. Which failing check is a flake and which one is the system telling you something true that nobody wants to hear. The fleet will go equally fast at all of it, cheerfully, and that is the whole danger.

So the tracks get automated and the map does not.

I still say the line, by the way. I have just stopped meaning it as encouragement. When I said it before, I was telling a team that good foundations would let them go faster, and they mostly heard permission to ask for time. What I would tell them now is closer to a warning: the train is already moving at the new speed, nobody consulted you about it, and the only question left is what you are standing on when it gets to the curve.