Wer in den letzten Monaten mit AI-Agenten wie Cursor AI oder GitHub Copilot gearbeitet hat, kennt das Gefühl, dass sich hier gerade etwas Grundlegendes verändert. Es ist der vermutlich größte Umbruch in der Arbeitsweise von Softwareentwicklern seit der Veröffentlichung des Agile Manifests 2001 und dessen Durchbruch als Massenphänomen vor gut zehn Jahren.
Kaum ein Unternehmen, egal welcher Branche, setzt heute noch auf den berüchtigten Wasserfall - agile Entwicklung mit Scrum als bekanntestem Framework und ungezählten Ablegern hat sich durchgesetzt.
Doch man muss die Frage stellen: Ist durch den Durchbruch der KI-Coding-Agenten das goldene Zeitalter der Scrum Master, Retros und Sprints vorbei?
"Over time, complexity started to look like sophistication. Overhead kept growing, and the process became the work." — Linear, "Issue tracking is dead"
Wenn Entwicklungszeit kein Engpass mehr ist
Ja, KI-Coding hat Schwächen. Halluzinationen, fehlender Systemkontext, fragwürdige Architekturentscheidungen - menschliches Review bleibt unverzichtbar. Aber selbst die größten Kritiker werden einräumen, dass die Ergebnisse bisweilen extrem beeindruckend sind. Und wir stehen hier am Anfang, nicht am Ende einer Entwicklung.
Richtig eingesetzt, verkürzt sich die Entwicklungszeit neuer Features drastisch. Entwickler werden von Implementierern zu Reviewern und Wächtern von kohärenten Systemen.
Während früher die Entwicklerkapazität der Flaschenhals war und sich das Backlog trotz größter Bemühungen schneller füllte als das Team Daily Standup sagen konnte, findet heute eine interessante Verschiebung statt: Nicht mehr das Abarbeiten steht im Fokus, sondern das präzise Vorgeben, was die KI in der nächsten Kaffeepause entwickeln soll.
Tickets sind für Menschen, Anforderungen für Maschinen
Genau hier liegt die Kernaufgabe der Zukunft: Probleme erkennen, Lösungen erdenken und das Ganze in Form von präzisen Anforderungen beschreiben - die Implementierung bekommt man dann quasi geschenkt.
Was würde sich hier besser eignen als die gute alte liebgehasste Spezifikation?
Der Unterschied zu Tickets ist dabei entscheidend: Ein Ticket ist typischerweise narrativ, kontextabhängig, für einen menschlichen Entwickler geschrieben. "Als Nutzer möchte ich..." liest sich wie Prosa. Eine Spezifikation dagegen ist ihrer Natur nach eindeutig, testbar und folgt einer semi-formalen Sprache. Genau das, was Maschinen brauchen.
| Ticket | Spezifikation | |
|---|---|---|
| Sprache | Narrativ, Prosa | Semi-formal, strukturiert |
| Zielgruppe | Menschlicher Entwickler | Mensch + Maschine |
| Testbarkeit | Implizit, interpretierbar | Explizit, verifizierbar |
| Eindeutigkeit | Kontextabhängig | Per Definition eindeutig |
Das Muster ist nicht neu. Es folgt dem Grundgedanken des Software Engineerings seit der NATO-Konferenz 1968, auf der der Begriff überhaupt erst geprägt wurde: define, (implement), test, manage, maintain. Nur dass implement heute zunehmend an die Maschine delegiert wird.
Anstatt ausschweifend in Tickets zu beschreiben, was entwickelt werden soll, die Dauer auszupokern, in GANTT-Charts zu tracken und daraus dann Prompts für die Maschinen zu übersetzen - warum nicht eine auf Maschinen zugeschnittene Spezifikation direkt in den Mittelpunkt stellen?
Ein sauber kuratiertes Lastenheft mit Prioritäten, dazu ein vollständiges Set an Testfällen - und das Team kann eigentlich mit gutem Gewissen zwei Wochen in Urlaub fahren, während die Agenten die Arbeit erledigen. Gut erholt und rechtzeitig zurück zur Auslieferung an den Kunden.
Doch so einfach ist es nicht.
Das Produkt wird nur so gut wie die Spezifikation
Die beschriebene Verschiebung wird stattfinden. Aber sie bedeutet keine kognitive Entlastung für das Team - im Gegenteil. Das Produkt wird niemals besser als seine Spezifikation. Und wer schon einmal versucht hat, wirklich eindeutige, vollständige und testbare Anforderungen zu formulieren, weiß, wie schwer das ist.
Spezifikation steht bei vielen Entwicklern ungefähr auf einer Beliebtheitsskala mit Meetings ohne Agenda. Zu Recht - klassische Spezifikationsarbeit ist oft bürokratisch, langsam und vom Code entkoppelt.
Ein oberstes Ziel muss es deshalb sein, die Spezifikationsarbeit attraktiver zu machen.
Spezifikation neu gedacht
An genau dieser Frage arbeiten wir mit OakCore. In der Spezifikation wird das Produkt entschieden - hier steht und fällt es. Dann darf das Werkzeug dafür kein Anhängsel sein: keine starren Listen in Tools aus den 90ern, keine Excel-Sheets, die per E-Mail durch die Abteilungen wandern, kein Copy-Paste zwischen Anforderung, Risikobewertung und Testplan.
OakCore bringt das alles an einen Ort. Anforderungen, Tests, Risikomanagement und Traceability in einer vernetzten Struktur - als Single Source of Truth über Projektrollen hinweg. Produktmanager, Entwickler, QA und Compliance arbeiten auf derselben Grundlage. Die KI prüft Specs auf Widersprüche und Lücken, bevor der erste Agent auch nur eine Zeile Code anfasst. Testergebnisse aus der Pipeline fließen direkt zurück in den Graphen - man sieht sofort, welche Anforderungen abgedeckt sind und wo es brennt.
Das Ziel: Spezifikationsarbeit, die sich nicht nach Pflichtenheft anfühlt, sondern nach dem, was sie sein sollte - die Schnittstelle zwischen menschlichem Denken und maschinellem Handeln.
Weniger Wie, mehr Was und Warum. Die Spezifikation wird zum zentralen Artefakt. Wer sie beherrscht, steuert die Maschine.