Jenseits von Vibe Coding

Warum das beste LLM allein den Durchbruch nicht bringt

Erinnert ihr euch noch an die Goldgräberstimmung vor 18 Monaten? Wir haben uns Nächte um die Ohren geschlagen, um den „perfekten Prompt“ zu finden. Wir haben Prompt Engineering betrieben, als wäre es Alchemie – ein bisschen „Step-by-step“, eine Prise „Du bist ein Senior-Experte“, und hoffen, dass das Gold unten rauskommt.

Dann kam das Vibe Coding: Einfach mal locker in den Editor quatschen, die KI machen lassen und schauen, ob der „Vibe“ stimmt. Andrej Karpathy, Mitbegründer von OpenAI, hatte diesen Begriff im Februar 2025 geprägt und damit eine Entwicklung auf den Punkt gebracht, die längst im Gange war: Der Entwickler gibt die Vision vor, die KI übernimmt die Implementierung. Das war spaßig, es war befreiend, aber seien wir ehrlich: Es war die handwerkliche Phase der KI-Revolution. Es war das digitale Äquivalent zum Malen nach Zahlen.

Die Ära der isolierten Werkzeuge ist vorbei

Wir müssen diese Werkzeuge – vom perfekten Prompt bis zum PDD – als das sehen, was sie waren: Lernphasen. Wir haben gelernt, mit der Maschine zu korrespondieren. Aber wer glaubt, dass die Reise damit endet, dass wir immer schlauere Prompts in immer größere Chatfenster tippen, der hat den Kern der Entwicklung noch nicht erfasst.

Die Zukunft der Softwareentwicklung entscheidet sich nicht an der Frage, ob du GPT-5, Claude 4 oder Llama nutzt. Das LLM ist austauschbar geworden – es ist der Motor, aber nicht das Auto.

Es zählt nicht das LLM allein, sondern das Gesamtsystem

Der entscheidende Punkt ist: Nicht das beste Modell entscheidet über den Erfolg, sondern das beste Gesamtsystem.

Das ist keine bloße Behauptung, sondern eine der am härtesten belegten Erkenntnisse der jüngeren KI-Forschung. Andrew Ng, einer der einflussreichsten Köpfe auf diesem Gebiet, hat in mehreren viel beachteten Vorträgen gezeigt, dass die Einbettung eines Modells in einen agentischen Workflow dessen Leistung weit stärker verbessert als der Wechsel auf ein nominell leistungsfähigeres Modell. In seinem HumanEval-Benchmark erreichte GPT-3.5 ohne agentische Unterstützung eine Korrektheit von 48,1%. GPT-4 kam im Zero-Shot-Verfahren auf 67,0%. Doch GPT-3.5, eingebettet in einen iterativen Agenten-Workflow, erzielte 95,1% – und übertraf damit das wesentlich modernere Modell um Längen. Ng selbst brachte es auf die Formel: Der Sprung von GPT-3.5 zu GPT-4 wird durch die Integration eines iterativen Agenten-Workflows in den Schatten gestellt.

Die Landschaft liefert die Bestätigung im großen Maßstab: Frameworks wie LangGraph, CrewAI und AutoGPT etablieren genau diese Architektur – Systeme, die Aufgaben autonom planen, iterieren, reflektieren und korrigieren. Es ist ein technologischer Shift, der den Fokus endgültig vom Modell auf das System verschiebt.

Wir bewegen uns weg von der isolierten Intelligenz hin zu einer symbiotischen Mensch-Maschine-Vereinigung. Es geht um ein hocheffizientes Trio:

Das Denken (Mensch): Wir liefern die Intention, die Architektur und das ethische sowie wirtschaftliche Framework. Wir sind die Strategen.

Das Ausführen (KI-Agenten): Die Maschine übernimmt die fehleranfällige Kleinarbeit, das Refactoring und die Boilerplate-Schlachten.

Das Toolset (Infrastruktur): Die nahtlose Integration in unsere IDEs, CI/CD-Pipelines und Monitoring-Tools.

