Warum Constraints wichtiger sind als kreative Prompts

In Gesprächen über Agentic Coding höre ich oft denselben Satz. "Wir brauchen bessere Prompts."

Im Alltag sehe ich dann häufig Folgendes. Das Ergebnis klingt im ersten Moment gut, im Review tauchen aber dieselben Probleme wieder auf.

Für mich ist der Hebel deshalb ein anderer. Nicht mehr Kreativität, sondern bessere Constraints.

Prompts setzen Richtung. Constraints setzen Grenzen. Und genau diese Grenzen machen den Unterschied zwischen Zufall und verlässlicher Lieferung.

Warum kreative Prompts in der Praxis oft scheitern

Ein kreativer Prompt kann beeindruckend aussehen. Die Antwort wirkt schnell plausibel, die Struktur sieht ordentlich aus, der Ton passt.

Das Problem zeigt sich erst später. Der Code verletzt bestehende Regeln, ignoriert Randfälle oder passt nicht sauber in die Architektur.

Nicht weil das Modell dumm ist. Sondern weil ich ihm zu viel Interpretationsspielraum gelassen habe.

Je offener der Auftrag, desto mehr muss die KI raten. Und dieses Raten wird in Softwareprojekten schnell teuer.

Der entscheidende Perspektivwechsel

Ich behandle ein LLM nicht wie einen kreativen Kollegen, der zwischen den Zeilen alles versteht. Ich behandle es wie einen sehr schnellen, aber wörtlichen Pair-Programming-Partner.

Wenn ich unpräzise bin, bekomme ich unpräzise Ergebnisse. Wenn ich präzise bin, steigen Reproduzierbarkeit und Qualität deutlich.

Für mich gilt deshalb: Wenn der Output schwach ist, liegt der Fehler oft nicht im Modell, sondern im Input.

Was ich unter Constraints verstehe

Ein Constraint ist für mich eine klare technische Leitplanke, die den Lösungsraum begrenzt.

Zum Beispiel:

• keine neuen öffentlichen Methoden,
• nur bestehende Services verwenden,
• keine Änderung am Datenmodell,
• Fehler nur über definierte Exception-Typen,
• Tests müssen grün bleiben,
• keine neuen Abhängigkeiten ohne Begründung.

Mit solchen Leitplanken wird aus "Mach mal" ein klarer, prüfbarer Engineering-Schritt.

Ein kurzes Beispiel aus dem Alltag

Variante A, nur Prompt:

"Baue das Login robuster."

Variante B, Prompt plus Constraints:

"Verbessere den Login-Flow. Nutze nur bestehende Auth-Services. Keine neue öffentliche API. Fehler als AuthenticationFailedException und RateLimitExceededException. Keine Änderung am Datenbankschema. Füge Tests für Lockout und Retry hinzu. Alle bestehenden Tests müssen grün bleiben."

Beide Varianten klingen ähnlich. Die zweite liefert in der Praxis deutlich stabilere Ergebnisse, weil der Rahmen klar ist.

Mein Minimal-Set für gute Agenten-Aufträge

Wenn ich mit Agenten arbeite, definiere ich vorab mindestens diese sieben Punkte:

1. Zielwirkung: Was soll fachlich besser werden?
2. Technischer Rahmen: Was darf nicht verändert werden?
3. Qualitätskriterien: Welche Tests und Checks müssen bestehen?
4. Sicherheitsregeln: Welche Policies gelten zwingend?
5. Architekturgrenzen: Welche Module dürfen betroffen sein?
6. Akzeptanzkriterien: Woran erkenne ich Erfolg konkret?
7. Abbruchkriterien: Wann wird ein Vorschlag verworfen?

Das dauert wenige Minuten und spart später viele Schleifen.

Wie ich dafür Spec Kit nutze

Für die operative Arbeit nutze ich dafür oft den Workflow aus dem Open-Source-Projekt Spec Kit. Der große Vorteil ist für mich, dass Constraints nicht nur im Chat stehen, sondern als Artefakte im Projekt landen.

Der Ablauf bleibt dabei klar:

1. /speckit.constitution, um Prinzipien und Guardrails festzulegen.
2. /speckit.specify, um das Was und Warum zu beschreiben.
3. /speckit.plan, um technische Leitplanken und Architekturentscheidungen festzulegen.
4. /speckit.tasks, um kleine, überprüfbare Arbeitspakete zu erzeugen.
5. /speckit.implement, um kontrolliert umzusetzen statt blind zu generieren.

Gerade bei Teamarbeit hilft mir das, weil dadurch jedes Ergebnis gegen dieselben Regeln geprüft werden kann. Damit werden Constraints reproduzierbar, statt von Person zu Person unterschiedlich ausgelegt zu werden.

Wo ich kreative Prompts trotzdem nutze

Kreative Prompts sind nicht wertlos. Ich nutze sie gezielt dort, wo Exploration gewünscht ist.

Zum Beispiel für:

• erste Lösungsvarianten,
• Strukturvorschläge für Doku,
• Namensideen,
• Diskussionsgrundlagen in frühen Phasen.

Sobald ich in die Umsetzung gehe, wechsle ich auf klare Constraints.

Drei typische Fehler bei Agentic Coding

1) Intent und Umsetzung vermischen

Wenn Ziel, Regeln und Implementierungsdetails ungeordnet in einem Text landen, steigen Missverständnisse auf allen Seiten.

2) Keine Verifikation erzwingen

Ohne Type-Checks, Linter und Tests bleibt KI-Output nicht vertrauenswürdig. Dann wird Geschwindigkeit mit Qualität verwechselt.

3) Kontext nicht pflegen

Wenn Regeln nur im Chat-Verlauf stehen, gehen sie verloren. Deshalb halte ich Vorgaben in stabilen Artefakten wie AGENTS.md und Spezifikationen fest.

Was Entscheider im E-Commerce damit gewinnen

Wenn KI-unterstützte Änderungen ohne klare Leitplanken in Checkout, Preise oder Integrationen laufen, steigt das Risiko schneller als der Nutzen.

Für mich schaffen Constraints deshalb nicht nur Code-Qualität, sie schaffen vor allem planbare Entscheidungen im Tagesgeschäft.

Quelle

Die hier beschriebenen Schritte und Kommandos orientieren sich am öffentlichen Spec-Kit-Workflow:

• github.com/github/spec-kit

Fazit

Agentic Coding funktioniert für mich dann gut, wenn ich Absicht und Ausführung sauber trenne. Die Spezifikation ist die Wahrheit. Der Agent ist das Werkzeug. Ich bin verantwortlich für Bewertung und Freigabe.

Prompts helfen beim Start. Constraints sichern das Ergebnis. Und genau dadurch wird aus schneller Generierung verlässliches Engineering.

Wenn du magst, nutze unseren Projekt-Check, um Architektur, Testreife, Sicherheitspraktiken und Betriebsfähigkeit systematisch zu bewerten.