Leçons pratiques de la construction d’une base de code de 350 000 lignes en solo avec des agents IA

L'environnement d'ingénierie comme contexte

Le projet de 52 jours du développeur (600 commits, ~965 000 lignes de code traitées, 356 000 lignes de code de production) a révélé que la qualité de la sortie des agents dépend de manière critique de l'environnement d'ingénierie, et pas seulement du modèle. La base de code elle-même sert de système de contexte pour l'agent, éliminant le besoin de fichiers RAG ou de mémoire séparés.

Des limites architecturales claires se sont avérées essentielles. La base de code suit un découpage DDD strict : couche domaine pour les structures de données, couche service pour la logique métier, couche handler pour la conversion de format HTTP, avec 22 modules de domaine ayant des limites claires. Cela indique aux agents où effectuer les modifications.

La structure des répertoires fonctionne comme une documentation avec un alignement des noms entre les piles. Pour une fonctionnalité comme "Loop" : backend/internal/domain/loop/ pour les structures de données, backend/internal/service/loop/ pour la logique, web/src/components/loops/ pour le frontend. Cette correspondance directe entre le concept produit et le chemin du code élimine le besoin pour les agents d'explorer l'intégralité de la base de code.

L'amplification de la dette technique

La dette technique se propage de manière exponentielle avec les agents IA. Lorsque les développeurs font des compromis temporaires — contournant la couche service pour interroger directement la base de données ou utilisant des nombres magiques codés en dur — les agents réutilisent systématiquement ces modèles comme des approches légitimes. Contrairement aux ingénieurs humains qui reconnaissent le mauvais code comme des pièges, les agents traitent les modèles existants comme des précédents valides.

La conclusion pratique : le refactoring régulier devient essentiel non pas pour l'esthétique mais pour maintenir la pureté du signal d'ingénierie. Lorsque les bonnes pratiques dominent, les agents amplifient les bonnes pratiques ; lorsque les raccourcis dominent, les agents amplifient les raccourcis. Cela représente un coût de maintenance unique dans le développement collaboratif avec des agents.

Le typage fort comme garde-fou de qualité

L'utilisation de Go + TypeScript + Proto fournit une détection d'erreurs à la compilation qui déplace les erreurs des agents du temps d'exécution au temps de développement. Les fonctions générées par les agents avec des signatures incompatibles provoquent des échecs de compilation. TypeScript détecte immédiatement les incompatibilités de format d'API. Le code généré par Proto ne se compile pas si les formats de message changent sans synchronisation backend. Ces erreurs passeraient inaperçues jusqu'au runtime dans les langages faiblement typés.

Système de feedback à quatre couches

Les agents ont besoin de quatre couches de feedback pour une itération efficace :

• Compilation — rechargement à chaud, redémarrages de Go en moins d'une seconde, erreurs de type TypeScript signalées en temps réel. Élimine les erreurs de syntaxe et de type.
• Tests unitaires — 700+ tests couvrant les couches domaine et service. Les agents savent en moins de 5 minutes s'ils ont introduit des régressions, en particulier pour les conditions limites comme l'isolation multi-locataire.
• Tests E2E — validation de bout en bout des chemins fonctionnels réels. Capture les problèmes d'intégration que les tests unitaires ne peuvent pas atteindre.
• Pipeline CI — chaque PR exécute la suite complète de tests, le linting, la vérification de type, la construction multi-plateforme. Le filet de sécurité final avant la fusion.

Les quatre couches fournissent une latence croissante et une couverture élargie : la première couche confirme les changements d'une seule ligne, tandis que la quatrième valide le refactoring inter-modules.