KI verstärkt, was da ist, und legt Schwächen offen

Ich stelle mir nicht mehr die Frage, ob ich KI nutzen soll, sondern wie ich sie nutze, um besser und schneller zu werden. In den letzten Wochen habe ich viel ausprobiert und bin dabei auf ein Thema gestoßen, zu dem ich zu wenig lese.

Abgesehen vom reinen Tippen von Quellcode gibt es viele Stellen, an denen KI Probleme sichtbar macht. Viele davon liegen in Prozessen in Unternehmen, die im Management oder in den Teams selbst entstehen.

KI repariert keine organisatorischen Schwächen. Sie wirkt wie ein Brennglas oder wie ein Hochpassfilter. Starke Signale werden verstärkt, schwache verschwinden. Wer Klarheit, Disziplin und Flow hat, wird schneller. Wer nicht, spürt Engpässe härter und früher. Die folgenden traditionellen Arbeitsweisen, Strukturen und Techniken stellen die größten Hindernisse für die erfolgreiche KI-Integration und Nutzung dar.

Falscher Optimierungsfokus und starre Prozesse

Fokus auf Auslastung statt auf Wertschöpfung: Wenn eine Organisation darauf ausgerichtet ist, die Auslastung ihrer Ressourcen zu maximieren oder als reine Feature Factory zu agieren, verpufft der Effekt von KI. KI sorgt in diesem Fall nur dafür, dass sich die Arbeit noch schneller vor den bestehenden Engpässen staut.

Zerstückelte Lieferketten und Silos: Lange Freigabeprozesse, ständige Übergaben zwischen verschiedenen Abteilungen und strikte Silos zwischen Entwicklung und Betrieb bremsen die Geschwindigkeit, die KI eigentlich ermöglicht, massiv aus. Eine brüchige Informationslieferkette staut Arbeit nur schneller an.

Traditionelle Jahresplanung: Die Beibehaltung von jährlicher Planung und streng projektbasierter Finanzierung bei gleichzeitiger Einführung agiler oder KI-gestützter Werkzeuge führt lediglich zu teuren, aber wirkungslosen Zeremonien, ohne die Lieferfähigkeit zu verbessern.

Dysfunktionales Anforderungsmanagement, Klarheit ist der Engpass

Wasserfall-Mentalität und starre Vorab-Dokumentation: Der Versuch, Anforderungen im Vorfeld in gewaltigen, starren Dokumenten wie System Requirements Specifications oder Business Requirements Documents festzuhalten, ist ein massives Problem. Diese Dokumente gaukeln eine Gewissheit vor, die es zu Projektbeginn nicht gibt, und fokussieren sich mehr auf das Dokument selbst als auf den Nutzer.

Sloppy Agile, Agil als Ausrede für Planlosigkeit: Das andere Extrem ist ebenso schädlich. Die falsche Interpretation, dass Agilität bedeutet, keine Dokumentation zu benötigen oder auf das Nachdenken vor dem Programmieren zu verzichten, ist fatal. Ohne klare, testbare Anforderungen generiert KI nur schneller Code für das falsche Produkt, was zu endlosen Überarbeitungsschleifen führt.

Richtige Dokumentation zur richtigen Zeit: Das agile Prinzip bedeutet funktionierende Software über umfassende Dokumentation, nicht statt Dokumentation. Ich brauche testbare Akzeptanzkriterien, BDD-Szenarien und lebende Spezifikationen, die sich mit dem Lernen ändern und erweitert werden.

Mangelnde technische Disziplin und Infrastruktur

Manuelles Testen: Wenn Teams weiterhin manuell testen, dann generiert KI schneller Code, als das Team die Änderungen testen kann. Gerade automatisierte End-to-End-Tests können vorab klären, ob ein neues Feature "Seiteneffekte" hat und an einer anderen Stelle etwas kaputt gegangen ist.

Langlebige Feature-Branches: Wenn Teams weiterhin lange, isolierte Code-Zweige nutzen, entstehen jetzt viel schneller Merge-Orgien, weil sich Änderungen überschneiden und es somit Merge-Konflikte gibt, die von Menschen wieder aufgelöst werden müssen oder zu doppeltem Code führen.

