Der ROI hängt am Fundament: Was Googles DORA-Team über KI-gestützte Entwicklung berechnet

Google Cloud hat im Februar 2026 einen 60-seitigen Bericht zum Return on Investment KI-gestützter Softwareentwicklung veröffentlicht. Das DORA-Team und die hauseigene Beratungseinheit „delta" rechnen darin in einem Modellunternehmen vor, was Werkzeugeinkauf, Lehrgeld und Wertzuwachs im ersten Jahr ergeben. Die zentrale Aussage steht außerhalb der Tabellen: KI wirkt als Verstärker. Ohne reifes Fundament verstärkt sie die Dysfunktionen einer Organisation.

FC
· 14 min Lesezeit

Google Cloud hat im Februar 2026 einen 60-seitigen Bericht veröffentlicht, der den Return on Investment KI-gestützter Softwareentwicklung in eine Formel überführt. Das hauseigene DORA-Team und die Beratungseinheit „delta" rechnen darin an einem Modellunternehmen vor, was die Einführung agentischer Werkzeuge im ersten Jahr kostet und einbringt.

Das DORA-Team gehört mittlerweile zu Google und gilt seit 2014 als die einflussreichste Forschungsstelle für die Vermessung von Softwareentwicklung. Aus seinen Studien stammen die vier zentralen Auslieferungs-Metriken rund um Lead Time, Deployment Frequency, Change Failure Rate und Recovery Time, die heute branchenübergreifend Standard sind. Der Bericht “The ROI of AI-assisted Software Development” erscheint als gemeinsame Arbeit mit der internen Beratungseinheit „delta", die Google-Cloud-Kunden bei der Einführung von KI begleitet.

Der Bericht ist in sieben Kapitel gegliedert. Er beginnt mit einer Zusammenfassung und baut einen Business Case auf. Dann beschreibt er die Marktspaltung bei der KI-Bewertung und führt durch die Berechnung des ROI mit Wertfaktoren, Kostenfaktoren und Beispielrechnungen. Es folgen fünf strukturelle Voraussetzungen für eine erfolgreiche Adoption und eine Investitions-Roadmap. Den Schluss bildet eine Anleitung zur Sicherung langfristiger Erträge. Im Anhang liefert er einen Beispiel-ROI-Rechner, dessen interaktive Version unter dora.dev/ai/roi/calculator öffentlich verfügbar ist.

KI als Verstärker, Code als Last

Die Aussage, dass KI als Verstärker wirkt, taucht im Bericht in vielen Variationen auf. Sie folgt aus der zentralen Beobachtung des 2025er DORA-Reports: Wer ein gut funktionierendes Engineering-System hat, multipliziert dessen Stärken durch KI. Bei einem dysfunktionalen System multipliziert sie die Dysfunktionen. „Without this foundation, AI creates localized pockets of productivity that are often lost in downstream chaos", schreiben die Autoren. Die Folge ist eine bemerkenswerte Umdeutung dessen, was als Code-Output zählt.

Mit Bezug auf das Standardwerk „Software Engineering at Google" zitiert der Bericht die Maxime, dass Code in der Lebenszeit eines Systems häufig „eine Last, kein Aktivposten" sei. Der Betrieb eines Systems übersteige die Kosten seiner Erstellung um Größenordnungen. Mehr Code, ohne Aufsicht erzeugt, vergrößere den Verifikations-Aufwand und führe zu langfristiger technischer Schuld. Diese Umkehr ist programmatisch: Sie verschiebt das übliche KI-Versprechen vom „mehr Code, schneller" auf „weniger Engpass, durchgehend".

Eine bekannte These, jetzt in einer Geldgröße

Wer den Bericht parallel zum jüngsten Beitrag zum Team-Betriebssystem für Agentic CLI liest, findet einen unmittelbaren Bezugspunkt. Die These dort lautete, dass Werkzeuge ohne Methode Fehler ins Ergebnis verschieben, wo sie unsichtbar bleiben. Die Stanford-Studie von Christopher Potts und Moritz Sudhof bezifferte den Anteil der unsichtbar gewordenen Fehler auf 88 Prozent in Dialogen mit ungeübten Anwendern. Der DORA-Bericht liefert die organisationsökonomische Seite dazu. Die unsichtbaren Fehler sind nicht nur ein Qualitätsproblem, sondern tauchen auch in den Auslieferungs-Metriken auf, als gestiegene Change Failure Rate und längere Recovery Time, mit messbarem Umsatzeffekt.

