„Der Hauptgrund, warum wir trotz KI-Einsatz den möglichen Wertzuwachs in IT-Projekten nicht sehen, sind Management-Fehler“
Das Interview führte Anika Dewald
Die systematische Nutzung von generativer KI in der Software-Entwicklung ist in einem großen Teil der Unternehmen angekommen. Und auch wenn deutsche Unternehmen im internationalen Vergleich nicht vorne mit dabei sind, setzen laut dem State of AI Development Report 2026[1] von OutSystems, immerhin 56 % der befragten deutschen Unternehmen generative KI in der Anwendungsentwicklung ein.
Das hat vor allem mit Blick auf die Entwicklungs-Geschwindigkeit in kurzer Zeit sehr viel verändert.
Michael Spanier, Gründer und Geschäftsführer von Colenet, ist als Product Owner und Berater in Software-Entwicklungs-Teams ganz unterschiedlicher Unternehmen unterwegs. Auch bei seinen Projekten kommt KI, genauer: agentische Software-Entwicklung, zum Einsatz, die eine neue High-Performance bei der Feature-Erstellung ermöglicht.
Michael berichtet im Interview, mit welchen neuen Hindernissen Development-Teams dadurch heute zu kämpfen haben. Er bemängelt, dass Management-Entscheidungen mit Blick auf Prozess-Tools, Budgetverteilung und Autonomie der Teams nicht zur neuen Situation passen.
Michael, KI-Einsatz ist in vielen Software-Teams inzwischen Alltag.
Was hat sich dadurch aus deiner Sicht am stärksten verändert?
Das Tempo. Aber eben nur auf der Ebene der einzelnen Entwickler. Genau da fangen die Probleme an. Ein Team braucht ein gemeinsames Verständnis darüber, was gerade gebaut wird, was als Nächstes kommt und wie sich die Anforderungen dorthin entwickelt haben. Ohne das läuft jeder Entwickler mit seiner eigenen KI-Beschleunigung in eine andere Richtung los. Man wird schneller, aber nicht gemeinsam schneller.
Deloitte beziffert die Aufteilung der KI-Budgets auf 93 Prozent Technologie und 7 Prozent Menschen.[2]
Deckt sich das mit dem, was du in Unternehmen siehst?
Ziemlich genau. In den Teams hat sich die Arbeitsweise innerhalb von Monaten verändert – und drumherum praktisch nichts. Dieselben Prozesse, dieselben Werkzeuge, dieselben Budgetlogiken. Das ist in erster Linie eine Management-Aufgabe, und die wird gerade breit versäumt. Atlassian hat das in seinem State-of-Teams-Report[3] selbst gemessen: 89 Prozent der Führungskräfte sehen ihre Teams mit KI schneller arbeiten, aber nur 6 Prozent können daraus einen konkreten wirtschaftlichen Nutzen belegen. Die Diagnose dahinter teile ich sogar. Ich ziehe nur einen anderen Schluss daraus.
Die Diagnose lautet: Teams brauchen ein gemeinsames Verständnis. Der Schluss aus Tool-Hersteller-Sicht: Ihr braucht ein Werkzeug dafür. An welcher Stelle steigst du aus?
Genau da. Dieses gemeinsame Verständnis braucht kein weiteres SaaS-Tool. Und hier sehe ich gerade den Fehlinvest in vielen KI-Budgets: Das Geld fließt in ein zusätzliches Werkzeug, wie zum Beispiel Jira oder Confluence, das Entwickler neben ihrer eigentlichen Arbeit bedienen müssen – statt in die Arbeit selbst.
Du sprichst von Fehlinvest innerhalb der KI-Budgets. Woran machst du das konkret fest?
An etwas, das ich immer wieder erlebe: Entwicklerinnen und Entwickler, deren KI-Token-Budget nach drei von acht Arbeitsstunden aufgebraucht ist. Oder, bei Monatsbudgets, Teams, die schon am achten Tag des Monats komplett ohne Tokens dastehen – für den Rest des Monats de facto ohne KI-Unterstützung. Das ist Irrsinn. Und der Grund dafür ist genau dieser Fehlinvest: Man glaubt, ein Tooling außen herum bringt den Erfolg, steckt das Budget dort hinein und schränkt es ausgerechnet bei den Tokens ein, die die Entwickler brauchen, um zu arbeiten.
Aber ist ein gegeneinander abwägen „entweder Tokens oder Prozess-Tools” denn hilfreich? Müsste nicht in beides investiert werden, eben nur ausreichend?
Die Budget-Abzweigung für die Tools ist nur eine Sache, die mich daran stört. Die zweite Sache ist, dass diese Prozess-Steuerungs-Tools, die bis jetzt die meisten Teams in der Software-Entwicklung genutzt haben, schlicht nicht für die Anforderungen gebaut wurden, die KI-gestützte Entwicklung mit sich bringt. Meiner Erfahrung nach, gehen sie am aktuellen Arbeitsprozess vorbei und machen damit den Developern unnötige und umständliche Mehrarbeit.
Wenn nicht über zusätzliche Tools – wie löst ihr Themen wie Spezifikation oder Dokumentation, die für ein gemeinsames Verständnis des aktuellen Arbeitsstands wichtig sind?
Unsere Feature-Spezifikationen liegen direkt im Git-Repository und zwar grob strukturiert in drei Punkten:
Erstens, was gebaut werden soll und warum.
Zweitens, woran man erkennt, dass es fertig ist (Akzeptanzkriterien und Tests).
Und drittens, ein Status direkt im Dokument: Entwurf → Umsetzung → Freigabe.
Mehr braucht es nicht. Kein Login, keine Lizenz, kein zweites System, das synchron gehalten werden muss.
Meine These: KI-Teams brauchen kein Jira und kein Confluence mehr.
Das funktioniert für alle, die ohnehin im Repository arbeiten. Was ist mit Fachbereichen, Stakeholdern oder Management, die eine Roadmap sehen wollen? Verlagerst du das Problem nicht nur?
Das Management schaut ohnehin nicht in Tools wie Jira, Azure DevOps usw. rein. In den größeren Konzernen werden dazu vorwiegend PowerPoint-Folien präsentiert. Stakeholder arbeiten nach meiner Erfahrung ebenso wenig mit diesen Werkzeugen, das läuft über E-Mails, Gespräche, Interviews. In der Ideation-Phase binden wir sie sehr systematisch ein, aber eben nicht über ein Tool.
Was diese Rollen tatsächlich brauchen, ist etwas anderes: Aggregation. Die Informationen, die in diesen Tools stecken, zusammenziehen und richtig darstellen. Auch dafür entwickeln wir Lösungen, die Management-Fragen beantworten. Das ist ein Teilaspekt dessen, was wir Agile PMO nennen (Agile Project Management Office).
Der andere Teilaspekt ist Requirement Engineering, und da kommt der Fachbereich ins Spiel. Das Requirement Engineering verändert sich bei der Entwicklung mit agentischer KI ebenfalls. Es geht nicht mehr darum, eine Anforderung als User Story oder Epic abzulegen. Es ist ein Analyseprozess. Der wird heute deutlich wichtiger. Und er arbeitet mit entwicklungs-ähnlichen Werkzeugen, obwohl es um Fachbereichsaufgaben geht. Man hat es plötzlich mit tausenden Anforderungen zu tun, die ein Mensch gar nicht mehr parallel im Blick haben kann, dazu Varianten, Governance-Constraints, … . Dort unterstützt KI massiv.
Für mich ist das ein weiterer Hinweis darauf, dass die Werkzeuge, die wir aus der herkömmlichen Software-Entwicklung am Start haben, nicht mehr ausreichen. Sie liefern nicht die Blickwinkel, die wir eigentlich brauchen. Deshalb setzen wir immer weniger auf diese Werkzeuge und ihre Plugins, sondern gehen stattdessen in individuelles Customizing, das am Geschäftsprozess des Unternehmens ausgerichtet ist.
Abgesehen von den Tools und der aus deiner Sicht veralteten Budget-Planung, die du kritisierst:
Siehst du noch weitere Probleme, vor denen Teams stehen, die mithilfe agentischer KI Software entwickeln, – und die auf mangelnde Anpassung management-seitig zurückzuführen sind?
Es wird immer dann schwierig, wenn Entwicklerinnen und Entwickler einfach ein KI-Werkzeug in die Hand gedrückt wird mit gleichzeitig hoher Erwartung, dass es gewinnbringend eingesetzt wird, ohne dass vorher teamübergreifend für ein gemeinsames Verständnis gesorgt wird, wie man mit KI-Agenten überhaupt arbeitet. Das sehe ich übrigens nicht allein als einen Management-Fehler. Wo dieser Konsens fehlt, tragen die Teams auch eine Mitverantwortung – man sollte hier als Team eine Lösung anstoßen oder wenigstens den Bedarf äußern, statt darauf zu warten, dass das Problem von oben gelöst wird.
Außerdem verwechseln viele immer noch „mit einer KI chatten“ mit KI-unterstütztem Arbeiten. Dabei ist das gerade mal die unterste von fünf Stufen agentischen Codings: „Chatbot“, wie wir es in unserem Reifegradmodell[4] nennen. Echtes Agentic Coding beginnt erst dort, wo man selbst keinen Code mehr direkt schreibt. Wer auf Stufe 1 stehen bleibt und dort keinen wirtschaftlichen Nutzen misst, misst nicht KI-gestützte Entwicklung. Er misst ein Chatfenster.
Auf welcher Stufe dieses Reifegradmodells arbeitet ihr in euren Projekten?
Auf Level 4, „On the Loop“: Agenten laufen parallel und autonom durch Requirements, Bau und Test, wir prüfen asynchron, statt live mitzuschauen. In Teilen sind wir schon näher an Level 5 dran. Nur der letzte Schritt, das Deployment auf Produktion, bleibt bei uns bewusst eine menschliche Entscheidung. Das ist kein Widerspruch, sondern die Grundhaltung dahinter: KI ist ein Werkzeug – zusätzlich zu den Skills, die die Entwicklerinnen und Entwickler ohnehin mitbringen, nicht als Ersatz dafür.
„Asynchron prüfen“ klingt für viele erst mal wie „hinterher drüberschauen und durchwinken“. Woran merkt ihr, dass da noch jemand wirklich hinschaut?
Das kann man messen: an der Quote der Bugs, die in Produktion gefunden werden. Diese Escape-Rate müsste eigentlich minimal und konstant sein. Sobald ich merke, dass sie ansteigt, habe ich eine Indikation, dass in meiner gesamten Validierungskette etwas nicht stimmt. Dann ist die Frage: Ist mein KI-gesteuertes Werkzeug zu schwach, um die Anforderung zu verstehen und richtig zu validieren, oder gibt es andere Ursachen? Das ist übrigens unbenommen davon, ob ich KI oder menschliche Intelligenz einsetze – Escape Defects auf Produktion sind immer eine gute Metrik, die man messen sollte.
Vorbeugen tun wir vorne, ab der Requirement-Phase. Wir arbeiten mit Behavior Driven Development: Funktionalitäten werden natürlichsprachlich beschrieben. Der Fachbereich gibt damit vor, wie fachlich geprüft wird. Daraus werden automatisierte Tests abgeleitet. Diese ersten Regeln sind menschengemacht und genau das macht sie zu Leitplanken. Wir ziehen solche Guardrails bewusst in unser Engineering ein als Sicherheits-Standard und weil sie die Validierung verbessern.
Und noch eine letzte Sache zu dem Punkt: „Asynchron prüfen“ heißt bei uns nicht, „tagelang unbeobachtet laufen lassen“. Unsere Laufzeiten liegen im Maximalfall bei vier, fünf Stunden. Danach validieren wir im Allgemeinen als Menschen: Wo stehen wir, und was ist der nächste logische Schritt? Wir bauen ja selten etwas eins zu eins nach – wir wollen eine Veränderung hineinbringen und die muss die KI steuern. Doch am Ende bleibt immer der Mensch relevant, der den letzten Abnahmetest macht.
Wenn ein Team damit anfangen will, mit agentischer KI Software zu entwickeln:
Was ist deine Empfehlung für den Start?
Nutzt Spezifikationen, die direkt am Code liegen. Immer verfügbar, als Markdown, maschinenlesbar. Das ist die Grundlage für gutes Requirement Engineering und für Agenten, die tatsächlich verstehen, was sie bauen sollen.
Die Grundsätze qualitativen Software Engineerings müssen ebenso wie beim rein menschlichen Entwickeln immer erfüllt sein. Sofern das nicht der Fall ist, wird KI Schaden erzeugen.
Für mich ist das der Grundpfeiler guter agentischer Arbeit. Was das Engineering mit KI wirklich braucht, ist eben kein zusätzliches Tool außen herum, sondern Budgets für agentische KI-Plattformen, die auf der Basis guter Software-Entwicklung aufgebaut werden und den Agenten alle relevanten Informationen über Schnittstellen zur Verfügung stellen.
Wir haben bei unseren Kunden bereits gezeigt, dass dieser Ansatz funktioniert.
Vielen Dank!
Software-Entwicklung mit agentischer KI
Möglichkeiten, Grundlagen und Risikovermeidung. – Wir klären Ihre Fragen im direkten Gespräch und unterstützen bei Bedarf gerne bei der Umsetzung.
Jetzt Termin vereinbaren mit Michael Spanier.
[1] The State of AI Development Report 2026 (von outsystems)
[2] „Deloitte’s CTO on a stunning AI transformation stat: Companies are spending 93% on tech and only 7% on people“ (von Nick Lichtenberg, in: Fortune)
[3] „The state of teams 2026″ (von Atlassian)
[4] Die 5 Stufen des Agentic Coding (von Pascal Gugenberger, Colenet)
