KI beschleunigt, ersetzt aber kein Verständnis
Die zentrale Frage lautet nicht: Kann die KI das bauen? Sondern: Können wir das Ergebnis fachlich und technisch begründen?
Unreflektierte KI-Nutzung verleitet dazu, direkt in die Lösung zu springen. Ein Prompt, ein plausibles Ergebnis und dann direkt der nächste Schritt. Das kann sich zunächst produktiv anfühlen. Doch Annahmen bleiben dabei oft unausgesprochen, Randfälle werden zu spät erkannt und wichtiges Wissen steckt nur noch im Chatverlauf einzelner Personen.
Gerade in Teams ist das problematisch. Code muss auch später noch verständlich, wartbar und reviewbar sein. Entwickler tragen weiterhin die Verantwortung für Architektur, Qualität und die Auswirkungen einer Änderung.
Was ist Spec Driven Development?
Spec Driven Development, kurz SDD, ist kein starres Formular und auch keine neue Programmiersprache. Es ist ein Arbeitsmodus: Erst Problem, Zielbild und Rahmenbedingungen verstehen und festhalten. Danach wird die Umsetzung konsequent daran ausgerichtet.
Die Spezifikation ist dabei kein Dokument, das einmal geschrieben und anschließend abgelegt wird. Sie begleitet den gesamten Prozess. Sie hält Ziele, technische Leitplanken, offene Fragen, Entscheidungen und Testideen fest.
Damit wird sie zur gemeinsamen Arbeitsgrundlage, sowohl für das Entwicklungsteam als auch für die Zusammenarbeit mit KI. Statt nur einen Chatverlauf als Kontext zu haben, entsteht ein nachvollziehbares Artefakt, auf das sich alle Beteiligten beziehen können.
Erst verstehen, dann umsetzen
Ein praxistauglicher SDD-Workflow lässt sich in fünf Schritte gliedern:
- Zunächst analysieren wir Ticket, Fachkontext, bestehenden Code und mögliche Auswirkungen einer Änderung. KI kann hier helfen, Zusammenhänge zu strukturieren und unbekannten Code verständlicher zu machen.
- Danach formulieren wir das Zielbild: Was soll sich ändern, was darf nicht verändert werden und welche Risiken akzeptieren wir nicht?
- Offene Fragen werden bewusst gesammelt und geklärt. Denn unbeantwortete Fragen beantwortet eine KI sonst stillschweigend mit Annahmen. Testideen gehören bereits in diese Phase, weil sie Missverständnisse früh sichtbar machen.
- Erst dann entsteht Code. Die Spezifikation liefert dafür Kontext, Grenzen und klare Prüfkriterien. Umsetzung und Review erfolgen bewusst in kleinen, nachvollziehbaren Schritten.
- Zum Abschluss prüfen wir den Code wieder gegen die Spezifikation. Erfüllt er die Ziele? Bleibt er innerhalb der Leitplanken? Sind Tests und Randfälle berücksichtigt? Und vor allem: Können wir die Lösung einem Kollegen erklären?
Gemeinsam feiern gehört dazu
Neben dem fachlichen Austausch gab es auch wieder einen besonderen Anlass: Ein Teammitglied feierte sein zehnjähriges Jubiläum bei Davitec. Natürlich durften die Davitec-Muffins nicht fehlen, ein schöner Rahmen für gemeinsame Gespräche und ein Dankeschön für langjährige Verbundenheit.
Guter KI-Code bleibt erklärbar
Spec Driven Development nimmt Entwicklung nicht das Tempo. Es verlagert die Aufmerksamkeit an die richtige Stelle: vor die Umsetzung und in die bewusste Prüfung der Ergebnisse.
KI ist stark, wenn es um Analyse, Strukturierung und Beschleunigung geht. Die Spezifikation sorgt dafür, dass diese Stärke im Team nutzbar und überprüfbar wird. So wird aus einem schnellen KI-Vorschlag keine magische Blackbox, sondern eine Lösung, die fachlich und technisch verantwortet werden kann.
Wer den Ansatz ausprobieren möchte, findet mit Spec Kit und OpenSpec erste Werkzeuge für strukturierte Spezifikations-Workflows. Entscheidend ist aber nicht das Tool, sondern die Haltung dahinter: erst verstehen, dann bauen.
– – – – –
Weiterführende Links
👉 www.davitec.de
Foto: Davitec