Wenn diese drei Rädchen nicht perfekt ineinandergreifen, nützt dir auch das schlauste Modell der Welt nichts. Ein brillanter Motor in einem Auto ohne Räder bringt dich nicht von Bremen nach Hamburg.

Die schleichende Standardisierung der Modelle

Die Austauschbarkeit des Motors ist längst kein theoretisches Szenario mehr. In der LMSYS Chatbot Arena, dem derzeit wohl aussagekräftigsten Benchmark für Sprachmodelle, liegen die führenden Systeme dicht beieinander: Claude 3.5 Sonnet führt mit einem Elo-Wert von 1308, dicht gefolgt von GPT-4o (1302) und Gemini 1.5 Pro (1290). Die Abstände sind so gering, dass sie für die praktische Entwicklungsarbeit kaum noch eine Rolle spielen. Das Modell wird zur austauschbaren Ware – zur „Commodity“. Der Wert entsteht nicht mehr durch die Wahl des richtigen Anbieters, sondern durch die Intelligenz der Integration: durch Retrieval Augmented Generation, durch kontextsensitive Tool-Nutzung, durch durchdachte Systemarchitektur.

Die stille Weichenstellung: Wer baut dein System?

Genau dieses Gesamtsystem wird jetzt gebaut – die Frage ist nur: von wem?

Die großen KI-Anbieter arbeiten mit Hochdruck an einer Zukunft, in der Agenten, Skills und Deep Reasoning nahtlos miteinander verzahnt sind. GitHub Copilot Workspace etwa ist der Prototyp eines geschlossenen Ökosystems, in dem die KI die gesamte Pipeline kontrolliert – von der Idee über den Code bis zum Pull Request, alles in natürlicher Sprache. Code wird automatisch mit Tests versehen, durchläuft Iterationen und Validierungsschleifen, bevor ein Entwickler überhaupt einen Blick darauf wirft. Die IDE denkt mit, die Pipeline korrigiert, der Agent antizipiert. Das sind keine isolierten LLM-Features mehr – das ist ein durchdesigntes Ökosystem, das uns schrittweise an die Hand nimmt. Bequem, effizient, produktiv.

Und genau hier liegt die Gefahr: der schleichende Vendor Lock-in. Wir gewöhnen uns an eine nahtlose Erfahrung und geben dafür Stück für Stück die Kontrolle über unseren Stack ab. Aus der Symbiose wird Abhängigkeit. Die Frage, die sich jede und jeder stellen muss, lautet: Will ich Anwender in einem fremden System sein? Oder schaffe ich mein eigenes?

Die gute Nachricht: Noch sind nicht alle Wege verbaut. Die Entwicklung lokaler Modelle hat in den letzten Monaten eine Dynamik entfaltet, die selbst Optimisten überrascht hat. Modelle wie Llama 3 oder Mistral lassen sich mit Tools wie Ollama oder LM Studio auf handelsüblichen Laptops ausführen – und liefern Ergebnisse, die für viele professionelle Coding-Aufgaben völlig ausreichen. Ja, ein lokaler Tech-Stack verlangt heute noch ein Quäntchen mehr Geduld. Aber wer hätte vor zwei Jahren gedacht, dass leistungsfähige LLMs flüssig auf unseren Notebooks laufen? Ich gebe zu, ich war mir sicher, dass das kommt. Und wer heute beobachtet, wie schnell sich lokale Modelle, offene Orchestrierungs-Frameworks und community-getriebene Toolchains entwickeln, der spürt: Die Möglichkeiten sind nicht nur absehbar – sie sind zum Greifen nah.

Mein Denkanstoß für die kommende Zeit

Hör auf, dem nächsten „Wunder-Prompt“ hinterherzujagen. Fang an zu überlegen: Wie sieht mein persönlicher Tech-Stack der Symbiose aus? Wie integriere ich das Denken und das Ausführen so, dass ein stabiler Workflow entsteht, der auch dann noch steht, wenn das nächste Modell um die Ecke kommt? Und vor allem: Wem vertraue ich die Architektur meines Systems an – einem Anbieter oder mir selbst?

