- In der IT-Branche ist in letzter Zeit eine neue Servicekategorie namens „Vibe Coding Cleanup“ entstanden:
Vibe Coding Cleanup as a Service
- Während sich die Realität zeigt, dass der Großteil von KI-generiertem Code nicht produktionsreif ist, entsteht ein neuer Servicemarkt, der diesen Code aufräumt und korrigiert
- Nachdem Andrej Karpathy Anfang 2025 „Vibe Coding“ definierte, nutzen zwar 92 % der Entwickler KI-Tools, doch Probleme bei der Codequalität und Sicherheitslücken treten deutlich zutage
- Tatsächlich spezialisieren sich Entwickler inzwischen darauf, von KI erzeugte Inkonsistenzen, Duplikate und unlogische Logik zu beheben; spezialisierte Marktplätze und Beratungsangebote breiten sich aus
- KI ist bei kleinen Aufgaben hervorragend, berücksichtigt aber den Systemkontext nicht und produziert dadurch strukturelle Schulden und Sicherheitsprobleme; daraus entsteht wiederum eine neue industrielle Chance, eine Art „Aufräum-Ökonomie“
- Wenn Unternehmen KI-Coding erfolgreich nutzen wollen, sollten sie Prototypen der KI überlassen, aber gezielt in Fachkräfte für Architektur, Sicherheit und das Aufräumen von Tests investieren
Das Aufkommen und die Verbreitung von Vibe Coding
- Anfang 2025 verwendete Andrej Karpathy den Begriff „Vibe Coding“, wodurch sich das Konzept etablierte
- Ein Ansatz, bei dem per natürlichsprachlichem Dialog ganze Funktionen erzeugt werden
- Getrieben von der Erwartung, die Produktivität um das Zehnfache steigern zu können, verbreitete es sich schnell
- Laut GitHub nutzen 92 % der Entwickler KI-Coding-Tools
- Copilot erzeugt jeden Monat Milliarden Zeilen Code
- Laut einer Analyse von GitClear zeigt sich bei der Nutzung von KI-Code jedoch eine um 41 % höhere Code-Fluktuation
- Code, der innerhalb von zwei Wochen zurückgerollt oder neu geschrieben wird, nimmt deutlich zu
- Eine Stanford-Studie zeigt, dass Entwickler mit KI-Unterstützung mehr unsicheren Code schreiben und zugleich eher glauben, ihr Code sei sicherer
- KI-Tools verstärken durch fehlende Eingabevalidierung, veraltete Abhängigkeiten und unklare Designentscheidungen verschiedene Antipatterns
Die Realität der Aufräum-Ökonomie
- In der IT-Branche ist in letzter Zeit still und leise ein neues Servicefeld rund um Vibe-Coding-Cleanup entstanden
- Anfangs war es kaum mehr als ein Scherz nach dem Motto „Wir reparieren den chaotischen Code, den KI gebaut hat“, inzwischen entwickelt es sich aber zu einer realen Geschäftschance
- Laut einer Untersuchung von 404 Media bauen einige Entwickler ihre Karriere allein auf dem Aufräumen von KI-Code auf
- Sie zerlegen Inkonsistenzen, Duplikate und absurde Logik, die als „AI-Spaghetti“ bezeichnet werden
- Ulam Labs bewirbt Vibe Coding Cleanup als Kernservice
- Auch ein spezialisierter Marktplatz namens VibeCodeFixers.com ist entstanden
- Innerhalb weniger Wochen meldeten sich mehr als 300 Experten an, und Dutzende Projekte wurden vermittelt
- Typischer Kunde: „ein Startup, das Tausende Dollar an OpenAI-Credits verbraucht hat und nun einen halb funktionierenden Prototypen besitzt“
Warum KI-Code scheitert
- Das Problem ist nicht, dass KI an sich schlechten Code schreibt, sondern dass sie den Systemkontext nicht versteht und lokal optimierten Code erzeugt
- Dadurch häufen sich inkonsistente Muster, doppelte Logik und Sicherheitslücken, was zu technischer Schuld führt
- Laut Forschung der Georgetown University enthalten mindestens 48 % des KI-generierten Codes Sicherheitslücken
- etwa die Offenlegung geheimer Informationen, die Nutzung veralteter Bibliotheken oder Race Conditions unter Last
- Noch gravierender ist, dass Entwickler den von KI erzeugten Code selbst nicht ausreichend verstehen und Probleme deshalb nicht richtig erkennen
- Thoughtworks bezeichnet das als „Capability Debt“
- ein Zustand, in dem Teams ihre Fähigkeit zur Code-Wartung verlieren und in KI-Abhängigkeit geraten
Marktchance
- Der Cleanup-Markt wächst rasant, doch konkrete Zahlen sind schwer zu erfassen
- Gartner prognostiziert, dass bis 2028 75 % der Unternehmensentwickler KI-Codeassistenz nutzen werden
- Damit dürfte in den meisten Projekten ein Aufräumbedarf entstehen
- Selbst wenn nur ein Teil davon Cleanup benötigt, entsteht aufgrund der Größenordnung ein beträchtlicher neuer Markt
- Auch wirtschaftlich ist das attraktiv
- Startups erstellen mit KI schnell ein MVP, investieren danach aber ähnlich viel Zeit und Geld in das Aufräumen
- Trotzdem bleibt es schneller als traditionelle Entwicklung
- Cleanup-Spezialisten verlangen 200 bis 400 US-Dollar pro Stunde
- Auch produktisierte Angebote wie Pauschalpakete, KI-Code-Audits oder „Vibe-to-Production“-Pipelines verbreiten sich
- Laut Thoughtworks ist bei Projekten mit KI-Nutzung der Refactoring-Anteil gesunken, während die Code-Fluktuation weiter zugenommen hat und vor dem tatsächlichen Produktiveinsatz ein umfangreicher Cleanup-Prozess unverzichtbar ist
- Viele Beratungsunternehmen beginnen bereits, Spezialisten für KI-Code-Cleanup oder Remediation einzustellen
- Unterm Strich ist der Cleanup-Markt real, wächst schnell und weist noch viele unerschlossene Bereiche auf
Auswirkungen auf das Engineering
- Es findet ein grundlegender Wandel der Softwareentwicklungsmethodik statt
- Der Entwicklungsprozess wird zu einem arbeitsteiligen Modell umgebaut: KI implementiert, Menschen übernehmen Architektur, Tests und Cleanup
- Gergely Orosz vergleicht KI-Tools mit „einem extrem motivierten Junior-Entwickler“ und betont, dass sie zwar schnell Code schreiben, aber immer Aufsicht brauchen
- KI bleibt jedoch dauerhaft auf dem Niveau eines Junior-Entwicklers stehen und wächst nicht zu einem Senior heran, weshalb die Rolle von Cleanup-Experten dauerhaft nötig bleibt
- Es entstehen auch neue Karrierepfade
- Junior-Entwickler können mit Cleanup-Kompetenz innerhalb von zwei Jahren Gehälter auf Senior-Niveau erreichen
- Senior-Entwickler, die die Stärken und Grenzen von KI verstehen, schaffen hohen Mehrwert
- Erfolgreich sind nicht die Unternehmen, die KI am meisten einsetzen, sondern jene, die systematische Cleanup-Prozesse aufbauen
- Organisationen mit einem robusten Cleanup-Prozess können sich einen Wettbewerbsvorteil verschaffen
Die Position von Donado Labs
- Donado Labs betont auf Basis zahlreicher Erfahrungen beim Aufräumen von Vibe-Code, dass KI zwar bei der Beschleunigung nützlich ist, aber zwingend ein professioneller Cleanup-Prozess nötig bleibt
- Für Prototyping und wiederkehrende Arbeiten soll KI eingesetzt werden, Kernarchitektur sowie Sicherheit und Tests bleiben Aufgabe von Menschen
- Mit dem Service „Vibe to Production“ werden KI-Prototypen auf Unternehmensniveau gebracht
- einschließlich Tests, Sicherheitsverstärkung und Dokumentation
- Unternehmen, die KI-Coding erfolgreich nutzen, sind nicht jene, die KI am meisten einsetzen, sondern jene, die KI intelligent nutzen und in Cleanup investieren
- Entscheidend ist, Cleanup parallel zu betreiben, bevor sich technische Schulden ansammeln
- Auf die Behauptung, KI werde Programmierer ersetzen, lautet die Gegenfrage: „Wer räumt diesen Code auf?“ – genau darin liegt die echte Geschäftschance
4 Kommentare
In den frühen GPT-Tagen gab es Leute, die bei externen Programmiererinnen und Programmierern den Preis drückten, indem sie sagten, sie hätten mit AI einen Prototyp gebaut und man müsse ihn nur noch ein bisschen fertigstellen.
> Ordnungsprofis verlangen 200 bis 400 Dollar pro Stunde
Aber ehrlich, gibt es wirklich Leute, die so etwas machen?
Schon vor dem Aufkommen von Vibe Coding dachte ich, dass es gut wäre, wenn es einen Service gäbe, der chaotischen Code aufräumt – und tatsächlich hat es jemand gebaut. Aber ich glaube nicht, dass wir das in unserem Unternehmen einführen werden T_T
Früher waren Auftragsarbeiten, bei denen man bei KI-Bildern die Finger korrigiert, mal im Trend … aber inzwischen macht man selbst das nicht mehr.
Ich denke, dass AI-Cleanup wohl einen ähnlichen Weg gehen wird.
Hacker-News-Kommentare
Ich übernehme schon seit ziemlich langer Zeit über mein Geschäft solche „Aufräum“-Projekte.
Früher kamen die kaum funktionierenden Codebasen meist von externen Agenturen, aber inzwischen scheint die Quelle eher zu LLMs zu wechseln.
Am Ende wiederholen sich offenbar dieselben Probleme.
Nur die Methode zur Kostensenkung hat sich geändert.
Es gibt eindeutig Gründe, Abkürzungen zu nehmen, aber das eigentliche Problem entsteht, wenn man sich nicht wirklich bewusst macht, dass das später teuer werden kann.
Ob Manager, Mitarbeiter oder externe Dienstleister – das Ergebnis ist oft ähnlich.
Ich habe bislang noch nie gezielt einen Service zur strukturellen Überarbeitung von vibe-coding-Plattformen beworben, aber vielleicht ist jetzt der Zeitpunkt, das einmal zu versuchen.
Der australische Softwaremarkt ist klein, deshalb hört man von den Ergebnissen solcher Experimente nicht besonders viel.
Ich denke, der Unterschied zwischen vibe coding und ausgelagerter Entwicklung liegt in der Menge des produzierten Codes.
Ich habe einmal per vibe coding ein einfaches Helper-Skript erstellen lassen; wenn ich es selbst geschrieben hätte, wäre es vielleicht nur ein Drittel so groß geworden, und die meisten Edge Cases hätte ich gar nicht behandelt, wobei einige der zusätzlichen Ausnahmebehandlungen unnötig waren und andere tatsächlich geholfen haben.
Meine eigentliche Arbeit bestand darin, den Code zu überfliegen und eine Zeile zum Löschen von temp-Dateien zu entfernen, weil dabei versehentlich das Home-Verzeichnis hätte gelöscht werden können.
Später, als ich tiefer in die Datenverarbeitung eingestiegen bin, habe ich dann bemerkt, dass einige temp-Dateien fehlten und es noch an zwei weiteren Stellen Löschcode gab.
Tatsächlich war der Code für Menschen einfach zu umfangreich, um alles realistisch vollständig zu prüfen.
Trotzdem ist das in Bezug auf Geschwindigkeit ganz klar enorm effizient.
In Zukunft werde ich den Code wohl weniger gründlich lesen und stattdessen lieber mit AI in einer Sandbox Tests laufen lassen.
Besonders bei Tools mit einem „Plan-Modus“ wie Claude Code gibt es einen großen Unterschied.
Ich nutze Claude Code bei der Arbeit derzeit viel und frage im Plan-Modus immer zuerst im Gesprächsformat, „wie man das implementieren würde“, und verfeinere den Detailplan dann über ein paar Gesprächsrunden zu einem guten Design.
Danach sagt mir die AI genau, welchen Code sie erzeugen wird, inklusive Code-Diff, und erst nachdem ich das final freigegeben habe, wird der eigentliche Code generiert.
Im Gegensatz dazu war der Code, den ich früher von Outsourcing-Teams reviewt habe, oft ein völlig chaotischer Haufen Spaghetti-Code, bei dem man kaum verstehen konnte, was überhaupt los ist.
Ich denke, es ist keine schlechte Idee, zumindest aus SEO-Gründen vibe-coding-bezogene Begriffe auf der Website zu platzieren.
Ich hatte einen ähnlichen Gedanken.
Aber wenn ein Projekt vibe-coded wurde und deshalb voller Bugs ist, reicht es dann, wenn ich hingehe, die Fehler behebe und die Struktur aufräume?
Ich frage mich, wie ein Unternehmen, dem schon die Fachkenntnis für die anfängliche Einrichtung gefehlt hat, die Wartung danach weiterführen soll.
Ich glaube, sowohl Outsourcing als auch LLM-basierte Entwicklung erfordern am Ende ähnliche Fähigkeiten.
Also weiterhin solide Grundlagen im Engineering: Anforderungen strukturieren, kommunizieren, Stakeholder managen, Spezifikationen definieren, testen und dokumentieren.
Es fühlt sich etwas seltsam an, dass Karpathys Konzept des "vibe coding" auf diese Weise so populär geworden ist.
Ich vermute, das ist vor allem unter Leuten verbreitet, die wenig echte Entwicklungserfahrung haben.
So wie ich vibe coding verstanden habe, bedeutet es eine Art Flow-Zustand, bei dem man einfach mit der AI redet und dem entstehenden Strom vertraut, ohne die Code-Ergebnisse wirklich zu prüfen oder nennenswert zurückzuschauen.
Wenn die Qualität der Software, die man ernsthaft bauen will, auch nur ein bisschen wichtig ist, ist das eine wirklich schreckliche Methode.
Für Twitter-Memes, selbstgefällige Spielereien oder kleine Skripte für zu Hause mag das funktionieren, aber für die Entwicklung eines echten Produkts halte ich es für absurd.
Dass der Begriff so groß geworden ist, liegt wohl eher daran, dass jemand Bekanntes wie Karpathy ihm einen eingängigen Namen gegeben hat; hätte es jemand anderes gesagt, wäre es vermutlich untergegangen.
Schon vor AI haben Junioren oder weniger erfahrene Entwickler oft auf diese Weise programmiert.
Sie haben irgendwo etwas per Copy-and-Paste übernommen, geschaut, ob es irgendwie läuft, und wenn dann seltsame Bugs oder Core Dumps auftraten, einfach die Reihenfolge im Sourcecode verändert, bis das Problem irgendwie verschwand.
Mit so einem Stil bekommt man im Unternehmen mindestens eine Warnung, landet auf einem Performance-Improvement-Plan oder wird im schlimmsten Fall ganz aussortiert.
Nicht-Experten haben in der Kommunikation mit Softwareingenieuren oft keine brauchbaren Ergebnisse bekommen.
Das Aufkommen von vibe coding ist für mich auch eine Art Selbstkritik daran, welche Art von Software wir bisher ausgeliefert haben.
Die Softwarequalität der vibe-coded Startups, die ich kenne, ist in der Praxis zwar miserabel, aber solange sie das tut, was die Gründer wollen, spielt Qualität in dieser Phase keine große Rolle.
Solange Softwarequalität dem Geschäft keinen echten Schaden zufügt, werden sie kaum das Risiko eingehen wollen, Entwickler einzustellen, die ihre Idee womöglich verfälschen.
Am Ende ist etwas Schrottiges, das sofort genau das tut, was sie wollen, für sie die bessere Option als perfekte Software, die nicht das ist, was sie sich vorgestellt haben.
Ob es einem gefällt oder nicht: vibe coding wird nicht verschwinden.
Ich selbst stimme dem Konzept auch nicht besonders zu, aber ich sage im Unternehmen Kolleginnen und Kollegen gelegentlich: „Das habe ich vibe-coded gebaut.“
Für uns bedeutet das einfach, dass der Großteil des Codes automatisch mit AI erzeugt wurde.
So erzeugten Code würden wir aber niemals ungeprüft direkt in Production bringen.
Wir verwenden das eher leichtgewichtig im Sinn von: „Ich habe mal eben per vibe coding eine coole App zusammengeklickt“ – also nur experimentell.
Ich glaube, Karpathy meinte damit eher, dass vibe coding ein „mögliches Experiment“ ist, das man ausprobieren kann, um zu sehen, wie weit man damit kommt und wie unterhaltsam das ist.
Es war meiner Meinung nach nicht als Empfehlung gemeint, in Unternehmen ernsthaft Produkte ausschließlich so zu bauen.
Die Leute haben den Kontext dieses Ausdrucks viel zu frei für sich umgedeutet.
Karpathy hat in einem YouTube-Video sogar erklärt, was er damit eigentlich meinte.
Verwandter Artikel
Karpathy auf YouTube: Software Is Changing (Again)
Ich denke, das Missverständnis wurde größer, weil die Leute glauben wollen, dass schwierige Dinge jetzt leicht werden.
Ich glaube immer noch, dass schon der ursprüngliche Tweet eher ein Witz oder ein Ausdruck von Freiheit im Sinne von „YOLO coding“ war und nicht als Empfehlung für einen echten Arbeitsprozess gedacht war.
Es war einfach eine locker formulierte Beschreibung dieses befreienden Gefühls in dem Moment.
Inzwischen wird vibe coding praktisch als abwertender oder spöttischer Begriff für jede Form von AI-Coding-Hilfe verwendet.
Jedes Tool kann gut oder schlecht eingesetzt werden, aber derzeit bekommt online das Meme „wie dumm vibe coding ist“ besonders schnell Zustimmung.
Langsam wird das wirklich ermüdend.
Der Kern des Artikels ist die Behauptung: „Wenn ein Startup dank vibe coding sein MVP mehrere Wochen schneller bauen kann und später trotzdem ähnlich viel Zeit und Geld in die Bereinigung stecken muss, ist es immer noch schneller als traditionelle Entwicklung.“
Ich frage mich, ob das wirklich stimmt.
Meiner Erfahrung nach ist der Geschwindigkeitsunterschied womöglich gar nicht so groß, wenn Entwickler direkt mit AI-Unterstützung bauen.
Vor allem, wenn man weiß, dass ein MVP oder Prototyp später ohnehin direkt in Production landet, fühlt es sich langfristig besser an, die Architektur von Anfang an sauber aufzusetzen.
Aber die meisten aus Produkt und Management betrachten diese Zeit als Verschwendung.
Der eigentliche Vorteil von vibe coding ist, dass das Produktteam nicht erst Entwicklern erklären muss, was es will, sondern es direkt selbst ausprobieren kann.
Vielleicht gibt es sogar einen Markt für vibe-coding-basierte Produkttools, die weniger den Code selbst erzeugen, sondern vor allem Spezifikationen und Prototypen klarer machen.
Solche Tools könnten Entwicklern bessere Vorgaben geben und zugleich dem Business mehr Beitrag und Eigenständigkeit ermöglichen.
In Startups ist Time-to-Market so wichtig, dass es völlig rational sein kann, technische Schulden in Kauf zu nehmen, selbst wenn die Gesamtkosten und der Gesamtaufwand am Ende höher sind, solange man dafür früher live gehen kann.
Genau deshalb bauen Leute ja überhaupt technische Schulden auf.
Twitter hat ursprünglich auch als Web-App auf Ruby on Rails angefangen, und immer wenn Justin Bieber getwittert hat, sind die Server abgestürzt und der fail-whale erschien.
Mit dem Wachstum wurden dann schließlich Experten eingestellt und die Architektur grundlegend neu aufgesetzt, damit sie robuster und besser skalierbar wurde.
Für ein MVP vielleicht weniger, aber für einen Prototypen könnte es brauchbar sein.
Wenn es in einer Organisation oder bei Einzelnen nicht die Disziplin gibt, Prototypen nicht in prod zu schieben, sollte man vibe coding besser vermeiden.
Wir wissen alle, wie schwer es ist, das Management davon zu überzeugen, dass der Code, der gerade hübsch aussieht und aktuell benutzt wird, intern ein einziges Chaos ist und komplett neu gebaut werden muss.
In solchen Fällen sind no-code-Tools deutlich sicherer.
Die Realität ist doch, dass die meisten MVPs oder Prototypen sehr schnell in Production landen.
Ich erinnere mich, dass jemand einmal sagte: „Wenn dir der MVP-Code nicht körperlich weh tut, verbringst du zu viel Zeit mit Codequalität.“
Am Ende wird solcher Provisoriums-Code zum Rückgrat des Unternehmens.
Einen Dienst, der nur solche Aufräumarbeiten übernimmt, könnte man wohl „C-Suite Cleanup as a Service“ nennen, aber wenn man so wirbt, würde einen wahrscheinlich niemand beauftragen.
Schon beim Lesen hatte ich deutlich das Gefühl, dass der Text von Claude geschrieben wurde – sogar ohne em-dashes.
Natürlich hat OP vermutlich eigene Gedanken und Materialien in den Prompt gegeben, aber die typischen Formulierungen und der Satzklang wirkten exakt wie das, was man oft aus LLMs kennt, sodass sich das Lesen etwas erzwungen anfühlte.
Vielleicht wird dieser Stil in Zukunft als „LLM-Schreibstil“ altbacken wirken.
Jetzt wird wohl vibe-writing cleanup as a service zum nächsten großen Ding.
Ich habe schon seit Langem viele em-dashes verwendet, aber inzwischen scheint die Zeit gekommen zu sein, das notfalls bewusst zurückzufahren.
Microsoft Word ersetzt Bindestriche automatisch durch em-dashes.
Ich finde, vibe coding ist ein bisschen wie DIY-Klempnerarbeit.
Man probiert es selbst, und wenn im Bad das Wasser ausbricht, muss man am Ende doch den Notdienst-Klempner teuer bezahlen.
Und beim nächsten Mal hat man immerhin etwas dazugelernt.
Man kann es ähnlich sehen, aber auch professionelle Klempner nutzen gute Tools, die DIY-Arbeit unterstützen.
Der Unterschied ist, dass Profis wissen, wann und bis zu welchem Punkt sie so etwas einsetzen sollten.
Eigentlich ist es sogar noch schlimmer.
Bei Klempnerarbeiten sieht man mit eigenen Augen, was getan wird, aber bei vibe code funktioniert plötzlich eines Tages etwas nicht mehr und man hat keine Ahnung, warum.
Auf YouTube sieht man oft genug DIY-Klempner, die sorgfältiger arbeiten als Profis.
Es hängt wohl davon ab, ob vibe coder aus solchen Erfahrungen tatsächlich lernen.
Das wird sich erst mit der Zeit zeigen.
Ich finde diese Analogie wirklich passend.
So wie ein unter Druck stehender Immobilienmakler hastig an den Leitungen herumrepariert, um ein Haus zu verkaufen, so bauen Startup-Gründer schnell irgendetwas zur Demo zusammen, um Investoren und Kunden anzulocken, und holen später die echten Experten für das Cleanup dazu.
Mit etwas Glück verhindern sie bis dahin noch den großen Unfall.
Ich war überrascht, dass es den Begriff Janitor Engineer schon in der Branche zu geben scheint.
Außerdem waren nach „Why AI code fails at scale“ im Artikel alle weiteren Links kaputt, was mich bei einem so neuen Text zusätzlich gewundert hat.
Ich hoffe übrigens, niemand fühlt sich davon angegriffen.
Seit vibe coding populär geworden ist, habe ich selbst halb im Scherz den Ruhestandsplan, als „all-organic-code“-Berater unterwegs zu sein und von AI erzeugte Codeklumpen auseinanderzunehmen und aufzuräumen.
Wirklich selten sind eher neue Greenfield-Projekte.
vibe coding untergräbt gerade sehr schnell Dokumentation und architektonische Klarheit.
Unternehmen betrachten die Menge erzeugter Code-Tokens und die Geschwindigkeit von Prototypen als die einzig wichtigen Kennzahlen und ignorieren die versteckten Kosten für Wartung und Cleanup.
Die eigentliche Fähigkeit ist jetzt nicht mehr die Generierung, sondern das Aufräumen.
Das wahre Können besteht darin, von Anfang an richtig zu führen, damit am Ende ordentliche Software herauskommt.
Es gibt Leute, die bei Claude Code denken: „Das ist jetzt der neueste Stand der Technik“, aber wenn man es richtig machen will, braucht es viel mehr Beteiligung.
Eigentlich unterscheidet sich das gar nicht so stark von klassischem Engineering.
Es geht darum, Kosten zu minimieren und Anforderungen zu erfüllen.
Wenn Wartbarkeit nicht ausdrücklich gefordert wird, bekommt man eben genau das ursprünglich beabsichtigte Ergebnis.
Warum sollte das das Ende der Dokumentation sein?
Man kann auch erst die Dokumentation schreiben und dann entwickeln, während man später prüft, ob der Code zu dieser Doku passt.
Oder man lässt Dokumentation aus dem Code generieren und überprüft anschließend selbst, ob sie angemessen ist.
Unser Unternehmen macht seit Jahrzehnten Notfallwiederherstellungen für Kundensysteme, wenn es zu kritischen Ausfällen kommt, die schwere finanzielle Schäden verursachen und intern nicht mehr selbst behoben werden können.
In den letzten Jahren hat die Zahl solcher Fälle ziemlich schnell zugenommen.
vibe code ähnelt Legacy-Code in vieler Hinsicht.
Man fühlt sich unsicher dabei, Änderungen vorzunehmen, und sowohl die interne als auch die externe Qualität ist niedrig.
Es gibt aber auch Unterschiede.
Gemessen an seinem Alter ist die Codebasis kleiner, der Termindruck höher und die Erwartungshaltung überzogen.
Am kosteneffizientesten ist es, Fehler nicht erst zur Laufzeit sichtbar werden zu lassen, sondern sie so weit wie möglich in die Design- oder Compile-Time-Phase zu verlagern.
Das Problem ist, dass AI dazu führt, dass alle viel zu schnell bis zur Runtime durchrennen.
Der Artikel „Vibe code is legacy code (val.town)“ ist dazu übrigens lesenswert.
Passender HN-Beitrag
Legacy-Code ist nicht automatisch immer schlecht.
Oft ist er einfach komplex oder schlecht dokumentiert, und über lange Zeit haben sich kleine und große operative Fixes darauf abgelagert.
Viele Betriebsprobleme und neue Anforderungen sind darin bereits verarbeitet, sodass er in echten Produktionsumgebungen oft erstaunlich gut läuft.
Problematisch wird es, wenn niemand mehr da ist, der die Codebasis wirklich kennt, und irgendwann nicht einmal mehr Leute verfügbar sind, die die damals verwendete Sprache oder die Tools beherrschen.
Ich frage mich, ob vibe coding auch in stark typisierten Sprachen funktioniert.
Ich stimme zu, dass man vibe-erzeugten Code ähnlich wie Legacy-Code behandeln kann.
Aber mich würde interessieren, ob Menschen bei vibe code ebenfalls wirklich zögern, Änderungen vorzunehmen.
Ich frage mich, ob LLM-Codegenerierung irgendwann wieder verschwinden könnte.
Der Artikel geht immer davon aus, dass LLM-Code zwangsläufig erzeugt wird und danach immer Cleanup nötig ist; aber wenn die Kosten für LLM plus Cleanup dauerhaft höher sind als ein Entwicklergehalt, müsste man dann nicht am Ende doch wieder dazu zurückkehren, dass Menschen den Code direkt schreiben?
Code mit LLM zu generieren, ihn danach zu prüfen und dann erst zu verwenden, ist etwas anderes als vibe coding.
vibe coding bedeutet, den fertigen Code ohne Prüfung direkt zu verwenden.
Ich glaube allerdings nicht, dass eine der beiden Vorgehensweisen verschwinden wird.
Das heutige AI-basierte vibe coding verliert bereits an Hype.
Warum? Weil bald wieder eine noch bessere AI kommt.
Wenn man den ganzen Tag nur vibe coding betreibt, könnte daraus am Ende ein Kostenmodell werden, das nicht tragfähig ist.
Vielleicht war die Begeisterung aller nur eine Illusion, ausgelöst durch übermäßige Unterstützung und Assistenz, und später kommt dann das schmerzhafte Erwachen.
Der Trend zu Assistenzwerkzeugen für Predictive Completion und automatische Generierung, die auf allen verfügbaren Coding-Beispielen beruhen, wird aber ganz sicher nicht verschwinden.
Früher hat man schließlich auch ohne Syntax Highlighting programmiert, aber heute macht das absichtlich niemand mehr.
Nur weil ich zum 80. Mal etwas wie DFS neu eintippe, steigt mein Selbstwertgefühl als Programmierer dadurch nicht.