Die ersten 20 Minuten sind Magie.
Danach braucht dein KI-Projekt ein System.

Die Szene kennt inzwischen fast jeder, der ernsthaft mit Coding Agents arbeitet. Am Anfang fühlt sich alles leicht an. Nach ein paar Sessions merkst du, dass Features aneinander vorbeibauen, alte Stellen wieder kaputtgehen und der Agent in Fehlerschleifen hängt. Andrej Karpathy hat das einmal so beschrieben, dass diese Agenten oft wie schlampige Junioren arbeiten: Der Code sieht auf den ersten Blick in Ordnung aus. Die Probleme sitzen im Detail.

Drei Dinge, die Agenten dir nicht sagen

Bessere Modelle ändern das Tempo. Sie ändern nicht automatisch die Arbeitsweise. Drei Muster kommen immer wieder:

• Stille Annahmen. Fehlt eine Vorgabe, entscheidet der Agent trotzdem. Er biegt ab, schreibt dazu, wählt einen Stack, und sagt dir das oft nicht. Du merkst es erst, wenn die nächste Session auf einem Fundament aufsetzt, das du nie so gewollt hast.
• Overengineering. Agenten lieben Komplexität. Wo 100 Zeilen reichen, entstehen 1.000. Jede zusätzliche Schicht macht die App unübersichtlicher, bis der Agent selbst den Faden verliert.
• Jasager-Modus. Fragst du, ob Idee X gut ist, kommt in den meisten Fällen: ja, super, machen wir. Was du brauchst, ist ein Sparringspartner, der widerspricht. Den bekommst du nicht, wenn du ihn nicht dazu zwingst.

Das Ergebnis ist immer dasselbe. Die App bläht sich Session für Session auf. Irgendwann durchblickst du nicht mehr, und der Agent auch nicht. Dann baut er an der Anforderung vorbei oder macht Bestehendes kaputt. Genau das ist der Moment, in dem aus einem schnellen Prototyp ein teures Chaos wird.

Nicht besser prompten. Ein System bauen.

Die gute Nachricht aus der Praxis: Diese Probleme lassen sich fast vollständig vermeiden. Nicht mit längeren Prompts. Mit einem wiederholbaren Ablauf. Drei Bausteine reichen.

1. Erst die Spezifikation, dann der Code

Bevor der Agent eine Zeile schreibt, steht fest, was gebaut wird. Das Produkt zerlegst du in einzelne Features. Jedes Feature bekommt ein kurzes Anforderungsdokument mit Akzeptanzkriterien. Das Format ist alt und gut:

Angenommen ein Besucher ist auf der Registrierungsseite. Wenn er Vorname, Nachname, eine gültige E-Mail und ein Passwort mit mindestens acht Zeichen absendet, dann wird ein Konto angelegt.

Das klingt trocken. Es ist der größte Hebel. Du kannst später genau daran prüfen. Der Agent kann seine eigene Arbeit daran messen. Anthropic beschreibt das für Claude Code ähnlich: Klare Akzeptanzkriterien schlagen vages Prompting. Wir haben das schon länger unter Spec-Driven Development eingeordnet. Hier ist der praktische Grund, warum es bei Agenten so hart zählt.

2. Context, der den Rahmen setzt

Context Engineering heißt nichts anderes: Du gibst dem Agenten zur richtigen Zeit das richtige Wissen. Dann trifft er weniger stille Annahmen. Vier Werkzeuge haben sich bewährt:

• Eine Start-Datei. AGENTS.md oder CLAUDE.md: kurze Projektbeschreibung, grobe Struktur, Arbeitsregeln. Maximal eine Seite. Mehr wird ignoriert oder verdünnt. Warum zu viel Kontext kippt, steht in Mehr Context, bessere Ergebnisse?.
• Skills. Klare Arbeitsanleitungen in Textform: so schreibst du Specs, so implementierst du, so testest du. Schritt 1, Schritt 2, Schritt 3.
• Subagents. Kleine Helfer für Teilaufgaben, ohne die ganze Chat-Historie. Sie bekommen einen Auftrag und laufen los. Spezialisieren kannst du sie, musst du aber nicht.
• Aktuelle Doku statt Trainingsgedächtnis. Agenten kennen Frameworks oft in einer alten Version. Ein MCP-Zugang zur aktuellen Dokumentation (etwa Context7) verhindert, dass Integrationen auf veraltetem Wissen aufsetzen.

3. Du nimmst ab. Immer.

Human in the Loop klingt nach Hype. Es ist das Gegenteil: Du liest die Spec, du liest den Testbericht, du prüfst das Ergebnis. Autonome Loops, die stundenlang allein bauen, sehen beeindruckend aus. In der Praxis wirfst du danach oft die Hälfte weg. Tokens sind dafür zu schade. Urteil ist der Teil, den kein Agent ersetzt.

Das ist auch unsere Haltung zu KI: Tempo ja, Verantwortung bleibt beim Menschen. Genau das meinen wir mit Handarbeit. Mehr dazu in Von Vibe Coding zu Agentic Engineering.

Ein Ablauf, den du wiederholen kannst

So sieht das System in einer Session aus. Immer gleich, Feature für Feature:

1. Briefing. Was ist das Produkt, für wen, was liegt außerhalb.
2. Interview. Der Agent fragt nach, statt dass du dir alle Anforderungen aus den Fingern saugen musst.
3. Spezifikation. Anforderungen plus Akzeptanzkriterien, von dir freigegeben.
4. Systemdesign. Welche Seiten, Komponenten, Felder. Und: wie gehen wir mit personenbezogenen Daten um.
5. Umsetzungsplan. Eine Checkliste gegen die Spec. Das grenzt ein, was gebaut wird, und bremst Overengineering.
6. Implementierung. Erst jetzt schreibt der Agent Code.
7. Qualitätsprüfung. Eigene Tests, Abgleich mit den Akzeptanzkriterien, dann deine Abnahme.

Das ist kein neuer Prozess. Es ist der alte Software-Lebenszyklus, nur so geschnitten, dass ein Agent ihn nicht überspringen kann. Wer nur vibecodet, überspringt genau diese Schritte. Deshalb fühlt sich der Anfang magisch an und das Ende teuer.

Was das für den Mittelstand heißt

Für uns ist das keine Tool-Debatte. Es entscheidet, ob aus einem schnellen Prototyp ein System wird, das im Alltag hält. Eine Registrierung, die DSGVO-tauglich ist. Eine Zahlung, die du nachvollziehen kannst. Eine Automatisierung, die du abschalten kannst, wenn sie falsch liegt.

Wenn du intern mit Cursor, Claude Code oder ähnlichen Agenten arbeitest, reicht oft schon dieser Rahmen: eine Seite Projektregeln, Specs vor Code, Abnahme nach jedem Feature. Wenn du das nicht selbst aufsetzen willst, bauen wir genau so: erst klären, dann umsetzen, und du behältst Code, Daten und Zugänge.