KI im Konzern: Schnellere Entwicklung braucht andere Prozesse

Wenn die Implementierung statt fünf Tagen nur noch zwei dauert, die Änderung danach aber zwölf Tage auf Reviews, Freigaben und ein gemeinsames Testfenster wartet, ist das Produkt kaum früher beim Nutzer. Die lokale Arbeit wurde schneller. Der Gesamtprozess nicht.

Genau diese Verschiebung macht KI in großen Unternehmen sichtbar. Ein Entwickler kann Code, Tests und eine erste Dokumentation in einem Bruchteil der bisherigen Zeit vorbereiten. R&D kann Hypothesen schneller prüfen und Prototypen früher zeigen. Gleichzeitig bleiben Abhängigkeiten zwischen Teams, widersprüchliche Dokumentation und gewachsene Freigaberunden unverändert. Der Engpass rückt aus der Implementierung in die Organisation.

Das ist kein Argument gegen große Unternehmen. Ihre Formalitäten sind selten aus reiner Freude an Bürokratie entstanden. Regulierung, Produkthaftung, wechselnde Mitarbeiter, verteilte Systeme und jahrzehntelang betriebene Software brauchen Nachvollziehbarkeit. Problematisch wird es, wenn niemand mehr unterscheiden kann, welche Formalität ein echtes Risiko beherrscht und welche nur eine frühere Unsicherheit verwaltet.

KI verstärkt den vorhandenen Arbeitsfluss

Die Zahlen zur Produktivität passen nur auf den ersten Blick nicht zusammen. Drei Feldexperimente bei Microsoft, Accenture und einem weiteren Fortune-100-Unternehmen mit insgesamt 4.867 Entwicklern ergaben für Nutzer eines Coding-Assistenten rund 26 Prozent mehr erledigte Aufgaben. Eine randomisierte METR-Studie mit erfahrenen Open-Source-Entwicklern kam dagegen für frühe 2025er-Werkzeuge auf 19 Prozent längere Bearbeitungszeiten. Im Februar 2026 berichtete METR von Hinweisen auf bessere Ergebnisse mit neueren agentischen Werkzeugen, hielt die Daten wegen Auswahleffekten aber selbst für zu unsicher, um die Größe des Nutzens zu beziffern.

Die Befunde widersprechen sich weniger, als es scheint. Aufgabe, Codebasis, Erfahrung, Werkzeug und Abnahmekriterium verändern das Ergebnis. Der DORA-Report 2025 fasst den organisationalen Teil treffend zusammen: KI wirkt als Verstärker. Gute Feedbackschleifen, gepflegte interne Daten und kleine Änderungen profitieren. Unklare Zuständigkeiten und schwerfällige Abläufe werden ebenfalls verstärkt.

Das erklärt auch eine auffällige Zahl aus Atlassians Befragung von 3.500 Entwicklern und Führungskräften. Fast alle befragten Entwickler berichteten von Zeitersparnis durch KI, während die Hälfte zugleich mehr als zehn Stunden pro Woche durch organisatorische Reibung verlor. Solche Selbstauskünfte sind keine Stoppuhr. Als Diagnose sind sie trotzdem nützlich: Schnellerer Code beseitigt keine Wartezeit.

Der Ticketbaum ist nicht das Produkt

In einem gewachsenen Konzern kann aus einer Produktidee zunächst eine Initiative werden, darunter ein Epic, mehrere Features, Stories und Subtasks. Die Fachbeschreibung liegt in Confluence, eine Architekturentscheidung in einem Kommentar, die Abnahmebedingung in einem Ticket und die tatsächliche Regel im Code. Jede Ebene ist für sich nachvollziehbar. Zusammen entstehen mehrere Wahrheiten.

Das halb agile, halb wasserfallartige Vorgehen folgt daraus fast zwangsläufig. Das Team arbeitet in Sprints, muss den Inhalt aber Monate vorher für Budget, Abhängigkeiten und Gremien festlegen. Rückfragen landen als Ticketkommentare, weil das gesprochene Wort nicht als belastbar gilt. Also wird mehr geschrieben, ohne dass die Dokumentation dadurch konsistenter wird. Bei der Integration mehrerer Systeme wächst die Zahl der Abstimmungen schneller als die Zahl der fachlichen Entscheidungen.

KI sollte diesen Apparat nicht automatisch befüllen. Sonst entstehen nur mehr Epics, längere Zusammenfassungen und noch überzeugender klingende Kommentare. Der bessere Ansatz beginnt mit einer einzigen, kleinen Beschreibung der Absicht. Alles Weitere wird daraus abgeleitet und bleibt mit der Änderung versioniert.

