Vom Vibe zum Kontext: Brauchen wir die Spezifikation noch?

Stand: Oktober 2026. Wer heute mit Claude Code, Copilot, Cursor oder ähnlichen Werkzeugen arbeitet, kennt das Spannungsfeld: Einerseits wirken die Modelle inzwischen so stark, dass ein grober Arbeitsauftrag oft erstaunlich weit trägt. Andererseits merkt man in echten Projekten schnell, dass gute Resultate selten nur aus einem guten Einzeiler entstehen. Genau an dieser Stelle verläuft die Linie von Vibe Coding zu Context Engineering. Die zugespitzte These dieses Artikels lautet deshalb: Ja, enge Prompt-Vorgaben werden in manchen Situationen weniger wichtig. Aber der Aufwand verschwindet nicht – er wandert vom Formulieren einzelner Prompts in das Gestalten des Projektkontexts.

Vibe Coding: Begriff, Versprechen, frühe Praxis

Der Begriff „vibe coding“ geht auf Andrej Karpathy zurück. In seinem vielzitierten X-Post vom 2. Februar 2025 beschrieb er einen Stil, bei dem man „den Code fast vergisst“, Änderungen in Alltagssprache anfordert, Fehler einfach zurück ins Modell kippt und häufig sogar „Accept All“ drückt, ohne Diffs gründlich zu lesen. Das war keine präzise Methodik, sondern eher eine bewusst zugespitzte Beschreibung einer neuen Praxis: weniger tippen, mehr sagen, schnell iterieren, auf das Modell vertrauen.

Der Reiz daran ist offensichtlich. Für Greenfield-Ideen, Wegwerf-Prototypen, UI-Skizzen oder kleine Hilfstools kann dieses Vorgehen sehr produktiv sein. Wer ein Formular, ein kleines Script oder einen simplen Service auf einem verbreiteten Stack bauen will, profitiert davon, dass Modelle sehr viele bekannte Muster bereits aus dem Training kennen. In solchen Situationen ist Vibe Coding nicht bloß Faulheit, sondern eine Form von Hebel: weniger Reibung zwischen Idee und erstem lauffähigem Ergebnis.

Aber schon in Karpathys Ursprungstext steckt die Warnung mit drin. Er schreibt ausdrücklich über „throwaway weekend projects“ und darüber, dass der Code jenseits seiner üblichen Verständnistiefe wachsen kann. Genau dort beginnen die Risiken: Unscharfe Anforderungen, blinde Übernahme von Änderungen, schwer erkennbare Sicherheitsprobleme und technische Schulden, die erst später sichtbar werden. Unabhängige Studien aus 2025 und 2026 stützen genau diese Skepsis: LLM-generierter Code kann funktional wirken und trotzdem Sicherheits- oder Qualitätsprobleme enthalten, die ohne zusätzliche Prüfung leicht durchrutschen.

Der Umschwung: Warum aus dem lockeren Prompt ein Kontext-Handwerk wurde

Dass sich anschließend der Begriff Context Engineering durchgesetzt hat, ist kein Zufall. Anthropic beschreibt Context Engineering als die Weiterentwicklung von Prompt Engineering: Nicht nur die Worte im Prompt zählen, sondern die gesamte Menge an Tokens und Signalen, die das Modell in einer Situation sieht – Systemanweisungen, Tools, externe Daten, Message History, MCP-Kontext und weitere Zustände.Der Schwerpunkt verschiebt sich also von „Wie formuliere ich die Anfrage?“ zu „Welche Informationen soll das Modell in welchem Moment überhaupt sehen?“

Der Grund dafür liegt in der Art, wie heutige Coding- und Agentenwerkzeuge arbeiten. Moderne Agenten operieren nicht mehr nur in einem einzigen Turn, sondern in Schleifen mit Werkzeugen, Zwischenständen und Folgeentscheidungen. Dabei wächst der potenziell relevante Kontext ständig. Es reicht dann nicht, ein Modell mit möglichst viel Text zu überschütten. Man muss auswählen, strukturieren und zur richtigen Zeit nachladen.

