Es gab eine Zeit, da war die Aufregung groß. Eine neue Modellgeneration jagte die nächste, jeder Benchmark fiel, jeder Twitter-Thread klang nach Revolution. Heute, drei Jahre später, sortiert sich das Feld. Die Tools sind da, sie funktionieren, sie sind in IDEs integriert. Die Aufregung ist weg.
Was bleibt, ist unspektakulär.
Auf den Punkt
Wer die nächsten fünf Minuten nicht hat: drei Jahre KI-Hype, drei Beobachtungen, eine Konstante. Die Tools haben sich verändert. Die Aufgaben, die wir mit ihnen lösen, haben sich verändert. Die Art, wie wir über sie reden, hat sich verändert. Was sich nicht verändert hat, ist die Person, die weiß, was sie nicht weiß. Wer diese Rolle spielt, ist in jedem Team der Anker.
Glossar
- Begriff
- Demo-Lücke
- Bedeutung
- Die Diskrepanz zwischen dem, was ein KI-System in einer Demonstration leistet, und dem, was es im Alltag leistet. In der Demo sind Aufgaben eng gefasst, der Kontext frisch, die Latenz null. Im Alltag sind Aufgaben verworren, der Kontext alt, und die Latenz nicht garantiert.
- Begriff
- Distribution Shift
- Bedeutung
- Der schleichende Drift zwischen der Welt, die ein Modell in seinen Trainingsdaten gesehen hat, und der Welt, in der es heute eingesetzt wird. Wer ein Modell über Monate betreibt, erlebt diesen Drift regelmäßig, oft unbemerkt, bis ein Output auffällt.
- Begriff
- Iteration
- Bedeutung
- Eine einzelne Runde Modell-Aufruf plus Code-Anpassung. In der KI-gestützten Entwicklung ist die Iteration das neue Atom der Arbeit, der kleinste Baustein, der die Produktivität misst.
Drei Beobachtungen aus drei Jahren
Wer die Concept-Map liest, sieht: drei verschiedene Beobachtungen, die alle vom selben Punkt ausgehen. Das ist Absicht. Die Beobachtungen sind unabhängig voneinander entstanden, aber sie hängen am gleichen Phänomen: KI als Werkzeug hat die Arbeit verändert, nicht denken müssen wir weiter selbst.
Die Gewohnheitsfrage
Wer heute ein Softwareteam führt, stellt nicht mehr die Frage setzen wir KI ein. Die Werkzeuge sind in den Editor eingewandert, das ist passiert. Die Frage ist eine andere: wann vertrauen wir, wann prüfen wir, und wie schnell korrigieren wir?
Es gibt Teams, die mit Copilot-ähnlichen Assistenten Code-Review-Zeit um die Hälfte reduziert haben - und Teams, die mit denselben Werkzeugen jeden Patch von Hand gegenprüfen, weil das Vertrauen nie kam. Beide berichten Erfolg. Beide haben Recht.
Wer eine Empfehlung sucht, bekommt sie aus dieser Beobachtung: die Einführung von KI-Werkzeugen ist weniger eine Technologie-Frage als eine Vertrauens-Frage. Wer das Vertrauen nicht kultiviert, bekommt Werkzeuge, die niemand benutzt. Wer das Vertrauen überbeansprucht, bekommt Patches, die niemand prüft. Beide Zustände sind unbrauchbar.
Das Missverständnis der Demo
Demos zeigen das Beste. Wer ein Modell auf einer frischen, eng gefassten Aufgabe laufen lässt, bekommt oft etwas Beeindruckendes. Die Frage ist die zweite Aufgabe. Die dritte. Die fünfzigste, wenn die Bibliothek gerade aktualisiert wurde und der Kontext dreht.
Die Halbwertszeit der Aufregung
Wer ein Jahr in einem Feld arbeitet, sieht den Zyklus, in dem neue Werkzeuge aufgeregt werden, integriert werden und dann Teil der Landschaft werden. KI-Tools sind keine Ausnahme. Was vor drei Jahren noch Demo war, ist heute alltäglich. Was heute noch Marketing ist, wird in zwei Jahren Werkzeugkasten sein.
Die Halbwertszeit der Aufregung ist kurz. Im Sommer 2023 waren KI-Bildgeneratoren das Thema. Im Sommer 2024 waren es Agenten. Im Sommer 2025 waren es multimodale Workflows. Jede Welle hat denselben Verlauf: Ankündigung, Demonstration, Ernüchterung, Integration. Wer in jeder Welle das Signal vom Rauschen trennen will, braucht einen Anker.
Der Anker, den ich gefunden habe, ist die Frage nach dem Output, der ohne das Werkzeug nicht entstehen würde. Wenn ein KI-Werkzeug nur Dinge produziert, die ich ohnehin produziert hätte, ist es Verzierung. Wenn es Dinge produziert, die ich ohne es nicht oder nicht so schnell produziert hätte, ist es Werkzeug. Die Aufteilung ist simpel, aber die Anwendung erfordert Disziplin.
Drei Werkzeuge, die in den letzten drei Jahren diesen Test bestanden haben: Inline-Code-Vervollständigung für triviale Patterns, Agent-Workflows für Erkundungsphasen, semantische Suche für lange Dokumentationen. Drei Werkzeuge, die den Test nicht bestanden haben und entweder wieder verschwunden oder in Nischen geschrumpft sind: vollautomatische Code-Refactorings, autonome Test-Generierung, prädiktive Bug-Vorhersage. Die erste Liste wächst, die zweite schrumpft. Das ist die Form von ehrlicher Adoptions-Geschichte, die jeder Engineer für sich selbst schreiben sollte.
Das ist nicht spezifisch für KI. Es ist dasselbe Phänomen, das jede Software irgendwann trifft: die Annahmen von gestern gelten morgen nicht mehr. KI macht es nur sichtbarer, weil die Annahmen im Modell stecken und nicht im Code.
Die Konsequenz ist eine ehrliche Anforderung an die eigene Erwartung. Wer eine Demo sieht und denkt "so wird meine tägliche Arbeit aussehen", liegt in 80 Prozent der Fälle falsch. Wer die Demo sieht und denkt "so wird meine Arbeit an guten Tagen aussehen", liegt näher an der Realität.
Was sich verändert hat
Drei Dinge, die ich in den letzten Jahren beobachtet habe:
Junior-Entwickler lernen anders. Sie lesen weniger Spec, mehr Output. Das ist nicht schlecht, aber die Lernkurve verlagert sich. Wer einmal eine fertige Funktion gesehen hat, kann sie schneller abwandeln, aber schwerer von Grund auf verstehen. Die Generation, die mit KI aufwächst, wird andere Stärken haben als die, die ohne sie angefangen hat.
Reviews werden politischer. Wenn KI-Code kommt, will jemand das Label sehen. Wer zahlt den Bug, wenn der Vorschlag falsch war? Wer haftet, wenn die Sicherheitslücke übersehen wird? Diese Fragen werden in den meisten Teams noch zu wenig gestellt, weil die bequeme Antwort "es war halt KI" lautet.
Die Lust am Detail stirbt. Es gibt Code, bei dem es auf das Zeichen ankommt. Diese Aufmerksamkeit wird seltener. Wer ein Modell einen Edge-Case erklärt und das Modell die richtige Antwort gibt, hat in dem Moment etwas gewonnen, was kein Modell allein liefern kann: die Fähigkeit, den Edge-Case überhaupt zu sehen.
Was sich nicht verändert hat
Die Wertschätzung für jemanden, der weiß, was er nicht weiß. Das war schon vor KI rar und ist es heute noch. Wer ehrlich sagt ich verstehe diesen Teil nicht, ich brauche mehr Kontext, ist in jedem Team der Anker.
Und die Tatsache, dass die meisten Probleme nicht technischer Natur sind. Sie sind sozial. Sie sind organisatorisch. Sie sind das alte wir haben drei Monate gebraucht, um uns auf ein Format zu einigen, nur jetzt in einer Welt, in der die erste Antwort schneller kommt.
Es gibt eine Beobachtung, die ich in den letzten Monaten immer wieder gehört habe, von CTOs, von Engineering-Managern, von Senior-Entwicklern: "Die Diskussion über KI frisst Zeit, die wir für Architekturentscheidungen brauchen." Das ist kein Argument gegen KI. Es ist eine Beobachtung darüber, wo die Aufmerksamkeit hingeht. Wer KI einführt, sollte das wissen.
Ein letzter Gedanke
Die spannendste Beobachtung ist nicht, was KI kann, sondern wo sie nicht eingesetzt wird. Die wichtigsten Gespräche in einem Projekt finden immer noch zwischen Menschen statt, immer noch mit Kaffee, immer noch langsam. Das ist kein Defizit. Das ist die Architektur.
Wer die kommenden Jahre produktiv gestalten will, sollte nicht nur fragen, was KI kann. Er sollte fragen, was er selbst noch kann, was nur er kann, was die Organisation braucht, das kein Modell liefern kann. Die Antwort auf diese Frage ist der Grund, warum die meisten Teams KI nicht ersetzen werden, sondern nur die Teile ihrer Arbeit, die sie entbehren können.
Das ist die spannendste Beobachtung, die ich in drei Jahren gemacht habe. Sie ist unspektakulär. Sie hat keine Demo, keinen Benchmark, keinen viralen Moment. Aber sie hat den Vorteil, dass sie nach drei Jahren immer noch stimmt.
Weiterführend
- Cal Newport, Slow Productivity - ein Buch, das vor der KI-Welle geschrieben wurde und trotzdem den Ton trifft. Wer die langfristige Persikungung auf Arbeit denkt, findet hier das passende Vokabular.
- Hugging Face, The State of Open Source AI (Jahresbericht) - wer die Industrie beobachten will, ohne Marketing-Hype, findet hier Zahlen, die belegen, was tatsächlich im Einsatz ist.
- Patrick McKenzie, The Internet Was Nailed to a Cross Once - ein Blog-Post über die falsche Vorstellung, dass technologische Revolutionen schneller kommen als sie kommen. Liest sich als Erinnerung daran, dass die längste Reise nicht durch Geschwindigkeit gewonnen wird.