Die fünf systemischen Schlüssel des Berichts (Vertrauen, interne Plattform, Daten-Ökosystem, Nutzerorientierung, automatisierte Schutzschienen) decken sich weitgehend mit den Säulen einer methodisch geführten Schulung. Eine schriftlich fixierte Haltung zu KI entspricht einer Repo-Verfassung. Der als Produkt geführten internen Entwicklerplattform entspricht das Bild der Tool-Zonen, in denen Werkzeuge nach Risiko sortiert sind. In der Nutzerorientierung steckt der Auftrag, jede Auslieferung gegen ein klares Ziel zu schneiden. Das Ziel ist der ROI. Ohne die Methode bleibt er aber verstreut. Was vorher als Frage von Stil und Reviewkultur galt, taucht im DORA-Bericht als Variable im Geldmodell auf.

Was das für deutsche Teams heißt

Die Beispielzahlen des Berichts stammen aus einem US-Cloud-Native-Modell. Mit 176.000 Dollar Jahresvergütung liegt der Rechner am oberen Rand dessen, was eine deutsche Software-Fachkraft kostet, vor allem in regulierten Branchen mit Tarifbindung. Den Abstand zwischen Greenfield- und Brownfield-Wirkung gibt der Bericht mit 35 bis 40 Prozent gegen zehn Prozent an, und dieser Abstand trifft deutsche Anwenderlandschaften zudem härter. Hier ist mehr alterndes Bestandswissen verbaut als in den Vergleichswerten aus Mountain View. Ein Ergebnis aus dem Beispielrechner wird in Stuttgart oder Walldorf nicht eins zu eins eintreten.

Dennoch gilt die strukturelle Aussage, und sie steckt in einer Zahl: acht Monate. So lange dauert nach den Modellannahmen die Phase, in der mehr Geld in das System fließt als herauskommt. Wer in dieser Zeit die J-Kurve als Misserfolg liest und die Mittel zurückzieht, verspielt nach Lesart der Autoren den anschließenden Aufschwung. Mit einer Investition in das Fundament, also in Plattform, Daten, Verifikation, Vertrauen und Nutzerorientierung, nimmt ein Unternehmen die Kurve dagegen nach oben mit. Für das Warten auf das nächste Modell findet sich im Text keine Bestätigung. Der Rest dieses Beitrags rekonstruiert die Rechnung im Detail, ordnet die widersprüchlichen Marktdaten ein und benennt die Vorbehalte, die der Bericht selbst formuliert.

Die J-Kurve und ihre drei Kräfte

Im Zentrum des finanziellen Modells steht eine Kurve in Form des Buchstabens J. Der Bericht nennt sie die „J-Curve of AI value realization" und beschreibt sie als eine empirisch beobachtete Verlaufsform für große Transformationsprojekte. In der Frühphase der Einführung sinkt die Produktivität, manchmal über Monate. Erst danach steigt sie wieder, um schließlich exponentiell zu wachsen. Drei Kräfte ziehen die Kurve zunächst nach unten.

