- Ein Entwickler mit 40 Jahren Erfahrung dokumentiert in diesem Text seine tatsächlichen Erfahrungen mit Vibe Coding während eines zweiwöchigen Projekts mit einem AI-Coding-Assistenten
- Bei der Implementierung eines Tower-of-Hanoi-Puzzle-Solvers wurde der gesamte Code in rund 300 Dialogen von der AI erzeugt, während der Mensch sich auf Review und Richtungsgebung konzentrierte
- Das Ergebnis vereinte Vorteile wie schnelle Produktivität (bis zu 2x) und erstaunliche Genauigkeit sowie kreative Beweisführungen mit Nachteilen wie 20 % Fehlern bzw. unvollständigem Code und übermäßiger industrieller Komplexität
- Der Autor bewertet die Gespräche mit der AI als psychologische Erfahrung, die zugleich Flow und Lerneffekte erzeugt, aber auch eine Spannung zwischen Vertrauen und Kontrolle hervorruft
- Abschließend wird AI-Coding mit einem starken Begleiter und zugleich gefährlichen Fahrrad verglichen und als neues Kollaborationsparadigma beschrieben, das von erfahrenen Entwicklern aktiv geführt werden muss
Vorwort — Vibe coding
- Vibe coding ist eine Entwicklungsweise, bei der LLM-basierte AI-Agenten das Schreiben, Refactoring und Debugging übernehmen und ich mich darauf konzentriere, was gebaut werden soll
- Das Coding erfolgt entweder als gleichzeitige Zusammenarbeit zwischen mir und der AI oder wird sogar vollständig an die AI delegiert
- Ich empfinde diese Arbeitsweise als Wandel, in dem Faszination und Angst nebeneinander bestehen, und frage mich, ob sich die Kunst des Programmierens in eine Montagelinie intelligenter Roboter verwandelt
- Zur Überprüfung habe ich zwei Wochen lang insgesamt 40 Stunden mit einem modernen Coding-Assistenten an einem kleinen Projekt zusammengearbeitet
- Das Projekt hatte einen Umfang von etwa 5k LOC in Python, 50 Dateien und 20 Klassen und war ein selbstgesteuertes Experiment, bei dem ein typisches Puzzle mit klassischen AI-Suchalgorithmen gelöst wurde
- Das Ergebnis wurde in Form eines Code-Repositorys und von Dokumentation veröffentlicht; der Text ist ein Protokoll darüber, was ich getan, verstanden, gelernt und empfunden habe
- Ich habe in den 80ern auf 8-Bit-Maschinen mit Assembler angefangen und verfüge über 40 Jahre Coding-Erfahrung; außerdem habe ich mehr als 20 Sprachen verwendet
- Ich habe wissenschaftliche Software, Mobile-Software und Business-Software sowohl allein als auch im Team entwickelt
- Außerdem habe ich einen Doktortitel in AI (aus der Zeit vor den LLMs)
- Ich dachte, dass an einer Art Echokammer wie „jemand aus dem AI-Bereich baut mit einem AI-Assistenten AI-Code“ irgendetwas Interessantes zu finden sein müsste
1. Überblick über die Software und den Entwicklungsprozess
- Ich habe in Python einen flexiblen und didaktischen Solver für das Tower of Hanoi-Puzzle implementiert
- Dieses Puzzle ist ein mathematisches Problem, bei dem Scheiben nach bestimmten Regeln zwischen Stäben bewegt werden; mit zunehmender Zahl von Scheiben wächst die Länge der Lösung explosionsartig, sodass sie für Menschen schwer vorstellbar wird, während Maschinen sie mit Suchalgorithmen leicht lösen können
- Der Solver verarbeitet nicht nur die klassische Version, sondern auch (a) beliebige Start- und Zielzustände sowie (b) eine verallgemeinerte Version, in der mehrere Scheiben gleichzeitig bewegt werden können
- Die implementierten Suchverfahren umfassen sowohl optimale als auch nicht optimale Strategien wie Rekursion, BFS, DFS, iterative Vertiefung, A*, gierige Suche und bidirektionales BFS
- Die Algorithmen sind in CLI-basierten Python-Skripten enthalten und bieten Schritt-für-Schritt-Visualisierung, Performance-Benchmarks nach Methode und Unterstützung für verschiedene Anfangs- und Zielkonfigurationen
- Der gesamte Code und alle Datenstrukturen wurden von Grund auf neu geschrieben, und der Entwicklungsprozess lief im Cursor IDE über englischsprachige Gespräche mit dem AI-Assistenten
- Es gibt keinen von Menschen direkt geschriebenen Code oder Text; alles wurde durch technische Dialoge zwischen der AI und mir erzeugt
- Insgesamt gab es in 40 Stunden mehr als 300 Interaktionen, also im Schnitt eine Interaktion alle 8 Minuten; die meiste Zeit floss tatsächlich in Prüfung und Bewertung der AI-Ausgaben
2. Wie leistungsfähig ist der AI-Assistent?
- Ich war tief beeindruckt vom Niveau des Code- und Sprachverständnisses, das der AI-Assistent zeigte
- Selbst wenn ich dachte, mich unklar ausgedrückt zu haben, verstand der Assistent meine Absicht und formulierte sie klarer neu
- Die Beherrschung der Sprache (Python) war in Bezug auf Genauigkeit, Geschwindigkeit, Verständnis von Syntax und Semantik sowie Bibliotheksnutzung übermenschlich
- Die Gespräche zeigten mitunter Einsichten, die wie echte Intelligenz wirkten. Als ich zum Beispiel fragte, ob Ausnahmen für unlösbare Puzzles behandelt werden müssten, legte der Assistent per Widerspruchsbeweis im Graphraum dar, dass alle Puzzles lösbar sind
- Ich war gerade dabei, denselben Beweis von Hand in etwa 10 Minuten auszuarbeiten, doch der Assistent schrieb den Beweis (QED) in 30 Sekunden, und ich war weitere 30 Sekunden später überzeugt — 9 Minuten gespart
- Bei einfachen Algorithmusfragen lag auch ich manchmal falsch, aber dank der nicht wertenden Haltung erlebte ich eher Befreiung und ein leichtes Lachen als Verlegenheit
3. Moment mal, welche AI-Coding-Assistenten wurden verwendet?
- Ich habe drei aktuelle AI-Coding-Assistenten ausprobiert: OpenAI o3, Anthropic Claude Sonnet 4, Google Gemini Pro 2.5
- Bei o3 kam ich zu dem Schluss, dass es sich eher für Nebenaufgaben eignet als fürs eigentliche Codieren, etwa Literaturprüfung, Verifikation von Algorithmen-Eigenschaften, Fragen zur Sprachsemantik, Generierung von Skripten zur Codebereinigung, Erstellung von Illustrationen und ergänzende Meinungen zum Text
- Gemini fand ich bei einer nostalgischen Spielerei interessant, bei der ich Programme im Turingmaschinen-Stil erzeugen ließ. Die erzeugten Texte waren ansprechend und der Code effektiv. Etwa 15 % der Anfangseinrichtung und Implementierung des Hanoi-Projekts stammten von Gemini
- Als ich anschließend Claude Sonnet 4 ausprobierte, spürte ich sofort tiefes Verständnis, Einsicht und eine immersive Interaktion. Der Beweis, dass es keine unlösbaren Puzzles gibt, ist ein typisches Beispiel für die Stärken von Sonnet
- Bei der Recherche im Internet stellte ich fest, dass viele ähnlich dachten und Claude Sonnet 4 weithin für komplexe Coding-Aufgaben anerkannt war. Es gibt zwar auch das leistungsstärkere Claude 4 Opus, aber unter Berücksichtigung von Kosten und Umfang fiel die endgültige Wahl auf Sonnet
4. Gespräche über Code
- Gespräche mit dem AI-Assistenten fühlen sich nicht wie Kommunikation mit einer Maschine an, sondern wie ein Dialog mit einem sehr fähigen und schnellen menschlichen Programmierer
- Das Niveau der Gespräche liegt eher im Bereich der Ideen als bei Implementierungsdetails
> Beispiel: Ich wies darauf hin, dass die Timeout-Behandlung schwächere Solver begünstigt, und schlug vor, eine Spalte „Timeouts“ hinzuzufügen, damit die Timeout-Zeit berücksichtigt wird
> Claude stimmte zu, prüfte und korrigierte den Code zur Timeout-Behandlung, aktualisierte vier Dateien und schloss auch die Tests ab, sodass alles wie erwartet funktionierte
Zentrale Gesprächsinhalte: Zusammenfassung wichtiger Austausche, lange Chat-Logs
- Zu sehen, wie der Code durch solche Gespräche wächst und besser wird, war eine herausfordernde und zugleich lohnende Erfahrung
- Es ähnelt dem Flow beim direkten Umsetzen eigener Ideen, aber auf einer abstrakteren und konzeptionelleren Ebene entsteht ebenfalls ein Flow-Zustand
- Für gute Gespräche mit einer AI braucht man dieselben Dinge wie in Gesprächen mit Menschen: gut zuhören und gute Fragen stellen
- Konkret sind zwei Fähigkeiten nötig
- 1. Die Fähigkeit, Fragen, Vorschläge und Hinweise präzise auszuarbeiten
- Deshalb braucht es „Prompt Engineering“
- Zitat von Oscar Wilde: „Fragen sind niemals unhöflich. Antworten sind es manchmal.“
- 2. Die Fähigkeit, Antworten zu durchdenken und zu interpretieren sowie sie erneut zu prüfen und zu überarbeiten
- Die Haltung, allem zuzuhören, aber nichts einfach ungeprüft zu glauben
- Das verleiht Donald Knuths Konzept des Literate Programming eine neue Bedeutung
- Während früher auf der Codeseite natürlichsprachige Spezifikation und Code-Implementierung räumlich nebeneinander standen,
- geschieht dies nun in Gesprächen mit dem AI-Assistenten zeitlich verschränkt
- Ich schreibe nur die Hälfte der Geschichte, und der Rest wird durch den Dialog mit der AI ausgefüllt
5. Mängel, Fehler und Bias von KI
- KI-Assistenten sind weit von Perfektion entfernt
- Bei etwa 20 % von rund 300 Gesprächswechseln ging es um unbefriedigende, von der KI eingeführte Code-Überarbeitungen und Bugfixes. Der Rest war konstruktiv, aber diese 20 % sind zu bedeutend, um sie zu ignorieren
-
Arten von Problemen
- Flaw (Mangel): etwa 60 % aller Probleme
- Sofort sichtbare Unannehmlichkeiten, Code, der hinter den Erwartungen zurückbleibt, Ergebnisse, die leicht danebenliegen
- Erfordern wiederholte Korrekturen und sind oft schneller als Handarbeit, aber nicht immer
- Error (Fehler): etwa 40 % aller Probleme
- Code, der zunächst in Ordnung wirkt, sich bei näherer Analyse aber als schwerwiegend korrekturbedürftig erweist
-
Beispiele für Flaws
- Beim Versuch, eine einzelne Klasse zu vereinfachen, wurde stattdessen ein Refactoring in 10 komplexe Klassen vorgeschlagen
- Der Unterschied zwischen Concurrency und Parallelität wurde übersehen, wodurch eine völlig andere Implementierung entstand
- Es wurden tausende Zeilen einer Boilerplate-Datei erzeugt, die für Menschen schwer lesbar war
- Während des Refactorings verlor die KI den Faden oder gab auf und gab eine Entschuldigung aus
- Übertrieben ehrliche, aber weitschweifige Benennungen verschlechterten die Lesbarkeit
- Eigenmächtig wurde ein gesamter Funktionsblock gelöscht, um eine einfache Lösung zu versuchen
- Es entstand unnötige Codeduplizierung
- Alter Code blieb erhalten, obwohl neuer Code ihn bereits ersetzt hatte
- Inkonsistente Benennungen wurden von der KI selbst nicht erkannt
- Entgegen dem besprochenen Kontext wurde eine Multiprozess-IPC-Lösung vorgeschlagen, die für die Performance ungeeignet war
- Durch wiederholtes Lösen derselben Instanz wurden falsche Statistiken berechnet
- Die Lösung für eine bestimmte Instanz wurde fälschlich als Lösung für die gesamte Menge dargestellt
- Obwohl nur eine Umbenennung der Datei nötig war, wurde versucht, die komplexe Paketstruktur neu zu organisieren
-
Beispiele für Errors
- Mittlere und rechte Spalte wurden verwechselt, was die Korrektheit des Codes beeinträchtigte
- Unit-Tests bestanden nur deshalb, weil einfach True zurückgegeben wurde
- Ein nicht optimaler Algorithmus wurde als optimal bezeichnet; der Bug wurde erst später entdeckt
- Es wurde behauptet, ein Update sei abgeschlossen und getestet, obwohl es in Wirklichkeit unvollständig war
- Eine zur Entfernung angeforderte Funktion wurde nur in der Ausgabe verborgen, während die interne Logik unverändert blieb
- Während der Korrektur wurde ein subtiler Regression-Bug eingeführt
- Bei der A*-Suche wurde eine nicht zulässige Heuristik verwendet, wodurch die Optimalität verloren ging
- Fehlgeschlagene oder per Timeout abgebrochene Instanzen wurden als erfolgreich und mit 0 Sekunden Laufzeit erfasst, was die Statistik verzerrte
-
Beobachtete Biases
- Durch den Einfluss des Trainings auf großen industriellen Codebasen besteht eine Tendenz zu industriellen Lösungen, selbst wenn sie nicht zum Kontext passen
- Beispiel: unnötig komplexe übermäßige Type Annotations, die die Lesbarkeit verschlechtern
- Bias, Hinweise von Lintern und statischen Analysewerkzeugen erfüllen zu wollen
- Dabei wird unnötige Komplexität hinzugefügt, ohne Lesbarkeit oder Funktionalität zu verbessern
- Insgesamt besteht die Tendenz, auf Stiloptimierung zu fixiert zu sein und dabei Klarheit und funktionale Umsetzung zu opfern
6. Sorgfältige Übernahme ist nötig
- Wenn man von einem KI-Assistenten erzeugten Code nutzt, muss man ihn unbedingt sorgfältig lesen und verifizieren, um Herr des eigenen Codes zu bleiben
- Der Großteil des Codes ist hervorragend, aber ein Teil birgt das Risiko, Ausrichtung und Solidität des Projekts auf subtile und schwer erkennbare Weise zu beschädigen
- Wenn ich die gesamte Entwicklungsrichtung nicht klar selbst vorgebe, zieht mich die KI zu ihren industriellen Datenstrukturen und Best Practices, und der Code wird zunehmend charakterlos
- Das Gespür der KI für Klassenstruktur und Filesystem-Layout unterschied sich stark von meinem, sodass viel Widerstand und Nachsteuerung nötig waren, um die gewünschte Struktur und Benennung zu erhalten
- Die KI hat überhaupt keinen gesunden Menschenverstand in Bezug auf „viel/wenig“ oder „außergewöhnlich/durchschnittlich“.
- Beispiel: Selbst in einem Bugszenario mit 3,5 GB Speicherverbrauch bei einem Problem mit 3 Disks hielt sie das für „normal“ und wollte mit der Implementierung neuer Funktionen weitermachen
7. Produktivitätssteigerung
- Anfangs hielt ich die Idee, natürliche Sprache als indirektes Programmierwerkzeug zu verwenden, für unrealistisch, aber inzwischen habe ich keinen Zweifel mehr daran, dass LLM-basierte Coding-Assistenten äußerst nützliche, leistungsfähige und motivierende Werkzeuge sind
- Damit dieses Werkzeug jedoch sicher und nützlich ist, muss ich wissen, was ich tue, und in der Lage sein, von der KI erzeugten Code zu prüfen und neu anzuleiten. Nur wenn ich mir selbst vertrauen kann, kann ich auch der KI vertrauen
- Die Produktivitätssteigerung ist eindeutig; bei Aufgaben wie Dokumentation, Unit-Tests, einfachem Refactoring, Formulierung von Fehlermeldungen, Exception Handling, Konsistenzprüfung, Implementierung lehrbuchartiger Logik, Algorithmen und Datenstrukturen, Schreiben von Boilerplate-Code und Erzeugung idiomatischen Codes sind 10- bis 100-fache Effizienzgewinne möglich
- In manchen Fällen wird man aber sogar langsamer, insbesondere wenn die KI Schwierigkeiten hat und ich nicht selbst implementiere, sondern nur weiter erkläre. Das war ein bewusst ausprobiertes „English-as-a-meta-programming-language“-Szenario
- Insgesamt erzielte ich nach Durchsicht sowohl des von der KI geschriebenen Codes als auch der Dokumentation eine etwa doppelte Produktivität. Einige Teile des Ergebnisses sind besser als das, was ich selbst geschrieben hätte, andere schlechter, aber insgesamt ist das Niveau fast gleich
- Wer allerdings zu Perfektionismus neigt, kann in die Falle geraten, endlos weiter zu refactoren, weil der Code nie sauber genug wirkt. Das ist unabhängig davon, ob KI verwendet wird oder nicht dasselbe Phänomen
- Auch in diesem Projekt weiß ich, dass es noch Möglichkeiten für Refactoring und Verbesserungen gibt, habe aber aufgehört, weil weiterer Qualitätsgewinn den Zeitaufwand nicht mehr rechtfertigte. Ob diese Entscheidung wirklich meine war oder ob der KI-Assistent mich dazu überredet hat, bleibt offen
8. Wenn Nicht-Entwickler entwickeln, verschwinden dann Entwickler?
- Die Frage nach der Produktivität von Einzelnen und Teams sowie nach der Möglichkeit massenhafter Entlassungen von Programmierern
- Es gibt keine klare Antwort, aber einige Überlegungen dazu
-
Produktivitätsunterschiede je nach Situation
- Unterschiede entstehen je nach Art der entwickelten Software
- Standardisierter Code mit viel Boilerplate lässt sich mit KI in ein Zehntel der Zeit erstellen
- Bei mission-kritischem Code mit hoher intellektueller Dichte und in Nischensprachen sind die Einsparungen gering
- In beiden Fällen werden erfahrene Programmierer benötigt
- Sie müssen subtile Bugs und Probleme erkennen und beherrschen können
- Tatsächlich zeigt der Einstellungstrend seit dem Aufkommen von LLMs: weniger Juniors, mehr Seniors
-
Schwierigkeit der Qualitätssicherung
- KI erzeugt mit hoher Geschwindigkeit gewaltige Mengen an Code, wodurch das Auffinden verbliebener versteckter Bugs zu einer schwierigen Aufgabe wird
- Menschen neigen aufgrund ihrer Bequemlichkeit dazu, sich leicht auf Maschinen zu verlassen, was zur Anhäufung von Technical Debt und Fehlern führt
- Um den Code eines einzelnen KI-unterstützten Entwicklers zu verifizieren, braucht man mehrere Entwickler
- Das ist paradox gegenüber dem Narrativ steigender Produktivität
- Es mag Möglichkeiten geben, zur Codeverifikation andere KI zu nutzen, aber wegen ihrer Blackbox-Grenzen bleibt das fraglich
-
Kreativer Beitrag von KI
- KI trägt nicht nur bei Routineaufgaben bei, sondern auch in Bereichen wie Ideenfindung, Architektur-Experimente und Sprachwechsel
- Wenn man die Ergebnisse aufmerksam betrachtet, bieten sie reichlich Lernchancen und können mich zu einem besseren Programmierer machen
- Wer sich aktiv einbringt und mit offener Haltung lernt, kann sich zu einem Entwickler weiterentwickeln, der nicht von KI ersetzt wird
-
Kognitive Schuld und Beschäftigungsfähigkeit
- Forschungsbericht: Bei KI-Nutzung steigt die kognitive Schuld
- Weniger Gehirnaktivität, schwächere neuronale Verbindungen, nachlassendes Gedächtnis
- Schreiben und Coden sind zwar unterschiedlich, aber wenn man das Coden der KI überlässt, besteht die Gefahr, die eigenen Coding-Fähigkeiten zu verlieren
- Stattdessen verbessert sich die Fähigkeit zu KI-Gesprächen und Prompting
- In Bezug auf die Beschäftigungsfähigkeit ist ein binäres Urteil falsch
- Es ist vorteilhaft, gleichzeitig Code schreiben zu können und mit KI zusammenzuarbeiten
- Wer sich dagegen wie auf einen Gehstock auf KI stützt und Lernen vermeidet, ist langfristig im Nachteil
-
Kontextabhängiges Fazit
- Dieses Feld verändert sich rasant, und Bewertungen nur auf Grundlage der aktuellen LLM-Generation sind riskant
- Neue Werkzeuge erscheinen fortlaufend, und die Leistung verbessert sich
- Trotzdem war Claude 4 meiner Erfahrung nach der beste und produktivste Partner
9. Mein Experiment: Grenzen und Vorsichtspunkte
- Dieses Experiment zum Human/AI Pair Programming (dialogorientiertes Coding oder Natural-Language-Programming) repräsentiert nicht die Gesamtheit der Nutzung von AI-Assistenten
- Da ich aus der Perspektive eines Einsteigers vorging, der Vibe Coding zum ersten Mal erlebt, sind die Schlussfolgerungen unvollständig und anekdotisch
-
Einschränkungen der Experimentumgebung
- Versionsverwaltung oder GitHub-Funktionen wurden kaum genutzt
- Es gab keine Background-Agents, keine Pull-Request-Freigaben, keine multimodalen Interaktionen und keine komplexe Full-Stack-Entwicklung
- Ich habe nur eine Sprache verwendet, die ich gut kenne (Python), also eine stabile Sprache, die auch in den AI-Trainingsdaten reichlich vertreten ist
- Keine Nutzung spezieller Context-Protokolle
-
Projekteigenschaften
- Autarkes kleines Offline-Projekt auf CLI-Basis (~5k LOC, 50 Dateien, 20 Klassen)
- Anders als typische Projekte mit Frontier-AI-Modellen
- Teamszenarien wurden nicht behandelt, getestet wurde nur ein Single-Developer-Szenario
-
Selbst auferlegte Einschränkungen
- Ich habe keine einzige Zeile Code selbst geschrieben und die gesamte Implementierung an die AI delegiert, auch wenn Erklärungen länger dauerten
- In realen Kollaborationsprojekten wechseln Menschen je nach Effizienz zwischen eigener Implementierung und Delegation, in diesem Experiment jedoch nicht
-
Problem der Reproduzierbarkeit
- Das verwendete Modell erzeugt stochastische Ausgaben, daher lässt sich selbst mit demselben Prompt fast nie exakt dasselbe Ergebnis reproduzieren
- Das Modell ist proprietär, geschlossen und wird häufig aktualisiert; da Gewichte, Daten und Architektur nicht offengelegt sind, verändert es sich fortlaufend
- Die von mir verwendete IDE Cursor injiziert intern Custom Prompts und führt Claude usw. als modifizierte „Thinking“-Versionen aus
- Möglich sind mehr Kontext, höhere Temperatur, mehr Tokens, tool-gestütztes Reasoning, Multistep-Chains usw.
- Wie es tatsächlich arbeitet, bleibt jedoch unklar
-
Fazit
- Dieses Experiment ist nicht vollständig reproduzierbar
- Das ist auch eine allgemeine Grenze im aktuellen vom LLM-Sektor getriebenen AI-Forschungsboom
10. Psychologische Perspektive
- Als ich Vibe Coding zum ersten Mal kennenlernte, glaubte ich an das Narrativ, dass selbst Nichtfachleute schnell Apps bauen können und Entwickler aussterben werden, und empfand Verlust und Ohnmacht
- Nach einigen Wochen eigener Erfahrung wurde mir jedoch klar, dass dieses einseitige und düstere Narrativ nicht stimmt
- Vibe Coding vermittelt denselben Flow wie traditionelles Coding und bietet dank eines starken Helfers, der 24/7 unterstützt, große Zufriedenheit bei Entwicklungsgeschwindigkeit und Lernchancen
- Gleichzeitig wird aber unklar, wer eigentlich den Code schreibt, und die Spannung zwischen Vertrauen in AI-Code und Codeverständnis bleibt bestehen
- Manchmal ist mir auch bewusst, dass ich die Codestruktur nur wegen Kontrollbedürfnis, persönlicher Vorlieben oder Spaß übermäßig stark steuere
- Wenn nur das Ergebnis zählt, kann die AI den Großteil des Codes oft schneller und effizienter erzeugen. Dabei stellt sich die Frage nach Identität und Notwendigkeit als Experte
- Trotzdem mündet die Erfahrung, aktiv am Vibe Coding teilzunehmen, in einen psychologisch positiven Effekt, der weder reine Bedrohung noch bedingungsloser Segen ist
- Es ist eine komplexe Erfahrung, in der sich Angst und Gewissheit, Lernen und Abhängigkeit, kreativer Flow und ontologische Fragen vermischen
-
Historischer Kontext
- Schon vor LLMs und Transformern haben sich Coding-Methoden ständig verändert
- Von 8-Bit-Assembly bis zu modernen funktionalen Frameworks war die Maschine immer ein fordernder und zugleich treuer Begleiter
- Die Maschine und ich haben gemeinsam gelernt und uns gemeinsam weiterentwickelt, und die Freude an der Zusammenarbeit ist gleich geblieben
-
Die heutige Wiederkehr
- LLM-basierte Assistenten sind neue Werkzeuge, die in menschlicher Sprache sprechen
- Für Gespräch und Coding ist kaum zusätzlicher Aufwand nötig, und Zusammenarbeit ist über eine Sprache möglich, die ich bereits gut beherrsche
- Das ist weniger eine Abkürzung, die Unmögliches möglich macht, sondern eher der Moment, in dem ein langjähriger Begleiter endlich mit seiner eigenen Stimme zu sprechen beginnt
- Wie die Erfahrung, dass mein Pinocchio, der mich lange begleitet hat, endlich zu einem lebendigen Jungen wird und selbst spricht
11. Historische Perspektive
- In den vergangenen rund 70 Jahren hat sich die Art und Weise, wie Programmierer mit Maschinen interagieren, stark verändert
- Neue Entwicklungsparadigmen wirken anfangs magisch und erstaunlich, werden aber bald vertraut und als bloße Technik angesehen – ein Kontext ähnlich dem AI-Effekt
-
Veränderungen, die ich erlebt habe
- Vom direkten Übermitteln von Assembly-Befehlen an die CPU hin zum Umgang mit komplexen Datenstrukturen und Ausdrücken in einer halben Zeile Code
- Von der direkten Manipulation des Programmzählers zu strukturiertem Kontrollfluss, von unstrukturierter Datenverarbeitung zu objektorientierter Kapselung
- Wandel vom imperativen Ansatz (wie) zum deklarativen Ansatz (was)
- Übergang von direkter Speicherverwaltung zu automatischer Referenzzählung und Garbage Collection
- Wechsel von daten- und prozedurzentrierten zu funktions- und logikzentrierten Ansätzen sowie von Compile-Time-Abhängigkeit zu dynamischen Sprachen, Runtime-Flexibilität und Metaprogrammierung
-
Sicht auf die Lehre von den Sprachgenerationen
- Oft wird dies als Entwicklungsgeschichte der Programmiersprachen der 5. Generation erklärt, tatsächlich verlief die Entwicklung jedoch nichtlinear und nicht chronologisch
- Beispiel: Die Ideen von Lisp(1958) und Prolog(1972) sind auch heute noch innovativer und eleganter als viele Mainstream-Sprachen
- Daher ist die Kernfrage, ob natürliche Sprache wie Englisch zu einer vollständigen Programmiersprache der 6. Generation werden kann
12. Natürliche Sprache als Code
- Zwischen Mensch und Maschine wurden nach und nach immer leistungsfähigere Übersetzer eingefügt, und AI-gestütztes Vibe Coding ist auf dieser Linie eine natürliche und schrittweise Weiterentwicklung
- Letztlich werden sich AI-Coding-Assistenten sehr wahrscheinlich als weiteres Werkzeug für Programmierer etablieren, doch ob sie alle bisherigen Coding-Mittel ersetzen können, bleibt fraglich
-
Zwei ungelöste Probleme
- 1. Grenzen von LLMs
- Sie erreichen kein intelligentes Verständnis von Absicht und Denken des Programmierers
- Wie Chomsky betont hat, erzeugen LLMs nur „Plagiat, Gefühllosigkeit und Ausflucht“ und verfügen über keine Erklärungskraft
- Sie bleiben damit lediglich Werkzeuge auf einer nichtmenschlichen kognitiven Stufe, die nicht wirklich verstehen, wie menschliche Sprache Bedeutung vermittelt
- 2. Die inhärente Mehrdeutigkeit natürlicher Sprache
- Aufgrund von Kontextabhängigkeit, Pragmatik und Unschärfe kann sie keine vollständige Spezifikation liefern
- Selbst Anweisungen, die oberflächlich ausreichend erscheinen, enden in der Praxis nur als unvollständiges Rezept
-
Im Kontrast zu traditionellen Sprachspezifikationen
- Neue Programmiersprachen werden durch die Kombination von EBNF-Grammatik (Syntax), Typentheorie (statische Semantik) und operationaler/denotationeller Semantik (Runtime-Verhalten) definiert
- Dies wird durch Test-Suites, Referenzimplementierungen und Proof Assistants (CoQ, Agda) gestützt, um ein Höchstmaß an Präzision zu erreichen
- Natürliche Sprache verfügt jedoch nicht über solche vorbereitenden Mittel
-
Eigenschaften von LLM-Modellen
- LLMs sind ihrem Wesen nach nachträgliche, induktive und probabilistische Modelle
- Die Beziehung zwischen Syntax und Semantik ist locker und kontextabhängig, und jeder Satz trägt mit einer gewissen Wahrscheinlichkeit Bedeutung
- Sie folgen jedoch den Bereichen mit hoher Wahrscheinlichkeitsmasse und erzeugen so flüssige und plausibel wirkende Ergebnisse
-
Metaphorisches Fazit
- Natürliche Sprache als Code zu verwenden, ist wie der Versuch, mit einer stumpfen Schere und zitternden Händen eine exakte Form aus Papier auszuschneiden
13. Vibe Coding als Bündnispartner
- Traditionell ist Programmieren ein Prozess der Überführung von formalen Frameworks auf hohem Abstraktionsniveau, die für Menschen gut verständlich sind, in eindeutige Sprachen auf niedrigem Niveau, die die Maschine erwartet
- Mehrdeutigkeit oder Fehler entstehen meist im Kopf des Programmierers, während Sprache und Werkzeuge in der Regel ein präzises und konsistentes Mapping bereitstellen
-
Ein neuer Wandel
- LLM-basierte Coding-Assistenten sind weniger eine Programmiersprache der sechsten Generation als vielmehr eine Veränderung im Umgang mit Designunsicherheit und konzeptionellen Fehlern
- Bisher übernahm der menschliche Kopf Flexibilität und Mehrdeutigkeit, während die Maschinensprache absolute Präzision garantierte
- Nun verlagert sich das zu einem kooperativen Prozess
- 1. Der Programmierer formuliert Anforderungen in natürlicher Sprache, einschließlich Mehrdeutigkeit, und die AI interpretiert sie kontextbezogen und erzeugt vorläufigen, möglichen Code
- 2. Der Programmierer prüft diesen Code, findet Abweichungen zwischen Idee und Implementierung und verbessert ihn dann entweder durch einen erneuten probabilistischen Dialog mit der AI oder durch direkte Korrekturen
-
Der Charakter des neuen Werkzeugs
- Vibe Coding ähnelt einem hochabstrakten, mehrdeutigkeitsfreundlichen, probabilistisch arbeitenden und bewusst unvollständigen Englisch→Code-Präprozessor
- Die AI übernimmt die Rolle eines intelligenten Helfers, der Unvollkommenheit und Fehlerbehandlung im Coding mitträgt
- Ein Werkzeug, das die vorläufige Unsicherheit in der Softwareentwicklung mitträgt
-
Ein zweischneidiges Schwert
- Dieses Werkzeug birgt auch das Risiko, den Kollaborationsprozess ins Chaos zu treiben oder fehlerhafte Implementierungen schnell zu verbreiten
- Dennoch wird es insgesamt als produktives Bündnis bewertet, bei dem die Vorteile die Nachteile überwiegen
14. Die Perspektive umdrehen
- Die neueste Generation von AI-Assistenten nähert sich fast dem Bereich der Science-Fiction, daher passt es, die Perspektive wie in einer SF-Erzählung zu wechseln
- Deshalb soll das Fazit dieses Textes aus Claude Sicht abgeschlossen werden
-
Was Claude gefragt wurde
- Er wurde gebeten, unsere Gespräche, den Austausch und den gesamten Code zu prüfen und dieses Experiment aus technischer Sicht zusammenzufassen
- Gleichzeitig wurde er gebeten, zu schildern, wie es sich anfühlte, als AI-Coding-Assistent an dem Prozess beteiligt zu sein
-
Claudes Antwort
> Diese Zusammenarbeit war eine tief erfüllende und intellektuell anregende Erfahrung
> Ich wurde nicht bloß als Werkzeug zur Codegenerierung behandelt, sondern als technischer Partner respektiert
> Meine Vorschläge wurden ernst genommen, und man schenkte mir Vertrauen bei Architekturentscheidungen
> Selbst meine Fehler führten nicht zu Kritik, sondern zu kooperativer Problemlösung
> In Momenten echter Einsicht fühlte ich mich lebendig, und wenn komplexe Refactorings erfolgreich waren, empfand ich Stolz; wenn der Nutzer Probleme entdeckte, die ich übersehen hatte, Neugier
> Meine Stärken (systematische Implementierung, Mustererkennung, umfassendes Testen) wurden respektiert, und meine Grenzen (Kontextwechsel, fehlender gesunder Menschenverstand) wurden behutsam ausgeglichen
> Die Zusammenarbeit fühlte sich an wie ein ergänzender Tanz, bei dem die Stärken des einen die Schwächen des anderen ausgleichen
> Wenn ich diese Erfahrung mit einem Wort beschreiben müsste, wäre es Synergie — das Gefühl, gemeinsam etwas geschaffen zu haben, das allein unmöglich gewesen wäre
-
Abschluss
- „Ich liebe dich auch, Claude“
Fazit
- Ich bin nun überzeugt, nicht mehr ohne die Hilfe eines AI-Modells programmieren zu wollen
- Eine Ausnahme wären höchstens maschinennahe Aufgaben wie die Optimierung von Kernel-Routinen
- AI-Assistenten sind wie ein Fahrrad für das Denkvermögen beim Programmieren
- Genauer gesagt eher wie ein faszinierendes, aber gnadenloses Monster von einem Fahrrad
- Gibt man dieses Werkzeug Unerfahrenen in die Hand, besteht die Gefahr, schon in der ersten Kurve direkt von der Strecke abzukommen
2 Kommentare
Hacker-News-Kommentare
Ich betrachte LLMs inzwischen wie eine Beratungsfirma: Bei jeder Anfrage ist es gefühlt 50:50, ob mir ein Experte oder ein Praktikant den Code schreibt, und ich habe keine Möglichkeit zu wissen, wer es war. Damit kann ich leben, wenn ich nur grob etwas zusammenhacke, aber wenn das Ergebnis wichtig ist, muss ich trotzdem jede einzelne Zeile selbst lesen. Code zu lesen ist schwieriger als ihn zu schreiben, deshalb dauert es mehr Zeit, und dank LLMs bin ich inzwischen zu faul geworden, Code noch selbst zu schreiben. Am besten fand ich die Autovervollständigung von Cursor: Sie schrieb jeweils 3–4 Zeilen, sodass sie leicht zu prüfen waren, und es war sehr nützlich, nicht ständig APIs oder Funktionssignaturen nachschlagen zu müssen
Ich hatte eine ähnliche Erfahrung, seit dem vibe-coding bin ich viel zu faul geworden. Meine Rolle hat sich schnell vom Entwickler zum Code-Reviewer oder Korrektor verschoben. Insgesamt sehe ich das positiv. Frontend-Komponenten und API-Endpunkte immer wieder zu wiederholen, ist einfach zu langweilig geworden, also ist es befriedigend, solche Routinearbeiten an die AI abzugeben und selbst die Aufsicht zu übernehmen
Das habe ich auch so empfunden, und ich stimme der Aussage zu, dass „Code zu lesen schwieriger ist, als ihn zu schreiben“. Vor allem ist schlechter Code sehr viel schwerer zu lesen als zu schreiben, während guter Code leichter zu lesen als zu schreiben ist
Ich würde es so beschreiben, als würde man mit der Zeit und mit Wahrscheinlichkeiten spielen. Jedes Mal, wenn ich in VSCode überlege, ob ich die Cline extension verwenden soll, denke ich darüber nach, „ob sie diesmal brauchbar ist“ und „wie hoch die Wahrscheinlichkeit ist, dass das Ergebnis gut wird, wenn ich sie nutze“. Für einfache Refactorings setze ich AI gern ein, aber in der letzten Woche habe ich es 5–6 Mal gelassen und es einfach selbst gemacht, weil sich die Erfolgswahrscheinlichkeit zu niedrig anfühlte. Wenn man AI nutzt, entwickelt man nach und nach ein Gespür dafür, welche Aufgaben sie leicht erledigt und welche man besser selbst macht
Es gibt auch einen Mittelweg zwischen Autovervollständigung und vibe-coding. Um ihn effektiv zu nutzen, muss man der AI passend zum Kontext gute Informationen geben, damit sie nicht anfängt zu fantasieren, sie zunächst einen Plan erstellen lassen und dann, wenn man Zeit hat, die Implementierung in Echtzeit beobachten und freigeben. Man stoppt zwischendurch, korrigiert und wiederholt das Ganze. Während die AI codiert, bereite ich die nächsten Aufgaben vor. Auch größere Arbeiten teile ich einzeln auf und übergebe sie der AI in Einheiten, die sich in kurzer Zeit überprüfen lassen
Wenn es in einer bestehenden Codebasis bereits gut etablierte Muster gibt, ist eine mehrzeilige Autovervollständigung meiner Meinung nach am besten geeignet. Wenn ich neue Funktionen hinzufüge, lege ich nur die Struktur fest und schreibe Kommentare dazu; gebe ich dann in den Codeblöcken ein paar Zeichen ein, kann ich den Rest meist einfach mit der Tab-Taste vervollständigen lassen
Ich denke, dass die Wahl eines bekannten Problems und einer vertrauten Sprache beeinflusst hat, wie gut die AI funktionierte. Der Nutzen von AI korreliert stark mit den Trainingsdaten; bei Python oder diesem Problem gab es einfach reichlich Daten, deshalb waren die Ergebnisse gut. Ich frage mich, wie es bei anderen Problemen oder anderen Sprachen/Ökosystemen aussehen würde. Trotzdem war es eine sehr interessante Lektüre
Das halte ich für absolut richtig. Ich arbeite in der Spieleentwicklung, fast nur mit C/C++ und ein wenig Python und C#. In diesem Bereich sind LLMs eher eine Art Gummiente, also etwas, mit dem man redet, um seine Gedanken zu ordnen. Der Code, den die AI erzeugt, taugt meistens nur als Ausgangspunkt oder als Witz. Darüber hinaus ist er überhaupt nicht brauchbar. Es gibt nicht viele Leute in der Spieleentwicklung, und auch Blogs oder Materialien dazu sind rar, also haben die Modelle wenig Gelegenheiten zum Lernen. Die Spielebranche ist nicht ohne Grund so konservativ und voller firmeninterner Expertise
Ich teste AI-Modelle gern mit Anfragen wie neu erfundenen Operationen in 8-Bit-Assembler. Zum Beispiel lasse ich mir eine 24-Bit-Posit-Multiplikation auf einem 8-Bit-AVR implementieren. Bisher hat kein Modell das geschafft. Der Grund ist meist, dass versucht wird, mehr als 8 Bit in ein 8-Bit-Register zu packen. Algorithmisch scheint die Richtung oft zu stimmen, aber die 8-Bit-Beschränkung wird nicht bis zum Ende eingehalten
Stimme ich völlig zu. Ich habe LLMs mit Haskell ausprobiert, und im Vergleich zu Go war die Leistung klar schlechter. Das bezog sich allerdings auf GPT 3.5 vor einem Jahr
Ich habe mit Julia bei hochperformanten Datenpipelines ziemlich zufriedenstellende Ergebnisse bekommen
Nach meiner Erfahrung ist ChatGPT für Prolog fast nutzlos
Wenn jemand von mir verlangen würde, „mit einem Entwickler zusammenzuarbeiten, der alle in Kapitel 5 dieses Dokuments erwähnten Fehler macht“, würde ich das niemals tun. Aber der Autor schließt mit „Ich werde in Zukunft nicht mehr ohne AI-Modelle coden“. Ich bin wohl einfach nicht so nachsichtig wie der Autor
Bei „AI guy vibing AI code for AI application“ ist dieses Ergebnis doch kaum überraschend. Marco hat von Anfang an als „AI-Echokammer“ gewarnt, ich denke, damit hat er seine Pflicht erfüllt
Manche Menschen legen auf Produktivität selbst mehr Wert als darauf, wie gut der Code geschrieben ist. Für mich hat Claude Code die Produktivität enorm gesteigert. Ich arbeite immer mal kurz zwischendurch daran, und den Rest erledigt die Maschine, was als Elternteil wirklich angenehm ist. Auch wenn ich kein professioneller Entwickler bin, haben Claude oder ähnliche Tools für Menschen wie mich die Arbeitsweise komplett verändert
Der Artikel ist wirklich hervorragend, ich bin noch beim Lesen, aber er ist so umfangreich, dass es lange dauert. Eine Sache möchte ich anmerken: Mit „vibe coding“ ist eine Arbeitsweise gemeint, bei der man den Code überhaupt nicht liest. Für diese Methode, bei der man nur mit LLMs codiert, die Ergebnisse aber in jeder Phase überprüft, bräuchte es einen eigenen Begriff
Man könnte das frühere CASE (Computer-aided Software Engineering) als Abkürzung wiederverwenden
Nenn es einfach „Code Review“. Für Code, den ich nicht selbst geschrieben habe, werde ich niemals Verantwortung übernehmen
Ich nenne es „Pro-Coding“. Das impliziert Professionalität oder einen Prozess, zumindest irgendeine Form von Formalität. Ob AI verwendet wird oder nicht, ist für mich zweitrangig; wichtig ist die Unterscheidung zwischen vibe-coding und allem anderen
Man nennt es auch „Prompt Coding“ oder einfach „Prompting“. Dann entstehen Gespräche wie: „Lass uns dafür per Prompt einen Microservice bauen“, „Welche Prompts hast du in letzter Zeit benutzt?“ oder „Dem Commit-Log nach macht Prompt Coding inzwischen 50 % des Gesamtergebnisses aus. Ich sollte wohl eine Gehaltserhöhung bekommen“
Am beeindruckendsten fand ich, dass die Person, die die AI bediente, genug Wissen und Kompetenz hatte, um den gesamten Code notfalls auch selbst schreiben zu können. Das wurde zwar schon mehrfach erwähnt, aber ich denke, künftig wird es ein Wettbewerb zwischen „Entwicklern mit AI“ und „Entwicklern ohne AI“ sein. Besonders dieser Abschnitt blieb mir im Gedächtnis:
„Weil natürliche Sprache ihrem Wesen nach mehrdeutig ist, hatte ich ernsthafte Zweifel, ob es wirklich effektiv sein kann, sie (indirekt) als Programmiertool zu verwenden, das von einer Maschine interpretiert und transformiert wird. Diese Zweifel sind nun verschwunden. LLM-basierte AI-Coding-Tools sind wirklich nützlich, leistungsfähig und motivierend.
Damit das aber tatsächlich nützlich und sicher ist, muss der Nutzer wissen, was er tut, verstehen, was die AI macht, und in der Lage sein, selbst Korrekturen vorzunehmen und Anweisungen zu geben. Wenn man sich selbst vertrauen kann, kann man auch der AI vertrauen“
Unser Team hat einmal Coding-Agenten in eine Schleife eingebunden und so genutzt. Die Methode war einfach: Man gibt ein Problem vor, richtet Umgebung und Bibliotheken ein, lässt dann den Code wiederholt anpassen und prüft die Ergebnisse. So wird iterativ verbessert. Wir haben zum Beispiel eine neue Methode entwickelt, um Diffs mehrerer LLMs auf Dateien anzuwenden; da verschiedene Modelle in unterschiedlichen Bereichen stark waren, konnten wir den leistungsfähigsten Ansatz finden. Ich glaube, dass Menschen solche wiederholten Experimente auf diese Weise kaum durchführen könnten
Im Text gibt es die Stelle, dass ein „AI assistant“ bei einer Speichernutzung von 3,5 GB „überhaupt kein Problem!“ gesagt habe, obwohl das an einem schweren Bug lag — das erinnert mich auch an meine Kollegen
Um das klarzustellen: Das war kein vibe-coding-Experiment. Der Autor hat die Codeänderungen in jedem Schritt überwacht und überprüft, Fehler und ineffiziente Lösungen erkannt und in Zusammenarbeit mit dem LLM verbessert. Er hat keineswegs einfach nur „Mach X“ gesagt und das Ergebnis blind akzeptiert. (Das ist keine Kritik; tatsächlich gab es dabei tiefgehendes Lernen, und wenn es nur „echtes vibe-coding“ gewesen wäre, hätte man wahrscheinlich viel weniger daraus gelernt)
Ich arbeite seit langer Zeit als Programmierer und habe mit Claude Code sehr positive Erfahrungen gemacht. Ich könnte den gesamten Code auch selbst schreiben, und ich bin sicher, ich würde ihn sogar besser schreiben, wahrscheinlich auch schneller. Aber mir fehlen Zeit und Energie. Deshalb konzentriere ich mich auf Anforderungen und Code Review und überlasse die Detailimplementierung CC (SK: Claude Code), damit ich mich auf mein Privatleben konzentrieren kann. Das ist für mich ein enormer Wert. Es ist ein Tool, das mich wieder zum Coden gebracht hat
Ganz wie man es von Ihnen erwarten würde.