Jusqu’où peut-on développer avec le vibe coding ?

Il s’agit d’un retour d’expérience centré moins sur le produit lui-même que sur les aspects techniques et d’implémentation.

Ce sont des réflexions entièrement personnelles.

Merci d’en tenir compte en gardant à l’esprit qu’il s’agit d’un projet développé tout en apprenant, pendant le semestre de 4e année d’université !

Pourquoi ce projet a commencé

• Développer un produit avec l’état d’esprit de créer une startup, du point de vue PM/PO
• Vérifier s’il est réellement possible de développer un MVP full-stack avec Claude Code
• Résoudre le problème de la découverte de valeurs en investissement boursier
• Adopter activement des produits commerciaux pour en tirer des insights au fil du processus

Timeline du projet et informations complémentaires

• Conception + développement : 1 mois
• Déploiement : 1 semaine
• Exploitation : 2 mois
• Montant investi
  • Claude Code : 100 USD
  • Compte développeur Apple : 100 USD
  • AWS : environ 220 USD
  • Managed DB : environ 300 USD
  • Free tier : Datadog, Langfuse, Posthog
  • Publicité : 40 000 KRW
  • Total : environ 1 000 000 KRW (de ma poche..)

Processus de développement

Frontend

• Définition des design tokens
• Implémentation de 3 pages clés avec Figma
• Application des design tokens à Expo, avec implémentation via Figma MCP
• Tentative d’utilisation d’Expo MCP, mais comme ce n’était pas stable, débogage en regardant directement le rendu
• Génération de nouvelles pages sans wireframe Figma, avec un prompt du type « utiliser les design tokens et reprendre le concept visuel d’autres pages… »

Backend

• Demande de développement d’API à partir des exigences
• Demande de créer aussi les endpoints nécessaires à partir des exigences du frontend
• En utilisant une stack généraliste comme Django, il a été possible de développer avec Claude Code sans goulot d’étranglement sur l’implémentation

IA

• Définition d’une architecture multi-agents, puis demande d’implémentation sur cette base
• Ajout de liens web en référence afin de suivre les spécifications récentes de LangChain et du LLMOps
• Utilisation de prompts générés par le LLM lui-même pour le service LLM

Observability

• Mise en place initiale sur la base de ClickStack, puis migration vers Datadog
• Application du logging et de l’analytics après le développement de l’ensemble du système

Infra

• Pulumi devait être utilisé au départ, mais comme Claude Code s’en sortait mal, les fichiers de déploiement ont été rédigés à partir de scripts basés sur AWS CLI
• Pas de mise en place de CI/CD ni de serveur de dev pour des raisons de coût

Liste des technologies adoptées

• Service : abonnement/paiement, social login, mode sombre
• Données : collecte de données via API, CDC, ETL
• IA : multi-agents, Text-to-SQL, Agentic RAG, streaming SSE, gestion de session, Retry, Rate Limit
• LLMOps : AB Test, Cloud Based Prompt Management (OTA Update), Synthetic Dataset, Evaluation

Enseignements

Implémentation

• Avec le plan Claude Code à 100 USD pendant environ un mois, il a été possible de créer seul un produit de ce volume
• L’UI a été développée uniquement en définissant les spécifications des design tokens ; si un design system complet avait aussi été implémenté et intégré dans Claude.md, il aurait sans doute été possible de développer un frontend plus vite et plus stable
• Importance du design system. Il améliore énormément la productivité en frontend. Il est plus rapide d’implémenter d’abord puis de corriger que de créer Figma en amont. Il existe d’ailleurs des pages réellement implémentées mais absentes de Figma.
• Définition des cas d’exception. C’est encore plus important dans les apps mobiles et les systèmes IA. Il faut concevoir et implémenter non seulement le happy path, mais aussi la gestion globale des timeouts du système, les politiques de background, la reprise du streaming, les erreurs simples, etc. Claude Code implémente parfois le traitement des erreurs de lui-même, mais ne les résout pas de manière élégante et intégrée entre frontend et backend. Il faut donc lui demander explicitement de traiter ces points.
• Interdiction des gros refactorings. Au départ, tout le code React et CSS du frontend était placé dans un seul fichier, puis un refactoring a été tenté pour le séparer. Au final, ce fut un échec. La séparation a bien eu lieu, mais l’UI s’est retrouvée différente de l’originale, et il a fallu procéder à une séparation progressive. Il semble donc nécessaire de réfléchir à l’architecture du code dès le début du développement, et si l’on compte utiliser des composants, d’ajouter ces consignes au prompt pour qu’ils soient correctement exploités.
• Utilisation de Claude.md. Après avoir développé une fonctionnalité, demander à Claude Code quoi ajouter dans Claude.md sur la base de ce contenu. Le fichier devient progressivement trop volumineux, donc demander de ne garder que l’essentiel et de supprimer le reste. Utiliser readme et claude.md de façon adaptée pour contrôler et exploiter le contexte du LLM. (à l’époque où il n’y avait pas de skills)
• Les sous-agents n’ont pas été utilisés. Même sans eux, le résultat était suffisamment bon, donc ils n’ont pas servi. En pratique, il suffisait de demander en mode Plan jusqu’à ce que la planification du développement soit suffisamment détaillée, puis de laisser l’agent développer de façon autonome.
• Il vaut mieux définir à l’avance les packages et technologies utilisés. Il faut travailler en indiquant précisément les spécifications dans Claude.md, le README ou un document dédié afin d’éviter la duplication de code ou l’usage d’une autre stack. (Skills ?)