Fehlendes Continuous Delivery: Ohne eine automatisierte Pipeline, kleine Arbeitspakete, Trunk-based Development und automatisierte Deployments erzeugt die KI nur schnelleren Ausschuss, der das System überlastet.

Falsche Erfolgsmessung, Vanity-Metriken

Messen von Aktivität statt Geschäftswert: Wenn das Management den Erfolg von KI daran misst, wie viele Codezeilen geschrieben, wie viele Tickets geschlossen oder wie schnell Code vervollständigt wird, misst es lediglich den Ausstoß, aber nicht das Ergebnis. Es bringt dem Unternehmen keinen Mehrwert, wenn durch KI Code zwar schneller geschrieben wird, dieser dann aber wochenlang auf eine Freigabe warten muss oder in der Produktion fehlschlägt.
Anzahl Deployments ohne Kontext zu Stabilität: Viele Releases sagen nichts aus, wenn Ausfälle, Hotfixes oder Rollbacks gleichzeitig steigen.
Story Points pro Team oder Sprint: Hohe Punktzahlen wirken gut, aber ohne validierten Nutzen sind sie nur Aktivität und sogar zwischen Teams nicht vergleichbar.
Anzahl Codezeilen pro Tag oder Sprint: Mehr Code ist nicht automatisch besser, oft wächst nur die Wartungslast.
Anzahl automatisierter Tests ohne Aussage zur Wirksamkeit: Testanzahl kann steigen, auch wenn die Tests keine kritischen Fehler abdecken oder nur für Code-Abdeckung erstellt werden, ohne dass die Business-Logik geprüft wird.

Warum vor Wie, Klarheit ist der Engpass

Ich sehe in vielen Teams, dass das "Wie" deutlich früher diskutiert wird als das "Warum". Architektur, Tools und Umsetzung sind greifbar, das Ziel bleibt diffus. Genau das ist das Problem. Das "Warum" gibt Richtung, das "Wie" ist Ausführung. Ohne klare Wirkungshypothese wird KI schneller, aber nicht richtiger, sie produziert mehr Output ohne sicheren Nutzen.

Für mich beginnt Klarheit mit einer testbaren Aussage: Welche Wirkung soll eintreten, woran erkenne ich sie, und was wäre ein falsches Ergebnis. Daraus folgen Akzeptanzkriterien, BDD-Szenarien und eine Spezifikation, die leben darf. Ich halte mich an diese Reihenfolge, weil sie Nacharbeiten, Bugs und Fehler reduziert und mir hilft, klein zu liefern und schnell zu lernen.

Wenn Klarheit fehlt, entstehen Schleifen. KI verstärkt diese Schleifen nur. Sie deckt das Problem auf, sie löst es nicht. Wer den Engpass lösen will, muss zuerst das "Warum" sauber klären, alle Projektbeteiligten ins Boot holen und erst dann das "Wie" beschleunigen.

Fazit

Für Entscheidungsträger lautet die wichtigste Erkenntnis: Die Einführung neuer Plattform-Fähigkeiten wie KI erfordert zwingend neue Arbeitsweisen. Was vor KI galt, gilt weiterhin. Saubere Software-Entwicklung, klare Architektur, Tests, Automatisierung und echte Agilität sind der Schlüssel zur Geschwindigkeit.

Klarheit war immer der Engpass, nicht die Geschwindigkeit der Codeproduktion. Wenn ich Entwicklern KI-Tools gebe, aber fehlerhafte Workflows und Engpässe bestehen lasse, wird das Unternehmen im besten Fall nur marginale Verbesserungen sehen, und im schlimmsten Fall eine Beschleunigung der bestehenden Probleme. Ich setze auf testbare Annahmen, Story Refinement und lebende Spezifikationen, die nah am Code bleiben und sich laufend validieren lassen.

Quellen

Dieser Beitrag basiert auf folgenden Quellen: