Fünf Stufen, fünf Hebel

Ich gebe seit einigen Monaten Schulungen zu Agentic Software Engineering. Und die erste Frage ist fast immer dieselbe: „Wie viel schneller wird mein Team damit?”

Schneller. Das ist das Wort, an dem sich alles aufhängt. Schneller coden, schneller Tickets schließen, schneller liefern. Und ja, Geschwindigkeit ist ein Hebel. Aber es ist der kleinste.

Was ich immer wieder sehe: Teams, die KI nur als Beschleuniger einsetzen, bleiben unter ihren Möglichkeiten. Manche werden sogar langsamer, weil sie ein neues Werkzeug in einen alten Prozess pressen und sich dann wundern, dass es knirscht.

Dabei gibt es mindestens fünf verschiedene Arten, wie KI einen Hebel bietet. Und jede einzelne verändert die Arbeit auf eine andere Weise.

Stufe 1: Geschwindigkeit

Das ist die Stufe, die jeder kennt. Autocomplete im Editor, Copilot, Tab-Tab-Tab. Der Code, den ich ohnehin geschrieben hätte, entsteht schneller. Die Boilerplate verschwindet. Die Unit-Tests generieren sich halb von allein.

Der Hebel: Geschwindigkeit. Gleiche Arbeit, weniger Zeit.

Das ist nicht nichts. Aber es ist auch nicht das, was den Unterschied macht. Denn wenn ich vorher mittelmäßigen Code geschrieben habe, schreibe ich jetzt schneller mittelmäßigen Code. Die Qualität bleibt gleich. Nur die Menge steigt.

Und hier liegt das Problem, das ich in fast jedem Team sehe: Alle optimieren auf diese Stufe. Weil sie greifbar ist. Weil man sie messen kann. Weil „30 % schneller” auf einer Folie gut aussieht. Aber 30 % schneller in die falsche Richtung ist kein Fortschritt.

Stufe 2: Breite

Stufe 2 ist subtiler und wird oft übersehen. Hier geht es darum, etwas zu tun, das ich vorher schlicht nicht konnte.

Ein konkretes Beispiel: Ich bin kein Swift-Entwickler. Trotzdem habe ich letzte Woche einen funktionierenden macOS-Prototyp zusammengebaut. Das Modell hat nicht für mich „gecoded”. Es hat mir den Zugang zu einer Domäne eröffnet, in der ich mich sonst tagelang einlesen müsste.

Ich nenne das den Breite-Hebel. Fähigkeiten, die vorher eine Spezialisierung erfordert hätten, sind plötzlich erreichbar.

Für Teams bedeutet das: Der Frontend-Entwickler, der plötzlich einen Datenbank-Migrationsplan entwerfen kann. Der Architekt, der ein Terraform-Setup aufbaut, ohne DevOps-Erfahrung zu haben. Nicht perfekt, aber gut genug, um zu starten und zu iterieren.

Das verändert, wer welche Aufgaben übernehmen kann. Und damit verändert es die Teamstruktur.

Stufe 3: Qualität

Hier wird es für mich persönlich interessant. Und hier steigen die meisten aus, weil es unbequem wird.

Stufe 3 bedeutet: Ich nutze KI nicht als Produzent, sondern als Sparringspartner. Ich zeige ihr meinen Architekturentwurf und frage: Wo sind die Schwachstellen? Ich beschreibe eine Entscheidung und lasse mir Gegenargumente generieren. Ich lege ihr mein API-Design vor und frage: Was passiert, wenn sich die Anforderungen in sechs Monaten ändern?

Was sich hier ändert, ist die Qualität der Ergebnisse. Bessere Entscheidungen statt mehr Output.

Ab hier ist KI kein Produktivitäts-Tool mehr. Es ist ein Denk-Werkzeug. Und das ist der Punkt, an dem viele Angst bekommen. Denn es bedeutet, sich hinterfragen zu lassen. Von einer Maschine.

Ab hier werden die erfahrenen Leute hellhörig. Die Juniors freuen sich über Autocomplete. Aber die Seniors und Architekten merken: Das hier kann mir helfen, blinde Flecken zu finden, die ich alleine übersehe. Ich nutze das mittlerweile systematisch. Bevor ich eine Architekturentscheidung einem Kunden präsentiere, hat ein LLM sie auseinandergenommen. Das Modell ist nicht schlauer als ich. Aber es kommt aus einer anderen Richtung.