Genau deshalb sind Projektdateien wie CLAUDE.md oder AGENTS.md, gespeicherte Memory-Einträge, Skills und Subagents so wichtig geworden. Anthropic dokumentiert offen, dass CLAUDE.md-Dateien dauerhafte Projektregeln, Architekturhinweise und Arbeitskonventionen in jede Session laden, während Auto Memory Korrekturen und Muster über Sessions hinweg verfügbar macht. Subagents wiederum dienen explizit dazu, Teilaufgaben in einem eigenen Kontextfenster abzuarbeiten, damit die Hauptkonversation nicht mit Nebensächlichkeiten vollläuft. Das ist genau das Gegenteil von „ein großer Prompt löst alles“.

Context Engineering meint deshalb nicht primär längere Prompts. Es meint bessere Kontextarchitektur. Welche Projektregeln gelten immer? Welche Informationen braucht nur ein Spezialagent? Was wird dauerhaft gespeichert, was nur just in time geladen? Und was muss der Mensch explizit vorgeben, weil das Modell es unmöglich aus dem Training kennen kann?

Die These auf dem Prüfstand

Jetzt zur eigentlichen These: „Heutige Modelle sind so gut, dass enge Kontextvorgaben oft nicht mehr nötig sind. Häufig reichen wenige Sätze, die das Projekt beschreiben.“

Der faire Befund ist: Das stimmt manchmal. Und genau das macht die These so attraktiv.

Sie trägt vor allem dort, wo Aufgaben nah an verbreiteten Mustern liegen. In einem frischen Projekt mit Standard-Stack, bekannten Bibliotheken und überschaubarem Zielbild können Modelle erstaunlich viel ergänzen. Ein grober Auftrag wie „baue einen kleinen FastAPI-Service mit JWT-Login, PostgreSQL und Tests“ liefert heute oft schon einen erstaunlich brauchbaren Startpunkt. Für kleine Features, Prototypen oder interne Tools ist der Abstand zwischen knapper Anweisung und lauffähigem Entwurf deutlich kleiner geworden. Das liegt nicht daran, dass Kontext unwichtig wäre, sondern daran, dass ein Teil des Kontexts bereits im Modell steckt: Framework-Konventionen, Standardprojektstrukturen, übliche Testmuster, bekannte API-Formen.

Die These bricht aber dort, wo das Entscheidende nicht im allgemeinen Trainingswissen steckt. Große, gewachsene Codebasen enthalten lokale Wahrheiten: interne Abkürzungen, historische Architekturentscheidungen, Teamkonventionen, Sonderfälle im Deployment, implizite Sicherheitsannahmen, Legacy-Schnittstellen und Wartbarkeitsregeln. Genau dieses Wissen ist für das Modell nicht erratbar. Wer hier mit nur zwei Sätzen startet, bekommt nicht „weniger Spezifikation“, sondern häufiger Halluzinationen mit professionellem Tonfall.

Hinzu kommt ein zweiter Bruchpunkt: Qualität und Sicherheit sind nicht automatisch aus hoher Modellgüte ableitbar. Eine quantitative Analyse von 2025 kommt zu dem Schluss, dass funktionale Korrektheit kein verlässlicher Indikator für Codequalität und Sicherheit ist; gerade deshalb seien statische Analysen und zusätzliche Verifikation nötig. Eine weitere Studie über agentische Program-Reparatur auf SWE-bench zeigt, dass agentische Workflows ebenfalls neue Schwachstellen erzeugen können – besonders dann, wenn mehr Autonomie erlaubt wird und Kontext über Issue und Codebasis unvollständig ist. Kurz gesagt: Bessere Modelle reduzieren manche Reibung, aber sie eliminieren nicht die Kosten fehlender Kontextinformation.

