Meine Frau wollte Dior. Ich gab 600 $ für Claude Code aus, um stattdessen eine Datenbank mit 2 Mio. Zeilen per Vibe-Coding zu erstellen.
Meine Frau und ich sind seit zehn Jahren verheiratet, und sie wollte zu unserem Hochzeitstag eine Dior-Tasche.
Anstatt irgendetwas zu kaufen — weil ich völlig in ein KI-Experiment vertieft war — verbrachte ich den gesamten Feiertag eingeschlossen in meinem Arbeitszimmer, jonglierte mit drei Claude Code-Abos für jeweils 200 $/Monat und versuchte, ein LLM davon zu überzeugen, eine verteilte C++-Datenbank mit 2 Millionen Zeilen Code zu cross-kompilieren.
Und ihr könnt euch wahrscheinlich denken, was mir später passiert ist. 😂
Im Nachhinein war das keine optimale Ressourcenallokation.
Also habe ich an diesem Wochenende zwei Lektionen gelernt.
Erstens: Hör auf deine Frau. „Happy wife, happy life“ ist nicht nur ein Slogan. Es ist ein Prinzip der Systemstabilität.
Zweitens: KI fühlt sich bei kleinen, klar abgegrenzten Aufgaben magisch an. Sie verhält sich ganz anders, wenn man sie auf eine echte verteilte Infrastruktur loslässt.
In diesem Beitrag geht es um die zweite Lektion.
Hintergrund
Ich bin der Maintainer und ein Core-Contributor von Milvus, der zum Zeitpunkt des Schreibens beliebtesten Open-Source-Vektordatenbank mit 42K+ Stars auf GitHub (~2 Mio. Zeilen C++, Go und Python). Das System ist vollständig verteilt: Proxy-Nodes, Query-Nodes, Data-Nodes und Index-Nodes koordinieren sich alle über Message Queues. Mein Bereich ist die Storage- und Indexing-Schicht.
Ich hatte Claude Code seit ein paar Monaten genutzt und war wirklich beeindruckt. Es ergänzte alle fehlenden Features einer ganzen CLI für 20 $ an Tokens. Es steigerte einen Performance-Hotpath für Queries an einem Tag um den Faktor 5, die Art von Optimierung, für die ich eine Woche gebraucht hätte, nur um den Code gut genug zu verstehen, um ihn anzufassen. Es fühlte sich an, als hätte man einen kompetenten Junior Engineer, der nie schlief und nicht nach Stunden abrechnete.
Ich beschloss, ihm ein echtes Problem zu geben: Cross-Platform-Kompilierung.
Die 600-$-Lektion
Seit Jahren wollte im Milvus-Team niemand die Cross-Platform-Kompilierung anfassen. Das Build-System ist eine Mischung aus Go, C++ und Rust, zusammengehalten durch über Jahre angesammelte Conan- und CMake-Patches, die niemand erneut anfassen wollte. Es unter Linux zum Laufen zu bringen, ist schon miserabel. Windows und modernes macOS waren ein derartiger Albtraum beim Bauen, dass das Team sie als Problem von jemand anderem behandelte.
Ich dachte, jetzt habe ich Claude Code. Ich kann das schaffen.
Zunächst sah es so aus, als hätte ich recht. Windows kompilierte, und ich reichte den Patch ein, in der Annahme, der schwierige Teil sei vorbei.
Dann schlug Linux fehl. Ich reparierte Linux, und Mac schlug fehl. Ich reparierte Mac, und die GPU-Umgebung schlug fehl. Jeder Fix führte zwei neue Probleme auf einer anderen Plattform ein, und die Patches begannen sich aufzutürmen. Am Ende hatte ich einen Patch mit 1000 Dateien und ~100k Zeilen, der Conan-Konfigurationen, CMake-Skripte, C++-Kompatibilitäts-Shims und Dinge berührte, die ich nicht erkannte.
Das Verrücktmachende waren nicht die Bugs; es war die Schleife. Ich sagte Claude immer wieder: „Keine hacky Fixes“, „gib mir die saubere Lösung“. Es gehorchte jedes einzelne Mal und generierte Patches, die sauberer aussahen. Dann zerstörte jeder saubere Patch drei andere Plattformen, und der Zyklus begann von vorn. Wenn man in meine .claude/settings.local.json schaute, fände man 147 manuell genehmigte Berechtigungsregeln. Jede einzelne ist ein Zeitstempel dafür, wie ich dachte: „Dieses Mal wird es funktionieren.“
Ich gab 600 $ für den Max-Plan aus und verbrannte einen ganzen Urlaub, und alles, was ich hatte, war ein Haufen git reset --hard-Befehle.
Ich saß da und starrte auf mein Terminal, fragte mich, ob das Ganze nur gut verpackter Hype war. Dann wurde mir klar, dass das Problem nicht Claude war. Es war, als würde man einem Doktoranden sagen, er solle einen Artikel in Nature unterbringen, ohne die Forschungsfrage festzulegen. Ich hatte ihm ein Problem gegeben, ohne jemals zu definieren, was „gelöst“ eigentlich bedeutete.
Was tatsächlich funktioniert
Das Scheitern lag nicht an Claudes Intelligenz. Es war ein Prozessfehler. Also fing ich mit einem anderen Prozess von vorn an.
Constraints vor Code. Nicht „bring es dazu, unter Windows zu kompilieren.“ Die tatsächlichen Constraints, explizit aufgeschrieben: Alle Plattformen bestehen ihre Unit-Tests, CI ist überall grün, keine #ifdef-Plattform-Hacks, kein Herum-Shimmen um kaputte Dependencies. Das ist der schwierige Teil — es erfordert zu wissen, wie „fertig“ aussieht, was wiederum erfordert, sorgfältig nachzudenken, bevor man irgendetwas anfasst. Bei komplexer Infrastruktur steckt der Großteil der Arbeit im Denken.
Tests reviewen, nicht Code. Ich schreibe Testfälle (oder lasse Claude sie generieren), aber ich reviewe die Tests, nicht die Implementierung. Prüft dieser Test, dass das Conan-Recipe auf ARM korrekt aufgelöst wird? Deckt er die CMake-Konfiguration in Docker ab? Das kann ich in Minuten beurteilen. Ich kann keine 10.000 Zeilen plattformübergreifender C++-Patches mit irgendeiner Zuversicht reviewen, egal wie viel Zeit ich habe.
Bottom-up, eine Ebene nach der anderen. Lass Claude nicht 1000 Dateien ändern. Fixiere zuerst die Dependency-Versionen. Sobald diese Constraints verifiziert sind, geh zur CMake-Konfiguration über. Sobald das stabil ist, plattformspezifischer Code. Jede Ebene ist klein genug, um sie vollständig zu verifizieren, bevor man zur nächsten übergeht.
Ich habe den plattformübergreifenden Build mit diesem Ansatz von Grund auf neu gemacht. Zwei Tage. Ein paar Dutzend Commits. Jeder einzelne klein, jeder einzelne mit einem passenden Test. Keine #ifdef-Hacks — der eigentliche Fix bestand darin, Conan-Recipes zu aktualisieren und Versionen von Third-Party-Libraries anzuheben, also die tatsächliche Dependency-Kette zu reparieren, statt sie zu übertünchen.
Gleiche Aufgabe. Völlig anderes Ergebnis.
Die Test-Erkenntnis verdient einen eigenen Punkt: In einem verteilten System mit einer ausgereiften Testsuite sind die Tests die Spezifikation. Wenn diese Integrationstests bestehen — alle 47, die bei meinem ersten Versuch rot wurden — dann sind die Seal/Flush-Contracts intakt, das WAL-Replay ist korrekt, und Query Nodes können Segmente weiterhin per mmap laden, ohne Korruption. Ich muss den C++-Code nicht lesen, um das zu wissen.
Ich habe aufgehört, Code zu reviewen. Ich habe angefangen, Tests zu reviewen. Der Code wurde zu einem Implementierungsdetail.
Hardware draufwerfen
Sobald der Workflow stimmte, tauchte ein neuer Flaschenhals auf: Ich saß da und wartete.
Eine Claude-Code-Session, die sich durch eine Codebase mit 2 Mio. Zeilen kaut, ist nicht schnell. Jede Aufgabe dauert 20–30 Minuten Echtzeit. Der Flaschenhals war nicht Intelligenz. Es war Durchsatz.
Also sagte ich meiner Frau, ich bräuchte einen Server mit GPU für meine „AI agents.“ Dieses Gespräch lief ungefähr so gut, wie man es erwarten würde. Ich kaufte ihn trotzdem — plus einen Mac Mini passend zu meinem MacBook. Am Ende hatte ich drei Maschinen und sechs Terminals, auf denen jeweils eine unabhängige Claude-Code-Session lief.
Was das möglich macht, ist git worktree. Jede Session bekommt ihre eigene Aufgabe, ihren eigenen Branch und ihr eigenes Arbeitsverzeichnis, vollständig von den anderen isoliert. Und weil der Constraints-first-Ansatz bedeutet, dass jeder Branch seine eigenen Akzeptanzkriterien hat, ist Parallelität trivial sicher: Wenn die Tests jedes Branches unabhängig bestehen, ist das Mergen risikoarm.
Für den plattformübergreifenden Build bedeutete das: Eine Session löste Linux-ARM-Conan-Dependencies auf, eine behob die macOS-CMake-Konfiguration, und eine kümmerte sich um Windows-MSVC-Kompatibilität — alles gleichzeitig, ohne sich gegenseitig zu stören. Was früher serielles Context-Switching zwischen Plattformen war, wurde zu paralleler Ausführung über Maschinen hinweg.
Das Muster lässt sich auf die tägliche Arbeit übertragen. An einem beliebigen Tag refaktoriert eine Session den Compaction Scheduler, eine andere optimiert den HNSW Search Path, und eine dritte schreibt Integrationstests für einen Edge Case beim Streaming Insert. Ich springe zwischen Terminals hin und her wie ein Manager, der bei seinen Direct Reports nach dem Stand sieht — nur dass diese Direct Reports nie Kaffeepausen brauchen und keine Meinungen zur Sprint-Planung haben.
Die eigentliche Lektion ist, dass Vibe-Coding-Infrastruktur compute-bound ist, nicht talent-bound. Der limitierende Faktor ist nicht, wie schlau die KI ist; es ist, wie viele Instanzen man parallel laufen lassen kann. Anthropic used 16 parallel Claude instances to build an entire C compiler, wodurch sich meine sechs Terminals bescheiden anfühlten.
Worauf ich immer wieder zurückkomme
KI löst genau das Problem, das du ihr vorsetzt, nicht mehr. Wenn du das Problem falsch rahmst, bekommst du eine perfekte Lösung für das Falsche.
„Kompiliert auf macOS 15“ — in einer Stunde gelöst. Aber das ist ein lokales Optimum. Das eigentliche Ziel war „kompiliert überall ohne Hacks“. Das sind unterschiedliche Probleme. Die KI konnte das nicht wissen. Das liegt vollständig beim Engineer.
Mit KI für sich selbst zu bauen ist schockierend einfach — du kennst deine Maschine, deine Grenzfälle, und „funktioniert bei mir“ ist ein erreichbares Optimierungsziel. Infrastruktur zu bauen, die für jeden Nutzer, auf jeder Plattform, in jeder Umgebung funktioniert, ist grundlegend anders. In dieser Lücke lebt Engineering weiterhin. Bei Infrastruktursoftware ist diese Lücke enorm.
Die schwierigsten Bugs in unserem Produktionssystem — die, die nach dem Merge ein Revert erforderten — wurden von keinem der KI-Code-Review-Ansätze entdeckt, die wir ausprobiert haben. Die Bugs waren syntaktisch korrekt. Das Problem lag in den impliziten Annahmen des Entwicklers, unsichtbar im Diff und nicht im umgebenden Code vorhanden. Das Systemverhalten ergab nur Sinn, wenn man ein mentales Modell davon hatte, wie drei verschiedene Komponenten zusammenarbeiten sollten — ein Modell, das nur im Kopf eines Entwicklers existierte und nie aufgeschrieben wurde.
Dafür braucht es immer noch einen Menschen, der das System gut genug versteht, um zu wissen, welche Fragen gestellt werden müssen.
Die drei 200-Dollar-Pläne und ein verlorener Urlaub waren die beste Investition, die ich gemacht habe. Nicht, weil sie mir beigebracht haben, wie man KI nutzt. Sondern weil sie mir beigebracht haben, wie man sie nicht nutzt.
Die Tools sind wirklich gut. Das fehlende Puzzleteil war immer der Workflow um sie herum. Tests vor Code, Constraints vor Tests und genug Hardware, um alles parallel laufen zu lassen. Das ist die ganze Sache.
Die Probleme, die ungelöst bleiben
Nach allem — dem gescheiterten Patch, den Reset-Befehlen, den sechs parallelen Terminals — ist das schwierigste Problem immer noch das menschliche.
Im Moment habe ich zwei Kopfschmerzen, und für keines davon gibt es eine saubere Lösung.
Das erste: meine Frau. Sie ging mit vernünftigen Erwartungen in den Urlaub. Sie ging wieder, nachdem sie zugesehen hatte, wie ich mein Leben mit git reset --hard zurücksetzte. Das Budget für die Dior-Tasche wurde zu einer Serverrechnung. Verständlicherweise ist sie von meinen plattformübergreifenden Build-Erfolgen nicht beeindruckt. Ich habe noch keinen Workflow für „wie man sich dafür entschuldigt, den Jahrestag mit Distributed-Systems-Arbeit verbracht zu haben“ gefunden. Claude Code ist hier nicht hilfreich. Ich habe versucht zu fragen. Es schlug Blumen und eine handgeschriebene Notiz vor. Ich sagte ihm, es solle konkreter werden. Es generierte zwölf Varianten eines herzlichen Briefs in der Stimme eines C++-Entwicklers. Keine davon kam an.
Falls jemand das Problem gelöst hat, eine Beziehung aufrechtzuerhalten, während man sich durch einen Urlaub vibe-codet, bin ich sehr offen für Workflow-Vorschläge. 😂
Das zweite: wie man das über mich hinaus skaliert. Alles oben Genannte — der Constraints-first-Ansatz, die Parallelität mit git worktree, die testorientierte Review-Disziplin — befindet sich derzeit in meinem Kopf und in meinem lokalen Setup. Es in den täglichen Workflow eines Teams zu bekommen, ist schwieriger als jeder plattformübergreifende Build.
Das ist teilweise ein Tooling-Problem. Aber hauptsächlich ist es ein Menschenproblem. Diese Art von Workflow erfordert Engineers, die wirklich Freude daran haben, herauszufinden, wie Dinge funktionieren — Menschen, die tatsächlich zuerst den Test schreiben, die Befriedigung in einer sauberen, klar definierten Constraint finden und die nicht die Abkürzung zu „mach einfach, dass es durchläuft“ nehmen. Diese Kombination ist seltener, als sie sein sollte.
Also ja — wir stellen ein.
Wenn du die Art von Engineer bist, die einen Artikel über Infrastructure Vibe Coding liest und sofort starke Meinungen dazu entwickelt, was ich falsch gemacht habe, dann bist du genau die Person, mit der ich sprechen möchte.
Milvus ist ein wirklich schwieriges Distributed-Systems-Problem: Storage Engines, Indexing-Pipelines, Compaction, Replikation, Failure Recovery — alles unter realer Produktionslast. Wir bauen keine Demos. Wir bauen Infrastruktur, auf die Menschen angewiesen sind.
Wenn es interessant klingt, Probleme auf diesem Niveau zu lösen, dann komm und bau mit uns.
Und ich kümmere mich um den Plan zur Rettung des Jahrestags.
Du kannst dir unsere offenen Stellen ansehen oder mich direkt auf LinkedIn kontaktieren.
Und wenn du mit irgendetwas in diesem Beitrag nicht einverstanden bist, umso besser — ich diskutiere es gerne mit dir.
Tritt unserer Slack-Community bei oder buche eine Milvus Office Hours-Session — wir sprechen immer gerne über verteilte Systeme, KI-Infrastruktur oder darüber, wo du meinst, dass wir falschliegen.
Weiterlesen
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.
Introducing Zilliz CLI and Agent Skills for Zilliz Cloud
Manage your vector database from your terminal or AI coding agent. Zilliz CLI and Agent Skills work with Claude Code, Cursor, Codex, and Copilot.
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.