KI-Coding braucht bessere Spezifikationen, nicht weniger Architektur

Auf X wird gerade über GitHubs spec-kit, Spec-Driven Development und die Idee diskutiert, dass KI-Werkzeuge nicht einfach auf vage Prompts reagieren, sondern Spezifikationen ausführen sollten.

Das klingt nach einer Tool-Debatte. Ist es aber nicht.

Für Gründer, Product Owner und CTOs ist der entscheidende Punkt viel einfacher: KI-unterstützte Softwareentwicklung macht Produkturteil und Architektur nicht überflüssig. Sie macht beides wichtiger.

Wenn Code schneller entsteht, wird unklare Absicht teurer.

Der Engpass verschiebt sich. Die Frage lautet nicht mehr nur: Kann jemand dieses Feature implementieren? Die Frage wird: Wissen wir genau, was gebaut werden soll, warum es wichtig ist, was nicht kaputtgehen darf, welche Kompromisse akzeptabel sind und woran wir erkennen, dass das Ergebnis gut ist?

Dort beginnt ernsthafte KI-Delivery.

Die Lektion hinter dem Trend

Die letzte Welle der KI-Coding-Euphorie drehte sich stark um Geschwindigkeit.

Man beschreibt eine App in natürlicher Sprache, ein Agent erzeugt Dateien, behebt Fehler, ergänzt Authentifizierung, verbindet eine Datenbank und deployed einen funktionierenden Prototyp. Für frühe Exploration ist das wirklich nützlich. Es senkt die Kosten, Ideen auszuprobieren. Teams sehen schneller, welche Form ein Produkt annehmen könnte, bevor Monate an Budget gebunden werden.

Aber Geschwindigkeit hat eine Falle.

Wenn der Prompt vage ist, wird trotzdem Code erzeugt. Wenn eine Geschäftsregel fehlt, wird der Agent eine annehmen. Wenn eine Sicherheitsanforderung nicht genannt wird, wählt das Tool möglicherweise den einfachsten Weg. Wenn die Architektur unklar ist, kann die Implementierung im Browser trotzdem beeindruckend aussehen.

Das sichtbare Ergebnis kommt schnell.

Die versteckten Entscheidungen kommen mit.

Darum ist die aktuelle Diskussion über Spec-Driven Development interessant. Der nützliche Teil ist nicht ein einzelnes Tool oder ein bestimmter Befehlssatz. Der nützliche Teil ist der Denkwechsel: Bevor ein KI-Agent Code schreibt, braucht das Team einen klaren Vertrag darüber, was die Software leisten soll.

”Vibe Coding” ist kein Betriebsmodell

Vibe Coding ist gut für Exploration.

Es ist kein vollständiges Betriebsmodell für ein ernsthaftes Produkt.

Es ist nichts falsch daran, mit KI ein Interface zu skizzieren, einen Workflow zu testen oder einen Wegwerf-Prototyp zu bauen. Im Gegenteil: Das kann ein sehr sinnvoller Einsatz von KI sein. Der Fehler entsteht, wenn die erste funktionierende Version so behandelt wird, als hätte sie bereits die Disziplinen durchlaufen, die produktive Software braucht.

Ein Prototyp beantwortet eine Frage:

Kann diese Idee schnell sichtbar gemacht werden?

Ein Produkt muss andere Fragen beantworten:

Löst es das richtige Kundenproblem?
Passt der Workflow zu echter Arbeit?
Bleibt das Datenmodell sinnvoll, wenn das Geschäft wächst?
Sind Rollen und Berechtigungen explizit?
Lässt sich das System testen, betreiben und ändern?
Versteht ein anderer Entwickler es in sechs Monaten noch?
Was passiert, wenn ein Edge Case in Produktion auftaucht?

KI kann bei all dem helfen. Aber nur, wenn das Team ihr ein besseres Ziel gibt als “bau diese App”.

In der Spezifikation steckt das Produkturteil

Eine gute Spezifikation ist kein bürokratisches Dokument, das nur einen Prozess zufriedenstellt.

Sie ist der Ort, an dem wichtige Produkt- und Geschäftsentscheidungen explizit werden.

Für KI-unterstützte Entwicklung sollte eine nützliche Spezifikation zuerst die Absicht des Systems beschreiben, nicht sofort die Implementierung. Sie sollte Business Outcome, Nutzer, Workflows, Einschränkungen und Akzeptanzkriterien so klar machen, dass ein Mensch oder Agent sinnvoll damit arbeiten kann.

Statt einen Agenten zu bitten, “ein Kundenportal zu bauen”, sollte das Team ausdrücken können:

wer die Nutzer sind;
welche Aufgaben sie erledigen müssen;
welche Daten sie sehen dürfen;
welche Daten sie nie sehen dürfen;
welche Workflows Zustimmung brauchen;
welche Teile auditierbar sein müssen;
welche Integrationen nötig sind;
wie Erfolg aussieht;
welche Kompromisse für die erste Version erlaubt sind.

Das ist nicht einfach ein längerer Prompt.

Es geht darum, Mehrdeutigkeit zu reduzieren, bevor Mehrdeutigkeit zu Software wird.

Produkt-Spezifikation und technischen Plan trennen

Eine praktische Disziplin ist besonders wichtig: Das “Was” sollte vom “Wie” getrennt werden, bis beides sauber betrachtet wurde.

Die Produkt-Spezifikation erklärt, was die Software erreichen soll und warum. Sie sollte nicht vorschnell jedes technische Detail entscheiden.

Der technische Plan übersetzt diese Absicht danach in Architektur:

Datenmodell;
API-Grenzen;
Frontend-Struktur;
Authentifizierung und Autorisierung;
Integrationsstrategie;
Deployment-Modell;
Testansatz;
Observability;
operative Verantwortung.

KI-Agenten verwischen diese Ebenen oft. Ein Prompt fragt nach einem Feature, und der Agent entscheidet sofort über Libraries, Datenbankstrukturen, Ordnerlayouts und API-Konventionen. Für einen Prototyp kann das in Ordnung sein. In einem echten Produkt haben diese Entscheidungen Kosten.

Das falsche Datenmodell bremst jedes spätere Feature. Der falsche Autorisierungsansatz wird zum Sicherheitsproblem. Die falsche Integrationsgrenze macht den Betrieb mühsam. Die falsche Teststrategie macht schnelle Lieferung fragil.

Architektur ist keine Zeremonie. Sie ist die Art, wie ein Unternehmen Optionen offenhält.

Akzeptanzkriterien sollten ausführbar werden

Die stärkste Spezifikation ist eine, die das Team testen kann.

Hier wird KI-unterstützte Entwicklung wirklich stark. Wenn das gewünschte Verhalten klar ist, kann ein Agent Tests, Implementierungsaufgaben, Edge-Case-Listen und Review-Checklisten erzeugen. Er kann Code gegen die beabsichtigte Funktion prüfen. Er kann helfen, Lücken zwischen Spezifikation und Umsetzung zu finden.

Das funktioniert aber nur, wenn Akzeptanzkriterien konkret sind.

Schwache Akzeptanzkriterien klingen so:

“Das Dashboard soll benutzerfreundlich sein.”
“Der Import soll Fehler behandeln.”
“Admins sollen Kunden verwalten können.”

Bessere Akzeptanzkriterien klingen so:

“Ein Nutzer mit der Rolle Finance kann Rechnungen nur für sein eigenes Unternehmen exportieren.”
“Wenn eine CSV-Zeile nicht validiert werden kann, läuft der Import weiter, speichert die abgelehnte Zeile und zeigt den Grund.”
“Ein Admin kann ein Kundenkonto deaktivieren, aber die Aktion braucht Bestätigung und wird ins Audit-Log geschrieben.”

Solche Aussagen sind nicht nur klarer für Menschen. Sie sind auch viel besserer Input für KI-Agenten.

Sie können zu Tests werden. Zu Implementierungsaufgaben. Zu Review-Kriterien. Und damit zum Unterschied zwischen einer überzeugenden Demo und einem verlässlichen System.

Spezifikationen sind nicht für immer eingefroren

Ein häufiger Einwand lautet, dass Spezifikationen zu starr für moderne Produktentwicklung wirken.

Der Einwand ist berechtigt, wenn die Spezifikation als eingefrorenes Dokument behandelt wird.

Der bessere Ansatz in KI-unterstützter Entwicklung ist eine lebende Spezifikation. Sie ändert sich, wenn das Team lernt, aber sie ändert sich bewusst. Wenn eine Entscheidung geändert wird, ändert sich die Spezifikation. Wenn sich die Architektur ändert, wird die Begründung festgehalten. Wenn ein Feature gestrichen wird, wird das Non-Goal explizit.

Das ist wichtig, weil KI-Werkzeuge gut darin sind, aus Kontext weiterzuarbeiten.

Wenn der Kontext chaotisch, veraltet oder widersprüchlich ist, übernimmt der Agent dieses Chaos. Wenn ein Projekt eine klare Produkt-Spezifikation, aktuelle Architektur-Notizen und explizite Einschränkungen hat, steigt die Chance auf nützliche Ergebnisse erheblich.