Stufe 4: Kapazität

Stufe 4 ist das, was gerade unter „Agentic” läuft. Ich gebe nicht mehr Schritt für Schritt Anweisungen, sondern delegiere eine Aufgabe. „Implementiere dieses Feature basierend auf der Spec.” „Schreib die Tests für dieses Modul.” „Refactore diese Klasse nach dem besprochenen Pattern.”

Hier geht es um Kapazität. Ich arbeite an mehreren Dingen gleichzeitig, weil die KI eigenständig arbeitet.

Das klingt trivial. Ist es nicht. Denn Delegation erfordert etwas, das die meisten Entwickler nie lernen mussten: präzise Spezifikation. Wenn ich einem Menschen sage „mach das mal schöner”, kann der nachfragen, den Kontext inferieren, meine Mimik lesen. Ein Agent macht genau das, was ich sage. Nicht mehr, nicht weniger.

In der Praxis heißt das: Wer bei Stufe 4 ankommen will, muss besser werden im Beschreiben und Spezifizieren. Das ist eine Fähigkeit, die bisher hauptsächlich bei Architekten und Product Ownern lag. Jetzt braucht sie jeder, der produktiv mit KI arbeiten will.

Ich erlebe das in meinen eigenen Projekten täglich. Ein Agent, der ein Feature autonom umsetzt, während ich parallel die Architektur für das nächste Modul entwerfe. Das ist ein Kapazitätssprung, der sich nicht in Prozenten messen lässt. Aber er funktioniert nur, wenn die Spec stimmt. Sonst kommt nach einer Stunde ein Feature zurück, das technisch korrekt und inhaltlich daneben ist.

Stufe 5: Transformation

Stufe 5 ist weniger eine Technik als ein Mindset-Shift. Die Frage ist nicht mehr „Wie mache ich X schneller?” oder „Wie delegiere ich Y?”. Die Frage ist: „Was kann ich jetzt tun, das vorher unmöglich war?”

Das ist die Stufe, die mich als Berater am meisten beschäftigt. Weniger wegen der Technik, mehr wegen der Frage, die sie aufwirft: Was machen wir mit unserem Geschäftsmodell?

Ein Beispiel aus meiner Praxis: Ein Kunde hatte jahrelang eine Idee für ein internes Tool auf dem Backlog. Zu teuer, zu aufwändig, kein Budget. Mit KI-gestützter Entwicklung war das plötzlich ein Zwei-Wochen-Projekt. Die Technologie war nicht der Blocker. Die Kalkulation war es. Und die Kalkulation hat sich geändert.

Das sehe ich gerade überall. Projekte, die seit Jahren im Backlog verrotten, werden plötzlich wirtschaftlich. Keine brillanten neuen Ideen. Die Kosten-Nutzen-Rechnung hat sich einfach verschoben. Das Spannende daran: Es sind oft nicht die offensichtlichen Projekte. Es sind die kleinen, spezialisierten Lösungen, die sich vorher für niemanden gelohnt haben.

Der Hebel hier ist Transformation. Andere Arbeit wird möglich, die vorher an der Kalkulation gescheitert ist.

Wenn ich mit Kunden über KI-Strategie rede, ist das der Punkt, an dem die spannenden Gespräche anfangen. Nicht „wie sparen wir Headcount?”, sondern „was können wir jetzt angreifen, weil die Kosten-Nutzen-Rechnung sich verschoben hat?”

Der Fehler, den alle machen

Die meisten Teams, die ich sehe, stecken bei Stufe 1. Geschwindigkeit ist einfach die offensichtlichste Metrik. Mehr Code pro Tag. Mehr Tickets pro Sprint. Mehr Output.

Aber mehr ist nicht besser. Dreimal so viel Code, der die falsche Abstraktion implementiert, ist kein Gewinn. Schnellere Tickets, die am echten Problem vorbeiarbeiten, sind Verschwendung. Ein Team, das dreimal so viel produziert aber genauso oft daneben liegt, hat nichts gewonnen.

Der eigentliche Produktivitätssprung passiert, wenn man aufhört, KI als Turbo zu sehen, und anfängt, sie als Hebel für bessere Arbeit zu begreifen. Geschwindigkeit ist Stufe 1. Die interessanten Dinge passieren danach.

Die meisten Teams werden eine Weile brauchen, um da hinzukommen. Das ist okay. Aber man sollte wenigstens wissen, wohin die Reise geht.