Der WOW-Effekt ist vorbei

Letzte Woche war ich zum Training bei einem Kunden. Zwölf Entwickler im Raum, alle mit Vorerfahrung. Einige nutzen Claude Code täglich im Arbeitsalltag, nicht als Spielerei. Vor ein paar Monaten wäre das noch eine Grundlagen-Session gewesen. Dieses Mal nicht. Den WOW-Effekt hatten die längst hinter sich.

Was stattdessen im Raum war: richtig gute Fragen.

“Wie setzen wir das in Legacy-Codebases ein?” “Darf ich Agenten auf Produktiv-Code loslassen?” “Was sind eure Erfahrungen jenseits der Greenfield-Spielwiese?”

Das sind andere Fragen als die, die ich sonst höre. Und sie zeigen, dass bei diesem Kunden etwas passiert, das ich in dieser Geschwindigkeit nicht erwartet hätte.

Wenn ein Team Feuer fängt

Was bei diesem Kunden anders ist: Von ganz oben ist das Commitment da, voll auf KI zu setzen. Alle Entwickler bekommen Claude-Code-Lizenzen und werden systematisch geschult. Alle werden ermutigt, das Zeug im Alltag einzusetzen.

Aber was mich wirklich beeindruckt hat, war nicht die Management-Entscheidung. Es war das, was danach passiert ist.

Die Kollegen, die schon länger mit KI-Agenten arbeiten, haben ihr Wissen weitergetragen. Beim Mittagessen, in Code-Reviews, in internen Demos. Wer einmal gesehen hat, wie ein Kollege mit einem Agenten ein Feature in einer Stunde umsetzt, das vorher einen Tag gedauert hätte, will das auch. Die nächste Person probiert es aus, stößt auf eine Frage, nimmt die Antwort mit ins Team. Das hat kein Manager angeordnet. Das passiert, weil die Ergebnisse für sich sprechen.

Und es bleibt nicht bei den Entwicklern. Das Thema sickert durch die ganze Organisation, weil die Leute sehen, was um sie herum passiert, und Teil davon sein wollen. Das hat Auswirkungen auf Staffing, auf Roadmaps, auf die Art wie dort Projekte geplant werden.

Drei Phasen, eine wachsende Kluft

Wenn ich die KI-Adoption bei meinen Kunden beobachte, zeichnet sich ein Muster ab.

Phase 1: Staunen. KI schreibt Code. Teams probieren Copilot oder ChatGPT, generieren Boilerplate, fassen Meetings zusammen. Alle finden es beeindruckend, die meisten nutzen es unregelmäßig.

Phase 2: Die richtigen Fragen. Der WOW-Effekt verblasst. Dafür kommen Fragen, die wehtun. Funktioniert das auch in meiner 200.000-Zeilen-Codebase? Was passiert mit der Architektur, wenn Agenten autonom arbeiten? Wo ziehe ich die Grenze zwischen generiertem und handgeschriebenem Code?

Phase 3: Die Organisation kippt. Nicht nur Entwickler arbeiten anders. POs, Ops-Leute, Fachexperten wollen rein. Die Frage verschiebt sich von “Wie nutze ich das Tool?” zu “Wie verändert sich unsere Arbeitsweise?”. Und das geht weit über Code hinaus.

Die meisten Unternehmen, die ich als Berater sehe, stehen bei Phase 1. Etliche sogar davor. Copilot ist lizenziert, ein paar Leute nutzen es für Autocomplete, der Rest hat es zweimal ausprobiert und wieder vergessen. Vielleicht mal eine E-Mail zusammenfassen oder ein Meeting-Protokoll generieren. Agentische Workflows, autonome Agenten auf echtem Code? Findet nicht statt. Nicht auf breiter Fläche.

Gleichzeitig gibt es Teams, die bei Phase 2 ankommen und mit einer Geschwindigkeit lernen, die mich selbst überrascht.

Die Kluft zwischen diesen Welten wird täglich breiter.

Das Kulturproblem

Woran liegt es? Es wäre einfach, die Tools verantwortlich zu machen. Aber das greift zu kurz.

Die Teams, die abheben, haben keine besondere Toolchain. Sie haben eine Kultur. Eine, in der es okay ist, etwas auszuprobieren und dabei auf die Nase zu fallen. In der Kollegen sich zeigen, was funktioniert hat. In der niemand auf eine Freigabe wartet, bevor er ein Werkzeug anfasst.

