Claude Code a aidé à créer une application Elixir de production sans écrire de code à la main en quatre mois

L'auteur a décrit une expérience de quatre mois : une application Elixir/Phoenix en production a été construite via Claude Code sans écriture manuelle de code. Au cours de cette période, le projet a atteint 1 702 commits, 3 880 tests et 94,83% de couverture, mais a connu deux incidents graves en production en chemin.

Échelle du Projet

Il ne s'agissait pas d'une démo ou d'un projet personnel, mais du service EasyStocksAI pour évaluer plus de 1 000 actions selon 15 métriques. L'application calcule des scores sur quatre blocs, gère des portefeuilles avec historique des transactions, compare les résultats avec des stratégies de benchmark et affiche des graphiques interactifs. L'auteur a également créé un blog avec un parser Markdown personnalisé capable de transformer les tickers et les commandes en liens et graphiques intégrés.

La stack est également entièrement production-ready : Elixir/Phoenix LiveView, PostgreSQL, Oban, Tailwind et Lightweight Charts.

Par les chiffres, le projet s'est avéré être plus proche d'un produit complet qu'une expérience. La base de code contient 422 mille lignes de code Elixir, plus de 73 mille lignes de tests, plus de 300 modules, 34 workers Oban et 80 migrations de base de données. Les données sont extraites de cinq API simultanément avec fallback en cascade : si une source ne répond pas, le système bascule automatiquement à la suivante. Tout s'exécutait sur une infrastructure modeste : un VPS sur Vultr et PostgreSQL en AWS RDS, tandis que CI/CD a été construit via GitHub Actions.

Comment la Qualité a été Maintenue

Le mécanisme de contrôle principal était un fichier CLAUDE.md que Claude Code lit à chaque session. L'auteur le décrit comme la constitution du projet : il contient les commandes obligatoires, les interdictions et les règles architecturales. Sans de telles contraintes, l'IA écrit un code fonctionnel mais mal géré ; avec elles, elle maintient un style cohérent et ne oublie pas le processus. Chaque nouvelle erreur devenait une nouvelle règle, donc le document s'est développé avec le produit.

• Après chaque modification, mix format et mix credo --strict sont obligatoires
• Pas une seule ligne de code de production sans test échouant
• Pour les données financielles, float est interdit ; seul Decimal est autorisé
• Les workers Oban ne peuvent pas faire de requêtes à la base de données dans les boucles
• La base de données est considérée comme la source de vérité, non l'état des processus

En plus de cela, l'auteur a séparé les rôles au sein du développement IA lui-même. En mode Director, le modèle s'occupe de l'architecture, des ADRs et des plans de modification ; en mode Implementor, il écrit du code strictement selon le plan et uniquement via TDD. Le cycle de travail est divisé en trois phases distinctes : brainstorming, planification détaillée et exécution par petites étapes de 2–5 minutes. Cette approche élimine la dérive architecturale : chaque nouvelle session IA lit les ADRs, les plans et les fichiers mémoire et continue le projet depuis le contexte établi, pas depuis le début.

Où l'IA a Cassé la Production

La partie la plus précieuse de l'histoire n'est pas les chiffres, mais l'analyse de deux incidents en production.

Dans le premier cas, les workers Oban et les requêtes web partageaient un seul pool de 15 connexions à PostgreSQL. Quand un backfill de 923 tâches a été lancé, l'interface a effectivement échoué. Le problème a été résolu avec un ObanRepo dédié avec un pool séparé pour les opérations internes de la queue. Après cela, des budgets de requête obligatoires pour chaque worker et des limites de concurrence de queue ont été ajoutés aux règles.

La deuxième défaillance était encore plus instructive. L'IA a ajouté un ConnectionWatchdog pour surveiller la santé du pool et éviter de répéter le premier incident. Mais la surveillance elle-même est devenue la cause de la défaillance suivante : sous charge, les requêtes avec des timeouts agressifs ont commencé à tuer les connexions, et le watchdog a mis à terre tout le pool Oban en quelques secondes. Finalement, le composant a simplement été supprimé, et la leçon a été enregistrée dans la mémoire du projet.

«

Ne jamais utiliser de pooled connections avec des timeouts agressifs pour la surveillance »

Séparément, l'auteur a intégré un MCP Debug Server dans l'application afin que Claude Code puisse se connecter à la production comme à un outil : lire les logs, vérifier les queues Oban, exécuter des requêtes SQL, vérifier les métriques et redémarrer les workers sans SSH et debugging manuel. Mais même ici, il y a des limites : l'accès est restreint à une whitelist d'actions pour que le debugging ne devienne pas une faille de sécurité.

La conclusion principale de l'auteur est simple : l'IA peut tout à fait bien maintenir la production réelle, à condition d'avoir des règles, de la mémoire, des postmortems et des limites d'accès claires.

Ce que Cela Signifie

Cette histoire montre que le développement avec IA peut déjà atteindre le niveau production, mais pas tout seul. Le rôle clé n'est pas joué par le modèle, mais par la discipline autour : TDD, décisions architecturales, fichiers mémoire, postmortems et guardrails rigides. Si un humain reste l'architecte et l'éditeur du processus, l'IA accélère vraiment la livraison sans nécessairement sacrifier la qualité.