Quand chaque petit changement a un blast radius

La première phase du vibe coding paraît absurdement productive. Cursor et Claude Code peuvent générer login, dashboard, réglages et push notifications assez vite pour qu’un seul fondateur mette un MVP en ligne en quelques jours.

Les ennuis commencent au deuxième ou troisième cycle de changements. Un petit réglage dans les settings casse l’auth. Une mise à jour du profil perturbe les notifications. Les bugs semblent sans rapport, mais le code n’a aucune frontière imposée, donc chaque partie de l’app peut affecter les autres.

Voilà le piège du vibe coding. Cursor et Claude Code sont incroyables pour générer du code qui marche. Ils ne sont pas conçus pour générer du code maintenable. Quand vous demandez un écran de réglages à Claude, il vous donne un écran de réglages. Il ne vous donne pas un écran de réglages qui respecte vos frontières de service, suit votre contrat de thème et valide ses entrées. Il remplit le prompt. Vous, vous comblez l’écart.

Pourquoi le vibe coding casse à l’échelle

Quand vous avez dix utilisateurs, un edge case cassé se traduit par un DM auquel vous pouvez répondre. Quand vous en avez mille, c’est un événement de churn. Quand vous en avez dix mille, c’est une panne qui menace l’entreprise. La même codebase qui semblait magique au stade MVP devient terrifiante au stade de croissance.

Le développement traditionnel gère cela avec des code reviews, des ADR et des seniors qui disent « non ». Mais quand vous livrez avec Cursor et Claude Code à une vitesse multipliée par 10, vous ne pouvez pas vous permettre un goulot d’étranglement humain dans chaque boucle de vérification. Ce goulot annule le bénéfice de vitesse. Il vous faut quelque chose de plus rapide qu’une review humaine, mais tout aussi fiable.

Contraintes déclaratives : la réponse

Les garde-fous : des vérifications déterministes et déclaratives qui s’exécutent en millisecondes. Ils ne se fatiguent pas. Ils ne perdent pas le contexte. Ils ne consomment pas de tokens. C’est le système immunitaire architectural de votre app vibe codée :

# These aren't suggestions. They're non-negotiable gates.
# They run on every commit. Human or AI code — doesn't matter.

1. TypeScript strict mode catches interface violations
   - noUncheckedIndexedAccess
   - exactOptionalPropertyTypes

2. ESLint catches architectural violations
   - no className outside primitive seam
   - import from barrels, not implementations

3. dependency-cruiser catches boundary violations
   - Circular dependencies caught at commit time
   - Never reach production

4. Pre-commit hooks run ALL checks before code lands
   pnpm run verify → lint, typecheck, depcruise, test
   If any check fails, the commit is blocked.

Le coût de l’absence de garde-fous

Sans garde-fous, le code généré par IA suit une spirale de mort prévisible : générer vite, livrer vite, casser vite, déboguer en panique en production, perdre des utilisateurs, perdre du sommeil, perdre confiance. J’ai vu des équipes passer des sprints entiers à corriger du code généré par IA alors qu’une seule règle ESLint aurait suffi à l’empêcher. Le temps économisé grâce au vibe coding la première semaine, elles l’ont reperdu dix fois à la dixième.

Avec des garde-fous, le cycle se transforme : générer vite, valider vite, livrer en sécurité. Cursor et Claude Code continuent d’écrire le code. Les garde-fous imposent les frontières. Vous obtenez la vitesse de l’IA avec la sécurité architecturale.

À quoi ressemblent des garde-fous prêts pour la production

Dans une architecture React Native prête pour la production, les garde-fous font partie des fondations :

  • TypeScript strict mode dès le premier jour, avec noUncheckedIndexedAccess et exactOptionalPropertyTypes
  • dependency-cruiser fait respecter les frontières de dossiers et empêche les dépendances circulaires
  • ESLint bloque className en dehors de la couche de primitives de styling
  • Hooks de pré-commit exécutent la suite de vérification complète à chaque commit

Résultat : le code généré par IA reste dans les limites. Cursor génère composants, écrans et hooks à pleine vitesse. Mais il ne peut pas violer les frontières de service. Il ne peut pas faire fuiter le moteur de styling. Il ne peut pas créer de dépendances circulaires. Les garde-fous définissent ce qui est autorisé. L’IA remplit les blancs.

La transition sans friction

L’Autotomy Expo Starter Pack a été conçu exactement pour cette transition :

  • Interfaces de service définies avec barrel exports
  • Composition root pour la gestion des dépendances
  • Primitives UI sémantiques avec un contrat de thème
  • Boundaries de dépendances hard et optionnelles
  • Gestion centralisée du cycle de vie
  • Validation des URL aux frontières de route
  • Garde-fous déterministes en pré-commit
  • Pattern d’autotomie pour refactorer en sécurité

Vous n’arrêtez pas le vibe coding. Vous vibe codez au-dessus d’une fondation qui passe à l’échelle. Cursor génère des écrans contre votre contrat de thème. Claude Code génère des features contre vos interfaces de service. Vos hooks de pré-commit attrapent les violations de frontière avant qu’elles n’atteignent la production. Votre app peut grandir de dix à dix mille utilisateurs sans l’effondrement architectural qui tue la plupart des projets codés par IA.

La vitesse a de la valeur. La structure est ce qui rend cette vitesse durable. Si vous livrez une app React Native avec Cursor et Claude Code, investissez dans les garde-fous avant d’en avoir besoin. Ils coûtent moins cher qu’un refactor, et ils se rentabilisent la première fois qu’ils attrapent une régression au moment du commit au lieu de la laisser arriver dans les mains de vos utilisateurs.