Die Lernkurve steht am Anfang: die Zeit, die Teams benötigen, um neue Schnittstellen, Arbeitsabläufe und Promptingstrategien zu beherrschen. Dazu kommt die Verifikationssteuer („verification tax"), die Zeit, die Entwicklerinnen und Entwickler aufwenden, um KI-Output gegen Halluzinationen zu prüfen und gegen Sicherheits- und Architekturstandards zu verifizieren. Als dritte Kraft nennt der Bericht die Pipeline-Anpassung, weil schneller erzeugter Code an Test- und Freigabeengpässen aufläuft, die zuvor noch ausreichten. Der Bericht deutet diese drei Kräfte als Lehrgeld der Transformation. Ein Versagen der Technologie sieht er darin nicht. Wer ein Budget aufstellt und die J-Kurve nicht einplant, riskiere, in der Talsohle die Mittel zu kürzen und damit den späteren Anstieg zu verspielen.

Was die Einführung kostet

Der Beispielrechner beziffert diesen Investitionsblock in expliziten Größen. Er setzt 500 technische Mitarbeitende an, eine voll belastete Jahresvergütung von 176.000 Dollar, eine J-Kurven-Dauer von drei Monaten und einen Produktivitätseinbruch von 15 Prozent. Allein als Lehrgeld ergeben sich daraus 3,3 Millionen Dollar. Hinzu kommen die direkten Werkzeug- und Schulungskosten. Das Beispielmodell veranschlagt 250 Dollar Lizenz pro Nutzerkonto und Jahr, dazu 80 Dollar zusätzliche Nutzungskosten (etwa für Token), 9.600 Dollar Schulung pro Person und 100.000 Dollar zusätzliche Infrastrukturkosten. Diese Summe addiert sich zu 5,065 Millionen Dollar. Zusammen mit der J-Kurve ergibt das eine Gesamtinvestition im ersten Jahr von 8,365 Millionen Dollar.

Was die Einführung einbringt

Auf der Wertseite arbeitet das Modell mit drei Posten. Ein Posten ist die freigesetzte Personalkapazität, die der Bericht als „Headcount Reinvestment Capacity" bezeichnet. Sie entsteht, wenn Entwicklerinnen und Entwickler durch KI Zeit gewinnen, die sie in höherwertige Arbeit reinvestieren können. Bei 12,5 Prozent eingesparter Nettozeit pro Kopf entspricht das im Beispiel 11 Millionen Dollar. Ein weiterer Posten ist der zusätzliche Umsatz aus mehr ausgelieferten Features. Liefert ein Team 50 Features pro Jahr aus, sind es künftig 56. Ein Drittel davon hat Umsatzwirkung, mit 0,5 Prozent auf einen Produktportfolio-Umsatz von 100 Millionen Dollar. So kommen knapp 990.000 Dollar dazu. Der dritte Posten hat ein umgekehrtes Vorzeichen. Aus dem 2025er DORA-Report stammt der Befund, dass die Einführung von KI mit einer höheren Change Failure Rate korreliert. Im Modell steigt der Anteil fehlerhafter Auslieferungen dadurch von 5 auf 6 Prozent. Bei vier Stunden Wiederherstellungszeit und 100.000 Dollar Ausfallkosten pro Stunde schlägt das mit minus 344.000 Dollar zu Buche. Aufsummiert ergibt sich ein Gesamtwert von 11,646 Millionen Dollar im ersten Jahr.

Hinter der Dreierstruktur des Modells steht ein breiteres Wertgerüst, das der Bericht im Kapitel zur Wertberechnung mit fünf Säulen beschreibt: Kosteneffizienz, Produktivität, Developer Experience, User Experience und Geschäftswachstum. Je weiter man im Modell nach rechts geht, desto schwächer wird der unmittelbare Bezug zur KI im Engineering, desto stärker wird der finanzielle Hebel. Der Bericht macht in einer Grafik (Figure 4) sichtbar, was der 2025er DORA-Report empirisch gemessen hat. Die größte Wirkung der KI-Adoption findet sich auf der individuellen Effektivität, gefolgt von einer höheren Lieferinstabilität (mit umgekehrtem Vorzeichen), dann von organisatorischer Performance, sinnvoller Arbeit, Code-Qualität, Produkt-Performance, Lieferdurchsatz und Team-Performance. Burnout und Reibung verändern sich kaum. Die Streuung der Effekte ist breit, und die Wirkung hängt vom System ab, in dem das Werkzeug arbeitet.

Der Developer Experience widmet der Bericht eine eigene Passage. Er behält sie ausdrücklich im Modell, nimmt sie aber aus Vorsicht aus der Beispielrechnung heraus. Der Zusammenhang zwischen einer KI-Einführung und der Bindung von Personal sei real, aber statistisch zu variabel, um ihn in eine Punktschätzung zu legen. Als qualitatives Argument bleibt er stark, weil der Ersatz einer Software-Fachkraft typischerweise das Eineinhalb- bis Zweifache des Jahresgehalts kostet. Wer eine bessere Arbeitsumgebung schafft, weil Routinearbeit an Agenten ausgelagert wird, senkt diese Wechselkosten. In der Sample-Berechnung lässt der Bericht diesen Posten bewusst weg, in der Argumentation führt er ihn aber als „mächtiger qualitativer Hebel".

Aus diesen beiden Seiten der Rechnung folgt eine ROI-Quote von 39 Prozent im ersten Jahr und eine Amortisation nach 0,7 Jahren, also etwa acht Monaten. Der Bericht ordnet die Größenordnung ein. Eine Amortisation zwischen sechs und neun Monaten gelte als Benchmark für agile Teams, zwischen zwölf und achtzehn Monaten für regulatorisch geprägte Großorganisationen. Für eine längere Perspektive verweisen die Autoren auf eine eigene Datenerhebung. Google-Cloud-Kunden hätten über drei Jahre eine durchschnittliche Rendite von 727 Prozent auf ihre KI-Investition gemeldet. Die Zahl stammt aus einer Veröffentlichung von Google Cloud selbst. Der Bericht kennzeichnet sie als Kundenmeldung ohne unabhängige Validierung.

Methodenhinweise im Eigentext

An mehreren Stellen weist der Bericht selbst auf die Grenzen der Berechnung hin. Im Hinweiskasten zur Methodik heißt es, die Kalkulationen seien „eine hochunsichere Schätzung, gedacht um ein Gespräch in Gang zu setzen, nicht als rigide mathematische Formel". Die Autoren zitieren die Statistiker-Maxime, alle Modelle seien falsch, manche aber nützlich. Wer im Rechner einzelne Annahmen verändert, sieht das Endergebnis sofort kippen. Eine konservative Variante senkt den Wert auf 80 Prozent und erhöht die Kosten auf 150 Prozent, eine optimistische geht in die andere Richtung. Der Spielraum ist breit. Die Autoren empfehlen ausdrücklich, mehrere Szenarien gleichzeitig durchzurechnen, und raten davon ab, einer einzelnen Punktschätzung zu vertrauen.

Die Marktspaltung

In einer längeren Passage fragt der Bericht, warum bei nahezu universeller Einführung die finanziellen Resultate so weit auseinanderliegen. Er beschreibt drei Lager. Die optimistische Position beruft sich auf eine Google-Cloud-Erhebung, nach der 78 Prozent der befragten Führungskräfte einen Return aus mindestens einem generativen KI-Anwendungsfall berichteten. Außerdem nennt sie 88 Prozent positive Rückmeldungen unter frühen Anwendern agentischer Systeme. Die neutrale Position verweist auf den Stanford AI Index 2025, der die Erwartungen an die Belegschafts-Produktivität als „durchgängig gemischt" einordnet. Während die Adoption hoch sei, bleibe die strukturelle Transformation in den meisten Branchen selten und es ergäben sich überwiegend marginale Produktivitätsgewinne. Das pessimistische Lager zitiert Forschung aus dem MIT-NANDA-Projekt. Demnach scheitern interne Unternehmens-Implementierungen häufig, was Beschäftigte in eine „Schatten-KI-Wirtschaft" treibe, in der sie auf nicht autorisierte Verbraucheranwendungen ausweichen. Die hauptsächliche Hürde liege laut MIT-Befund im organisatorischen Design. Budget und Technologie seien es nicht.

Etwas versteckt im Kapitel zur ROI-Modellierung steht eine bemerkenswerte Zahl. Eine Auswertung des Stanford-Forschungsprogramms zur Software-Engineering-Produktivität habe gezeigt, dass KI-Werkzeuge bei einfachen, auf der grünen Wiese gestarteten Aufgaben einen Produktivitätsgewinn von 35 bis 40 Prozent erzeugten. Bei komplexem, alterndem Bestandscode liege die Wirkung dagegen oft bei zehn Prozent oder darunter. Die Autoren des Berichts verwenden diesen Unterschied, um die Auswahl von Anwendungsfällen zu rechtfertigen. Wer KI primär in Greenfield-Szenarien einsetze, sehe schneller Wirkung. Für Brownfield-Migrationen brauche es stärkere Vorarbeit am Engineering-System. Wie diese Vorarbeit im Bestand aussehen kann, zeigt die agentische Engineering-Pipeline für den SDLC.

Fünf strukturelle Voraussetzungen

Im Kapitel „Build the organizational foundation for AI adoption" benennt der Bericht fünf systemische Schlüssel, die ein Unternehmen aus den verstreuten lokalen Produktivitätszuwächsen herausführen sollen. An erster Stelle steht Vertrauen, technisch umgesetzt als „clear and communicated AI stance". Gemeint ist eine schriftlich fixierte Haltung der Organisation zu KI, die Erwartungen, Grenzen und Reviewpflichten festlegt. Es folgt eine interne Entwicklerplattform (IDP), die als Produkt behandelt wird und Reibung im Umgang mit Werkzeugen, Pipelines und Architekturmustern minimiert. In der agentischen Ära fungiere die IDP als „Risikominderer und Kontextlieferant für Agenten". Ein KI-zugängliches Daten-Ökosystem ist die dritte Voraussetzung, weil Agenten nur so gut sind wie die Daten, auf die sie zugreifen. Eine kompromisslose Nutzerorientierung richtet die durch Werkzeuge gewonnene Geschwindigkeit auf reale Probleme aus. Auf die Zahl der Pull-Requests kommt es dabei nicht an. Als Letztes nennt der Bericht automatisierte Verifikations-Schienen („Guardrails"), die als Bremsen wirken und es dem Engineering-System erlauben, sicher schneller zu fahren.

Eine Formel des Berichts bündelt die These: „Wir messen KI nicht an dem Code, den sie schreibt, sondern an den Engpässen, die sie freiräumt." Die Aussage steht im Kapitel zum Geschäftsfall. Sie verschiebt das übliche Versprechen, KI ersetze Entwicklerstellen, in eine andere Logik. ROI messe, wie viel latentes menschliches Kreativitätspotenzial freigesetzt werde, indem systemische Routinearbeit an autonome Agenten ausgelagert werde. Die Zahl der abbaubaren Stellen sei dafür kein Maß.

Empfehlung gegen Stellenstreichung

Konsequent rät der Bericht von einer Kostensenkungsstrategie auf der Personalseite ab. Wer Produktivitätsgewinne in Stellenstreichungen ummünze, beschädige die Moral, vermindere die Lernbereitschaft und erzeuge Anreize, sich gegen Prozessverbesserungen zu sperren. Die Autoren empfehlen stattdessen, freigesetzte Kapazität als Reinvestition in Innovation zu rahmen. Die so gesparten Kosten seien vermiedene Kosten für ausgebliebene Neueinstellungen. Um Einsparungen durch Entlassungen gehe es dabei nicht. Diese Lesart ist im Modell auch deshalb angelegt, weil die Wechselkosten für Personal in Software-Berufen typischerweise das Eineinhalb- bis Zweifache des Jahresgehalts betragen.

Der Begriff „verification tax" kehrt im Text immer wieder. Im Kapitel über zusätzliche und indirekte Kosten beschreibt der Bericht, wie eine niedrige Vertrauensbasis die J-Kurve vertieft. Wenn jeder Codeblock zweimal gegengelesen werde, bevor er in die Pipeline gehe, lösten sich die Produktivitätsgewinne auf. Vertrauen behandelt der Bericht deshalb als harte finanzielle Variable. Es zu erzeugen verlange ein System, das Verifikation belohne. Die rohe Code-Menge dürfe dabei kein Anreiz sein. Die Forschung zur agentischen Softwareentwicklung beschreibt dieselbe Verschiebung: Verifikation wird zum Engpass, auf den die agilen Praktiken keine Antwort haben.

Experimentfrequenz als Finanzgröße

Der Bericht argumentiert in einer eigenständigen Passage, die Frequenz von Experimenten sei ein finanzieller Indikator und nicht nur ein Engineering-Wert. Der Argumentationsgang stützt sich auf das Konzept der Optionalität aus der Finanzwelt. Eine Option sei eine risikoarme Investition, die das Recht eröffne, später größer zu investieren, ohne es zu müssen. Ein Prototyp oder ein A/B-Test sei eine solche Option. KI senke die Vorlaufkosten dieser Option, indem sie die Zeit für Code-Erstellung drastisch verkürze. Wer mehr Optionen halte, müsse weniger früh auf eine einzige Hypothese setzen.

Die finanzielle Lesart fügt der Methodik eine Dimension hinzu, die sich von reiner Geschwindigkeit unterscheidet. Ob ein Team mehr Code in der gleichen Zeit ausliefert, tritt dabei zurück. Die Frage lautet, wie viele Hypothesen ein Team in der gleichen Zeit durch echte Nutzerinnen und Nutzer prüfen kann, bevor es Ressourcen in eine Skalierung investiert. Hohe Experimentfrequenz, schreibt der Bericht, sei ein Frühindikator dafür, dass die Organisation die KI absorbiert habe und nicht in falsche Features investiere.

