After 25 years with TDD, we are now parting ways. The incremental TDD steps were great for human cognition, but didn't survive the transition to agentic coding.

Test-Driven Development (TDD) has been my default programming mode for 25 years. TDD simply made me a better developer. It’s been invaluable.

However, the time has come to bid farewell to my old companion. Agentic coding is sufficiently different from manual coding, meaning we need to question existing development principles and practices. And TDD didn’t survive my transition into AI-native development: forcing an agent through increments optimized for human cognition negates many of the benefits.

This article reflects on my decades as a TDD practitioner as well as the agentic characteristics that made me abandon the technique. As customary, we’ll start from the beginning.

Depuis quelques années, je vois passer le même conseil : "Une bonne architecture doit rester simple et adaptée au contexte. Un vrai dev ne fait pas d’over-engineering."

Puis : "Pas besoin de microservices, CQRS, Event Sourcing..."

Déjà, mettre microservices, CQRS et ES dans le même sac, c’est comparer l’urbanisme, la circulation et les archives d’une ville : même système, problèmes différents.

Mais surtout : sur quoi vous basez-vous pour déterminer le "bon niveau d’architecture" ? Sur ce que le client vous a raconté au premier atelier de 10mn ?

Un client décrit ce qu’il croit vouloir aujourd’hui, rarement ce que son logiciel devra absorber demain.

Sur mes 3 derniers projets :

• "Il nous faut juste une calculatrice" est devenu un système de pilotage des achats pour 30 M€.
• "Un Excel amélioré" est devenu un outil gérant charges, machines, compétences et turnover.
• "Le planning sera très simple" est devenu une application multisite avec des problèmes de connexion.

Si j’avais dimensionné l’architecture sur le discours initial, j’aurais fait quelque chose de "simple". Tellement simple qu’il aurait fallu tout réécrire quelques mois plus tard. 🤦‍♂️

Une partie du problème vient du web : on appelle "application" une page avec trois formulaires et une base derrière. Pour un site plaquette, pas besoin de sortir l’artillerie lourde. Mais une vraie application de gestion utilisée par des 10ene ou 100ene de personnes, c’est autre chose : les règles bougent et les exceptions deviennent la norme.

Je vais bientôt avoir 30 ans d’expérience dans la tech : 5 ans dans l’infra, 15 ans sur des logiciels de gestion traditionnels, bientôt 10 ans en CQRS/ES. J’ai eu le temps de voir ce qui tient dans la durée et ce qui casse à la prochaine demande métier.

Le coût d’une architecture ne se mesure pas au nombre de classes créées au démarrage, mais au prix du changement 6 mois, 3 ans ou 10 ans plus tard.

Une architecture trop simpliste produit souvent un effet cocasse : comme le logiciel supporte mal le changement, on essaie d’empêcher le client de changer d’avis. On contractualise, on fige, on ressort le fameux "Mais vous aviez dit que...".

C’est pratique : au lieu de rendre le logiciel adaptable, on essaie de rendre le client immuable.

Et non, CQRS/ES ne servent pas uniquement à l’audit ou à la traçabilité. On peut aussi les choisir parce qu’on accepte une évidence : on ne sait pas encore ce que le métier nous demandera demain.

Bref, considérer qu'une architecture ambitieuse est forcément de l’over-engineering parce que le besoin semble simple aujourd’hui, c’est juste remplacer un dogme par un autre.

C’est comme partir à la guerre sans arme en disant : "YAGNI. On fabriquera les fusils quand quelqu’un commencera à tirer. 🤓 "

Une bonne architecture n’a pas pour but de prédire l’avenir. Elle doit faire en sorte que, lorsqu’il vous donne tort, vous ne soyez pas obligé de tout réécrire.

La simplicité, oui. Le simplisme déguisé en expertise, beaucoup moins.

Humans are hacking AI systems. Humans are hacking with AI systems. But also, AIs are hacking human systems.

They’re finding and exploiting vulnerabilities in computer code, and they’ll soon be doing the same with all sorts of other codes.

For example: the tax code can be hacked. Vulnerabilities are called loopholes, exploits are called tax avoidance strategies, and black hats are called accountants. Similarly, financial markets can be hacked.

So can any system of rules or laws, including democracy itself.

AIs will hack these systems at our request, and they’ll also do this innately, organically – and possibly in ways we don’t immediately see.

We need to consider a world where increasingly sophisticated hacks or our social, economic, and political systems are discovered computer speeds, and then exploited at computer scale and scope.

Right now, our systems of patching these systems operate at a human pace, which won't be good enough.