Die Spezifikation wird zum gemeinsamen Gedächtnis für Team und Werkzeuge.

Das ist besonders wertvoll in kleinen Unternehmen und im Mittelstand, wo Wissen oft in wenigen Köpfen steckt. KI kann Delivery beschleunigen, aber sie kann nicht sicher jede kommerzielle, operative und regulatorische Einschränkung aus einem kurzen Prompt ableiten.

Was das für Gründer ändert

Für Gründer lautet die praktische Lektion nicht: Hört auf, KI-Tools zu nutzen.

Die Lektion lautet: Nutzt KI für Geschwindigkeit, aber gebt Produktklarheit nicht ab.

Bevor ein KI-Tool die nächste Version baut, sollten ein paar unbequeme Fragen beantwortet sein:

Welches kleinste Geschäftsergebnis muss dieses Release erreichen?
Welche Nutzer und Workflows sind im Scope?
Welche Workflows sind explizit nicht im Scope?
Mit welchen Daten arbeitet das System?
Was würde rechtliches, operatives oder reputatives Risiko erzeugen?
Welche Entscheidungen kann man später ändern, und welche werden teuer?
Was muss wahr sein, bevor echte Kunden es nutzen?

Das muss kein schwerer Enterprise-Prozess werden. Für ein frühes Produkt kann eine fokussierte Zwei-Seiten-Spezifikation reichen. Entscheidend ist, dass das Team die Entscheidungen trifft, bevor die Implementierung sie zufällig trifft.

Was das für CTOs und Product Owner ändert

Für technische Führung verschiebt KI-Coding die Review-Arbeit.

Die Frage ist nicht nur, ob der Code kompiliert. Die Frage ist, ob die Implementierung zur Produktabsicht und Architektur passt.

Review sollte deshalb auch prüfen:

Erfüllt der Code die formulierten Akzeptanzkriterien?
Hat der Agent versteckte Geschäftsregeln eingeführt?
Unterstützt das Datenmodell künftige Änderungen?
Sind Berechtigungen explizit und testbar?
Werden Fehler so behandelt, dass der Betrieb damit arbeiten kann?
Entsteht Kopplung, die das nächste Release bremst?
Sind die generierten Tests sinnvoll oder nur Coverage-Theater?

Hier zahlt sich Architektur-first Delivery aus. Je klarer das Ziel, desto leichter lässt sich KI nutzen, ohne dass das System driftet.

Die McDougall Digital Sicht

Bei McDougall Digital ist genau dieser praktische Mittelweg interessant.

KI kann Softwareentwicklung beschleunigen. Sie kann Code erzeugen, Optionen explorieren, Edge Cases testen und repetitive Arbeit reduzieren. Aber ernsthafte Produkte brauchen weiterhin Produkturteil, Architektur, Wartbarkeit, Sicherheit und Betrieb.

Der gewinnende Workflow ist nicht “Mensch schreibt alles” oder “KI entscheidet alles”.

Es ist eine strukturierte Zusammenarbeit:

Menschen definieren Absicht, Einschränkungen und Kompromisse;
KI hilft, diese Absicht in Umsetzungsoptionen zu übersetzen;
Architektur hält das System kohärent;
Tests und Reviews machen Qualität sichtbar;
Betrieb macht das Ergebnis tragfähig.

Das ist der Unterschied zwischen einem beeindruckenden Prototyp und Software, auf die sich ein Unternehmen verlassen kann.

Wie wir helfen können

Wenn Sie mit KI-Coding-Tools bauen, ist der nützlichste nächste Schritt oft nicht der nächste Prompt. Es ist ein klarerer Delivery-Rahmen.

McDougall Digital hilft Gründern, Product Ownern und technischen Teams, KI-unterstützte Arbeit in wartbare Software zu übersetzen. Das kann bedeuten: eine Produkt-Spezifikation schärfen, einen KI-gebauten Prototyp prüfen, die Architektur für eine ernsthafte erste Version definieren, Berechtigungen und Datenflüsse härten oder einen Delivery-Prozess aufsetzen, in dem KI das Team beschleunigt, ohne still langfristige Schulden aufzubauen.

Die aktuelle X-Diskussion über Spec-Driven Development ist zeitnah. Der eigentliche Punkt bleibt.

Wenn Implementierung schneller wird, wandert der Wert nach vorne.

Am meisten profitieren nicht die Teams, die am meisten prompten. Sondern die Teams, die wissen, was gebaut werden soll, warum es wichtig ist und was Qualität bedeuten muss, bevor der Code erscheint.