Créer une application de production de 200k lignes de code via le Vibe Coding depuis un téléphone

Un développeur a mené une expérience pour tester si le « vibe coding » pouvait gérer un projet de haute complexité, en créant un outil professionnel de vibe coding mobile appelé Vibe Remote (maintenant disponible gratuitement sur l'App Store). L'outil permet de coder en déplacement sans configurer Tailscale — les utilisateurs scannent un code QR et commencent à coder depuis leur téléphone.

Stack technique & Processus de développement

Le projet utilise une architecture multiplateforme : CLI, web (https://vibe-remote.com), backend en Go, et iOS/macOS natif en Swift. Il propose des nœuds globaux, des protocoles personnalisés sécurisés et des interfaces TUI.

La contrainte était simple : construire l'outil en utilisant l'outil. Après que la première version a pu communiquer, le développeur a complètement arrêté d'utiliser son ordinateur portable. Plus de 95 % du code a été écrit en envoyant des messages à Claude Code via l'application tout en vivant sa vie à l'extérieur.

Flux de travail quotidien & Solutions

La routine quotidienne consistait à empiler 5 à 10 points de modification lors de multiples sessions parallèles à la maison, puis à demander à l'IA d'appeler une compétence personnalisée deploy-to-iphone pour pousser la compilation. Pendant que l'IA travaillait, le développeur regardait de courts dramas. Au parc, il regroupait les modifications iOS pour le déploiement à domicile, mais pour le backend Go et le site SSR, il demandait à l'IA de redémarrer le serveur local.

Pour résoudre le problème « Je ne peux pas voir mes modifications locales au parc », il a fait construire par l'IA un navigateur intégré et un tunnel proxy dans l'application elle-même, permettant de prévisualiser localhost:3000 depuis la machine à domicile directement sur le téléphone via un protocole sécurisé.

Volume de code & Vélocité

• Total de lignes : ~200 000 (140k Go, 60k Swift)
• Courbe de vélocité : Durant les 3 premières semaines, 150 000 lignes ont été produites. La vitesse est passée de 10 000 lignes/jour à 1 000, puis à 100-300 lignes de corrections chirurgicales par jour pendant la phase de finition.
• Épuisement : La phase de « fine-tuning » était plus fatigante que la construction initiale, nécessitant une vérification constante de petits détails d'UX avec une charge mentale élevée due au « contrôle qualité » via le chat.

Principaux enseignements

Le problème DRY

Une fois que le projet devient énorme, l'IA ne parvient plus à retrouver les implémentations existantes et commence à dupliquer la logique. La solution : traiter les instructions claude.md comme des « Lois » et demander explicitement : « Nous avons fait une logique similaire pour la fonctionnalité X ; va la trouver, abstrais-la et réutilise-la. Ne la réimplémente pas. » Sans cela, on obtient du « code zombie » où corriger un bug à un endroit le laisse dans des implémentations dupliquées.

Le piège du TDD

Initialement en utilisant un flux TDD strict (tests unitaires + de bout en bout) avec chaque test décrivant une branche fonctionnelle, échouant d'abord, puis réussissant. Bien qu'Opus 4.6 soit excellent pour cela, les tests de bout en bout sont devenus un goulot d'étranglement — attendre les exécutions complètes de la suite E2E a tué l'efficacité. Le développeur a finalement supprimé les E2E en faveur de tests unitaires à haute densité pour garder le « Vibe » rapide.

Abandonnez les outils « Superpuissance »

Le développeur a désinstallé les extensions « Superpuissance », constatant que pour 95 % des tâches, le langage naturel brut dans plusieurs sessions est meilleur. Il n'utilise qu'un « Mode Plan » quand l'IA est bloquée, avec cette demande : « Tu as essayé cela plusieurs fois et échoué. Résume les retours, recherche la meilleure pratique de l'industrie et donne-moi un plan d'exécution en une seule fois. » De petites demandes précises dans plusieurs fils parallèles sont plus efficaces pour les itérations orientées détail qu'une seule requête géante et complexe.

Arrêtez de vous soucier des Git worktrees

Beaucoup préconisent des worktrees séparés par agent, mais le développeur n'est pas d'accord. Il a exécuté jusqu'à 40+ agents sur la même branche simultanément, constatant que cela fonctionne tant que vous faites confiance à l'IA.