KI schreibt den Code: Warum die Spezifikation jetzt entscheidet
22. Oktober 2026
KI-generiert, redaktionell von 8thsense ausgewählt, geprüft und freigegeben. EU AI Act, Art. 50
Pratik Wadher, Technikchef des IT-Softwareanbieters Kaseya, hat seine Entwickler einen zentralen Teil der Software von KI-Agenten neu schreiben lassen. Seine wichtigste Erkenntnis daraus ist keine technische: „Der neue Code ist die Spezifikation”, sagte er im Gespräch mit The Register. Wer KI-Agenten Software bauen lässt, muss also vor allem präzise beschreiben können, was sie leisten soll. Für Geschäftsführer, die Prozessautomatisierung oder eigene Anwendungen in Auftrag geben, verschiebt sich damit die entscheidende Arbeit: weg vom Programmieren, hin zum sauber formulierten Fachwissen.
Sechs Wochen für eine neue Speicherschicht
Kaseya verkauft Software für IT-Dienstleister und kleinere bis mittlere Unternehmen, etwa für Fernwartung, Backup und IT-Sicherheit (Quelle: kaseya.com). Laut The Register vereinheitlicht ein Team unter Wadher derzeit Daten und Schnittstellen über die vielen Einzelprodukte hinweg. Als Beispiel nennt er die Speicherschicht: Sie soll künftig auf jede Art von Speicher schreiben können, vom ZFS-Dateisystem bis zum S3-Objektspeicher. Nach Wadhers Angaben wurde diese Schicht in sechs Wochen neu entworfen, geschrieben und getestet. Er betont, dass jahrelanges Fachwissen in das Design eingeflossen sei (Quelle: theregister.com). Wichtig für die Einordnung: Teamgröße, Kennzahlen oder einen Vorher-Nachher-Vergleich veröffentlicht Kaseya nicht. Die sechs Wochen sind eine Aussage des CTO, keine unabhängig geprüfte Zahl.
Erst die Beschreibung, dann der Code
Interessanter als das Tempo ist der Ablauf. Ein Mensch schrieb mit Hilfe von Coding-Agenten des KI-Anbieters Anthropic eine Spezifikation. Die Entwickler überarbeiteten sie mehrfach und ließen sie zusätzlich von sogenannten Kritik-Agenten prüfen. Erst danach erzeugte die KI den eigentlichen Code. Wadher beschreibt seine Arbeit inzwischen so: „Es ist fast so, als würde ich diese Agenten steuern.” Die besten Entwickler blieben dabei unverzichtbar. Die Spezifikationen sollen künftig wie Quellcode in GitHub versioniert werden, damit sie zuverlässig denselben Code erzeugen. Hier räumt Wadher selbst eine Schwäche ein: Er habe dabei schon Abweichungen gesehen. Kritisches Denken und Schreiben hält er für die wichtigsten Fähigkeiten der Zukunft. Wer nur Code generiere, ohne das Fachgebiet zu verstehen, komme nicht weit.
Spec-Driven Development ist kein Kaseya-Einzelfall
Der Ansatz hat einen Namen: Spec-Driven Development. GitHub hat dafür bereits im September 2025 das quelloffene Werkzeug Spec Kit veröffentlicht. Die Idee laut GitHub: Vom schnellen Ausprobieren per Zuruf („Vibe Coding”) hin zu einem festen Ablauf in vier Schritten (Quelle: github.blog):
Beschreiben: Was soll entstehen, für wen, woran misst man Erfolg?
Planen: Technik, Architektur und Rahmenbedingungen festlegen.
Zerlegen: Die Arbeit in kleine, einzeln testbare Aufgaben aufteilen.
Umsetzen: Der Agent arbeitet die Aufgaben ab, Menschen prüfen jeden Schritt.
GitHub fasst das so zusammen: Nicht mehr der Code sei die maßgebliche Wahrheit, sondern die Absicht dahinter. Gemeint sei aber ausdrücklich kein Wälzer an Anforderungsdokumenten, „die niemand liest”, sondern ein lebendes Dokument, das mit der Software wächst (Quelle: developer.microsoft.com). Beide Texte stammen vom selben GitHub-Produktmanager und liefern keine Messwerte.
Wo der Ansatz an Grenzen stößt
Eine unabhängige und deutlich nüchternere Sicht liefert Birgitta Böckeler vom Beratungshaus Thoughtworks. Sie hat mehrere Werkzeuge für Spec-Driven Development ausprobiert und stieß auf handfeste Probleme (Quelle: martinfowler.com). Die Agenten hielten sich trotz Vorlagen und Checklisten häufig nicht an alle Vorgaben. Bei kleinen Aufgaben wurde der Aufwand absurd: Ein Werkzeug machte aus einem einfachen Fehler vier User Stories mit 16 Akzeptanzkriterien, für Böckeler ein Fall von „mit Kanonen auf Spatzen”. Statt vieler sich wiederholender Textdateien würde sie lieber Code prüfen. Außerdem erinnert sie an frühere Versuche, Software allein aus Modellen zu erzeugen, und fragt, ob KI-Spezifikationen deren Nachteile erben könnten: Starrheit und nicht vorhersagbare Ergebnisse. Das deckt sich mit Wadhers eigener Beobachtung zu Abweichungen.
Was das für Unternehmen bedeutet
Für mittelständische Betriebe ist die Botschaft weniger exotisch, als sie klingt. Lastenheft und Pflichtenheft kennt jeder, der schon einmal Software in Auftrag gegeben hat. Neu ist, dass deren Qualität jetzt direkt über das Ergebnis entscheidet, weil die KI wörtlich umsetzt, was dort steht, und Lücken mit Annahmen füllt. Die Pflegevermittlung muss also genau beschreiben können, wann eine Betreuungskraft als verfügbar gilt. Die Tanzschule braucht klare Regeln für Probestunden, Nachholtermine und Kündigungen. Der Wohlfahrtsverband muss seine Freigabeketten kennen, bevor ein Agent Anträge vorsortiert. Dieses Wissen steckt in den Köpfen der Mitarbeitenden und lässt sich nicht einkaufen.
Praktisch heißt das: Starten Sie mit einem einzelnen, gut abgegrenzten Ablauf, etwa der Bearbeitung eingehender Anfragen, und lassen Sie die Fachverantwortliche ihn Schritt für Schritt aufschreiben, inklusive Ausnahmen. Das kostet einige Stunden, aber kein Lizenzbudget. Entscheidend ist danach, wer dieses Fachwissen in eine prüfbare Spezifikation übersetzt, die Ergebnisse gegen echte Fälle testet und die Beschreibung pflegt, wenn sich der Prozess ändert. Ob das intern oder mit Begleitung für KI-Automation und Workflow-Automation geschieht: Die Wahl des Werkzeugs ist zweitrangig. Wer seine Prozesse nicht beschreiben kann, bekommt auch von der besten KI nur schnell geschriebene Missverständnisse.