Ein kleines Experiment für den Alltag

Wer die These selbst prüfen will, braucht keine große Forschungsumgebung. Ein kleines Teamexperiment reicht. Nimm eine identische Aufgabe in einer realen, aber nicht geschäftskritischen Codebasis – zum Beispiel: „Füge eine neue Filteroption im Suchdialog hinzu, inklusive Tests und Dokumentation.“ Lasse das Modell einmal nur mit einer knappen Kurzbeschreibung arbeiten. Im zweiten Durchlauf gibst Du strukturierten Kontext dazu: relevante Dateien, Architekturhinweis, Akzeptanzkriterien, Projektregeln, Testbefehl und zwei typische Stolperfallen.

Verglichen werden nicht nur „geht“ oder „geht nicht“, sondern auch: Zahl der Rückfragen, Zahl der nachträglichen Korrekturen, Qualität der Tests, Einhaltung von Konventionen, Lesbarkeit der Änderungen und Review-Aufwand. Meine Erwartung wäre: Bei kleinen, generischen Aufgaben fällt der Unterschied kleiner aus als noch 2024. Aber sobald Projektwissen, Randbedingungen und nicht offensichtliche Standards wichtig werden, dürfte der strukturierte Kontext robuster abschneiden.

Wo die Grenze liegt

Die Grenze verläuft also weniger zwischen „alte“ und „neue“ Modelle als zwischen Aufgabentypen. Vibe-nahe Arbeitsweisen funktionieren dort gut, wo das Modell fehlende Details plausibel aus bekannten Mustern ergänzen kann. Sie werden riskant dort, wo fehlende Details fachlich, architektonisch oder sicherheitsrelevant sind.

Besonders kritisch wird es in vier Situationen. Erstens bei großen Altprojekten: Hier ist lokales Wissen wichtiger als allgemeines Frameworkwissen. Zweitens bei impliziten Teamregeln: Wenn Naming, Fehlerbehandlung oder Freigabepraxis nicht explizit gemacht werden, optimiert das Modell auf Plausibilität, nicht auf Eure Realität. Drittens bei Sicherheits- und Wartbarkeitsanforderungen: Studien zeigen, dass AI-generierter Code weiterhin systematische Schwächen aufweisen kann. Viertens bei längeren agentischen Ketten: Je mehr Schleifen, Tools und Zwischenschritte beteiligt sind, desto wichtiger wird gutes Kontextmanagement statt bloßer Hoffnung auf Modellintelligenz.

Fazit und Empfehlung

Verschwindet der Spezifikationsaufwand also? Nein. Er verschiebt sich. Weniger wichtig werden manche Prompt-Tricks aus der Frühphase: künstlich aufgeblasene Rollenprosa, starre Formulierungsrezepte und überoptimierte Einmal-Prompts. Wichtiger werden dagegen die Dinge, die das Modell nicht aus dem Weltwissen ableiten kann: Akzeptanzkriterien, Projektregeln, Architekturgrenzen, Entscheidungslogs, relevante Dateien, Test- und Sicherheitsanforderungen.

Meine konkrete Empfehlung lautet deshalb: Nutze kurze Prompts dort, wo das Problem generisch ist. Investiere aber gezielt in wiederverwendbaren Projektkontext, sobald dieselben Regeln mehrfach gelten. Schreibe CLAUDE.md oder AGENTS.md, halte Akzeptanzkriterien knapp und explizit fest, nutze Memory für wiederkehrende Korrekturen und trenne Recherche, Umsetzung und Review stärker über spezialisierte Agenten oder Subagents. Die Zukunft liegt nicht in der Wahl zwischen Vibe Coding und Spezifikation. Sie liegt darin, zu wissen, wann ein paar Sätze reichen – und wann fehlender Kontext später teurer wird als jede saubere Vorgabe am Anfang.