- Andrej Karpathys jüngste Aussage sorgt für Aufsehen: "Überlasst euch dem Vibe, akzeptiert exponentielles Wachstum und vergesst sogar, dass Code überhaupt existiert."
- "Vibe Coding" bezeichnet die Tendenz, die Problemlösung ohne klaren Plan oder eigenes Schreiben von Code an AI-Tools zu delegieren
- Über LLM-Agenten (Large Language Models) können Befehle in natürlicher Sprache gegeben werden, um Code zu erzeugen und zu ändern
- 2022: In ChatGPT konnte Code kopiert und geändert werden
- 2023: In das IDE integriertes Copilot konnte Code prüfen und ändern
- 2024–2025: Mehrere Dateien eines Projekts können geändert sowie eigene Tests ausgeführt und Korrekturen vorgenommen werden
Wie „Vibe Coding“ funktioniert
- Sowohl technische als auch nichttechnische Nutzer können Projekte über LLM-basierte Agenten aufsetzen
- Mit einfachen Anweisungen lassen sich Websites oder Apps erstellen (z. B. „Erstelle eine Website für ein Skigebiet“)
- Nach der initialen Einrichtung sind automatische Korrekturen und Tests möglich
-
Beispiele:
- Cursor, GitHub Copilot Agent Mode usw. können Dateien ändern und Befehle ausführen
- Automatische Korrekturen und Tests werden durchgeführt → durch mangelnde Konsistenz können Fehler entstehen
Das Problem der Autonomie von Agenten
- Agenten können Aufgaben automatisch ausführen, sind aber nicht vollständig autonom
- Wenn sie ohne Zustimmung des Nutzers ausgeführt werden, können Risiken entstehen (z. B. Ausführen von Befehlen im YOLO-Modus)
- Es können Probleme bei Codequalität und Genauigkeit auftreten
-
Hauptprobleme:
- Bestehender Code wird nicht wiederverwendet → dieselben Komponenten werden wiederholt erzeugt
- Es wird versucht, serverseitige Logik auf der Client-Seite auszuführen
- Nach falschen Codeänderungen treten Fehler auf → Behebung scheitert
- Erstellen von Unit-Tests schlägt fehl oder der Code wird beschädigt
Realistische Grenzen
- Modelle wie Claude 3.7 Sonnet können die Grenzen ihrer Trainingsdaten nicht überwinden
- Geht in einer Codebasis der Kontext verloren, sind konsistente Änderungen nicht möglich
- Mit wachsender Codegröße sinkt die Leistung, und der Kontext kann nicht aufrechterhalten werden
- Wird die Größe des Kontextfensters eines LLM überschritten, entstehen Konsistenzprobleme
-
Konkrete Problemfälle:
- Duplizierung von TypeScript-Interfaces
- Ausführung von Server-Logik im Client
- Fehlgeschlagene Änderungen an doppelten Komponenten
- Fehlgeschlagenes Schreiben von Unit-Tests
- Fehlgeschlagene Fehlerbehebung nach Code-Refactoring
Versuche zur Problemlösung
- Claude Plays Pokémon: Ein Agent spielt das Spiel durch Interaktion in Echtzeit
- Das Aufrechterhalten von Speicher und das wiederholte Korrigieren von Fehlern scheitern
- Der Aufbau von Langzeitgedächtnis scheitert → anhaltende Fehler treten auf
-
Verbesserungspotenzial:
- MCP (Model Context Protocol) und das Speichermanagement müssen verbessert werden
- Bei Codeänderungen muss das LLM frühere Änderungen präzise berücksichtigen
- Domänenspezifisches Gedächtnis und die Bewahrung des Arbeitsverlaufs sind nötig
Fazit
- „Vibe Coding“ kann bei der Umsetzung funktionaler Konzepte bis zu 80 % erreichen, aber um zuverlässige und sichere Produkte zu bauen, ist die Arbeit erfahrener Menschen erforderlich
- AI-Agenten ermöglichen es erfahrenen Personen, eigenständig mehr zu erschaffen, können aber Menschen, die schwierige Probleme mithilfe von Erfahrung und Intuition lösen, nicht ersetzen.
- Auf dem aktuellen Stand führt „Vibe Coding“ kaum zu tatsächlich nützlichen Produkten; die Hilfe erfahrener Entwickler ist unverzichtbar
- „Vibe Coding“ ist nur ein Hilfsmittel beim Schreiben von Code, kein vollständiger Ersatz
9 Kommentare
Der Ausdruck „aktuelles Niveau“ fällt mir ins Auge. Betrachten wir LLMs da nicht vielleicht mit dem menschlichen Zeitbegriff?
Was ich beim Coden mit KI empfinde, ist: Wenn man den Code in Einheiten mit dem Gefühl von Single-Responsibility-Prinzip + TDD aufteilt, damit die KI auch dann den Kontext verstehen kann, wenn man ihr nur Teile des Codes gibt, dann muss man es so fassen, dass sie den großen Gesamtzusammenhang nicht lesen muss und schon der lokale Kontext des jeweiligen Teils ausreicht.
Ich nutze KI für Hobbys am häufigsten zur Entwicklung von Webgames, und ich stimme dem zu. Wenn ein Projekt eine gewisse Größenordnung überschreitet, gibt es irgendwann Bereiche, in denen die KI – wenn man es so nennen will – deutlich an Fokus verliert. Ich nutze das auf folgende Weise: Ich füge den gesamten Projektbaum und den Quellcode des Spiels einschließlich TOC in einer einzigen Datei zusammen, lade diese Datei beim Erstellen eines neuen Threads hoch und setze die Arbeit dann fort. Und wenn ich Fragen stelle, verlange ich in der Antwort immer ausdrücklich, dass der aktuelle Projektname klar genannt wird. Trotzdem gibt es noch Teile, mit denen ich nicht zufrieden bin, aber ich bin sehr zufrieden damit, dass ich Hobbys, an die ich früher wegen des stressigen Alltags gar nicht zu denken wagte, nun in vergleichsweise kurzer Zeit fertigstellen kann.
Das Muster, etwas grob zu bauen und anschließend die restlichen Details nachzuarbeiten, gefällt mir sehr.
Es gibt verschiedene Versuche, aber die Grenzen des Erinnerungsvermögens sind eindeutig. Für ein PoC-Niveau ist es gut. Im Hinblick auf Geschwindigkeit sowie auf Möglichkeiten/Usability ist es gut.
Das Problem ist, dass man umso mehr erfahrene Fachleute braucht.
Wenn man bedenkt, dass beim Programmieren die meiste Zeit fürs Debugging und Lesen von Code draufgeht, halte ich das für ziemlich übertrieben. Die Leute, die AI entwickeln, sprechen zwar alle in diesem Tonfall darüber, aber zumindest wenn man sich die aktuelle Lage ansieht, scheint es nicht so zu sein. Wenn man an einen Punkt kommt, an dem keine menschliche Hand mehr nötig ist, braucht man dann überhaupt noch Programmierung? Dann wäre es doch besser, einfach die API-Beschreibung einzuspeisen und das LLM als Backend zu verwenden.
In der Praxis wird es oft so verwendet, dass man tatsächlich ein Schema konfiguriert und es dann darüber entgegennimmt.
Ich stimme zu. Anfangs zeigt sich ein Entwicklungstempo, das fast schon an Magie grenzt, aber je größer der Umfang wird und je mehr Dateien hinzukommen, desto mehr bekommt man am Ende nur ein aufgeblähtes, fehleranfälliges Ergebnis, wenn die verantwortliche Person für die Verwaltung (hier der Mensch) das nicht effektiv steuern kann. Wenn es bereits einen Punkt erreicht hat, an dem nichts mehr zu retten ist, verschwendet man nur Credits (Windsurf) oder Requests (Cursor). Es wird nach und nach besser werden, aber im Moment sollte man AI-Code nicht zu 100 % vertrauen.
Hacker-News-Kommentare
Der große Unterschied zwischen „AI-Hype vs. Realität“ liegt in den Produktivitätszahlen, von denen die Leute oft sprechen. Zum Beispiel zitieren YC-Partner ein Unternehmen, das eine „100-fache Geschwindigkeitssteigerung“ bei der Coding-Leistung behauptet. Solche Behauptungen müssten für externe Beobachter offensichtlich sein und sollten daher nicht auf Selbstauskünften beruhen.
Im Moment erleben wir einen neuen Outsourcing-Hype. Trotz all der übertriebenen Behauptungen sieht die Realität anders aus. Die Diskussion über LLM-Coding-Agenten ist schwer davon zu unterscheiden.
Das ist so, als würde die Go-Community sagen, Computer könnten menschliche Go-Spieler nicht schlagen. Es gibt bereits Beispiele für Modelle, die bessere Sortierverfahren gefunden haben. Mit den richtigen Anreizen und genügend Zeit werden Computer uns übertreffen.
Ein neues Problem mit Coding-LLMs: Offshore-Entwickler sind vollständig ins Team integriert. Aber der Einsatz von LLMs ist wahllos und sporadisch, sodass eingereichte Pull Requests zum Albtraum werden.
„Vibe Coding“ kann 80 % eines Konzepts umsetzen. Aber um etwas Zuverlässiges, Sicheres und Wertvolles zu bauen, braucht es erfahrene Menschen.
Kürzlich habe ich mit Claude und OpenAI o3-mini versucht, Matlab-Code nach Python zu konvertieren, aber die Leistung war sehr schlecht. In fast jeder wichtigen Zeile waren Fehler. Das ist eigentlich eine Aufgabe, die automatisiert werden sollte, aber sie ist gescheitert.
„Vibe-TDDing“ ist besser, als gar keine Tests zu haben. Wenn man Coding und Tests versteht, kann man mit LLMs negative externe Effekte verringern.
Nachdem ich geteilt hatte, wie man ein SaaS baut, passierten seltsame Dinge. Die Nutzung des API-Schlüssels erreichte das Maximum, Abonnements wurden umgangen, und in der DB wurden zufällige Dinge erzeugt. Das war wahrscheinlich ein Streich.
Viele Engineers unterschätzen offenbar die Fähigkeiten und die Produktivitätswirkung von AI-Coding-Tools, was mir ein Gefühl von Jobsicherheit gibt. Ich werde Cursor nicht mehr hergeben.