Le côté obscur du vibe coding : quand ton code fonctionne mais ne scale pas

Avoue-le : le vibe coding, c'estバイ禄e. Tu décris ce que tu veux, tu regardes l'agent construire, tu vois les tests passer au vert, tu déploies. Ça ressemble à de la magie. Jusqu'au moment où ça ne l'est plus.

Ce moment arrive généralement aux alentour de 3h du matin. Ton app démarre nickel, gère quelques requêtes avec élégance, puis se fait silencieusement tuer par un OOM reaper. Ou alors elle ouvre dix mille file descriptors et s'effondre. Ou encore elle tourne parfaitement avec tes données de test et fond lamentablement quand les vrais utilisateurs débarquent.

Le code était correct. Il résolvait le problème exactement comme spécifié. Il supposait juste que la mémoire était infinie et que les file handles ne manquaient jamais — parce que rien dans ton prompt ne disait le contraire.

Le tueur silencieux : les hypothèses implicites

C'est là que le vibe coding devient vicieux. Quand tu écris du code toi-même, tu portes tes contraintes en permanence dans ta tête. Tu sais que tu tournes sur un laptop avec 16 Go de RAM. Tu sais que le serveur de prod a des limites de file descriptors. Tu sais que ce CSV de 400 Go ne se charge pas comme ça en mémoire.

Mais quand une IA écrit ton code, ces contraintes n'existent pas. L'IA voit « charge le fichier, trie-le, écris le résultat » et se dit : super, je vais tout charger. Ça marche parfaitement dans les tests. Le fichier de test fait 50 Ko.

Les code reviews ne détectent rien non plus. Les lignes problématiques paraissent parfaitement raisonnables. Aucun drapeau rouge quand tu scannes à la recherche d'erreurs logiques — parce qu'il n'y en a pas. Le bug n'est pas dans la logique ; il est dans la boîte invisible dans laquelle la logique a été conçue.

Et si le compilateur était au courant ?

Là où ça devient intéressant. Un développeur nommé Nicolas Grislain explore une idée provocante : et si les contraintes de ressources étaient des types, pas des commentaires ?

Au lieu d'espérer que ton code généré par IA respecte les limites mémoire, et si le compilateur refusait littéralement de compiler du code qui les viole ? Et si « cette fonction ne garde jamais plus de 100 enregistrements en mémoire » et « ce programme n'a jamais plus de 3 fichiers ouverts simultanément » étaient des faits vérifiés par le compilateur, pas des prières murmurées pendant la code review ?

Ce n'est pas que de la théorie. L'expérience utilise Lean 4 — oui, le même Lean qui fait sensation dans les mathématiques formelles — pour encoder les budgets de ressources directement dans les types de fonctions. Le compilateur devient un auditeur de ressources, vérifiant automatiquement que ton code reste dans les limites avant même qu'il s'exécute.

Comment rendre les ressources tangibles

Le mécanisme central est étonnamment élégant : on fait passer les compteurs de ressources à travers le système de types. Au lieu de suivre « combien de fichiers sont ouverts » comme une variable runtime qui pourrait être ignorée, le système de types le suit comme un paramètre fantôme qui doit impérativement se équilibrer.

Quand tu ouvres un fichier, la signature du type reflète le changement : tu entres dans la fonction avec N fichiers ouverts et tu sors avec N+1. Quand tu le fermes, tu reviens de N+1 à N. Le compilateur suit ça à chaque étape, et tu ne peux tout simplement pas compiler du code qui ouvre un fichier sans le fermer, ou qui ouvre des fichiers au-delà d'un seuil défini.

La mémoire fonctionne de manière similaire, mais avec une nuance. Les enregistrements ne flottent pas librement en mémoire — ils vivent dans un pool borné avec un nombre fixe de slots. Tu ne gardes pas un objet Event ; tu gardes une référence vers ce pool. Le type suit combien de références vivantes existent à tout moment, et l'allocation requiert une preuve qu'il y a de la place.

La magie opère au point d'entrée : le programme doit démarrer avec zéro ressource utilisée et terminer avec zéro. Tu ne peux pas fuir de handles ou de refs. Tu ne peux pas dépasser les seuils. Le compilateur refuse, tout simplement.

Pourquoi c'est important pour le vibe coding

Cette approche transforme notre façon de penser les prompts pour les assistants IA. Aujourd'hui, tu ajoutes peut-être une note comme « fais attention à l'usage mémoire » ou « ferme tous les file handles » — en espérant que l'IA fasse attention. Avec des types aware des ressources, tu specifies les contraintes formellement, et l'implémentation doit se réorganiser pour les satisfaire.

L'IA reçoit d'abord la version non contrainte. Les tests passent. Ensuite tu actives les limites. Le compilateur rejette immédiatement l'implémentation. L'IA doit restructurer son approche — peut-être en traitant le fichier par chunks au lieu de tout charger d'un coup, ou en utilisant un connection pool au lieu d'ouvrir des fichiers directement.

L'implémentation ne fonctionne pas juste par chance ; elle fonctionne de manière prouvée dans les limites du budget.

La réalité pratique

Soyons clairs : ce n'est pas encore un outil prêt pour la production pour la plupart des équipes. L'approche Lean 4 demande une configuration significative, et il y a un overhead cognitif pour raisonner en termes de types indexés. Mais l'idée sous-jacente a de la valeur quel que soit l'implémentation.

Quand tu fais du vibe coding, tu sous-traites non seulement l'écriture du code mais aussi le modèle mental de ton système. Ton assistant IA ne connaît pas ton environnement de production. Il ne sait pas que ton conteneur a 512 Mo de RAM. Il ne sait pas que ton kernel Linux bride les file descriptors à 1024.

En attendant de meilleures façons d'encoder ces contraintes, on a quelques options pragmatiques :

1. Sois explicite dans tes prompts — « Le fichier d'entrée peut contenir jusqu'à 10 millions de lignes » vaut mieux que « gère les gros fichiers efficacement »

2. Teste avec des données à taille prod — Si tes données d'entraînement sont minuscules, ton IA ne captera pas les patterns de ressources

3. Utilise des APIs bornées — L'architecture qui limite naturellement l'usage des ressources (connection pools, streaming au lieu de chargement) est plus difficile à mal utiliser

4. Surveille les outils resource-aware — L'industrie commence à explorer des façons de rendre les contraintes explicites dans le code généré par IA

En conclusion

Le secret sale du vibe coding n'est pas qu'il écrit du code bogué — c'est qu'il écrit du code correct dans un espace de contraintes invisible. Cet espace inclut ton laptop, ton environnement de test, et peut-être tes mille premiers utilisateurs. Il n'inclut certainement pas « la production à l'échelle ».

Les systèmes de types resource-aware comme cette expérience Lean 4 pointent vers un futur où « correct » veut dire plus que « logiquement juste ». Ça veut dire « prouvé pour rester dans les limites qui existent réellement ».

C'est un futur worth building toward. En attendant, garde tes données de test proches de la taille prod, et ajoute peut-être une note supplémentaire dans tes prompts à propos de ces file descriptor limits.

Ton futur toi en astreinte te remerciera.