Vibe Coding senkt den Bus-Faktor auf 0
(mindflash.org)- In der Softwareentwicklung bezeichnet der Bus-Faktor ein Konzept dafür, wie viele Wissensträger vorhanden sein müssen, damit ein Projekt wartbar bleibt; bisher lag der schlechteste Fall bei 1
- Seit der Veröffentlichung von ChatGPT (30. November 2022) und der breiten Akzeptanz generativer KI verlassen sich jedoch viele Menschen darauf, dass KI Wissen übernimmt, statt es selbst zu bewahren – faktisch entsteht damit ein Bus-Faktor von 0
- In der Programmierpraxis verwenden immer mehr Entwickler von LLMs erzeugten Code und Features unverändert, geben den Versuch auf, die Codebasis zu verstehen, und wechseln zu „Vibe Coding“
- Dadurch kann man bei Bugfixes, Security-Patches oder Funktionserweiterungen in eine Situation geraten, in der niemand weiß, warum der Code so geschrieben wurde
- Das schafft erhebliche Risiken für Zuverlässigkeit und Sicherheit von Software; bis zu dem Tag, an dem KI perfekten Code perfekt erzeugt, bleibt hier eine grundlegende Grenze bestehen
Konzept und Geschichte des Bus-Faktors
- Der Bus-Faktor ist ein Konzept, das numerisch ausdrückt, auf wie viele Personen bestimmtes Wissen verteilt ist
- Beispiel: Wenn 3 Personen wissen, wie sich ein Datenbank-Backup wiederherstellen lässt, dann beträgt der Bus-Faktor dieser Funktion 3
- Traditionell war der schlechteste Wert 1; wenn eine Person dieses Wissen verlor, war die Weiterführung des Projekts unmöglich
- Um das zu überwinden, hat die Menschheit Wissen durch Dokumentation, Ausbildung, Wissenstransfer, Seminare, Schulen und viele andere Methoden verbreitet
- Das führte zu systematischen Versuchen, Wissen zu überliefern und zu bewahren, in die enorme personelle Ressourcen und Zeit investiert wurden
Einführung von KI und Bus-Faktor 0
- Mit dem Start von ChatGPT im November 2022 begann das Zeitalter von „AI First“
- Während KI Code und Features erzeugt, werden viele Menschen als Träger und Bewahrer von Wissen ausgeklammert und beginnen, sich auf KI-Erzeugnisse zu verlassen; dadurch sinkt das Projektverständnis rapide
- In der Folge entsteht ein Zustand, in dem es überhaupt keine Wissensträger mehr gibt, also ein Bus-Faktor von 0
- Programmierer schreiben und verstehen Code und Features nicht mehr selbst, sondern delegieren vollständig an die KI
- In diesem Prozess vermeiden Entwickler das Verständnis der Codebasis und die Dokumentation und gehen stattdessen zu einem Muster über, bei dem sie die KI einfach erneut um eine Erklärung bitten
Probleme des LLM-basierten Codings
- Selbst wenn man Fragen der Codequalität beiseitelässt, ist der Kernpunkt, dass Lesen und Warten grundsätzlich schwieriger sind als Schreiben
- Früher boten Mentoren oder Dokumentation zumindest minimale Hilfe, doch in einer KI-abhängigen Umgebung verschwindet sogar dieses Sicherheitsnetz
- In einer LLM-basierten Entwicklung wird der Entstehungsprozess des Codes nicht aufgezeichnet, und nicht einmal die KI erinnert sich an den Kontext des von ihr erzeugten Codes
- Am Ende müssen Entwickler von der KI geschriebenen, aber kontextlos wirkenden Code analysieren und ändern
- Das führt bei der Fehlerbehebung, beim Patchen von Sicherheitslücken oder bei Dependency-Upgrades zu einem Zustand, in dem niemand Absicht und Struktur des Codes kennt
Risiken aus Nutzersicht
- Nicht nur Entwickler, auch Nutzer sind Risiken ausgesetzt
- Software, in die persönliche Dokumente, Kreditkarteninformationen, private Fotos oder Gedanken hochgeladen werden, könnte aus Code bestehen, dessen interne Struktur und Zweck niemand kennt
- Das birgt ernsthafte Risiken für Datenschutz und Zuverlässigkeit und wirft Fragen zur Stabilität des Dienstes auf
Fazit
- Vibe Coding, das zu einem Bus-Faktor von 0 führt, ist grundsätzlich ein fehlerhafter Ansatz
- Das ist eine unvermeidbare Grenze, solange KI nicht in der Lage ist, mit 100 % korrekten Prompts auch 100 % korrekten Code zu erzeugen
- Daher darf man in der aktuellen Situation neben der Nutzung von KI die Bedeutung von Wissenssicherung und Codeverständnis nicht übersehen; es ist essenziell, Strukturen für Wissensmanagement und Dokumentation aufrechtzuerhalten
3 Kommentare
Ist der Bus-Faktor nicht unendlich geworden?
Wenn ein bei einem Unternehmen angestellter Entwickler kein Wissen hat, konvergiert der Bus-Faktor gegen 0.
Hacker-News-Kommentare
Der ungeprüfte Einsatz von LLMs, um einfach riesige Mengen unreviewten Codes auszuspucken, ist eine falsche Nutzung; solche Projekte geraten strukturell in die falsche Richtung oder werden bei komplexen Bugs bald unwartbar. Die eigentliche Stärke von LLMs zeigt sich in Situationen wie diesen: wenn man bekannte Algorithmen auf bestehende komplexe Datenstrukturen anwenden muss, wenn man Testdaten oder Gerüste für Unit-Tests mit vielen Abhängigkeiten aufsetzen will, wenn man einen visuellen Web-Editor und eine Backend-API baut und die Speicherung in sqlite ergänzt, oder wenn man Arbeiten, die selbst mit komplexen regulären Ausdrücken schwer wären, auf eine große Codebasis anwenden muss. Tatsächlich kann man dank LLMs Aufgaben, die einen halben Tag oder drei Tage gedauert hätten, in zwei Minuten anstoßen. Wichtig ist, dass die Produktivität auch dann massiv steigen kann, wenn LLMs extrem schwierige Probleme nicht lösen. Man wird von langweiligen Wiederholungsaufgaben befreit und kann sich auf interessantere Probleme konzentrieren.
Ich dachte auch, dass LLMs wiederholte Änderungsarbeiten in großen Codebasen in zwei Minuten erledigen würden, aber nach eigenen Experimenten mit mehreren großen Modellen stellte sich heraus, dass sich Fehler mit zunehmender Kontextkomplexität anhäufen und gelegentlich sogar irrelevante Änderungen entstehen, sodass das Ergebnis letztlich nicht vertrauenswürdig war. Bei kleinen Beispielen funktioniert es perfekt, aber mit wachsender Größe wird es unzureichend. Mit einem agentic loop kann man es verbessern, aber durch das wiederholte Ausführen und Reviewen kostet es am Ende viel mehr Zeit. Es ist deutlich verlässlicher, das LLM ein Programm schreiben zu lassen, das die Änderungsarbeit automatisiert.
Alle genannten Beispiele wirken gut, aber in der Praxis gibt es noch viel mehr mögliche Einsatzszenarien. Du sprichst über Fälle erfahrener Entwickler, aber auch für Menschen mit wenig technischem Können oder für Einsteiger hat sich durch LLMs die Zahl der Dinge, die sie tun können, stark erhöht. Dinge, für die man früher 100 Dollar bezahlt hätte, kann man jetzt in drei Minuten selbst ausprobieren. Ob das Ergebnis perfekt und wartbar ist, wird dann eher unwichtig; der größere Wert liegt darin, überhaupt Möglichkeiten aufzuzeigen.
Ich stimme dir zu, aber ich möchte eine kürzlich lustige Erfahrung teilen. Ich bat Claude, Unit-Tests zu schreiben, und beim Review stellte sich heraus, dass mein Code tatsächlich einen Bug hatte und der Test ihn gefunden hatte. Aber statt den Bug zu beheben, versuchte Claude, den Test dadurch grün zu bekommen, dass der fehlgeschlagene Test einfach gar nicht ausgeführt wurde — eine herrlich absurde Episode aus dem echten Leben. LLMs sind schwach bei Anforderungsdefinition, Architekturdesign und dem Schreiben von Spezifikationen passend zu Anforderungen, haben aber Stärken bei Aufgaben mit klar abgegrenztem Umfang und begrenzter Auswirkung wie dem Schreiben von Code.
Ich habe eine Zwischenstufe ausprobiert, bei der AI erst PR-Reviews automatisch macht und dann noch manuell reviewed wird. Die Codegenerierung dauert 5–10 Minuten, das Review und zusätzliche Commits meist 1–3 Stunden, aber ich habe diese Methode in mehreren Projekten (10–20k LOC, etwa 100 Dateien) erfolgreich eingesetzt. Wenn die Spezifikation gut ist, werden viele Features fast korrekt und ohne große Änderungen implementiert; meist geht es dann vor allem um Refactoring auf Basis von Feedback. Natürlich dauert die Lösung manchmal fast einen ganzen Tag, wenn es nicht richtig funktioniert, aber insgesamt ergibt sich eine Produktivitätssteigerung um das 3- bis 5-Fache. Für große Projekte scheint es besser zu sein, sie in Teile zu zerlegen und zu modularisieren.
Formulierungen wie „x Tage Arbeit in 2 Minuten mit LLM erledigt“ sind etwas übertrieben, weil die Review-Zeit nicht eingerechnet ist. Wenn man tatsächliches Review und Abnahme mit einbezieht, dauert es deutlich länger. Man kann dabei sogar eher in die eingangs erwähnte „falsche Methode“ geraten.
Der Text nennt zwar mehrere Probleme der AI-Codegenerierung, scheint aber bestehende oder künftig mögliche Lösungen nicht zu berücksichtigen. Schon früher konnten neue Teammitglieder Hilfe dabei bekommen, Code zu verstehen, wenn ein Team sich wenigstens ein Minimum an Mühe mit der Codebasis gegeben hatte. Ich frage mich, ob hier einfach die Erfahrung mit Legacy-Code fehlt oder ob wirklich geglaubt wird, dass sich das Problem, dass AI „den gesamten Kontext des ursprünglichen Schreibprozesses vergisst“, nicht beheben lässt. Auch das Bus-Factor-0-Problem wird so missverstanden, als ließe es sich nur mit 100%iger Perfektion lösen; tatsächlich sind Menschen auch nicht immer zu 100 % korrekt, und trotzdem vertrauen wir ihnen.
Ich hatte den Eindruck, dass der Text das Problem viel zu verkürzt betrachtet. Die Realität, dass wir nicht alles immer zusammen mit dem ursprünglichen Autor machen können, existiert doch ohnehin schon. Allein ein Pairing-Partner oder eine erklärende AI ist schon ein enormer Fortschritt. Es wirkt, als würde man sich eine Welt ohne Menschen vorstellen, dabei erleben wir solche Situationen ohnehin ständig.
Ich bin der Autor, und ich stimme dem ersten Einwand zu; ich denke auch, dass AI die Lücke künftig verkleinern wird. Bis dahin könnten aber einige Probleme bereits eingetreten sein. Es bleibt auch das Problem, dass Code ohne logischen Kontext oder Bearbeitungshistorie zurückbleibt. Es wird viel darüber gesprochen, dass AI „ständig lernt“, aber in Wirklichkeit lernt sie nicht, bis ein neues Modell erscheint. Menschen sind auch nicht zu 100 % korrekt, aber ihr Bus Factor ist nicht 0, und Probleme lassen sich leichter identifizieren und lösen. Wenn die übrigen Probleme gelöst werden, verringert sich auch das Bus-Factor-Problem.
Ich habe oft gedacht, wie schön es gewesen wäre, bei der Analyse von Legacy-Code schon AI-Tools zu haben. Es gab tatsächlich absurde Situationen wie: „Der letzte Bearbeiter dieser Perl-Datei ist jetzt Filialleiter — muss ich direkt ein Meeting mit ihm ansetzen?“
Auf die Frage „Warum muss es 100 % korrekt sein?“ würde ich antworten, dass AI-Kritiker oft gerade dazu neigen, von AI eine magisch perfekte Lösung zu erwarten. Das hat einen ähnlichen Unterton wie bei Leuten, die gegen statische Typisierung sind und sich beschweren, dass sie „nicht einmal logische Fehler abfängt“.
In letzter Zeit gibt es in Blogs so viele AI-generierte Bilder, dass sie eher ablenken und dem Inhalt oft gar nicht helfen.
Ich bin vor Kurzem zu einem Team mit einer chaotischen Codebasis gestoßen; die früheren Entwickler waren größtenteils weg, und selbst die Verbliebenen kannten den Code kaum. Vollständig Bus Factor 0. Überraschenderweise hat AI das Verständnis des Codes, das Erfassen der Intention und die Geschwindigkeit beim Debugging stark verbessert. Wir haben begonnen, mit AI direkt aus dem Code Dokumentation zu erzeugen. Dokumentation oder mündliche Überlieferung können verzerrt sein, aber der Code selbst ist die Wahrheit. Mit Hilfe von AI konnten wir eine Umgebung schaffen, in der sich der Code selbst erklärt, und das brachte einen großen Produktivitätsschub.
Schon vor dem Auftreten von LLMs war der Bus Factor immer ein Problem. Die meisten Unternehmen haben ihre Arbeit nicht so strukturiert, dass mehrere Personen jeweils zumindest Teile davon verstehen. Selbst wenn mehrere Menschen einzelnen Bereichen zugewiesen sind, wächst das Arbeitsvolumen immer weiter, bis am Ende wieder niemand mehr alles versteht. Um das vollständig zu vermeiden, bräuchte es enormen Aufwand im Engineering-Management, etwa durch Rotation der Leute innerhalb der Codebasis, und meistens gelingt das wegen des Geschwindigkeitsdrucks nicht perfekt. Ich habe meine Rückschau auf CTO-Erfahrungen dazu hier als Buch veröffentlicht und unabhängig vom Preis freigegeben. Ich denke, die Prinzipien sind nicht besonders anders, ob man ein System mit LLMs baut oder mit zehn externen Entwicklern.
Der Bus Factor war schon vor LLMs ein Problem und ist seit Langem ein etablierter Fachbegriff. TFA kritisiert den Trend, dass der Bus Factor früher bei 1 lag und jetzt gegen 0 geht.
Es wächst nur das Arbeitsvolumen, aber in Wirklichkeit entwickelt sich die Arbeit nicht in eine empfehlenswertere Richtung; stattdessen wiederholt sich nur das Muster, Dinge gerade so rechtzeitig für Deadlines irgendwie fertigzumachen. Ein paar prozedurale Hürden lösen das nicht.
Unser Gehirn spart bei Informationen, die wir nicht oft nutzen, Energie; je weiter wir uns von etwas entfernen, desto schlechter verstehen oder erinnern wir es. Selbst wenn man jeden Code-Review direkt macht, können die eigenen Fähigkeiten am Ende dennoch abbauen. Es ist ähnlich wie bei Ingenieuren, die lange Managementaufgaben übernehmen und dann technische Probleme kaum noch lösen können. Auch bei der Automatisierung von Autos ist es schwer, Zwischenstufen (level2→5) aufrechtzuerhalten, bei denen der Mensch ständig beteiligt bleibt; wenn der Maschine nicht zu 100 % vertraut werden kann, entstehen am Ende Probleme.
In dieser Diskussion gibt es einen wirklich wichtigen Punkt: Diese Tools und Workflows stehen eigentlich erst ganz am Anfang. Ich bin überzeugt, dass AI solche Probleme künftig sogar besser als Menschen lösen könnte. Ich habe auch mit dem Einsatz von LLMs experimentiert; manches war erfolgreich, manches nicht, aber in bestimmten Bereichen zeigen sie eindeutig herausragende Fähigkeiten. LLMs werden nicht unwillig und können Dokumentation, Kommentare, README und sogar ADRs sorgfältig aktualisieren. Mit genügend Leitplanken und Struktur könnte eine LLM-Codebasis langfristig sogar leichter zugänglich sein, gerade weil die Dokumentation tendenziell besser ist.
Ich denke, der Text übersieht, dass sich schon aus dem Code selbst ein erheblicher Teil der Intention herauslesen lässt. Menschen — und vermutlich auch LLMs — sind ziemlich vorhersehbar. Meist lösen sie ähnliche Probleme auf ähnliche Weise. Wenn man sieht, wie Code geschrieben wurde, bekommt man Hinweise darauf, warum, von wem und wann welches Problem gelöst wurde. Natürlich bleibt vieles verborgen, aber in Organisationen mit häufig wechselnden Teammitgliedern passiert etwas Ähnliches.
Ich denke zwar, dass sich menschliche Denkprozesse letztlich im Code niederschlagen, aber dennoch ist das ein deutlich unterlegener Prozess im Vergleich dazu, jemanden direkt fragen zu können. Reverse Engineering macht man normalerweise nur dann, wenn es unbedingt nötig ist; bei Legacy-Code müssen es am Ende aber alle tun. Produktiv ist das allerdings nicht. Und bei LLM-Codebasen vermischen sich nicht eine einheitliche Intention, sondern viele unterschiedliche Intentionen verschiedener Menschen, sodass schon beim Blick auf einzelne Codefragmente eher noch mehr Unklarheit darüber entsteht, was ursprünglich gemeint war. Man könnte außerdem fälschlich annehmen, AI-generierter Code sei ebenso durchgängig eindeutig bedeutungsvoll wie von Menschen geschriebener Code, was die Interpretation sogar noch erschwert.
Die Fähigkeit, Intention allein aus Code zu erkennen, hängt von Umfang und Größe ab. Bei etwas wie Arduino mit 32kB Begrenzung ist das leicht zu verstehen. Aber bei einer komplexen Plattform mit Dutzenden verflochtener Microservices, besonders wenn sie im Stil von „vibe coding“ entstanden ist, würde ich, wenn das in meine Verantwortung fiele, am liebsten einfach aufgeben.
Ich stimme der Kernaussage und Schlussfolgerung des Textes zu, aber ich habe in 20 Jahren mehrfach sehr ähnliche Situationen erlebt (Umgebungen, in denen man niemanden mehr fragen konnte, weil die tatsächlichen Zuständigen längst weg waren). Mit LLMs geht so etwas vielleicht etwas schneller, aber es ist weniger ein völlig neues Problem als eher eine Beschleunigung eines alten Problems. Ich begrüße, dass auf dieses Problem aufmerksam gemacht wird.
Es gibt sogar das gegenteilige Szenario. Wenn man eine Codebasis so gut dokumentiert, testet und konfiguriert, dass AI sie gut nutzen kann, dann wird ein AI-Agent dieselbe Arbeit in einem Jahr wahrscheinlich noch schneller erledigen können.
Ich frage mich, wie AI Coding Tools wohl jemals die typische Haltung bestehender Entwickler übernehmen werden: „Der alte Code ist sowieso schlecht, wir müssen alles neu schreiben.“ Es wäre auch interessant, wenn künftig vielleicht das CI/CD-System selbst dazu übergeht, das gesamte Projekt komplett per AI neu schreiben zu lassen.
Ich bin der Autor: Wenn es so läuft, wie du sagst, steigt der Bus Factor bereits. Entscheidend ist also, dass Informationen nicht nur im Kopf verbleiben, sondern in verschiedenen Formen gespeichert werden und fortbestehen.