In vielen Enterprises sieht es anders aus. Bei einem anderen Kunden, ein paar Wochen vorher, habe ich das Gegenteil erlebt. Copilot war ausgerollt, flächendeckend lizenziert. Auf dem Papier war die Firma “KI-ready”. In der Praxis hat fast niemand das Ding für mehr als Autocomplete genutzt. Ein Entwickler sagte mir, er fasse Meetings damit zusammen. Sonst nichts. Das war der Stand.

KI ist freigegeben, aber nur in einem engen Korridor. Copilot ja, alles andere gesperrt. Experimentieren nur nach Genehmigung. Und wenn etwas schiefgeht, wird der Korridor enger statt weiter.

Das Ergebnis: Die Neugierigen werden ausgebremst, der Multiplikator-Effekt stirbt, und die Organisation lernt nichts. Die Leute wollen. Die Struktur lässt es nicht zu.

Ich halte das für ein strategisches Risiko. Nicht weil KI morgen alle Jobs ersetzt. Sondern weil der Abstand zwischen Organisationen, die lernen, und solchen, die bremsen, in Monaten entsteht, aber Jahre braucht, um aufzuholen. Kulturwandel bestellt man nicht bei Microsoft.

Planung schlägt Prompten

Eine Beobachtung bei den fortgeschrittenen Teams: Der Engpass ist nie das Tool. Der Engpass ist die Vorbereitung.

Die produktivsten Teams investieren den größten Teil ihrer Zeit in Planung und Spezifikation. Nicht in Prompts. Nicht in Tool-Konfiguration. In die Frage: Was genau soll der Agent tun, und woran erkenne ich, ob er es richtig gemacht hat?

Das ist im Grunde Software Engineering, wie es immer hätte sein sollen. Saubere Specs, klare Akzeptanzkriterien, durchdachte Architektur. Nur dass der Preis für schlechte Spezifikation jetzt sofort sichtbar wird. Ein Agent mit einer vagen Aufgabe liefert ein vages Ergebnis. Sofort. Kein Mensch der nachfragt, kein Kollege der den Kontext ergänzt.

Die Tools werden einfacher, aber die Anforderungen an die Menschen steigen. Nicht die technischen. Die konzeptionellen. Wer klar denken und präzise beschreiben kann, wird produktiver. Wer das nicht kann, hat jetzt ein Werkzeug, das seine Unklarheit in Echtzeit zu Code kompiliert.

Was sich verschiebt

In den Teams jenseits von Phase 1 beobachte ich eine Verschiebung. Es geht immer weniger darum, ob jemand eine Programmiersprache beherrscht. Es geht darum, ob jemand erkennt, wo Software ein Problem lösen kann.

In einem Geschäftsprozess die Stelle finden, an der Automatisierung einen Unterschied macht. In einer Codebase den Punkt erkennen, an dem ein Agent sinnvoll eingesetzt werden kann. Das ist keine rein technische Fähigkeit. Es ist eine Mischung aus Domänenwissen und technischem Gespür.

Diese Fähigkeit ist nicht an eine Berufsgruppe gebunden. Wer Prozesse versteht und Software-Chancen erkennt, kann mit den richtigen Werkzeugen etwas daraus machen. Egal ob Dev, PO oder Ops.

Was bleibt

Was ich in den letzten Wochen gesehen habe, lässt sich auf eine Beobachtung reduzieren: Teams, in denen Kollegen sich gegenseitig anstecken, die beim Mittagessen über ihre Erkenntnisse reden und intern Workflows teilen, die ziehen davon. Leise, aber schnell.

Und die Organisationen, die “erstmal abwarten” wollen, fallen genauso schnell zurück. Nicht weil ihnen Budget fehlt oder die Tools nicht reif genug sind. Sondern weil sie ein Kulturproblem haben, das sie als Toolproblem verkleiden.

Agentische Softwareentwicklung findet auf breiter Fläche noch nicht statt. Aber bei den Teams, in denen es stattfindet, verändert sich gerade alles. Und die werden nicht auf den Rest warten.

Wer gerade merkt, dass der WOW-Effekt vorbei ist: Gut. Jetzt geht’s los.