Butter bei die Fische: Die Technik der Vergangenheit war das „Was“. Die Zukunft ist das „Wie“ im großen Systemzusammenhang. Und die entscheidende Weiche für dieses „Wie“ stellen wir jetzt.

Quellen

  • Andrej Karpathy – Prägung und Popularisierung des Begriffs „Vibe Coding“ (2025, u. a. in Vorträgen und Social Media Beiträgen)
  • Andrew Ng – Vorträge und Veröffentlichungen zu „Agentic Workflows“ und der These, dass Systemdesign (Workflows, Iteration, Tooling) wichtiger ist als das einzelne Modell
  • LMSYS – Chatbot Arena Benchmark (Elo-Ranking von LLMs)
  • LangGraph – Framework zur Orchestrierung von zustandsbasierten Agenten-Workflows
  • CrewAI – Framework für kollaborierende KI-Agenten
  • AutoGPT – Frühes Open-Source-Projekt für autonome KI-Agenten
  • GitHub Copilot Workspace – Konzept eines integrierten, KI-gestützten Entwicklungs-Workflows
  • Llama 3 – Open-Source-Sprachmodell von Meta
  • Mistral – Europäische KI-Modelle, optimiert für lokale Ausführung
  • Ollama – Tool zum lokalen Ausführen von Sprachmodellen
  • LM Studio – Desktop-Anwendung für lokale LLMs
  • Eigener Artikel: „Prompt Driven Development (PDD) – Ein Manifest gegen das bequeme Raten“ – Blog von Benjamin Lam

Jenseits der Nostalgie:

Was der „Vibe Coding“-Stresstest über die reale KI-Entwicklung 2026 verrät

Wenn KI-Assistenz kein reines Werkzeug-Upgrade ist, sondern ein Stresstest für unsere Arbeitsweise, dann zeigt sich im „Vibe Coding“ nicht primär eine neue Schwäche – sondern die Skalierung eines altbekannten Problems. Und zum ersten Mal auch Ansätze, damit umzugehen.Wir leben in einer Ära beschleunigter Entwicklung.Auf Entwickler-Events herrscht Aufbruchstimmung: Anwendungen entstehen in Minuten, und „Vibe Coding“ – das iterative Generieren nach Gefühl – wird als Produktivitätssprung gefeiert.Und ja: Die Werkzeuge sind beeindruckend.Ein Formular, das früher einen halben Tag gebraucht hat, steht nach zwei Prompts. Eine API-Anbindung funktioniert plötzlich auf Anhieb.Das ist kein Problem. Das ist messbarer Fortschritt.

Der Stresstest beginnt später.


Die Szene ist bekannt:

Ein Entwickler erhält Code von der KI. Er ist syntaktisch sauber, benannt, strukturiert.

Ein kurzer Blick. Die Unit-Tests – ebenfalls generiert – laufen grün.

Der Entwickler geht zum nächsten Task über.

Nicht aus Faulheit. Sondern weil das Risiko-Ertrags-Verhältnis diesen Schritt rational erscheinen lässt.


Wenig später taucht ein Bug auf. Eine Inkonsistenz zwischen zwei generierten Komponenten.

Früher war der Weg klar: Stack Trace lesen, Breakpoint setzen, verstehen.

Heute gibt es einen zweiten Weg. Einen schnelleren:

„Behandle diesen Edge Case explizit und robust.“

Die KI liefert eine neue Version, inklusive angepasster Tests. Der Bug ist weg.

Das System läuft.

Der Stresstest ist noch offen.


Ein kurzes, reales Szenario:

Du änderst einen Prompt von „formatiere Datum als DD.MM.YYYY“ zu „als YYYY-MM-DD“. Die KI passt die Funktion an. Ein Test prüft das Format – grün.

Was der Test nicht prüft: Eine Vergleichslogik im Reporting-Modul erwartet das alte Format per Regex.

Alles grün. Drei Tage später ruft der Kunde an.

Das ist kein Einzelfall. Das ist der Stresstest im Kleinen.