Système IA

• ReAct est lent. L’UX est catastrophique. Même en configurant l’exécution parallèle des multi-agents, c’est encore trop lent.
• UX. Pour répondre au problème des réponses lentes, une UX affichant les étapes des multi-agents, du streaming, des animations et du rendu Markdown dynamique a été ajoutée. Mais si une réponse prend une minute, à quoi bon ?… (app B2C)
• Gestion cloud des prompts et des schémas d’outils. Le fait que cela puisse être appliqué en environnement online est un vrai avantage. Je pense désormais que c’est indispensable, et j’adore Langfuse.
• En Text-to-SQL, il faut inclure le schéma dans le prompt. Mais cela consomme beaucoup trop de contexte. Cela pourrait sans doute être résolu via fine-tuning ou RAG.
• Évaluation et itération. Un Synthetic Dataset a été constitué pour différents personas utilisateurs, puis l’évaluation a été faite avec LLM-as-a-Judge. J’aimerais l’automatiser, mais encore une fois, les ressources de développement manquent quand on est seul.
• Métriques d’évaluation et rubric : c’est plus compliqué que prévu. Les métriques génériques sont selon moi des choses comme la DAU et la MAU. Mais avec ce type de métriques, on ne peut pas tirer d’insights utiles. Il faut définir des métriques au cas par cas pour distinguer les cas de faible qualité, les corriger, puis itérer. Au final, il faut un système qui aide à bien créer des métriques custom. (et pour le multi-turn ?..)
• Les tiers OpenAI sont plus contraignants que prévu. À ces niveaux, il est difficile d’utiliser de bons modèles en production.

Infrastructure

• AWS est cher, Managed DB est cher. C’est bien, mais je le regrette
• ClickHouse est très cher, mais excellent. En managé, c’est pratique. Surtout avec le CDC intégré. (À quoi bon être rapide si le LLM est lent ?)
• Qdrant et Redis Cloud ne sont pas mal non plus. Le temps de mise en place est réduit, et le coût est faible.
• Datadog. C’est vraiment excellent. En revanche, ça allait devenir cher, donc seul le free tier a été utilisé. J’aime particulièrement la fonctionnalité qui regroupe et signale séparément les erreurs survenues. Il a été utilisé en ajoutant l’agent comme sidecar sur ECS.

Service

• Paiement et abonnement. L’usage de Toss Pay a été envisagé, mais finalement écarté. Il faut déjà payer des frais annuels, et comme il n’y a pas de documentation React Native, le SDK n’est pas terrible. Grosse déception. Au final, le choix s’est porté sur NICE Payments. Il n’y a pas de frais annuels et il existe aussi un serveur de développement, ce qui a permis un développement sans trop de difficulté.
• Paiement Apple. NICE Payments a été utilisé, mais il y a un problème. La politique de paiement d’Apple est stricte. Pendant le développement iOS, il y a eu des soucis liés aux politiques d’Apple, et il a fallu les résoudre à travers divers documents et ajustements d’UI. J’ai l’impression qu’utiliser directement le système de paiement interne d’Apple serait plus serein.
• Paiement et abonnement (prélèvement automatique), ce n’est pas la même chose. Pour implémenter le paiement automatique, il faut une infrastructure de scheduling et il faut aussi faire attention à la sécurité pour stocker la clé de carte. Cela a finalement été implémenté, mais c’est plus complexe que prévu. Cela m’a donné envie d’essayer Stripe.
• Notifications push. Cela se met en place facilement avec Expo. Au final, il faut tout de même un back-office pour envoyer les messages, mais je pense que c’est une fonctionnalité essentielle.

Réflexions

• L’importance des design patterns logiciels et de l’architecture va probablement augmenter.
• J’aimerais que davantage de gens s’intéressent à la création, avec des agents de code, de résultats qui dépassent le simple toy project.
• Évitons le surdimensionnement. Mais pour trouver un emploi, ne faut-il pas aussi connaître les architectures surdimensionnées ? La prochaine fois, il vaudra peut-être mieux tout terminer sur une seule instance avec docker-compose… (avec supabase ?)
• L’ère de la création d’entreprise en solo est presque là. Mais gagner de l’argent et construire quelque chose sont à mon avis deux choses différentes.
• Faire tout cela seul, ce n’est pas amusant
• Linear est aussi une bonne alternative à Jira. Comme je l’utilise pour la première fois, je ne sais pas encore bien comment afficher les tickets regroupés selon leur hiérarchie.

Résultat

• Le projet a été arrêté, faute de pouvoir assumer les coûts serveur.
• Solde : -100

Référence

Il y a du contenu supplémentaire à partir de la page 4.

https://figma.com/deck/wsGLEmFYOUPUheWBl1t23K/…