Ma femme voulait du Dior. J’ai dépensé 600 $ sur Claude Code pour vibe-coder une base de données de 2 millions de lignes à la place.
Mon épouse et moi sommes mariés depuis dix ans, et elle voulait un sac Dior pour notre anniversaire.
Au lieu d’acheter quoi que ce soit — parce que j’étais complètement absorbé par une expérience d’IA — j’ai passé toutes les vacances enfermé dans mon bureau, à jongler avec trois abonnements Claude Code à 200 $/mois, en essayant de convaincre un LLM de compiler en cross-compilation une base de données distribuée en C++ de 2 millions de lignes.
Et vous pouvez probablement deviner ce qui m’est arrivé plus tard. 😂
Avec le recul, ce n’était pas une allocation optimale des ressources.
J’ai donc appris deux leçons ce week-end-là.
Premièrement : écoutez votre épouse. « Femme heureuse, vie heureuse » n’est pas qu’un slogan. C’est un principe de stabilité des systèmes.
Deuxièmement : l’IA semble magique sur de petites tâches bien délimitées. Elle se comporte très différemment lorsqu’on la dirige vers une véritable infrastructure distribuée.
Cet article porte sur la deuxième leçon.
Contexte
Je suis le mainteneur et l’un des principaux contributeurs de Milvus, la base de données vectorielle open source la plus populaire, avec plus de 42 000 étoiles sur GitHub au moment de la rédaction (~2 M de lignes de C++, Go et Python). Le système est entièrement distribué : les nœuds proxy, les nœuds de requête, les nœuds de données et les nœuds d’index se coordonnent tous via des files de messages. Mon domaine est la couche de stockage et d’indexation.
J’utilisais Claude Code depuis quelques mois et j’étais sincèrement impressionné. Il a ajouté toutes les fonctionnalités manquantes d’une CLI entière pour 20 $ en tokens. Il a multiplié par 5 les performances d’un chemin critique de requête en une journée, le genre d’optimisation qui m’aurait pris une semaine rien que pour comprendre suffisamment bien le code pour y toucher. J’avais l’impression d’avoir un ingénieur junior compétent qui ne dormait jamais et ne facturait pas à l’heure.
J’ai décidé de lui confier un vrai problème : la compilation multiplateforme.
La leçon à 600 $ apprise
Pendant des années, personne dans l’équipe Milvus ne voulait toucher à la compilation multiplateforme. Le système de build est un mélange de Go, de C++ et de Rust, maintenu par des années accumulées de correctifs Conan et CMake que personne ne voulait rouvrir. Le faire fonctionner sous Linux est déjà pénible. Windows et les macOS modernes étaient un tel cauchemar à compiler que l’équipe les considérait comme le problème de quelqu’un d’autre.
Je me suis dit que j’avais Claude Code maintenant. Je pouvais m’en charger.
Au début, il semblait que j’avais raison. Windows compilait, et j’ai soumis le correctif, pensant que le plus dur était fait.
Puis Linux a échoué. J’ai corrigé Linux et Mac a échoué. J’ai corrigé Mac, et l’environnement GPU a échoué. Chaque correction introduisait deux nouveaux problèmes sur une autre plateforme, et les correctifs ont commencé à s’empiler. À la fin, j’avais un correctif de 1 000 fichiers, environ 100 000 lignes, touchant aux configurations Conan, aux scripts CMake, aux couches de compatibilité C++ et à des choses que je ne reconnaissais pas.
La partie exaspérante, ce n’étaient pas les bugs ; c’était la boucle. Je n’arrêtais pas de dire à Claude : « Pas de bricolages », « donne-moi la solution propre ». Il obéissait à chaque fois, générant des correctifs qui semblaient plus propres. Puis chaque correctif propre cassait trois autres plateformes, et le cycle recommençait. Si vous regardiez mon .claude/settings.local.json, vous trouveriez 147 règles d’autorisation approuvées manuellement. Chacune est l’horodatage d’un moment où je me suis dit : « Cette fois, ça va marcher. »
J’ai dépensé 600 $ pour le forfait Max et sacrifié toutes mes vacances, et tout ce que j’avais, c’était une pile de commandes git reset --hard.
Je suis resté assis là à fixer mon terminal, me demandant si tout cela n’était que du battage médiatique bien emballé. Puis j’ai réalisé que le problème n’était pas Claude. C’était comme demander à un doctorant de faire publier un article dans Nature sans préciser la question de recherche. Je lui avais confié un problème sans jamais définir ce que signifiait réellement « résolu ».
Ce qui fonctionne vraiment
L’échec n’était pas dû à l’intelligence de Claude. C’était un échec de processus. Alors j’ai recommencé avec un autre.
Les contraintes avant le code. Pas « faire en sorte que ça compile sous Windows ». Les vraies contraintes, écrites explicitement : toutes les plateformes réussissent leurs tests unitaires, la CI est verte partout, pas de bidouilles #ifdef spécifiques aux plateformes, pas de rustines autour de dépendances cassées. C’est la partie difficile — cela exige de savoir à quoi ressemble « terminé », ce qui exige de réfléchir soigneusement avant de toucher à quoi que ce soit. Avec une infrastructure complexe, l’essentiel du travail consiste à réfléchir.
Relire les tests, pas le code. J’écris des cas de test (ou je demande à Claude de les générer), mais je relis les tests, pas l’implémentation. Ce test vérifie-t-il que la recette Conan se résout correctement sur ARM ? Couvre-t-il la configuration CMake dans Docker ? Je peux évaluer ça en quelques minutes. Je ne peux pas relire 10 000 lignes de correctifs C++ multiplateformes avec une quelconque confiance, quelle que soit la durée dont je dispose.
De bas en haut, une couche à la fois. Ne laissez pas Claude modifier 1000 fichiers. Verrouillez d’abord les versions des dépendances. Une fois ces contraintes vérifiées, passez à la configuration CMake. Une fois celle-ci stable, au code spécifique aux plateformes. Chaque couche est suffisamment petite pour être vérifiée complètement avant de passer à la suivante.
J’ai refait le build multiplateforme de zéro en utilisant cette approche. Deux jours. Quelques dizaines de commits. Chacun est petit, chacun avec un test correspondant. Pas de bidouilles #ifdef — la vraie correction consistait à mettre à jour les recettes Conan et à incrémenter les versions de bibliothèques tierces, en corrigeant la chaîne de dépendances réelle plutôt qu’en la masquant.
Même tâche. Résultat complètement différent.
L’intuition sur les tests mérite son propre point : dans un système distribué doté d’une suite de tests mature, les tests sont la spécification. Si ces tests d’intégration passent — les 47 qui étaient passés au rouge lors de ma première tentative — alors les contrats seal/flush sont intacts, la relecture du WAL est correcte, et les nœuds de requête peuvent toujours charger des segments en mmap sans corruption. Je n’ai pas besoin de lire le C++ pour le savoir.
J’ai arrêté de relire le code. J’ai commencé à relire les tests. Le code est devenu un détail d’implémentation.
Lui lancer du matériel
Une fois le workflow correct, un nouveau goulot d’étranglement est apparu : j’étais là à attendre.
Une session Claude Code en train de mâcher une base de code de 2 millions de lignes, ce n’est pas rapide. Chaque tâche prend 20 à 30 minutes de temps réel. Le goulot d’étranglement n’était pas l’intelligence. C’était le débit.
J’ai donc dit à ma femme qu’il me fallait un serveur avec un GPU pour mes « agents IA ». Cette conversation s’est passée à peu près comme vous l’imaginez. Je l’ai acheté quand même — plus un Mac Mini pour accompagner mon MacBook. Au final, j’avais trois machines et six terminaux, chacun exécutant une session Claude Code indépendante.
Ce qui rend cela possible, c’est git worktree. Chaque session obtient sa propre tâche, sa branche et son répertoire de travail, complètement isolés des autres. Et comme l’approche contraintes d’abord signifie que chaque branche a ses propres critères d’acceptation, le parallélisme est trivialement sûr : si les tests de chaque branche passent indépendamment, la fusion est peu risquée.
Pour le build multiplateforme, cela signifiait une session résolvant les dépendances Conan Linux ARM, une corrigeant la configuration CMake macOS, et une gérant la compatibilité Windows MSVC, toutes exécutées simultanément sans interférence. Ce qui était auparavant une alternance sérielle de contexte entre plateformes est devenu une exécution parallèle sur plusieurs machines.
Le schéma se généralise au travail quotidien. Un jour donné, une session refactorise le planificateur de compaction, une autre optimise le chemin de recherche HNSW, et une troisième écrit des tests d’intégration pour un cas limite d’insertion en streaming. Je passe d’un terminal à l’autre comme un manager qui prend des nouvelles de ses subordonnés directs, sauf que ces subordonnés directs n’ont jamais besoin de pause café et n’ont pas d’opinions sur la planification des sprints.
La vraie leçon, c’est que l’infrastructure de vibe coding est limitée par le calcul, pas par le talent. Le facteur limitant n’est pas l’intelligence de l’IA ; c’est le nombre d’instances que vous pouvez exécuter en parallèle. Anthropic a utilisé 16 instances Claude parallèles pour construire un compilateur C entier, ce qui rendait mes six terminaux modestes.
Ce à quoi je reviens sans cesse
L’IA résout exactement le problème que vous lui mettez sous les yeux, rien de plus. Si vous cadrez mal le problème, vous obtenez une solution parfaite au mauvais problème.
« Compile sur macOS 15 » — résolu en une heure. Mais c’est un optimum local. Le véritable objectif était « compile partout sans bidouilles ». Ce sont des problèmes différents. L’IA n’avait aucun moyen de le savoir. C’est entièrement de la responsabilité de l’ingénieur.
Construire pour soi-même avec l’IA est incroyablement facile — vous connaissez votre machine, vos cas limites, et « ça marche chez moi » est une cible d’optimisation atteignable. Construire une infrastructure qui fonctionne pour chaque utilisateur, sur chaque plateforme, dans chaque environnement est fondamentalement différent. C’est dans cet écart que l’ingénierie existe encore. Pour les logiciels d’infrastructure, cet écart est énorme.
Les bugs les plus difficiles dans notre système de production — ceux qui ont nécessité un revert après le merge — n’ont été détectés par aucune des approches de revue de code par IA que nous avons essayées. Les bugs étaient syntaxiquement corrects. Le problème résidait dans les hypothèses implicites du développeur, invisibles dans le diff et absentes du code environnant. Le comportement du système n’avait de sens que si l’on détenait un modèle mental de la manière dont trois composants différents étaient censés se coordonner — un modèle qui n’existait que dans la tête d’un développeur, jamais consigné par écrit.
Ceux-là nécessitent encore un humain qui comprend suffisamment bien le système pour savoir quelles questions poser.
Les trois forfaits à 200 $ et les vacances perdues ont été le meilleur investissement que j’aie fait. Pas parce qu’ils m’ont appris à utiliser l’IA. Parce qu’ils m’ont appris comment ne pas l’utiliser.
Les outils sont réellement bons. La pièce manquante a toujours été le workflow autour d’eux. Les tests avant le code, les contraintes avant les tests, et assez de matériel pour tout exécuter en parallèle. C’est tout.
Les problèmes qui restent non résolus
Après tout ça — le patch raté, les commandes de reset, les six terminaux en parallèle — le problème le plus difficile à résoudre reste le problème humain.
Pour l’instant, j’ai deux maux de tête, et aucun des deux n’a de solution nette.
Le premier : ma femme. Elle est arrivée en vacances avec des attentes raisonnables. Elle en est repartie en me regardant git reset --hard ma vie. Le budget du sac Dior est devenu une facture de serveur. Elle n’est, à juste titre, pas impressionnée par mes réussites de build multiplateforme. Je n’ai pas encore trouvé de workflow pour « comment s’excuser d’avoir passé son anniversaire à faire du travail sur des systèmes distribués ». Claude Code n’est pas utile ici. J’ai essayé de lui demander. Il a suggéré des fleurs et une note manuscrite. Je lui ai dit d’être plus précis. Il a généré douze variantes d’une lettre touchante dans la voix d’un développeur C++. Aucune n’a fonctionné.
Si quelqu’un a résolu le problème de maintenir une relation tout en faisant du vibe-coding pendant des vacances, je suis très ouvert aux suggestions de workflow. 😂
Le second : comment faire passer cela à l’échelle au-delà de moi. Tout ce qui précède — l’approche constraints-first, le parallélisme avec git worktree, la discipline de revue test-first — est actuellement dans ma tête et dans ma configuration locale. L’intégrer au workflow quotidien d’une équipe est plus difficile que n’importe quel build multiplateforme.
C’est en partie un problème d’outillage. Mais c’est surtout un problème humain. Ce genre de workflow exige des ingénieurs qui aiment réellement comprendre comment les choses fonctionnent — des personnes qui écriront vraiment le test en premier, qui trouvent de la satisfaction dans une contrainte propre et bien définie, et qui ne prendront pas de raccourci vers « juste le faire passer ». Cette combinaison est plus rare qu’elle ne devrait l’être.
Donc oui — nous recrutons.
Si vous êtes le genre d’ingénieur qui lit un article sur le vibe coding d’infrastructure et commence immédiatement à se forger des opinions tranchées sur ce que j’ai mal fait, vous êtes exactement la personne à qui je veux parler.
Milvus est un problème de systèmes distribués réellement difficile : moteurs de stockage, pipelines d’indexation, compaction, réplication, récupération après panne — le tout sous charge de production réelle. Nous ne construisons pas des démos. Nous construisons une infrastructure dont les gens dépendent.
Si résoudre des problèmes à ce niveau vous semble intéressant, venez construire avec nous.
Et je m’occuperai du plan de récupération de l’anniversaire.
Vous pouvez consulter nos postes ouverts ou me contacter directement sur LinkedIn.
Et si vous n’êtes pas d’accord avec quoi que ce soit dans cet article, c’est encore mieux — je serai ravi d’en discuter avec vous.
Rejoignez notre communauté Slack ou réservez une session Milvus Office Hours — nous sommes toujours ravis de parler de systèmes distribués, d’infrastructure IA ou des points sur lesquels vous pensez que nous avons tort.
Continuer à lire
Zilliz Cloud Now Available in AWS Asia Pacific (Seoul)
Zilliz Cloud is now available in AWS Seoul — low-latency vector search, in-country data residency, and one-step migration for Korean AI teams. 31 regions across 5 clouds.
Vector Databases vs. Graph Databases
Use a vector database for AI-powered similarity search; use a graph database for complex relationship-based queries and network analysis.
DeepSeek Always Busy? Deploy It Locally with Milvus in Just 10 Minutes—No More Waiting!
Learn how to set up DeepSeek-R1 on your local machine using Ollama, AnythingLLM, and Milvus in just 10 minutes. Bypass busy servers and enhance AI responses with custom data.