Vibe Code ist Legacy Code
(blog.val.town)- Vibe Coding ist eine Methode, bei der mit Hilfe von AI Code intuitiv und schnell geschrieben wird — am Ende bleibt dabei Code zurück, den man nicht versteht, also Legacy Code
- Legacy Code ist Code, den niemand versteht; er verursacht technische Schulden und Wartungsprobleme, und bei neuen Features steigt die Wahrscheinlichkeit für Fehler
- Vibe Coding kann für Prototypen oder kurzfristige Projekte ein schnelles Entwicklungsmittel sein, ist aber für Projekte, die langfristig gewartet werden müssen, ungeeignet
- Wenn Nichtfachleute große Projekte per Vibe Coding umsetzen, besteht ein Risiko, das dem Geben einer Kreditkarte an ein Kind ähnelt
- Auch 2025 ist es bei der Entwicklung mit AI wichtig, Vorsicht und Verständnis zu bewahren
Was ist Vibe Coding?
- Andrej Karpathy definierte den Begriff „Vibe Coding“ als eine Programmierweise, bei der AI den Code schreibt und sich der Nutzer so wenig darum kümmert, dass er die Existenz des Codes selbst fast vergisst
- Dieser Ansatz unterscheidet sich von der traditionellen Softwareentwicklung dadurch, dass Entwickler ein Ergebnis erhalten können, ohne das Innere des geschriebenen Codes überhaupt zu verstehen
Die Probleme von Legacy Code und technische Schulden
- Code, den niemand versteht, ist bereits Legacy Code
- Solcher Code kostet viel Zeit in Wartung und Pflege, und bei Bugs oder dem Hinzufügen neuer Funktionen nehmen die Probleme deutlich zu
- Es wird betont, dass das Wesen des Programmierens nicht darin besteht, viel Code zu erzeugen, sondern konzeptionelle Theorien aufzubauen
Vibe Coding und Prototyping
- Vibe Coding ermöglicht schnellen Einstieg und schnelle Entwicklung bei Prototypen oder Einwegprojekten
- Wenn keine spätere Wartung erforderlich ist, fällt es weniger ins Gewicht, die Interna des Codes nicht zu kennen
- Dadurch steigt die Entwicklungsgeschwindigkeit stark, und neue Ideen lassen sich sehr gut erproben
Das Verständnisspektrum beim Vibe Coding
- Vibe Coding liegt auf einem Spektrum, in dem Entwickler umso mehr „Vibes“ nutzen, je geringer ihr Verständnis des Codes ist
- Grundsätzlich gilt: Je klarer ein Engineer die Anforderungen versteht, desto weniger Vibe Coding findet statt
- Wenn Nichtprogrammierer um Code bitten, ohne den Unterschied zwischen Web- und nativen Apps oder die Art der Datenspeicherung zu kennen, führt das in der Regel zu mehr Vibe Coding
Großes Vibe Coding durch Nichtfachleute: ähnlich wie eine Kreditkarte
- Wenn Nichtfachleute versuchen, große Projekte mit Vibe Coding zu bauen und zu pflegen, ist das ähnlich, als würde man einem Kind ohne jedes Verständnis eine Kreditkarte geben
- Anfangs mag alles einfach wirken, doch später folgen enorme Wartungskosten und Probleme
- Wenn am Ende die „Rechnung“ kommt und die Fähigkeit zur Problemlösung fehlt, kann sich die Lage sogar weiter verschlimmern
Ernsthafte Entwicklung im AI-Zeitalter 2025
- Andrej Karpathy betont, dass bei der Entwicklung mit AI Sorgfalt und Vorsicht sowie die Haltung, kontinuierlich über bestehenden Code zu lernen, unbedingt notwendig sind
- Wichtig ist menschliches Urteilsvermögen, um übertriebenes Selbstvertrauen der AI abzuwehren und guten von schlechtem Code zu unterscheiden
- Man sollte es nicht einfach nur der AI überlassen, sondern den Code unbedingt selbst lesen und verstehen
Einsatz von AI-Tools bei Val Town
- Val Town automatisiert mit dem AI-Assistenten Townie das Schreiben, Ausführen, Prüfen und iterative Verbessern von Code
- Townie ist ein für Vibe Coding geeignetes Tool und kann je nach Einsatzzweck frei genutzt oder streng kontrolliert werden
- Die Entwicklung mit AI verändert sich sehr schnell, und die Bedeutung einer theoretischen Grundlage in der komplexen Softwareentwicklung bleibt auch künftig bestehen
Warnung vor unbedachtem Vibe Coding durch Nichtfachleute
- Es ist keine gute Methode, wenn Nichtprogrammierer Tausende Dollar ausgeben, um eine riesige App-Idee per Vibe Coding umzusetzen
- Letztlich braucht es immer das menschliche Auge, das den Code intern selbst liest und analysiert; statt unverständlichen Legacy Code zu reparieren, ist es oft effektiver, von Grund auf neu und sauber zu entwerfen
Fazit und Ratschlag
- Beim Bau komplexer Software ist eine theoretische Grundlage entscheidend
- Durch die Fortschritte bei AI verändern sich Programmierweisen schnell, doch die Fachkompetenz menschlicher Entwickler bleibt weiterhin wichtig
- Wenn Nichtfachleute mit AI große Apps bauen wollen, kann es am Ende besser sein, den gesamten Code zu lesen und neu zu erstellen
12 Kommentare
Die Metapher ist, als würde man einem Kind eine Kreditkarte geben.
Das ist eine passende Metapher.
Oder man könnte es auch damit vergleichen, einem Kind ein Messer zu geben.
Wenn eine KI zum Generieren von Code aufkommt, die sogar Kommentare ergänzt und Ablaufdiagramme des Codes zeichnet, wäre das bis zu einem gewissen Grad hilfreich.
Dem kann ich ziemlich gut zustimmen. Ich erlebe das zum Teil tatsächlich selbst gerade …
Und zugleich frage ich mich, wie sich dieser Punkt mit den Leistungsänderungen der Modelle weiterentwickeln wird.
Das ist so treffend, dass ich mir zustimmend auf die Knie klopfe und weiterziehe. Menschen, die keinen Code verstehen, sagen beim Vibe-Coding „Wow“, aber Menschen, die Code verstehen, sagen: „Warum? So?“
Der Zustand der Kommentare ist erbärmlich.
Heißt das, man kann ein Auto nie fahren, bis man seine gesamte innere Struktur vollständig verstanden hat?
Ein Auto zu bauen, ohne die innere Struktur zu verstehen = Vibe Coding
Man kann darauf aufspringen. Aber bauen kann man es nicht.
Ich denke, es ist einfach eine Frage von Methode und Technik. Leute, die sagen, man solle KI gar nicht benutzen und stattdessen organisch von Hand coden, wirken auf mich wie Leute, die meinen, statt eines technischen Rechners sollte man lieber den Abakus klappern lassen oder statt Excel-Funktionen alles per Hand aufschreiben – als wäre das die einzig wahre Lehre.
Das ist eine falsche Analogie. Ein wissenschaftlicher Taschenrechner liefert genauso wie ein Taschenrechner oder Excel je nach Eingabewerten exakte Ergebnisse. Wenn KI einfach genau das ausgeben würde, was der Nutzer erwartet, wäre sie wohl keine so grundlegend andere Technologie als die vielen neuen Technologien, die bisher aufgetaucht sind. Das ist auch einer der Gründe, warum die Sorgen über Sicherheit und Halluzinationen mit der Zeit größer werden. Gen AI lässt sich nicht kontrollieren. Man muss die Grenzen heutiger LLMs verstehen und sie an den passenden Stellen einsetzen.
Das Vibe Coding steckt derzeit noch in den Kinderschuhen, aber ich denke, dass es im nächsten oder übernächsten Jahr zu einer ausgereiften Entwicklungsmethodik werden wird. So wie aus DevOps vielleicht AIDevOps wird, glaube ich, dass daraus auch AIAgile oder VibeAgile werden könnte.
Hacker-News-Meinung
Es geht um einen nichttechnischen Freund von mir. Er hat letztes Jahr selbst ein SaaS programmiert und gelauncht und begann fast ohne Marketing nur durch Mundpropaganda und Inbound-Anfragen Einnahmen zu erzielen. Er nutzte dafür Replit und Supabase, und wenn man bedenkt, dass die App mit dem Kundenfeedback immer komplexer wurde, ist das wirklich beeindruckend. Meiner Ansicht nach gab es in diesem Markt zwei etablierte Anbieter, und weil mein Freund ein deutlich moderneres Produkt zu einer viel niedrigeren Monatsgebühr anbot, waren diese wohl nicht gerade begeistert (die bestehenden Produkte waren allesamt Windows-Desktop-Software). Also engagierten sie Hacker, um das SaaS meines Freundes anzugreifen, und diese Hacker attackierten es ohne Geld zu fordern. Leider hatte mein Freund ohne Erfahrung schnell drauflos programmiert, sodass es viele Schwachstellen gab. Erstens war im Frontend-Code eine Benutzerliste offengelegt, sodass die Hacker allen Kunden E-Mails schicken konnten. Zweitens gelangten die Hacker an die Stripe-Schlüssel und erstatteten sämtlichen Kunden ihr Geld zurück. Drittens versuchen die Hacker noch immer XSS-Angriffe, und gelegentlich tauchen in Feldern Tags wie
<script>alert()</script>auf. Mein Fazit ist: Wenn jemand ohne Erfahrung per vibe-coding entwickelt, häufen sich sofort technische Schulden an. Gleichzeitig ist es aber erstaunlich, dass dieser Freund ohne Engineering-Erfahrung in nur wenigen Monaten die Tragfähigkeit eines Produkts beweisen konnte. Inzwischen stellt er Entwickler ein, um die Probleme zu beheben. Er hat mit nur ein paar hundert Dollar Einsatz die Business-Chance eines ziemlich guten Geschäftsmodells mit schlampigem und sicherheitsanfälligem Code nachgewiesen, deshalb denke ich letztlich, dass der Prozess trotzdem wertvoll warIch finde eher, dass die Annahme, die Konkurrenz stecke dahinter, ein Ausweichen vor Verantwortung ist. Wahrscheinlicher ist doch, dass ein automatisierter Schwachstellen-Scanner die Seite entdeckt hat und ein Hacker dann gesehen hat, wie schlecht abgesichert sie ist, und sich einen Spaß daraus gemacht hat. Wer öfter Exploit-Traffic auf internetverbundenen Diensten sieht, weiß, wie häufig so etwas vorkommt
Moralisch ist das in etwa so, als hätte jemand ohne Ingenieurserfahrung ein Haus gebaut und jemand anderes käme vorbei und würde es einfach eintreten und zum Einsturz bringen. Das Problem ist nicht vibe coding an sich, sondern der Mangel an Wissen, das man braucht, um wichtige Entscheidungen zu treffen. Solche Probleme können sogar in Fragen rechtlicher Haftung münden
Wenn es bereits etablierte Anbieter auf dem Markt gab, brauchte man dann wirklich so ein MVP, um die Tragfähigkeit zu belegen? Im Kern muss man nicht testen, ob Leute vom bestehenden Anbieter wechseln, wenn man es einfach billiger anbietet. Die Lektion für deinen Freund ist eher, dass einige Kunden anfangs zwar zahlen werden (ohne Daten zur Wiederkaufsrate), er aber letztlich Leute einstellen muss, um ein echtes Produkt zu bauen, und dann auch den Preisvorteil verliert. Sobald ernsthafte Marketingausgaben anstehen, wird das noch schwieriger. Am Ende bestätigt sich wieder nur, dass Ideen an sich wertlos sind und es auf die Fähigkeit zur Umsetzung ankommt
Dass dein Freund das Geschäft offenbar ohne nennenswerte Konsequenzen weiterführen kann, ist das eigentliche Grundproblem dieser Branche. In einer Welt, in der Software so streng reguliert wäre wie andere Ingenieurdisziplinen, müssten Entwickler oder Unternehmen für das Offenlegen von Kundendaten zwangsläufig rechtlich haften
Selbst wenn das Geschäft für sich betrachtet validiert wurde, kann es aus Kundensicht eher ein Verlustgeschäft sein. Sie zahlen Geld und setzen gleichzeitig wichtige Daten einer unsicheren Umgebung aus, während noch nicht einmal klar ist, ob das Produkt zuverlässig funktioniert. Jetzt sollen Entwickler eingestellt werden, um das zu reparieren, aber das wird vermutlich nicht so einfach sein, wie es klingt. Ich bin dafür, AI für Lernmaterial, Produktivität oder als Lernwerkzeug zu verwenden, aber ohne Menschen im Loop kann dabei etwas Schreckliches entstehen
Auch früher haben Nichtentwickler oder Junior-Entwickler immer wieder mit Microsoft Access, Excel und Ähnlichem relativ leicht Anwendungen gebaut und ausgerollt. Damals gab es ebenfalls Grenzen, Skalierungsprobleme und Verwaltungsalbträume, aber zugleich hat genau diese Entwicklung professionelle Entwickler dazu angetrieben, bessere Lösungen zu bauen. Beim Aufkommen des PCs war es ähnlich: Mainframe-Entwickler waren entsetzt über den „Wildwuchs“-Code aus der PC-Welt
Ich arbeite seit fast dreißig Jahren als Softwareingenieur und habe alle Kommentare unter diesem Beitrag gelesen. Und ich denke, dass fast alle Argumente gegen vibe coding genauso auf praktisch jede von Menschen geschriebene Codebasis zutreffen, die ich in dieser Zeit gesehen habe (natürlich mit Ausnahmen)
Ich verstehe nicht, was an einem zum Wegwerfen gedachten Prototyp schlecht sein soll. Das ist einer der wichtigsten Schritte beim Start eines Geschäfts. Für Legacy-Code gilt im Grunde dasselbe. Der größte Teil von Code, der tatsächlich Umsatz erzeugt, wird von den Entwicklern in der jeweiligen Organisation mit hoher Wahrscheinlichkeit bereits als Legacy betrachtet
Es gibt ja auch den Witz, dass alles in dem Moment Legacy-Code wird, in dem es in den trunk gemergt wird
Ich stimme teilweise zu, aber das Problem bei vibe coding ist, dass es dazu verführt, völlig planlos vorzugehen, ohne sauber zu recherchieren, ohne die Struktur der bestehenden Codebasis zu verstehen und ohne zu untersuchen, welche Lösung eigentlich gebraucht wird. Erst gestern hat ein Kollege, der Rust nicht gut kennt, per vibe coding ein neues Feature gebaut. Oberflächlich „funktioniert“ es, tatsächlich ist es aber ein riesiges Durcheinander (synchrones I/O im tokio-async-Kontext, Locks, selbstgebastelte Channel-Implementierung usw.). Obwohl es bereits sichere asynchrone Abstraktionen gibt, hat er neue und dazu noch falsche Abstraktionen eingeführt. Hätte er selbst recherchiert oder vorher um Hilfe gebeten, hätte er sich an Beispielen im bestehenden Code orientieren können
Jeder Code wird irgendwann Legacy-Code. Wenn ich an meine Zeit als Junior denke und an die vielen Produktionsskripte und Service-Codes, die ich von anderen Junioren reviewt habe, ist diese absolute Sichtweise viel zu extrem. Das Problem wiederholt sich in den meisten Organisationen. Ich verstehe auch, warum Leute Texte schreiben, die die Qualität von LLM-basiertem Code kritisieren, aber wer im Lauf seiner Karriere ständig Systeme anderer Leute repariert, erweitert oder refaktoriert hat, kennt diese Realität nur zu gut. Solange in der Softwareentwicklung nicht so strenge Standards für Konsistenz, Zertifizierung, Verantwortung und echte Resultate eingeführt werden wie im Maschinenbau, ist diese Debatte nur begrenzt sinnvoll. Die moderne IT-Industrie beruht ja geradezu auf der entgegengesetzten Philosophie: „agile“, „schnell bauen und es ist egal, wenn etwas kaputtgeht“. Schnell, mit wenig Design, häufig deployen, und wenn etwas schiefgeht, eben zurückrollen, und bei Ausfällen heißt es dann „kann man nichts machen“. Software wird wie ein Spielzeug behandelt. Vielleicht behauptet 1 %, es richtig zu machen, aber die meisten tun es nicht
Gerade passiert etwas Interessantes. Menschen, die wenig von Engineering verstehen, und teilweise auch solche, die es eigentlich besser wissen, es aber nicht sauber erklären, verbreiten online ein falsches Narrativ. Sie behaupten jetzt, Junior-Entwickler seien zehnmal produktiver und sogar PMs würden selbst Code deployen. Aber wenn man kurz die Augen schließt und sich den Code aus so einer Situation vorstellt, dann ist das zu 100 % Legacy-Code und Wegwerf-Code. Der Kern des Problems ist nicht, dass AI oder PMs direkt aus Figma Code herausziehen können oder dass Junioren wahllos Prompts abfeuern. Der eigentliche Grund für die Diskrepanz zwischen Erwartung und Realität ist, dass Begriffe und Konzepte, die ursprünglich über Jahre hinweg diskutiert und definiert wurden, nicht mehr sauber unterschieden werden.
Ein Lean-Prototyp und ein disposable Prototyp (nicht einmal ein MVP) sind nicht dasselbe. Ein MVP kann man erst nach einer erfolgreichen Validierung mit einem Lean-Prototyp bauen. Und ein Produkt ist wiederum etwas anderes als ein MVP.
Vibe-coding-Tools sind hervorragend dafür geeignet, disposable Prototypen schnell zu bauen, während IDEs mit LLMs besser zum Bau echter Produkte passen. Im jetzigen Stadium sind nur echte Ingenieure in der Lage, mit LLM-Prompts einen Lean-Prototyp zu programmieren; alle anderen bauen nur einfache Software, die auf disposable Code läuft
Bei „Ein Produkt ist etwas anderes als ein MVP“ würde ich das am liebsten fast allen Firmen sagen, bei denen ich gearbeitet habe. Inzwischen ist die Haltung in Vorständen und auf C-Level weit verbreitet, einfach „bis zum Quartalsende irgendetwas rauszubringen“, sodass Entwickler ein MVP bauen und dann sofort zum nächsten Projekt weiterziehen. Ganz unabhängig davon, ob es wirklich vibe coding ist oder nicht: In der Realität steigen die Business-Metriken schon dann, wenn etwas funktionsreich aussieht, egal wie es um die tatsächliche Qualität steht. Umgebungen, in denen echte Ingenieure (so nennt man offenbar inzwischen „Entwickler“) eigenständig Prototypen vorantreiben, sind ohnehin selten. Das sieht man vielleicht in Games oder in manchen Tech-Unternehmen. Die meisten konzentrieren sich ausschließlich auf das Bauen von MVPs. Vibe coding beschleunigt lediglich die Massenproduktion von MVPs, während die Qualität entsprechend geopfert wird
Diese Tendenz, Begriffe ohne Substanz durcheinanderzuwerfen, hat in der Branche in den letzten zehn Jahren sichtbar zugenommen. Diese Wörter tragen eigentlich den Kontext zahlloser Bücher, Diskussionen und langjähriger Debatten in sich. Wenn ein erfahrener Entwickler ein bestimmtes Wort benutzte, schwang darin der ganze Erfahrungshintergrund mit. Neue Mitarbeitende übernehmen diese Begriffe jedoch oft nur oberflächlich, ohne den Kontext und ohne überhaupt eine Definition. Am Ende weiß niemand mehr, was die Begriffe ursprünglich meinten oder warum genau dieses Wort zur jeweiligen Situation passt. Beispiele wären "agile", "technical debt", "DevOps" und zuletzt eben „vibe coding“. Auf HN gab es auch einen Beitrag über semantic drift. Das ist in der Softwarebranche ein häufiges Phänomen.
Ein technisches Beispiel wäre, dass in JavaScript 'object', 'JSON', 'dictionary' und 'hashmap' ständig vermischt werden. Ursprünglich bedeuten sie unterschiedliche Dinge, aber für JS-Entwickler läuft oft alles einfach unter „object“. Sprachlich und konzeptionell wird die Auflösung damit auf einen einzigen „Pixel“ reduziert
Früher haben Entwickler untereinander darüber gesprochen, dass sie jeweils eine bestimmte „Haltung“ zum Code haben. Heute ist die Ermüdung unter Entwicklern massiv gestiegen, weil niemand den Code mehr versteht. Früher griff in so einer Situation ein Ingenieur ein und machte kaputte Teile wieder brauchbar, oder ein Architekt reduzierte die Komplexität. Im Zeitalter der LLMs strömt nun hundertmal mehr Code herein, während Ingenieure und Architekten aus diesem Prozess faktisch ausgeschlossen werden. Das ist die Realität, die wir gerade direkt erleben.
Wenn jemand eine Testmethode erfindet, die dieses Problem löst (TDD MCP server, DDD MCP server oder irgendein Workflow bzw. irgendeine Architektur), dann steckt darin ein Startup im Billionenbereich. Wir brauchen dringend Werkzeuge, die Code Reviews massiv effizienter und skalierbarer machen
Ich denke, man muss erst einmal klarer definieren, was „funktionierende Software“ überhaupt bedeutet. Zum Beispiel sehen UIs aus LLMs alle gleich aus und enthalten oft subtile Fehler oder versteckte Probleme. Schon ein einziger User-Test deckt das sofort auf. Außerdem klammert sich generierte UI oft nur an aktuelle Trends, ohne wirklich etwas Neues hervorzubringen
Hast du schon einmal gesehen, wie interner Code in großen Unternehmen geschrieben wird? Das unterscheidet sich kaum von vibe coding. Wenn man ein LLM wenigstens darauf trimmt, einen Pentest zu bestehen, versucht es wenigstens noch etwas. Großunternehmen interessiert das oft nicht einmal
Eigentlich ist jeder Code Legacy. Deshalb ist es nichts Besonderes, wenn vibe coding schnell viel Code produziert. Am Ende ist auch „mein eigener Code“, den niemand versteht, genauso chaotisch. Aus Sicht der Wartung ist jeder Code letztlich Ballast. Bibliotheken können die Last nur verringern, aber wenn sie sich häufig ändern oder ihre Schnittstellen veraltet sind, werden sie zu noch schlimmerem Legacy-Ballast.
Wer lange genug Code schreibt, kommt am Ende meist zu derselben Erkenntnis: Die eigentliche Lösung ist, weniger zu bauen, also den Gesamtbedarf zu reduzieren. Jede Komplexität wird irgendwann zu einem „Problem, an das sich mein zukünftiges Ich nicht mehr erinnern wird“. In Wahrheit ändern sich Anforderungen ohnehin ständig, und selbst Anforderungen von Experten können falsch sein (und dieser „Experte“ kann man selbst sein)
Der Behauptung „jeder Code ist Legacy“ stimme ich nicht zu. Ein Teil davon ist klein genug, dass der Entwickler noch alles komplett im Kopf hat und der Code damit vollständig „live“ ist. Die eigentliche Definition von Legacy ist doch: groß, und in der Organisation gibt es niemanden mehr, der es wirklich besitzt. Vibe-Code erfüllt diese beiden Bedingungen praktisch schon im Moment seiner Entstehung
Legacy bedeutet, dass es keine Stakeholder mehr gibt und es dadurch schwierig geworden ist, den Code zu warten oder seinen Kontext zu verstehen
Ich möchte Probleme mit so wenig Code wie möglich lösen. Entscheidend ist, dass der Code möglichst nicht mein Problem wird. Es kommt darauf an, wie stark Abstraktionen „leaken“, und die Abstraktionen, die LLMs derzeit erzeugen, sind sehr schlecht. Wie sehr sich das in Zukunft verbessert, ist unklar.
Ich würde lieber in Werkzeuge investieren, die Codeverständnis interessanter, einfacher und billiger machen. Mein Freund Glen hat dazu vielleicht ein interessantes Projekt: https://glench.github.io/fuzzyset.js/ui/
Wie Geoffrey Litt sagt, könnten LLMs viel nützlicher dafür sein, temporäre Visualisierungstools, Debugger und Ähnliches zu bauen, die uns beim Verstehen unseres Codes helfen
Jeder Code birgt Risiken, aber nicht jeder ist Legacy. Bei vibe-coded Code fühlt es sich eher so an, als würde er sofort zu Legacy, weil ihm von Anfang an Kontext und Eigentümer fehlen
Als Einwand gegen „jeder Code ist Legacy“ würde ich sagen: Wenn ich in einem Projekt, das ich wirklich tief verstehe, die Ursache eines Bugs sofort erkennen und die Implementierung eines neuen Features im Kopf entwerfen kann, dann ist das kein Legacy-Code
Ich glaube, die Zeit, in der man „Code mathematisch betrachtet“, ist vorbei. Ausreichend große Software, die mit der realen Welt verbunden ist, kann nicht wie ein mathematischer Beweis garantiert wahr sein. Systeme in der Realität sind technische Artefakte, die auf formalen Garantien, erfahrungsbasierter Gestaltung, experimentellen Tests, Know-how und Performance-Kriterien beruhen.
Diese Tendenz wird sich bis hin zu den kleinsten Skripten ausdehnen. Die meiste Software muss gar nicht mathematisch bewiesen werden. Sie muss einfach nur ihren Zweck erfüllen. Ich schätze das handwerkliche Können des Programmierens sehr, aber ich denke, wir müssen diesen Teil langsam loslassen.
Am Ende läuft die Zukunft wohl auf zwei Optionen hinaus
ein Programm mit 100.000 Zeilen und 50.000 Tests, das alle Anforderungen garantiert, aber für niemanden gut lesbar ist, Gesamtkosten 50.000 Dollar (API-Token-Kosten)
von Menschen direkt entworfen, 30.000 Zeilen, 3.000 Tests, elegante Abstraktionen, dieselben Anforderungen erfüllt, Gesamtkosten 300.000 Dollar (Entwicklergehälter)
Wenn ich Softwarekunde wäre und mich für die Details nicht interessieren würde, sondern nur für den Preis, würde ich natürlich die Variante wählen, die sechsmal billiger ist
Man muss an den Moment denken, in dem eine neue externe Anforderung Änderungen erzwingt. Wenn diese Software in so einem Fall geschäftskritisch ist, bleibt einem am Ende nur der Wechsel des Anbieters. Deshalb sind Wartung und Support sowohl im B2B- als auch im B2C-Bereich unverzichtbar. Software muss immer in der Lage sein, sich an Veränderungen anzupassen
Daher auch der Witz: „Diesen Code haben nur ich und Copilot verstanden. Jetzt versteht ihn nur noch Copilot“
Bei der Aussage „ausreichend große, mit der realen Welt verbundene Systeme lassen sich nicht mathematisch als korrekt beweisen“ würden Leute aus der formalen Verifikation vermutlich heftig widersprechen oder innerlich doch zustimmen
Zwischen den beiden Szenarien müsste man fragen, welches beim nächsten Upgrade billiger und schneller ist. Im Moment denke ich noch, dass das Modell mit menschlichen Entwicklern günstiger ist, aber für die Zukunft bin ich mir nicht sicher
Tatsächlich habe ich in der Praxis fast nie eines dieser beiden Modelle gesehen
Die ultimative Entwicklungsstufe wäre vielleicht eine vollständig maschinenorientierte Programmiersprache, die Menschen überhaupt nicht mehr lesen müssen. Warum sollte ein LLM überhaupt noch in für Menschen gut lesbare Sprachen wie Python oder Swift übersetzen? Wenn am Ende nur direkt lauffähiges Verhalten zählt, verliert auch das Konzept der Wartbarkeit an Bedeutung. So weit sind wir noch nicht, aber vielleicht geht die Reise irgendwann dorthin
Gute Software ist immer in Wartung. Es kommen ständig neue Anforderungen hinzu, daher ist schon die Vorstellung lächerlich, man könne ein Feature einmal deployen und dann sei es für immer erledigt. Deshalb sind Code, Tests und Dokumentation wichtig, die zukünftige Änderungen mitdenken. Wenn LLMs bedeutungslosen Blackbox-Code in Massen erzeugen, gibt es kaum etwas Beängstigenderes. Dass LLMs menschliches Programmieren so vollständig erreichen, dass sich niemand mehr darum kümmern muss, gehört eher in den Bereich Science-Fiction. Coding ist nur ein Teil des gesamten Prozesses, tatsächlich nützliche Software zu schaffen
Ist Maschinensprache nicht im Grunde schon so etwas? LLMs sind auf für Menschen lesbare Interfaces optimiert, deshalb erzeugen sie JSON und kaum BSON
Ich frage mich ernsthaft, welches Problem das überhaupt lösen soll. Welche Probleme es erzeugen würde, ist dagegen ziemlich klar
Es fühlt sich ein bisschen an wie Stille Post: LLMs lernen von für Menschen geschriebenem Code, bekommen wieder Code als Eingabe und erzeugen daraus erneut Code, um das gewünschte Verhalten zu erhalten. Da fragt man sich schon, ob sie nicht direkt das Verhalten selbst erzeugen könnten
Wenn es um für Menschen schwer lesbare Sprachen geht, ist Malbolge das klassische Beispiel. Das erste echte "Hello World"-Programm dafür wurde sogar per genetischem Algorithmus erzeugt
Ich bin der ursprüngliche Autor. Ich freue mich auf die Diskussion mit euch
Der Begriff „vibe coding“ ist einfach zu perfekt. So ähnlich wie „Cloud Computing“ irgendwann völlig überdehnt wurde. Ursprünglich meinte das, elastisch EC2-Instanzen hochzufahren und nach Abschluss der Arbeit wieder zu verwerfen, aber die Metapher war so eingängig, dass am Ende sogar Gmail pauschal als „Cloud“ bezeichnet wurde.