Drei Vorbehalte

Der Bericht stammt aus dem Hause Google. Er enthält Verweise auf Google-Cloud-Werkzeuge und Beratungsdienste, sein Beispielrechner endet mit einer Kontaktoption zur „delta"-Praxis. Die methodische Solidität der Argumente bleibt davon unberührt, der Marketingrahmen ist aber zu erkennen.

Der Rechner beschränkt sich zudem auf das erste Jahr. Die hohen Mehrjahres-Renditen von 727 Prozent stammen aus einer separaten Quelle, die der Bericht selbst als Kundenmeldung kennzeichnet. Schließlich bleiben die zentralen Eingangsgrößen, also der Anteil eingesparter Zeit, die Erfolgsquote zusätzlicher Features und die Umsatzwirkung pro Feature, Schätzungen, deren Bandbreite der Bericht offen ausweist. Die Autoren machen aus dieser Unsicherheit kein Geheimnis. Sie betonen mehrfach, dass der Rechner ein Gesprächsöffner sei und kein Bilanzinstrument.

Reife als finanzielle Variable

Trotz dieser Vorbehalte bietet der Bericht etwas, das in der bisherigen Diskussion über KI-Werkzeuge fehlte. Er übersetzt die Aussage, dass das Fundament wichtiger sei als das Modell, in eine Geldgröße. Solange die Diskussion über agentische Werkzeuge auf den Vergleich von Modellen oder die Geschwindigkeit einzelner Aufgaben reduziert blieb, war die organisatorische Reife eine Aussage über Stil und Reviewkultur. Im DORA-Bericht wird sie zu einer Variable im finanziellen Modell. Eine konservative Annahme über die Reife der internen Plattform senkt den Gesamtwert von 11,6 auf rund 9 Millionen Dollar. Eine optimistische Annahme hebt ihn um den entsprechenden Betrag. Reife ist hier ein Faktor in der Rechnung.

Eine zweite Beobachtung behandelt der Bericht eher beiläufig. Die Inferenzkosten für die fortschrittlichsten Modelle seien zwischen November 2022 und Oktober 2024 um den Faktor 280 gefallen. Damit näherten sich die Kosten der Modellabfrage Null, und die echten Kosten verschöben sich auf die Governance, also auf Verifikation, Workflows und Qualifizierung. Wer in diesen drei Bereichen vorbereitet sei, mit Plattformteam, Reviewkultur und ehrlicher Lehrgeld-Planung, sehe in Jahr zwei und drei den exponentiellen Wertzuwachs, von dem die Autoren sprechen. Wer es nicht sei, bleibe in der Talsohle.

Diese Verschiebung erklärt einen zweiten Befund des Berichts. Die Frage, welches Modell ein Team einsetzt, wird im Bericht zwar erwähnt, aber konsequent in eine Nebenrolle gerückt. Die zentrale Variable ist die Kompetenz, das Modell in einen Arbeitsablauf einzubetten, der Verifikation belohnt und Risiko begrenzt. Was im Jahr 2024 noch als technische Frage galt, ist 2026 eine Organisationsfrage. Der Bericht will diese Verschiebung in einer Zahl sichtbar machen.

Eine Zwischenbilanz des Berichts fasst die Logik nüchtern zusammen: „Der Pfad zum ROI ist eine Sequenz des Aufbaus von Kompetenzen, kein Wettrennen um das neueste Modell oder das neueste Werkzeug." An dieser Aussage endet der Text. Sie liest sich nach 60 Seiten Methodik fast unscheinbar, in der Sache bezeichnet sie aber eine Kehrtwende. Der Wettbewerb um die schnellste Modellgeneration verliert die Rolle, die ihm 2023 und 2024 zugeschrieben wurde. An seine Stelle tritt der Wettbewerb um die reifste Engineering-Organisation. Im Lizenzvertrag entscheidet sich nicht, welche der beiden Disziplinen ein Unternehmen besser beherrscht. Das entscheidet sich in der internen Plattform, in den Reviewroutinen und in der Bereitschaft, drei Monate Lehrgeld zu zahlen, ohne die Mittel vorzeitig zu kürzen.

KI DORA ROI Software Engineering Methode Google Cloud Agentic Coding