KI verändert die Softwareentwicklung gerade grundlegend. Wir sehen es als unsere Aufgabe, diese Veränderung für Sie als unsere Kunden nutzbar zu machen. Damit Sie von schnelleren Ergebnissen und mehr Transparenz profitieren.
KI-Coding-Tools sind bei uns keine Spielerei mehr. Wir nutzen sie täglich und das verändert, wie wir Software bauen und denken.
Nur eine Zahl aus unserem Alltag: Aktuell ist etwa 50% unseres Codes KI-generiert. Der Rest? Review, Architektur, Konzeption. Die Arbeit, die sicherstellt, dass das Ergebnis auch funktioniert.
Und das ist erst der Anfang. Gartner prognostiziert, dass bis 2028 bereits 90% aller Software-Entwickler:innen KI-Code-Assistenten nutzen werden (gegenüber 14% Anfang 2024). Microsoft-CTO Kevin Scott geht noch weiter: Er erwartet, dass innerhalb der nächsten fünf Jahre 95% des Codes KI-generiert sein wird. Ich persönlich teile diese Einschätzung.
Das Problem, das niemand gerne anspricht
„Vibe Coding“, also das schnelle Zusammenklicken von Code mit KI-Unterstützung, funktioniert erstaunlich gut. Bis es nicht mehr funktioniert.
Irgendwann stößt jedes KI-gestützte Projekt an seine Grenzen: Die Komplexität der Codebasis wird so groß, dass die KI sich selbst im Weg steht. Ohne klare Struktur, ohne dokumentierte Architekturentscheidungen, ohne nachvollziehbare Anforderungen produziert sie Code, der kurzfristig läuft, aber langfristig zum Wartungsalbtraum wird.
Die Frage ist nicht mehr, ob KI Code schreibt. Die zentralen Fragen lauten: Hat dieser Code eine verlässliche Qualität? Ist er in zwei Jahren noch erweiterbar? Versteht überhaupt noch jemand, was das System tun soll?
Was sich gerade fundamental verschiebt
Wir beobachten drei Entwicklungen:
Der Wert von „Code tippen“ sinkt rapide. Was früher Wochen gedauert hat, erledigt ein KI-Agent in Stunden. Das ist großartig, bedeutet aber auch, dass „ich kann programmieren“ allein kein Differenzierungsmerkmal mehr ist.
Der Wert von „wissen, was gebaut werden soll“ steigt. Sinnvolle Business Cases, klare Anforderungen, durchdachte User Flows, präzise Akzeptanzkriterien: Das wird zum Engpass. Nicht das Tippen, sondern das Denken davor.
Der Wert von Architekturwissen bleibt hoch. Jemand muss wissen, wie gute Softwarearchitektur aussieht. Wie man ein System aufbaut, das skaliert, wartbar bleibt und sich erweitern lässt. Das kann KI (noch) nicht.
Daraus folgt für uns: Wir brauchen eine neue Art, Projekte zu spezifizieren. Eine, die für Menschen verständlich ist und die KI-Agenten als Arbeitsgrundlage nutzen können.
Wir nennen es „The Spec“.
Was ist die Spec?
Die Kurzfassung: The Spec ist eine strukturierte Projektdokumentation mit drei Eigenschaften:
- Single Source of Truth: Alles, was das System können soll, steht an einem Ort
- Lebt im Code-Repository: Nicht in einem Wiki, nicht in JIRA, sondern direkt beim Code
- KI-lesbar: So strukturiert, dass KI-Agenten damit arbeiten können
Die Spec beinhaltet dabei zwei Dinge: Die projekt-spezifischen Anforderungen (Was soll dieses System tun?) und unsere technischen Best-Practices und Architekturstandards (Wie bauen wir generell gute Software?).
„Aber ist das nicht wie ein Lastenheft?“
Berechtigte Frage. Der Grund, warum klassische Lasten- und Pflichtenhefte ausgestorben sind: Der Wartungsaufwand war enorm. Jede Änderung bedeutete stundenlange Dokumentationsarbeit, am Ende war das Dokument trotzdem veraltet.
Bei uns ist das anders: Die Spec ist maschinenlesbar, KI-Agenten können bei Änderungen unterstützen. Änderungen sind Teil des normalen Flows, kein separater Dokumentationsprozess. Das war das eigentliche Problem der alten Pflichtenhefte: Jede Änderung war teuer. Bei uns ist Ändern billig, wir bleiben agil.
Die drei Ebenen der Spec
Die Spec ist in Ebenen organisiert. Je tiefer Sie gehen, desto technischer wird es:
| Ebene | Inhalt | Zielgruppe |
|---|---|---|
| 1 | Projektziele, Nutzergruppen, Erfolgskriterien | Geschäftsführung, Stakeholder |
| 2 | Features, Abläufe, Akzeptanzkriterien | Projektleiter:innen, Product Owner |
| 3 | API-Endpunkte, Datenmodelle, technische Details | Entwickler:innen |
Das bedeutet: Als Projektleiter:in oder Geschäftsführer:in müssen Sie nicht die technischen Details verstehen. Sie lesen die ersten beiden Ebenen und wissen, was gebaut wird. Die Entwickler:innen tauchen tiefer ein.
Was das für die Projektsteuerung bedeutet
Für Projektmanager:innen löst die Spec konkrete Alltagsprobleme:
| Heute | Mit Spec |
|---|---|
| „Was ist die aktuelle Anforderung?“ Suche in JIRA, Confluence, Slack, E-Mails . | Nachschlagen in 30 Sekunden |
| „Wie bringe ich ein neues Teammitglied auf Stand?“ Tage bis Wochen Einarbeitung. | Onboarding anhand der Spec in Stunden |
| „Was passiert bei Team- oder Dienstleisterwechsel?“ Wissen in Köpfen, Sorge bei Übergabe. | Vollständige Dokumentation als Übergabe-Artefakt |
Was das für Sie bedeutet
Effizienz: Mehr Output bei gleichem Investment. Wir werden schneller. Nicht weil wir schludern, sondern weil Routinearbeit automatisiert wird. Features, für die wir früher zwei Wochen gebraucht haben, schaffen wir in einer. Oder wir nutzen die gewonnene Zeit, um das Feature mit Nutzenden zu testen und auf Basis des User Feedbacks iterativ zu verbessern.
Souveränität: Echte Unabhängigkeit. Die Spec ist ein Stück Risikomanagement. Sie sichert Sie ab am verletzlichsten Punkt jeder Softwareentwicklung: der Übergabe. Kein Aufgeschmissensein bei Teamwechseln oder Dienstleisterwechsel.
Iterationsgeschwindigkeit: Der 2-Wochen-Sprint-Rhythmus passt für die meisten Projekte. Aber wenn eine kürzere Time-to-Market oder ein intensiver Produktentwicklungszyklus gefragt ist, können wir das Tempo erhöhen.
Wie Mensch und KI zusammenarbeiten
Unser Ziel ist eine klare Arbeitsteilung:
| Phase | Mensch | KI-Agent |
|---|---|---|
| Konzeption | Definiert Anforderungen in der Spec | – |
| Entwicklung | Reviewt und steuert nach, ergänzt Expertenwissen | Generiert Code auf Basis der Spec |
| QA | Entscheidet über Go-Live | Testet gegen Akzeptanzkriterien |
| Dokumentation | – | Hält Spec und Code synchron |
Der Mensch bleibt in der Verantwortung. Aber die Routinearbeit (Standard-Code schreiben, Tests ausführen, Dokumentation aktualisieren) wandert zur KI.
Warum die Spec dafür entscheidend ist: KI-Agenten sind nur so gut wie ihr Kontext. Wenn wir einem KI-Agenten sagen „Bau mir ein Login“, bekommen wir irgendein Login. Wenn wir ihm eine Spec geben mit Akzeptanzkriterien, Sicherheitsanforderungen, UI-Design und Datenmodell, bekommen wir das Login, das wir brauchen.
Die Spec enthält unser Experten-Wissen, definiert klare Grenzen und gibt KI-Agenten präzise Anforderungen.
Für welche Projekte eignet sich die Spec?
Sinnvoll ab 6+ Monaten Laufzeit. Für Projekte, die länger leben sollen, die weiterentwickelt werden, die vielleicht irgendwann übergeben werden: Da zahlt sich die Spec aus.
Overkill für Wegwerf-MVPs. Wenn Sie in zwei Monaten wissen wollen, ob eine Idee funktioniert und das Ergebnis danach eh in die Tonne wandert, brauchen Sie keine Spec.
Mehr Sorgfalt am Anfang. Wir müssen in der Konzeptionsphase genauer wissen, was wir bauen. Das erfordert bessere Workshops, klarere Anforderungen, durchdachtere Designs. Dieser Aufwand zahlt sich über die Projektlaufzeit mehrfach zurück.
Wie geht es weiter?
Wir setzen uns weiter intensiv mit diesen Veränderungen auseinander, experimentieren täglich und sind überzeugt: Dieser Weg ist der richtige.
Unser konkreter Plan für 2026:
- Q1/Q2: Einführung bei ausgewählten Neuprojekten
- Laufend: Iterative Verbesserung auf Basis realer Erfahrungen
- Parallel: Ausbau unserer KI-Agenten-Infrastruktur
Sie möchten wissen, ob Spec-Driven Development für Ihr Projekt passt? Melden Sie sich für ein persönliches Gespräch bei mir. Unverbindlich und ohne Sales-Pitch, versprochen. Ich bin gespannt!
