Agile is Dead, Hello AiGile World
In practice, agile often means keeping the same codebase alive indefinitely, layering patch on patch, sprint on sprint, and hoping disciplined iteration can outrun the mess. Refactoring, yes. A full rewrite, usually no. That made sense when rewrites were expensive, slow, and usually reckless. AI changes the economics of that. If rebuilding becomes cheap enough, then maybe the healthier rhythm is not endless extension but cycles of build up, break down, and build up again.
You still use the sprint to ship, learn, and discover what the project actually is. But instead of carrying every compromise forward like inherited debt, you stop and rewrite around what you now know. Monthly, maybe. Or whenever enough awkward patches, badly handled edge cases, and accidental complexity have piled up that the clean version is easier to produce than the next fix.
This is more or less the conclusion I have arrived at from the last few days working on two projects.
Project A is old, at least in AI terms. GPT-3.5 era. Mostly hand-coded, with some Copilot tab completion sprinkled in, and some agents used for dataset creation. Now the client is back and wants data expansion, a couple of new features, plus updates for new markets.
Project B v1 is one of the current projects I’m working on, and we have been building on it for the last six months. It is a fairly new domain for us, with a new client who had done similar qualitative work before but now wanted it pushed into something more quantified. They were also not fully sure what the output should be, or did not want to hand us the answer directly. They wanted us to discover it, which I respect. But it also has a tight schedule with constant intermediate deliveries, updates, and patches, and the codebase looks exactly like that story sounds. We are in the final stretch, but there are still a lot of deliveries left.
Project B v2 is the thing we actually want on the other side of this: a generalized version of the project that could work as a platform and also support future bespoke client work. In practice, that is easier to solve with a complete rewrite built around what we have now learned actually matters.
For the last couple of days, Claude and I have been working on Project A and Project B v2, and it has been smooth. We found edge cases we had not thought about, but updating docs, backend, frontend, and data pipelines to absorb them has been straightforward.
Then today I had to make what looked like a simple update in Project B v1 for an immediate delivery, and both Claude and I kept running into wall after wall.
The newer shape, v2, even with fresh discoveries and unhandled edges, is flexible. The older lived-in version, the one patched under delivery pressure, resists basic change, and we kept getting lost in back alleys. That is what gave me the thought: if we had been able to start each month by rewriting the thing from scratch around the lessons already learned, and if the rewrite took at most a day, we would be in a much better position now.
I have not really used Fable yet, but if the AI people on Twitter are right, it may already be good enough for this kind of cadence. And if not Fable now, then whatever the state-of-the-art model is a year from now probably will be.
So maybe the future development rhythm looks like this: within the sprint, you add features. Between sprints, or at some regular threshold of accumulated mess, you hand the whole thing to your preferred harness and let it rewrite the system cleanly around the latest understanding. Not agile in the old sense. Hello AiGile World