The rewrite comes sooner

The promise of agent-based coding is speed. Ship in an afternoon what used to take a week. That part is real. I've watched it happen.

But there's a second half to the speed that nobody talks about, and it matters more than the first.

Every growing codebase hits inflection points. You build on an assumption that works, and at some point the assumption stops holding. A query that was fine at a thousand rows buckles at a million. A framework releases a version that changes the model you built on. An architecture that felt obvious at the start starts fighting you once the system has a real shape. At that point you don't patch. You re-implement a core piece. A partial rewrite.

In human-paced coding, these inflection points come every year or two. You feel them arrive slowly. You have time to feel grumpy about them, then plan, then do the rewrite over a few weeks.

With agent-based coding, the same inflection points come after months. Sometimes weeks. Not because the code is worse. Because you got there faster. You shipped six months of features in six weeks, and the assumptions those features were built on ran out of road at exactly the point they always would have.

Here's the trap. If you keep shipping past the inflection point, the code gets brittle. Every new feature fights the old assumption a little harder. Changes that used to be small become scary. The codebase gets harder to reason about, not because it's big, but because the foundations underneath it have quietly stopped being right. The speed that felt like a gift turns into the thing slowing you down.

So you have to treat the rewrite as a scheduled event, not a surprise. When the code starts pushing back, that's the signal. Don't push through it.

And here's the part I didn't expect. The thing that got you to the inflection point fast is also the best tool for getting through it.

A big refactor is really a conversation. Which assumption doesn't hold anymore, and why? What does the data actually look like now? What are users doing that the old architecture didn't anticipate? What's the current best practice for this problem? Doing that conversation with an agent is genuinely good. It's grounded in the actual code, not in what I remember from three years ago. It pulls in the most recent thinking on the problem. And it lets me reason about a large refactor against current best practice without spending a week reading first.

The rewrites don't go away. They just show up sooner, and I'd rather have the tool that ships fast also be the tool that helps me think when the foundations need to move.

The lesson, if there is one: the speed isn't the point. The cycles are just shorter. Ship fast, but watch for the inflection point, and when it comes, do the rewrite with the same tool that got you there. It's better at it than you'd think.