Überall siehst du gerade, wie jemand in 20 Minuten eine App mit Claude Code generiert. Am Anfang fühlt sich das auch magisch an: Nach ein paar Prompts gibt es ein vorzeigbares Ergebnis, und dein eigenes Software-as-a-Service-Produkt scheint greifbar nah.
Aber der Schein trügt. Während du Registrierung, Bezahlung, KI-Integration und weitere Features einbaust, wächst dein Code im Hintergrund unkontrolliert. In diesem Artikel erkläre ich dir, warum das passiert und welches System ich nutze, um von der Idee zu einem fertigen, sicheren Produkt zu kommen.
Kurz zu mir: Ich bin seit über 14 Jahren in Produktmanagement und Softwareentwicklung unterwegs, habe 2021 meine eigene Softwareagentur gegründet und auf 14 Mitarbeitende aufgebaut. In dieser Zeit habe ich über 150 Softwareprojekte durchgeführt oder begleitet.
Die 3 Probleme von Coding Agents
Auch aktuelle Modelle wie Opus 5 oder GPT 5.6 haben Schwächen, die dir spät im Projekt das Genick brechen können. Andrej Karpathy, Gründungsmitglied von OpenAI, hat es auf X treffend beschrieben: Coding Agents arbeiten immer noch wie schludrige Junior-Entwickler. Der Code sieht auf den ersten Blick gut und funktional aus. Erst bei genauerem Hinsehen merkst du, dass etwas nicht stimmt.
Konkret sind es drei Probleme.
1. Stille Annahmen
Sobald ein Coding Agent unsicher ist, zu wenig Informationen oder keine klare Vorgabe hat, trifft er Entscheidungen für dich. Er ergänzt hier etwas, biegt dort falsch ab. Das Fiese: Er sagt dir nicht einmal Bescheid.
2. Overengineering
Agents lieben Komplexität. Plötzlich stehen an einer Stelle 1.000 Zeilen Code, wo 100 gereicht hätten. Je öfter das passiert, desto aufgeblähter und unübersichtlicher wird deine App, bis der Agent selbst den Überblick verliert. Gerade bei Opus 5 ist mir das wieder stark aufgefallen.
3. Der Ja-Sager-Modus
Fragst du, ob X eine gute Idee ist, bekommst du in den meisten Fällen: „Ja, super Idee, machen wir genau so.“ Agents hinterfragen selten, ob dein Vorgehen wirklich das beste ist. Eigentlich willst du aber einen ehrlichen Sparringspartner, der auch mal sagt: „Lass uns das lieber anders machen.“
Das Ergebnis: eine App, die niemand mehr versteht
Mit jeder Session bläht sich deine App weiter auf und wird fragiler. Irgendwann blickst du selbst nicht mehr durch, und dein Agent auch nicht. Das merkst du daran, dass er an Anforderungen vorbeibaut, sich in Fehlerschleifen verfängt oder bestehende Funktionen kaputt macht.
Die Lösung: ein System statt besserer Prompts
Die gute Nachricht: Diese Probleme lassen sich fast komplett vermeiden. Nicht durch besseres Prompting, sondern indem du bei der Entwicklung ein System nutzt. Ein solches System hat drei Bestandteile:
| Baustein | Löst welches Problem? |
|---|---|
| Strukturierter Prozess mit Spezifikationen | Grenzt ein, was gebaut wird, und macht Ergebnisse prüfbar |
| Context Engineering | Gibt Rahmenbedingungen vor und verhindert stille Annahmen |
| Human in the Loop | Du nimmst Ergebnisse ab, bevor sich Fehler aufstapeln |
Baustein 1: Spezifikationen mit Akzeptanzkriterien
Statt direkt loszulegen, definierst du zuerst, was gebaut werden soll. Du zerlegst dein Produkt in einzelne Features und hältst jedes in einer Spezifikation fest, also einem Anforderungsdokument. So arbeitet man auch in der klassischen Softwareentwicklung.
In die Spezifikation schreibst du, allein oder mit Hilfe von KI, alle Anforderungen an die Funktion, inklusive Akzeptanzkriterien. Die formuliert man üblicherweise so: Angenommen (Vorbedingung), wenn (Aktion), dann (Ergebnis).
Angenommen, ein Besucher ist auf der Registrierungsseite.
Wenn er Vorname, Nachname, eine gültige E-Mail und ein Passwort mit mindestens 8 Zeichen eingibt und absendet,
dann wird ein Konto angelegt.
Solche Kriterien helfen doppelt. Du kannst die App später genau danach prüfen. Und dein Agent kann seine eigenen Ergebnisse damit abgleichen. Claude die Möglichkeit zu geben, seine Arbeit selbst zu überprüfen, ist laut Anthropic einer der größten Hebel für gute Ergebnisse mit Claude Code.
Unterm Strich lässt du Claude also erst entwickeln, wenn die Spezifikation für ein Feature fertig ist. Dieses Vorgehen heißt Spec-Driven Development.
Baustein 2: Context Engineering
Context Engineering heißt im Kern: Du gibst Claude gezielt das richtige Wissen zum richtigen Zeitpunkt. Damit steckst du den Rahmen ab, in dem sich der Agent bewegt, und nimmst ihm den Raum für stille Annahmen. Die wichtigsten Werkzeuge:
- CLAUDE.md bzw. AGENTS.md: Alles, was der Agent zum Start einer Session wissen muss: kurze Projektbeschreibung, Projektstruktur, Arbeitsworkflow, Verhaltensregeln. Maximal etwa eine Seite.
- Skills: Arbeitsanleitungen in einfachem Textformat. Du beschreibst Schritt für Schritt, wie Claude eine Aufgabe erledigen soll, etwa Anforderungen schreiben, entwickeln oder testen.
- Subagents: Kleine Helfer, die der Hauptagent für parallele Aufgaben dazuholt. Sie kennen den bisherigen Chatverlauf nicht und starten nur mit einem Auftrag vom Hauptagenten. Du kannst aber spezialisierte Subagents vorkonfigurieren.
- MCP-Server: Verbindungen zu externen Systemen. Sehr sinnvoll ist zum Beispiel Context7. Coding Agents bedienen sich sonst aus ihren Trainingsdaten, die bei Schnittstellen und Frameworks oft veraltet sind. Context7 gibt ihnen Zugriff auf die aktuelle Dokumentation.
So sieht der Prozess bei mir aus
Mein System durchläuft für jedes Feature dieselben Schritte:
- Spezifikation: Claude bekommt zuerst ein allgemeines Projektbriefing. Dann interviewt er mich zu den Anforderungen des Features. Ich muss mir also nicht selbst überlegen, welche Informationen er braucht, sondern beantworte einfach seine Fragen.
- Architektur: Claude prüft, welche Seiten das Feature braucht, welche Komponenten auf diese Seiten gehören, welche Felder und Buttons und in welcher Anordnung. Nebenbei prüft er relevante Themen wie den Datenschutz, wenn personenbezogene Daten verarbeitet werden.
- Umsetzungsplan: Auf Basis von Spezifikation und Systemdesign schreibt Claude eine Checkliste, was er im Code umsetzen muss, und prüft, ob damit alle Akzeptanzkriterien abgedeckt sind. Dieser Schritt grenzt ein, was gebaut wird, und verhindert so Overengineering.
- Implementierung: Claude setzt den Plan um.
- Qualitätsprüfung: Der wichtigste Schritt. Claude schreibt Tests, prüft, ob der Code funktioniert, und ob alle Anforderungen und Akzeptanzkriterien erfüllt sind.
Diesen Ablauf wiederholst du für jedes Feature. Weil er immer gleich ist, bekommst du reproduzierbare Ergebnisse in hoher Qualität.
Baustein 3: Human in the Loop
Der dritte Baustein bist du. Du nimmst die Ergebnisse deines Agents Schritt für Schritt ab: Du liest die Spezifikation, schaust in den Testbericht und prüfst das Endergebnis auf Vollständigkeit und Funktion.
Viele sprechen gerade davon, Agents möglichst lange autonom entwickeln zu lassen. Ich habe aber bisher keinen solchen Prozess gesehen, bei dem man danach nicht die Hälfte wegwerfen konnte, weil es doch nicht dem entsprach, was man wollte. Dafür sind mir meine Tokens ehrlich gesagt zu schade. Deshalb halte ich diesen Schritt nach wie vor für unverzichtbar.
Einordnung: Prompts sind der kleinste Hebel
Die Probleme von Coding Agents verschwinden nicht mit dem nächsten Modell. Stille Annahmen, Overengineering und der Ja-Sager-Modus sind typische Schwächen, die du mit einem guten Prompt nur abmilderst. Mit einem System aus Spezifikationen, gezieltem Kontext und deiner Abnahme kontrollierst du sie.
Für eine schnelle Demo reicht Vibe Coding. Sobald du ein Produkt bauen willst, das echte Nutzer, Zahlungen und Daten verarbeitet, brauchst du einen strukturierten Entwicklungsprozess. Wenn du gerade erst einsteigst, findest du in meiner Anleitung, wie du mit Claude Code deine erste Web-App entwickelst, die Grundlagen dafür.