Die Nostalgie-Falle: War früher wirklich alles stabiler?

Hier setzt ein vertrautes Gefühl ein:

„Früher musste man es verstehen, um es zum Laufen zu bringen.“

Das ist nachvollziehbar. Aber nur die halbe Wahrheit.

Denn das, was wir heute sehen, ist kein neues Problem.

Unverstandene Drittanbieter-Bibliotheken. Copy-Paste aus Stack Overflow ohne Kontext. Legacy-Systeme, deren ursprüngliche Architekt:innen längst nicht mehr im Team sind.

Das alles gab es vorher.


Die Probleme, die „Vibe Coding“ sichtbar macht, sind keine neuen Probleme.

Sie sind alte Probleme. Nur dass sie jetzt durch die Geschwindigkeit der KI gnadenlos skaliert werden.


Was sich verändert hat, ist nicht die Art der Probleme – sondern ihre Frequenz.

Mehr Code entsteht schneller. Und wird schneller wieder verworfen.

Die Code-Churn-Rate steigt. Duplikation nimmt zu. Refactoring nimmt ab.

Nicht dramatisch im Einzelfall – aber signifikant im System.


Der Unterschied ist damit weniger qualitativ als quantitativ.

KI bringt uns nicht in unbekanntes Terrain. Sie beschleunigt, wie oft wir durch bekanntes Terrain laufen – inklusive aller Schwächen.


AI-Legacy: Ein reales, aber adressierbares Phänomen

Was dabei entsteht, ist keine klassische technische Schuld.

Sondern etwas Diffuseres:

AI-Legacy.

Funktionierender Code, der sich schwer greifen lässt. Und niemandem wirklich „gehört“.


Die typische Situation:

Du änderst etwas Kleines – und etwas Großes bricht.

Nicht, weil der Code schlecht ist. Sondern weil das mentale Modell der Abhängigkeiten nicht mitgewachsen ist.


Das ist der eigentliche Stresstest.

Nicht der Code. Das Verständnis.


Und hier liegt die unangenehme Wahrheit:

Das Problem ist nicht, dass die KI unsicher arbeitet. Das Problem ist, dass sie uns sicher in die Irre führen kann.

Mit grünem Licht. Mit sauberem Code. Und trotzdem falschen Annahmen.


2026 ist nicht das Jahr, in dem die Branche das ignoriert. Es ist das Jahr, in dem sie beginnt, darauf zu reagieren.


Was sich gerade verschiebt

1. Tests entstehen nicht mehr nachgelagert

Moderne Umgebungen generieren Implementierung und Tests parallel.

Das „grüne Licht“ ist nicht mehr nur ein Indikator, sondern Teil des generierten Systems.

Vertrauen verschiebt sich – von der einzelnen Codezeile hin zur Testabdeckung.


2. Verständnis wird rekonstruierbar

Mit RAG über das Repository lässt sich fragen:

„Warum existiert diese Funktion – und wer hängt davon ab?“

Das mentale Modell wird nicht mehr nur aufgebaut. Es kann bei Bedarf wiederhergestellt werden.


3. Abstraktion verschiebt sich weiter nach oben

Die meisten Entwickler verstehen heute keine Speicheradressen mehr. Und das ist kein Problem.

KI-Code ist die nächste Abstraktionsebene.

Der Stresstest liegt nicht mehr im Verstehen jeder Zeile – sondern im Verstehen von Schnittstellen, Verträgen und Tests.


Die eigentliche Verschiebung: Vom Debuggen zum Verifizieren

Die KI erzeugt nicht nur Code. Sie verschiebt Verantwortung.

Weg von: „Habe ich jede Zeile verstanden?“ Hin zu: „Habe ich die richtigen Rahmenbedingungen gesetzt – und die Ergebnisse ausreichend geprüft?“


Der entscheidende Moment ist nicht der Bug. Der entscheidende Moment ist das „funktioniert“.


Ein kurzer Check:

Würde ich den generierten Test verstehen, wenn er fehlschlägt?


