La refonte du codebase d'Autonoma sur 18 mois : leçons sur les tests, la dette technique et les Server Actions

Pourquoi un produit réussi a nécessité une réécriture complète

Autonoma, une entreprise qui a pivoté à plusieurs reprises (recherche d'entreprise, génération de documentation, agent de codage, plateforme de test QA), a développé un produit pendant plus de 1,5 an, a acquis des clients, a levé des fonds auprès d'un acteur majeur de l'industrie et a recruté une équipe de 14 personnes. Malgré cette traction, ils ont décidé de jeter toute leur base de code et de recommencer à zéro.

L'ère sans tests et ses conséquences

Initialement, l'équipe utilisait un monorepo TypeScript sans mode strict et sans tests. Cela fonctionnait avec 2 ingénieurs qui possédaient de grandes parties de la base de code, mais est devenu désastreux après les embauches. La base de code a développé des problèmes de null, des comportements indéfinis et une mauvaise gestion des erreurs, entraînant l'apparition de bugs "de nulle part" et même la perte d'un client. Le fondateur avait initialement interdit les tests pour maintenir une culture de livraison rapide, mais a ensuite réalisé que cela affectait la qualité du produit et la productivité.

Décisions techniques motivant la réécriture

Le produit original a été construit pendant l'ère GPT-4 (pas 4o) lorsque les modèles nécessitaient de nombreuses garde-fous. Ils ont construit des wrappers sophistiqués Playwright et Appium avec des inspections complexes et 7 stratégies de clic qui s'auto-réparaient à la volée. Avec les avancées des modèles, cette inspection sophistiquée n'est plus nécessaire, rendant la base de code héritée avec la dette technique moins précieuse.

Abandon de Next.js et Server Actions

L'équipe s'éloigne de Next.js et Server Actions, citant plusieurs problèmes :

• Les Server Actions sont asynchrones, nécessitant des blocs useEffect ou une gestion manuelle de l'état dans React
• Elles sont difficiles à tester - les tests nécessitent de créer des objets Prisma avec des bases de données en mémoire ou de les simuler
• Aucune capacité d'injection de dépendances
• Elles s'exécutent séquentiellement globalement, créant un "Global Interpreter Lock artificiel en Python mais en TypeScript"

La nouvelle implémentation commence avec des tests dès le départ et utilise le mode TypeScript le plus strict.