Softwareprojekte verspäten sich, weil das Programmieren nie der Engpass war. Entwickler verbringen rund 16% ihrer Woche mit Code schreiben. Die anderen 84% gehen für Informationssuche, Warten auf Entscheidungen und das Wechseln zwischen Werkzeugen drauf. KI beschleunigt die 16%. Die Verzögerung wohnt in den 84% — und fast niemand hat ein Werkzeug darauf gerichtet.
Achtundsechzig Prozent der Entwickler sagen, KI spare ihnen mehr als zehn Stunden pro Woche.
Fünfzig Prozent sagen, sie verlieren mehr als zehn Stunden pro Woche an organisatorische Reibung.
Dieselbe Umfrage. Dasselbe Jahr. Dieselben 3'500 Entwickler in sechs Ländern. Atlassian veröffentlichte beide Zahlen in seinem State of Developer Experience Report 2025 und zog den einzigen verfügbaren Schluss: «Wir sind wieder genau da, wo wir angefangen haben.»
Ein voller Arbeitstag, Ihren Ingenieuren von einer Maschine geschenkt — und von Ihrer eigenen Firma vor Freitag still wieder eingezogen.
Wenn Sie letztes Jahr ein KI-Tooling-Budget freigegeben haben und Ihre Release-Termine sich seither nicht bewegt haben: Das ist der Grund. Nicht weil die Werkzeuge zu wenig lieferten. Sie lieferten exakt, was sie versprachen. Sie lieferten es in ein System, das nie durch Tippgeschwindigkeit begrenzt war.
Warum macht KI Softwareprojekte nicht schneller?
Fragen Sie einen CFO, was ein Software-Ingenieur den ganzen Tag tut, lautet die Antwort: Code schreiben. Fragen Sie einen VP of Engineering, bekommen Sie etwas Anspruchsvolleres mit identischer Arithmetik darunter — Kapazität wird in Entwicklertagen gezählt, und Entwicklertage gelten als Tage des Bauens.
Sind sie nicht. Atlassians Report 2025 beziffert das Programmieren auf 16% der Arbeitswoche eines Entwicklers — eine Zahl aus einem IDC Survey Spotlight vom Februar 2025. Sechseinhalb von vierzig Stunden. Die anderen dreiunddreissigeinhalb gehen ganz woanders hin: die API-Doku jagen, die im März noch stimmte; auf jemanden drei Zeitzonen entfernt warten, der bestätigt, ob ein Feld nullable ist; im Standup sitzen, das existiert, weil das Standup letzter Woche nichts entschieden hat.
Jetzt werfen Sie einen KI-Coding-Assistenten in diese Woche. Ein gutes Werkzeug. Nehmen Sie an — ohne Beleg, rein aus Grosszügigkeit —, dass er den Coding-Anteil dreissig Prozent schneller macht.
Dreissig Prozent von 16% sind unter 5% der Woche. Zwei Stunden.
Sie haben kein schnelleres Projekt gekauft. Sie haben Dienstagnachmittag gekauft.
Nichts davon überraschte Atlassian. Ihr Kopf der DevOps-Evangelisation hatte das Argument ein Jahr früher gemacht — und damals angemerkt, dass es kontrovers sei: Ein Coding-Assistent kann den Tag eines Entwicklers besser anfühlen lassen, ohne dass die Organisation schneller ausliefert. Das Programmieren war nie die Reibung. Das eine Werkzeug zu schärfen, das nicht stumpf war, hilft dem stumpfen nicht. Zwölf Monate und 3'500 Antworten später schlossen die 2025er-Zahlen die Debatte zu seinen Gunsten.
Das Entwickler-Produktivitätsparadox ist, was passiert, wenn einzelne Ingenieure messbar schneller werden und die Organisation, die die Software ausliefert, nicht. Es ist kein Rätsel. Es ist ein Verhältnis.
| Anteil an der Entwicklerwoche | Was ein KI-Coding-Tool damit macht | |
|---|---|---|
| Code schreiben | 16% | Beschleunigt es, erheblich |
| Alles andere — Informationen finden, sich an neue Technologie anpassen, Kontextwechsel, teamübergreifende Koordination, auf Entscheidungen warten | 84% | Im Wesentlichen nichts |
KI zielt auf 16% des Problems. Quellen: IDC Survey Spotlight (Feb. 2025); Atlassian State of DevEx 2025.
Und während Sie diesen Dienstagnachmittag kauften, ist der Engpass umgezogen. Tech Debt — das Ding mit einer Position auf jeder je geschriebenen Engineering-Roadmap — fiel 2025 aus Atlassians Top fünf der Reibungsquellen. Teamübergreifende Zusammenarbeit stieg. Die meisten Organisationen finanzieren mit dem diesjährigen Budget noch den letztjährigen Engpass — und messen das Ergebnis in Story Points.
Es gibt einen leiseren Befund im selben Report, der Sie mehr stören sollte als jede Schlagzeilenzahl.
Atlassian fragte Entwickler, was sie mit der Zeit tatsächlich tun, die KI ihnen zurückgibt. Die Antwort: Codequalität verbessern, neue Features bauen, Dokumentation schreiben.
Lesen Sie die Liste noch einmal. Fast alles davon sitzt in den 16%.
Die Dividende aus dem Coding-Anteil wird — nahezu vollständig — in den Coding-Anteil reinvestiert. Nicht weil Ingenieure kurzsichtig wären. Sondern weil es der einzige Teil der Woche ist, den sie anfassen dürfen. Dokumentation ist der eine Punkt der Liste, der in die 84% hineinreicht — und sie ist das Erste, was gestrichen wird, wenn der Sprint eng wird.
Sie haben Ihrem Team also zehn Stunden pro Woche geschenkt, und es hat sie für das eine Sechstel des Jobs ausgegeben, das schon funktionierte. Es hatte recht damit. Niemand hat ihm erlaubt, sie anderswo auszugeben.
Wo geht die Zeit wirklich hin?
Vor der Liste eine Zahl, die mehr zählt als die fünfzig Prozent: Neunzig Prozent der Entwickler verlieren mindestens sechs Stunden pro Woche daran. Sechs Stunden sind fast ein Arbeitstag. Das ist also kein Rand schlecht geführter Ausreisser, von dem Sie sich bequem ausnehmen können. Es ist die Verteilung. Ist Ihre Firma normal, steckt sie in diesen Daten.
Atlassians Top drei, der Reihe nach: Informationen finden. Sich an neue Technologie anpassen. Kontextwechsel zwischen Werkzeugen.
Lesen Sie sie noch einmal. Keines ist ein Coding-Problem. Jedes ist ein Wissens-Auffindungsproblem. Die Information existiert. Jemand in Ihrer Firma hat sie. Sie ist mit ziemlicher Sicherheit irgendwo aufgeschrieben. Ihr Entwickler kann sie nur nicht in den neunzehn Minuten finden, die er vor dem nächsten Call hat.
Hier ist ein Dienstag.
Ein Entwickler muss wissen, ob der Payment-Webhook bei einem 500er wiederholt. Die Antwort existiert. Sie steht in einem Slack-Thread von vor vierzehn Monaten, in einem Kanal, der bei einer Reorg archiviert wurde, geschrieben von jemandem, der im April ging. Also tut der Entwickler das Rationale: fragt im Teamkanal, bekommt vier Stunden nichts — und fängt derweil etwas anderes an.
Diese Aufgabe hat nicht vier Stunden gekostet. Sie hat vier Stunden gekostet plus einen Kontextwechsel — und der Wechsel kostete mehr als die Frage. Multiplizieren Sie das über jeden Entwickler, jeden Tag, ein Quartal lang. Das ist Ihr Liefertermin.
Und beachten Sie, welche Reibung in demselben Jahr auf Atlassians Liste stieg, in dem Tech Debt herausfiel: die Zusammenarbeit mit anderen Teams.
Die zählt, weil sie die einzige Kategorie der Liste ist, die ein Entwickler nicht anfassen kann. Ein Ingenieur kann an einem ruhigen Freitag aus eigenem Antrieb ein schlechtes Modul refaktorieren. Er kann das Plattform-Team nicht dazu bringen, die API-Änderung zu priorisieren. Er kann die Compliance-Freigabe nicht vorziehen. Er kann keiner Sitzung eine Entscheidung abringen, die dreimal verschoben wurde. Die am schnellsten wachsende Reibung ist genau die, die über seiner Gehaltsstufe sitzt — also auf Ihrer.
Wie repariert man ein spätes Projekt wirklich?
Nichts davon verlangt Neueinstellungen. Es verlangt, auf einen Teil der Woche zu schauen, den Sie nie gemessen haben.
-
Messen Sie das Warten, nicht die Arbeit. Sie verfolgen bereits Story Points, Velocity, Cycle Time. Alle messen die 16%. Loggen Sie stattdessen eine Zahl: Stunden zwischen «Entwickler blockiert» und «Entwickler entblockt». Sie wird Ihnen nicht gefallen. Genau darum geht es — mit einer selbst erhobenen Zahl kann man nicht streiten.
-
Geben Sie jeder blockierenden Frage einen benannten Menschen und eine Uhr. Keinen Kanal. Kein Gremium. Eine Person, mit vereinbarter maximaler Antwortzeit. Die meisten Vier-Stunden-Wartezeiten sind kein Warten auf eine Entscheidung. Sie sind Warten darauf, dass jemand bemerkt, dass eine Entscheidung nötig war.
-
Schreiben Sie die Antwort dorthin, wo die nächste Person darüber stolpert. Die Webhook-Antwort wird im November wieder gebraucht. Lebt sie in einer Slack-Antwort, ist sie weg. Legen Sie sie neben den Code — ein Entscheidungslog im Repo, ein Kommentar am Endpunkt. Die Regel ist nicht «alles dokumentieren». Sie lautet: «Wenn eine Frage vier Stunden kostet, bekommt ihre Antwort eine dauerhafte Adresse.»
-
Richten Sie KI auf die 84%. Die Werkzeuge besitzen Sie schon. Drehen Sie sie auf den Teil der Woche, der wirklich blutet — interne Dokumente durchsuchen, den Thread zusammenfassen, die Spezifikation entwerfen, für die niemand Zeit hat. KI-Agenten für interne Abläufe sind neben einem Coding-Assistenten unglamourös — und sie berühren fünfmal mehr der Woche. Atlassians eigene Rahmung: KI verbessert die Developer Experience, wenn sie auf echte Reibungspunkte zielt — nicht auf die eine Aufgabe, die nie ein Reibungspunkt war.
-
Fragen Sie Ihre Entwickler. Wirklich fragen. Atlassians Schritt eins — und er ist Schritt eins, weil er gratis ist. Die Leute, die die zehn Stunden verlieren, können Ihnen exakt sagen, wohin sie gehen. Niemand hat sie gefragt.
Der unbequeme Teil
Dreiundsechzig Prozent der Entwickler sagen inzwischen, ihre Führung verstehe ihre Schmerzpunkte nicht. Letztes Jahr waren es 44%.
Neunzehn Punkte in zwölf Monaten. Denselben zwölf Monaten, in denen KI-Adoption nahezu universell wurde und die berichteten Zeitersparnisse stark sprangen.
Das ist kein Zufall, und Atlassians eigene Lesart ist unverblümt: Die Führung steckt die KI-Ersparnis ein und lässt die Reibung exakt, wo sie war. Der Ingenieur bekommt das Werkzeug. Bekommt den Gewinn. Sieht ihn in dieselbe Warteschlange abfliessen, in die er immer abfloss. Und wird dann gefragt, warum der Termin gerutscht ist.
Nach den Zahlen des Reports verliert eine Organisation mit 500 Entwicklern daran etwa 7,9 Mio. Dollar im Jahr — eine modellierte Zahl, keine gemessene, aber das Modell ist nicht grosszügig.
Tooling wird gekauft, weil Tooling kaufbar ist. Man kann es am Dienstag freigeben und am Mittwoch verkünden. Zu reparieren, wem eine Entscheidung gehört, oder das vierstündige Warten auf ein nullable Feld zu töten, heisst zu ändern, wie Ihre Firma arbeitet. Das verkauft kein Anbieter. Keine Rechnung trifft ein. Niemand schreibt eine Pressemitteilung darüber.
Also geht das Geld dorthin, wohin die Rechnung gehen kann.
Beginnen Sie mit der Frage, nicht mit dem Werkzeug
Ihre Ingenieure wissen längst, wohin die Zeit geht. Sie wissen es seit Jahren. Die Umfrage hat nichts aufgedeckt, was sie Ihnen nicht bei einem Kaffee hätten sagen können — und 63% von ihnen sagen ohnehin, ihre Führung verstehe es nicht.
Also fragen Sie. Nicht nach der Roadmap. Nach dem Letzten, das sie sitzen und warten liess.
Reparieren Sie dieses eine Ding. Und dann schauen Sie, was es mit dem Termin macht.
Häufige Fragen
Warum sind Softwareprojekte noch spät, wenn KI den Code schreibt?
Weil Code schreiben nur 16% der Entwicklerwoche ist. Die anderen 84% gehen für Informationssuche, Warten auf Entscheidungen und Werkzeugwechsel drauf. KI beschleunigt den Coding-Anteil — der nie die Begrenzung war. Die Verzögerung sitzt in den 84%, unberührt.
Verbessert KI die Entwicklerproduktivität wirklich?
Ja — individuell. In Atlassians 2025er-Umfrage unter 3'500 Entwicklern meldeten 99% irgendeine Zeitersparnis und 68% über 10 gesparte Stunden pro Woche. Aber 50% verlieren zugleich über 10 Stunden pro Woche an organisatorische Reibung — der Gewinn erreicht den Liefertermin also selten.
Was ist 2026 die grösste Ursache für Projektverzögerungen?
Organisatorische Reibung, nicht Engineering-Kapazität. Atlassians 2025er-Daten führen als grösste Abflüsse: Informationen finden, sich an neue Technologie anpassen, Kontextwechsel zwischen Werkzeugen. Bemerkenswert: Tech Debt fiel aus den Top fünf — der Engpass ist umgezogen, die meisten Budgets nicht.
Was kostet Entwickler-Ineffizienz eine Firma?
Atlassians 2025er-Report modelliert für eine Organisation mit 500 Entwicklern rund 7,9 Mio. Dollar Verlust pro Jahr durch organisatorische Ineffizienz — auf Basis von etwa 10 verlorenen Stunden pro Entwickler und Woche. Eine modellierte Schätzung, keine Messung — aber mit konservativen Annahmen.
Die Lösung ist kein Tool, sondern wie die Arbeit geführt wird — deshalb liefert unsere Delivery-Praxis Releases mit festem Umfang und festem Preis. Wenn Ihr laufendes Projekt driftet, ist eine Zweitmeinung kostenlos.