Wenn die Antwort „Nein“ lautet, liegt dort der Engpass. Nicht im Code. Sondern im Modell dahinter.


Fazit: Bestanden – oder nur schneller geworden?

Der Stresstest 2026 zeigt kein klares Scheitern. Aber auch keinen vollständigen Erfolg.


Wir sind schneller geworden. Und wir sehen klarer, wo wir vorher schon unsauber gearbeitet haben.


Die Illusion der Kompetenz ist kein KI-Problem. Sie ist ein altes Muster – das durch KI schwerer zu übersehen wird.


Früher konnten wir uns länger darin bewegen. Heute bricht sie schneller auf.


Die eigentliche Antwort ist kurz – und sie tut weh:

Grüne Tests bedeuten nicht „richtig“.
Sie bedeuten nur, dass sich das System nicht widersprochen hat.

Und das reicht nicht.


Der Stresstest ist damit nicht bestanden. Aber er ist sichtbar geworden.


Wir sind schneller geworden. Und wir lernen gerade, ob wir in dieser Geschwindigkeit stabil sein können.


Die offene Frage ist nicht, ob KI uns besser macht.

Die offene Frage ist, ob wir bereit sind, Verantwortung auf einer neuen Ebene zu übernehmen.


Denn die Alternative ist leise:

Dass wir schneller werden. Komplexere Systeme bauen. Und den Unterschied zwischen „funktioniert“ und „verstanden“ verlieren.


Und genau dort entscheidet sich, ob das Fortschritt ist. Oder nur Beschleunigung.

Der nächste Programmier-Standard entsteht vor dem Code

Der nächste Programmier-Standard der Softwareentwicklung wird nicht mehr im Code definiert.

Er entsteht in der Leere davor.

Wir beobachten gerade eine Verschiebung der Zuständigkeit.

Lange Zeit war ein Repository vor allem ein Archiv für menschliche Logik: ein Ort, an dem Entwickler:innen ihre Gedanken in Syntax übersetzen.

Doch mit dem verstärkten Einsatz von KI beginnt sich diese Rolle zu verändern.

Ein Repository wird zunehmend zu einem Habitat für synthetische Intelligenz.

Die Kontrolle migriert.
Weg von der Syntax – hin zur kuratierten Umgebung, in der Systeme arbeiten.

Die alte Frage

Lange Zeit lautete die zentrale Frage der Softwareentwicklung:

Wer schreibt die effizienteste Schleife?

Oder allgemeiner:

Wer kann eine Idee am präzisesten in Code übersetzen?

Dieses Paradigma hat uns weit gebracht.

Aber mit KI verschiebt sich der Schwerpunkt.

Die neue Frage

Die entscheidende Frage könnte künftig eine andere sein:

Wer konstruiert den präzisesten Rahmen, in dem eine KI nicht halluziniert?

Denn moderne Entwicklungsprozesse bestehen immer häufiger aus einer Zusammenarbeit zwischen Menschen und Modellen.

In dieser Zusammenarbeit wird Code zunehmend zu einem Resultat, nicht mehr zum alleinigen Ursprung der Lösung.

Das bedeutet nicht, dass Programmieren unwichtig wird.

Aber der Engpass verschiebt sich.

Wir brauchen vielleicht nicht unbedingt bessere Coder.

Wir brauchen bessere Architekt:innen für Kontext.

Das Experiment: AARRS

Genau aus diesem Gedanken heraus beobachte ich ein kleines Versuchskonstrukt namens

AARRS – AI-Assistant-Ready Repository Specification

Zum Repository auf GitHub

AARRS ist kein Tool und kein Framework.

Es ist eher eine forensische Untersuchung einer einfachen Frage:

Wie muss ein Projekt strukturiert sein, damit eine KI nicht nur rät, sondern tatsächlich versteht?

Die Hypothese dahinter ist simpel:

KI ist nur so gut wie der Kontext, den sie bekommt.

Viele Repositories liefern diesen Kontext aber nur indirekt – verteilt über Code, Commit-Historie und implizites Wissen im Team.

Für Menschen ist das mühsam.
Für Maschinen ist es nahezu unsichtbar.