change:
  id: customer-address-v2
  outcome: reduce failed deliveries
  constraints:
    - preserve existing API clients
    - keep customer consent auditable
  owners:
    product: customer-experience
    technical: customer-platform
  evidence:
    - contract-tests
    - migration-report
    - rollback-plan
  risk: medium

Das ist kein neues Pflichtformular. Es ist ein Beispiel für ein kleines, versioniertes Änderungsartefakt, über das man sinnvoll streiten kann. Ein Agent darf daraus betroffene Repositories, frühere Entscheidungen, Verträge und Tests zusammensuchen. Er darf einen Plan, Akzeptanzbeispiele und Dokumentationsänderungen vorschlagen. Outcome, Einschränkungen, Risiko und Eigentümer bestimmt weiterhin das Team.

Der Unterschied zum Ticketbaum liegt in der Richtung: Menschen pflegen nicht fünf Darstellungen derselben Änderung. Die unterschiedlichen Sichten werden aus wenigen versionierten Quellen erzeugt. Das Ticket verweist auf das Artefakt, der Pull Request zeigt den Diff, und die Dokumentation verweist auf die Entscheidung. Eine Zusammenfassung für das Management darf anders aussehen als die technische Sicht, aber beide müssen auf denselben Stand zurückführbar sein.

Integration braucht Verträge statt mehr Abstimmung

Komplexe Integration wird durch KI nicht automatisch einfach. Ein Agent kann einen unbekannten Service schnell lesen und trotzdem eine fachliche Annahme übersehen, die nur das betreibende Team kennt. Gerade deshalb sollte die Zusammenarbeit weniger von Prosa und stärker von überprüfbaren Verträgen abhängen.

Beim Beispiel der geänderten Kundenadresse könnte das relevante Ereignis als Schema vorliegen:

{
  "$id": "CustomerAddressChanged.v2",
  "type": "object",
  "required": ["customerId", "address", "consentId"],
  "properties": {
    "customerId": { "type": "string" },
    "address": { "$ref": "Address.v2.json" },
    "consentId": { "type": "string" }
  }
}

Die KI kann im Code nach Produzenten und Konsumenten suchen, einen Kompatibilitätsbericht erstellen, Contract Tests ergänzen und Testdaten vorbereiten. Sie kann zeigen, dass das CRM consentId bereits liefert, der Versandservice das Feld ignoriert und ein alter Export mit Address.v1 arbeitet. Diese Fleißarbeit spart mehrere Such- und Abstimmungsrunden.

Entscheiden muss sie nicht. Ob eine alte Adresse noch verarbeitet werden darf, ist eine fachliche Frage. Ob beide Versionen parallel laufen oder ein Adapter nötig ist, ist eine Architekturentscheidung. Der Agent sammelt Evidenz; die beteiligten Teams verantworten den Vertrag. Genau dafür sind ADRs und ausführbare Spezifikationen wertvoll: Sie halten nicht jedes Gespräch fest, sondern das Ergebnis und seine Gründe.

Dokumentation wird abgeleitet, nicht abgeschafft

Confluence bleibt für Erklärungen, Einstiegspunkte und Übersichten nützlich. Es sollte nur nicht länger die dritte manuell gepflegte Kopie dessen sein, was Ticket und Code ebenfalls beschreiben. Eine Seite braucht einen benannten Eigentümer, einen überprüfbaren Bezug zu Vertrag, ADR oder Repository und ein sichtbares Aktualisierungsdatum. Fehlt diese Verbindung, darf ein Agent die Seite als möglicherweise veraltet markieren, aber nicht stillschweigend zur Wahrheit erklären.

KI kann aus einer freigegebenen Änderung verschiedene Sichten erzeugen: Release Notes für Nutzer, einen technischen Integrationshinweis und eine kurze Zusammenfassung für das Portfolio. Der jeweilige Text bleibt überprüfbar, weil er auf dieselben Artefakte verweist. Menschen müssen dann nicht jeden Satz dreimal schreiben. Sie prüfen, ob die abgeleitete Sicht für ihre Leser stimmt. Dokumentationspflicht wird dadurch konsistenter und zugleich kleiner: Festgehalten werden Entscheidung, Vertrag und Betriebsfolge – nicht jede Zwischenstufe der Diskussion.

flowchart LR
  Idea[Produktidee] --> Ticket[Ticket-Hierarchie]
  Ticket --> Docs[Separate Dokumentation]
  Docs --> Meetings[Abstimmungsrunden]
  Meetings --> Build[Große Umsetzung]
  Build --> Test[Gemeinsames Testfenster]
  Test --> Approval[Externe Freigabe]

  Intent[Versionierte Absicht] --> SmallChange[Kleine Änderung]
  SmallChange --> Evidence[Tests, Vertrag und Diff]
  Evidence --> Review[Peer Review]
  Review --> Release[Release]
  Release --> Feedback[Nutzer- und Betriebssignal]
  Feedback --> Intent

