The fable of the tortoise and the hare has a new version in software development, and this time it is measured in tokens. Every time a system with poor architecture grows, each new feature becomes more expensive to generate with AI. The hare that raced ahead without building foundations ends up paying more, whether for a feature or for the upkeep of its technical debt. The tortoise that invested in architecture from the start does not.
In the fable, attributed to Aesop (6th century B.C.), a tortoise and a hare decide to race each other. Of course, the hare took off running, confident it would win. The tortoise advanced without pause but without haste. At one point, the hare could no longer see the tortoise, so it decided to take a rest; after all, the tortoise would never beat it. The end of the story is that the hare fell asleep and the tortoise ended up winning the race.
The common factor in most development teams is to produce: to build the features that the company’s different departments require. Every developer tells themselves: “I’ll fix it and tidy it up later, what matters is that the feature is ready and they can use it.”
That is how technical debt piles up… TO-DO: apply this or that pattern… use a distributed architecture here or there… encapsulate the logic to follow the DRY principle (don’t repeat yourself), and so on… Want to hear an uncomfortable truth? That moment never comes. A company’s departments are not going to stop requiring new features, and it is very hard to halt the development team to eliminate technical debt through refactoring, remove legacy dependencies, or make deep architectural changes, among other things.
What you observe in practice is that systems where no focus is placed on architecture, and where no time is given to adjust it, end up reducing productivity. This leads to missing the delivery dates for improvements or new features, and to a higher cost than at the start of the project. Even as the number of engineers and developers grows, the amount of code generated stagnates.
In the book Clean Architecture, Robert C. Martin explains it this way: as releases go by, the effort per feature rises and effective productivity tends toward zero, even as more engineers are added. The team grows, the useful lines delivered stagnate.
Now, with development assisted or directly generated by AI, it is not only important to know what must be done, but —even more important— how to do it. This has at least two facets. The first we already mentioned: on a foundation with deficient architecture, each feature consumes more tokens than on a solid architecture, and that is paid on every delivery. The second, and less obvious: making an architectural change once the system is already a mess will carry a far higher cost.
As always, it is important for functional analysts, technical leads and systems managers to continuously explain the development process to those who make the decisions. Departments are not familiar with the internal processes of systems, nor with how a good early architectural decision can lower the cost and time of implementing new features in the future. If they understand it, they will also grasp that when an implementation takes a bit longer, nothing is being lost: it is being invested.
The paradigm has changed, and with it, what it means to go fast. The hare believes speed is delivering features now; the tortoise understands that sustained speed is investing in architecture so that every future delivery is cheap. In the age of AI, the tortoise not only wins the race: it wins in tokens.