Was ein KI-lesbares Repository auszeichnet

Ein Repository, das für KI-Assistenz vorbereitet ist, könnte zum Beispiel:

  • klare Einstiegspunkte für nicht-menschliche Leser enthalten
  • explizite Constraints als Leitplanken gegen Entropie definieren
  • maschinenlesbaren Repo-Kontext bereitstellen
  • eine Art Gebrauchsanweisung für Algorithmen mitliefern

Nicht als Ersatz für Architektur.

Sondern als Erweiterung der Dokumentationsebene.

Der mögliche Wendepunkt

Vielleicht erleben wir gerade eine stille Veränderung der Softwareentwicklung.

Eine Verschiebung von

Code-Produktion
hin zu
Problem-Definition und Kontext-Architektur.

Die eigentliche Ausführung rückt zunehmend in den Hintergrund.

Nicht weil sie unwichtig wird.

Sondern weil Maschinen sie immer häufiger übernehmen können.

Ein Artefakt, kein Standard

AARRS ist aktuell nur ein MVP.

Ein Denkanstoß.

Ein Artefakt, das eine Frage sichtbar machen soll.

Vielleicht entsteht daraus irgendwann ein Muster.

Vielleicht auch nicht.

Aber die zugrunde liegende Frage wird bleiben:

Wie bereiten wir unsere Projekte auf die Zusammenarbeit mit KI-Assistenten vor?

Oder anders gefragt:

Wie muss ein Repository aussehen, damit nicht nur Menschen darin denken können – sondern auch Maschinen?

Vom Epic zum Task – Jira Workflow Spickzettel

  1. Notiz: Kurzer Überblick, wie aus einer Idee ein umsetzbarer Task wird – vom großen Epic bis zum kleinsten Arbeitsschritt.

1. Epic – das große Warum

Ein Epic beschreibt ein übergeordnetes Ziel oder Thema, das mehrere Teilbereiche umfasst.
Es ist der Rahmen für ein zusammenhängendes Vorhaben, z. B. „Shopify Basis Theme erstellen“ oder „UX-Überarbeitung Checkout“.

  • Beschreibt den Nutzen und die Vision
  • Wird in Features oder Stories unterteilt
  • Dient der langfristigen Planung

2. Story – das greifbare Ziel

Eine User Story übersetzt das Epic in ein konkretes Ergebnis aus Nutzer:innen-Perspektive.

„Als Nutzer:in möchte ich das Farbschema im Theme testen können, um ein konsistentes Design sicherzustellen.“

  • Fokussiert auf den Mehrwert für Nutzer:innen
  • Definiert Akzeptanzkriterien
  • Kann geschätzt und priorisiert werden

3. Task – der Umsetzungsblock

Ein Task beschreibt die konkrete Arbeit, die nötig ist, um eine Story umzusetzen.
Er ist klein genug, um in einem Sprint abgeschlossen zu werden.

  • Beispiel: „CSS-Variablen für Farbthemen definieren“
  • Kann in Sub-Tasks unterteilt werden
  • Hat klare Done-Kriterien

4. Workflow – vom To-Do bis Done

Der klassische Jira-Ablauf:

  1. To Do – Aufgabe ist definiert
  2. In Progress – in Bearbeitung
  3. In Review – Code- oder Designprüfung
  4. Testing – Funktion wird geprüft
  5. Done – abgenommen und abgeschlossen ✅

Optional: Status wie „Blocked“ oder „On Hold“ markieren Abhängigkeiten.

5. Best Practices 💡

  • Klarheit vor Geschwindigkeit: Jede Story braucht ein „Warum“.
  • Tasks sind messbar: Immer mit Ergebnis oder Output abschließen.
  • Verknüpfungen nutzen: Stories mit ihren Epics und Tasks verbinden.
  • Review nicht vergessen: Ein Done ohne Review ist nur fast fertig.
Spickzettel für den Alltag:
Vom Epic zum Task ist kein bürokratischer Weg – es ist der Weg, aus Ideen Realität zu machen.