Agil wird man durch die Kosten einer Änderung

Agilität ist kein bestimmtes Board und keine Zahl von Meetings. Das ursprüngliche Agile Manifesto stellt funktionierende Software über umfassende Dokumentation und die Reaktion auf Veränderung über das Befolgen eines Plans. Beide Aussagen verlangen keine Sorglosigkeit. Sie verlangen, dass neue Information den Arbeitsstand tatsächlich verändern kann.

KI senkt die Kosten vieler Änderungen: Ein Prototyp ist schneller gebaut, eine Alternative schneller untersucht, ein Test schneller ergänzt. Damit wird es weniger sinnvoll, große Pakete lange im Voraus auszudefinieren. R&D kann wieder stärker mit Hypothesen arbeiten: Was wollen wir lernen, welches kleinste Experiment liefert Evidenz, und welches Ergebnis würde unsere Richtung ändern? Produktentwicklung kann denselben Rhythmus nutzen.

Die Voraussetzung sind kleine Batches. Mehr parallel erzeugter Code verschlechtert den Fluss, wenn die Review-Kapazität gleich bleibt. Die Folge wäre eine neue Form von Lagerbestand – halbfertige Pull Requests statt halbfertiger Tickets. Wie bei Developer Productivity zählt deshalb nicht die Tippgeschwindigkeit, sondern die Zeit bis zu belastbarem Feedback. DORA-Metriken helfen beim Diagnostizieren; sie dürfen nicht zum Ziel für einzelne Mitarbeiter werden.

Governance ohne pauschale Warteschlange

Kontrolle bleibt nötig, aber nicht jede Änderung verdient denselben Weg. Eine Textkorrektur, eine rückwärtskompatible API-Erweiterung und ein neues Berechtigungsmodell haben verschiedene Schadenspotenziale. Gute Governance macht diesen Unterschied ausführbar.

approval_policy:
  - risk: low
    requires: [tests, policy-checks, peer-review]
    decision: automated
  - risk: medium
    requires: [tests, contract-checks, owner-review, rollback-plan]
    decision: peer-approved
  - risk: high
    requires: [security-review, compliance-review, business-owner, audit-record]
    decision: manually-approved

Auch diese YAML-Datei ist nur eine Skizze, keine fertige Policy-Sprache. Der wichtige Punkt ist die Staffelung. Automatisierte Kontrollen erzeugen bei jeder Änderung dieselbe Evidenz. Menschen prüfen dort, wo Kontext, Haftung oder schwer rückbaubare Wirkung hinzukommen. DORA empfiehlt seit Jahren, schwere externe Change Approvals durch Peer Review, kontinuierliche Tests, Monitoring und gezielte Zusatzprüfung riskanter Änderungen zu ersetzen. Das ist weniger Bürokratie und zugleich präzisere Kontrolle.

flowchart TD
  Change[Änderung mit Evidenz] --> Risk{Risikoklasse}
  Risk -->|niedrig| Guardrails[Automatische Guardrails]
  Guardrails --> Peer[Peer Review]
  Peer --> Release[Release]
  Risk -->|mittel| Owner[Fachlicher und technischer Owner]
  Owner --> Release
  Risk -->|hoch| Specialist[Security, Compliance und Business]
  Specialist --> Approval{Freigabe}
  Approval -->|ja| Release
  Approval -->|nein| Rework[Überarbeiten oder verwerfen]

Der EU AI Act macht eine zweite Unterscheidung wichtig. Artikel 4 zur AI Literacy galt bereits seit Februar 2025: Wer KI-Systeme bereitstellt oder einsetzt, muss für angemessene Kenntnisse der beteiligten Personen sorgen. Zugleich stuft die Verordnung bestimmte Systeme zur Beschäftigtenbewertung, Verhaltensüberwachung oder verhaltensbasierten Aufgabenzuweisung als hochriskant ein. Aus Prozessdaten ein persönliches Produktivitätsranking zu erzeugen, wäre deshalb nicht nur kulturell zerstörerisch. Es berührt einen rechtlich besonders sensiblen Bereich. Governance soll die Arbeit absichern, nicht Menschen unter Generalverdacht stellen.

Die Organisation muss dem Arbeitsfluss folgen

Ein neuer Assistent allein ändert kein Organigramm. Auf Dauer passt aber eine Organisation mit vielen Übergaben schlecht zu einer Arbeitsweise, die in kurzen Schleifen lernen soll. Drei Strukturen werden wichtiger:

langlebige, funktionsübergreifende Produktteams, die eine Wirkung von der Idee bis zum Betrieb verantworten und kleine Änderungen selbst freigeben können
eine interne Plattform, die sicheren Zugriff auf Code, Dokumentation, Testumgebungen und freigegebene KI-Modelle als Standardweg anbietet
Governance-, Security- und Architekturgruppen, die Regeln, Referenzlösungen und Ausnahmen gestalten, statt jede normale Änderung einzeln durchzuwinken

Das entspricht dem Muster, das ich schon bei einfacherem Entwurf und weniger Prozess beschrieben habe: Erst die Änderung klein und ihre Erwartungen explizit machen, dann den Prozessschritt entfernen, der dadurch überflüssig wird. KI vergrößert den möglichen Hebel, ersetzt aber nicht diese Architekturarbeit.

Für die beteiligten Rollen verschiebt sich der Schwerpunkt:

Rolle	Neuer Schwerpunkt
Entwickler	Aufgaben schneiden, Kontext bereitstellen, generierte Änderungen prüfen, Tests und Betriebssignale entwerfen
Architekten	Systemverträge, Fitness Functions, Rückbaubarkeit und sichere Standardwege gestalten
Product Owner	Outcomes, Akzeptanzbeispiele und Nutzerfeedback schärfen, statt den Ticketbestand zu verwalten
Projektmanagement	Abhängigkeiten, Risiken, Wartezeiten und Work in Progress verringern, statt Tätigkeiten im Detail vorzuplanen

Keine dieser Rollen verschwindet. Im Gegenteil: Je billiger die Erzeugung von Vorschlägen wird, desto wertvoller werden Auswahl, Urteil und Verantwortung. Das Ergebnis eines einzelnen KI-Power-Users lässt sich nicht einfach auf einen Konzern hochrechnen. Teams brauchen gemeinsame Prüfkriterien, Lernzeit und einen Arbeitsfluss, der Unterschiede sichtbar macht.

Klein anfangen und den Gesamtzyklus messen

Ein konzernweites Transformationsprogramm wäre ein widersprüchlicher Anfang. Besser ist ein einzelner Wertstrom mit einer wiederkehrenden Änderung, deren Risiko bekannt ist. Dort lässt sich der heutige Weg vom Wunsch bis zum Betrieb aufzeichnen: Wie lange wird gearbeitet, wie lange gewartet, wie oft wird dieselbe Information übertragen, und an welcher Stelle entsteht Nacharbeit?

Für einen ersten Versuch reichen wenige Schritte:

ein versioniertes Änderungsartefakt und die führenden Quellen festlegen
der KI nur lesenden Zugriff geben und ihren Kontext nachvollziehbar protokollieren
Tests, Contract Checks und Dokumentations-Diffs automatisch als Evidenz erzeugen
zunächst ausschließlich kleine, reversible Änderungen durch den neuen Pfad schicken
Lead Time, Wartezeit, Zahl der Übergaben, Nacharbeit, Change Fail Rate und Zeit bis zum Nutzerfeedback vergleichen

Nicht messen würde ich erzeugte Codezeilen, geschlossene Tickets oder individuelle Prompt-Aktivität. Solche Zahlen belohnen Volumen. Der gewünschte Effekt ist ein anderer: weniger halbfertige Arbeit, weniger widersprüchliche Dokumentation, frühere Rückmeldung und ein kontrollierbarer Release.

Fazit

Die schwerfälligen Abläufe großer Unternehmen sind kein Naturgesetz, aber auch nicht bloß Dummheit aus der Vergangenheit. Sie bewahren Zuständigkeit, Wissen und Kontrolle dort, wo technische Mittel lange nicht ausgereicht haben. KI verändert diese Rechnung, weil sie Kontext schneller zusammentragen, Evidenz vorbereiten und wiederkehrende Prüfungen unterstützen kann.

Der Gewinn entsteht erst, wenn die Organisation die frei werdende Zeit nicht mit mehr Output füllt. Kleine Änderungen ersetzen große Planungspakete. Verträge ersetzen einen Teil der Abstimmung. Versionierte Artefakte ersetzen widersprüchliche Kopien. Risikobasierte Guardrails ersetzen pauschale Freigabeschlangen. Menschen behalten die Entscheidungen, bei denen Fachlichkeit, Haftung und Folgen zählen.

So kann KI Entwicklung und R&D tatsächlich agiler machen: nicht indem sie den alten Prozess schneller ausfüllt, sondern indem sie hilft, seine Umwege überflüssig zu machen.