# Was still bleibt > Drei Jahre KI-Hype, drei Beobachtungen, eine Konstante: geblieben sind nicht die Tools, sondern die Gewohnheiten, die wir drumherum gebaut haben. Veröffentlicht: 2026-08-18 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 {% definition term="Demo-Lücke" description="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." /%} {% definition term="Distribution Shift" description="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. Wer mehr dazu lesen will, findet in [Modell-Drift](/posts/modell-drift) eine genauere Aufarbeitung des Phänomens." /%} {% definition term="Iteration" description="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." /%} ## Was bleibt vom KI-Hype {% loop data="{\"items\":[{\"label\":\"Fokus\"},{\"label\":\"Tempo\"},{\"label\":\"Disziplin\"}]}" /%} 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. ## Drei Beobachtungen aus drei Jahren ### Fokus: wann vertrauen wir, wann prüfen wir? 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. ### Tempo: die zweite, die dritte, die fünfzigste Aufgabe 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. Das ist die alte [Demo-Lücke](#glossar), nur konkreter: im Alltag arbeiten Modelle mit altem Kontext, mit echten Latenzen, mit Aufgaben, die der Mensch selbst noch nicht ganz verstanden hat. ### Disziplin: ehrliche Adoptions-Geschichte Drei Werkzeuge, die in den letzten drei Jahren den 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. Die Frage, die ich als Anker benutze: produziert dieses Werkzeug einen Output, der ohne es nicht entstehen würde? Wenn die Antwort nein ist, ist es Verzierung. Wenn ja, ist es Werkzeug. Die Aufteilung ist simpel, die Anwendung erfordert Disziplin. Jeder Engineer sollte diese Liste für sich selbst schreiben. Wer das nicht tut, behält eine Marketing-Erinnerung statt einer ehrlichen Adoptions-Geschichte. ## KI-Tools im Engineering-Alltag ### Was sich verändert hat **Junior-Entwickler lernen anders.** Sie lesen weniger Spec, mehr Output. Das hat seine Tücken, denn 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. Wer das vertiefen will, dem hilft der Blick auf [Agentische Arbeit](/posts/agentische-arbeit) weiter: derselbe Punkt, nur aus der Perspektive von Teams, die mit autonomen Workflows experimentieren. ## 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. 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. ## Ein letzter Gedanke Die spannendste Beobachtung ist, wo KI *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. Wer [Prompt als Protokoll](/posts/prompt-als-protokoll) gelesen hat, kennt diese Logik: der Wert liegt nicht im Output, sondern in der Disziplin, mit der der Output erzeugt wird. 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 - **[Slow Productivity](https://calnewport.com/slow/)** (Cal Newport), ein Buch, das vor der KI-Welle geschrieben wurde und trotzdem den Ton trifft. Wer die langfristige Perspektive auf Arbeit denkt, findet hier das passende Vokabular. - **[State of Open Source on Hugging Face: Spring 2026](https://huggingface.co/blog/huggingface/state-of-os-hf-spring-2026)**, wer die Industrie beobachten will, ohne Marketing-Hype, findet hier Zahlen, die belegen, was tatsächlich im Einsatz ist. - **[Kalzumeus Software](https://www.kalzumeus.com/)** (Patrick McKenzie / patio11), ein Blog, der seit zwei Jahrzehnten die falsche Vorstellung korrigiert, dass technologische Revolutionen schneller kommen als sie kommen. Liest sich als Erinnerung daran, dass die längste Reise nicht durch Geschwindigkeit gewonnen wird.