Seit Januar 2026 beobachte ich, wie einzelne Engineers in unserem Team mehrere Features in einer einzigen Woche liefern, für die wir zuvor einen Monat oder länger gebraucht hätten. Das war keine schrittweise Verbesserung, sondern ein plötzlicher Sprung. Die Modelle und die Infrastruktur haben eine Schwelle erreicht, sodass sich die Spielregeln im Engineering fundamental verändert haben.

Ich bin nicht der Einzige, der das beobachtet. Tobi Lütke von Shopify sagt, er habe „in den letzten drei Wochen mehr Code geliefert als im gesamten Jahrzehnt davor." Etienne de Bruin, der Dutzende CTOs coacht, berichtet von einem Junior Engineer, der drei produktionsreife Services in einer einzigen Woche gebaut hat. Gabe Pereyra von Harvey sagt, der Engpass in der Produktentwicklung habe sich von der Implementierung hin zu Review und Priorisierung verschoben.

In diesem Artikel teile ich die sechs Lektionen, wie KI Produkt und Engineering Teams bereits verändert hat und was meiner Meinung nach nötig ist, um heute wettbewerbsfähige Organisationen aufzubauen. Basierend auf den Erfahrungen beim Umbau unseres Forgent Engineering Teams rund um autonome Agenten.

1. Die Fähigkeitsschwelle

Im Januar 2026 überschritten Coding Agenten eine Kohärenzschwelle. Die Modelle wurden nicht einfach schneller beim Autocomplete. Sie wurden fähig zu anhaltendem, mehrstufigem Reasoning: eine Implementierung planen, sie über mehrere Dateien hinweg ausführen, Tests laufen lassen, Fehler diagnostizieren und autonom iterieren, bis die Tests bestehen. Dies ist ein exponentieller Trend, der in den METR Benchmarks und anderen sichtbar ist.

Zwei Durchbrüche trieben diese Entwicklung. Reinforcement Learning from Verifiable Rewards (RLVR), also das Training von Modellen gegen maschinell überprüfbare Ergebnisse wie das Bestehen von Tests, verbesserte die Codequalität und Selbstkorrektur dramatisch. Inference Time Compute Scaling gab den Modellen die Fähigkeit, bei komplexen Problemen „intensiver nachzudenken". Darüber hinaus ermöglichten längere Kontextfenster, robuste Werkzeugnutzung und Verbesserungen der Infrastruktur eine kohärente Ausführung über Dutzende von Schritten hinweg.

Karpathy beschrieb diesen Übergang als den Wechsel von „Vibe Coding" zu „Agentic Engineering", bei dem Engineers autonome Agenten orchestrieren, anstatt selbst Code zu schreiben. Gabe Pereyra von Harvey veranschaulicht die Geschwindigkeit dieses Wandels: Seine Eltern, beide in Stanford ausgebildete Informatiker, einer bei Apple, die andere Stanford Professorin, wurden vom Fähigkeitssprung völlig überrascht. Wenn selbst Fachexperten ihn nicht kommen sahen, haben die meisten Branchen noch nicht einmal begonnen zu verarbeiten, was das bedeutet.

Der Zeithorizont für die Aufgabenbewältigung bezeichnet die Aufgabendauer (gemessen an der Bearbeitungszeit eines menschlichen Experten), bei der ein KI Agent mit einer bestimmten Zuverlässigkeit voraussichtlich erfolgreich ist. Der 50 % Zeithorizont ist beispielsweise die Dauer, bei der ein Agent voraussichtlich in der Hälfte der Fälle erfolgreich ist. Die folgende Grafik zeigt die 50 % und 80 % Zeithorizonte für führende KI Agenten, berechnet auf Basis ihrer Leistung bei über hundert unterschiedlichen Softwareaufgaben. Hinweis: Die Achsen sind log linear, das beobachtbare Wachstum ist daher exponentiell; Quelle: METR Benchmarks

II. Was wir beim Umbau unserer Engineering Organisation rund um Agenten gelernt haben

Lektion 1: Überprüfbare Ziele sind der Schlüssel. Der wichtigste Enabler für langlebige Agenten ist, ihnen ein messbares Ziel zu geben. Wenn ein Agent Tests ausführt, Fehler erkennt und iterieren kann, solange bis die Tests bestanden sind, kann man ganze Features übergeben. Tobi Lütke von Shopify ließ Autoresearch auf ihre Templating Engine los und erzielte über Nacht 53 % schnelleres Rendering durch 93 automatisierte Commits. Kent Beck argumentierte kürzlich, dass TDD relevanter denn je ist, gerade weil Agenten maschinell überprüfbare Feedbackschleifen brauchen. Auf der anderen Seite: Vage Anweisungen produzieren vage Ergebnisse. UI/UX Arbeit mit Anweisungen wie „erstelle eine intuitive Benutzeroberfläche" liefert nach wie vor keine guten Ergebnisse.

Lektion 2: Die Infrastruktur ist wichtiger als das Modell. Ein Agent ist nur so effektiv wie die Infrastruktur um ihn herum: wie Kontext zusammengestellt wird, wie Werkzeuge bereitgestellt werden und wie Feedbackschleifen (Tests, Linter, Evaluatoren) Selbstverifikation ermöglichen. Bei Forgent haben wir intensiv in strukturierte Regeln (CLAUDE.md Dateien, Skill Definitionen), Coding Infrastruktur (Preview Server, automatisierte Tests, Evals) und breiten Zugang zu Informationen im gesamten Unternehmen investiert. LangChain berichtete, dass sie ihren Coding Agenten von 52,8 % auf 66,5 % auf TerminalBench verbesserten, indem sie ausschließlich die Infrastruktur änderten. Aber es gibt eine Kehrseite: Ohne gute Praktiken wird der Geschwindigkeitsmultiplikator zum Schuldenakzelerator. Der DORA Report 2025 bestätigte, dass KI verstärkt, was bereits vorhanden ist. Teams mit starken Delivery Praktiken werden schneller, während Teams ohne solche technische Schulden in beispiellosem Tempo anhäufen.

Lektion 3: Leitplanken und QA sind wichtiger als Geschwindigkeit allein. Die Kehrseite von zehnfachem Output ist ein zehnfach höheres Risiko für Qualitätsverlust. Die Analyse von Stack Overflow ergab 75 % mehr Logikfehler in KI erstellten PRs im Vergleich zu von Menschen geschriebenen. Amazon erlebte dies Anfang 2026, als KI gestützte Codeänderungen zu Serviceausfällen beitrugen. Bei Forgent setzen wir Agentenschwärme ein, darunter BUGBOT und Claude Code Review für kontinuierliches Code Review, und betrachten Tokenausgaben für Review Tooling als hochrentable Investition. Geschwindigkeit ohne Qualität und Zuverlässigkeit ist wertlos.

Lektion 4: Der Engpass verschiebt sich zu Urteilsvermögen und Geschmack. Wenn Bauen billig wird, ist der teuerste Fehler, das Falsche zu bauen. Produktgespür, Nutzerforschung und die Disziplin, „Nein" zu sagen, wurden unsere wirkungsvollsten Fähigkeiten. Produktentdeckung und menschliches Review sind jetzt die Engpässe, Aktivitäten, die noch nicht sinnvoll automatisiert werden können. Wir beobachten die Entstehung des Product Engineers: eine Rolle, die Nutzerempathie, Produktgespür und technische Kompetenz vereint. Da KI die in jeder Disziplin erforderliche Tiefe reduziert, brauchen Unternehmen Allrounder, die Disziplinen zusammenführen. Nicht alle sind dieser Meinung. Anthropics Growth Team stellt stattdessen mehr PMs ein. Die richtige Antwort hängt vermutlich von Teamgröße und Koordinationsaufwand ab.

Lektion 5: Die Organisation muss sich ändern, nicht nur die Werkzeuge. Wenn Agenten die Ausführung übernehmen, erfordert die verbleibende menschliche Arbeit enge Koordination. Isolierte Funktionen erzeugen Übergabeaufwand, den Agenten nicht beseitigen. Bei Forgent bestehen Projektteams jetzt aus ein bis zwei Engineers, einem PM und einem Designer, klein genug, um in einem Raum zu sitzen und schnell Entscheidungen zu treffen. Mittelfristig glaube ich, dass Funktionen wie Produkt, Design und Engineering weiter verschmelzen werden. Wie Dorsey und Botha argumentieren, müssen Organisationen davon abkommen, Menschen als Informationsrouter einzusetzen, und stattdessen ein „Weltmodell" des Unternehmens aufbauen, in dem KI die Koordination übernimmt und Menschen Urteilsvermögen und strategisches Denken beisteuern.

Lektion 6: Kontextwechsel, nicht Rechenleistung, begrenzt die Parallelisierung. Agenten können parallel laufen, aber Menschen können nicht endlos den Kontext wechseln. Mein effektives Limit liegt heute bei zwei parallelen Agenten, die an unabhängigen Features arbeiten. Darüber hinaus übersteigt der Reviewaufwand die eingesparte Zeit. Die knappe Ressource ist menschliche Aufmerksamkeit. Engineers müssen eine neue Fähigkeit erlernen: den Wechsel vom Coden zum Beaufsichtigen von Agenten, zu wissen, wo KI versagt, welchen Code man reviewen muss und wie man sich selbst als Agentenmanager skaliert.

III. Was das für Tech Teams bedeutet

In Infrastruktur investieren, nicht nur in Modelle. Baut die Infrastrukturschicht in Eure CI/CD ein: strukturierte Regeln, Preview Server, automatisierte Evals und Qualitätsleitplanken. Jede Regel, die Ihr kodifiziert, und jede Feedbackschleife, die Ihr automatisiert, macht jeden zukünftigen Agentenlauf zuverlässiger.

Kontextzusammenstellung automatisieren. Die Effektivität von Agenten hängt davon ab, den richtigen Kontext zur richtigen Zeit zu haben. Integriert Eure Werkzeuge (Slack, Notion, GitHub, Figma, Eure Codebasis), damit Agenten auf alle zugreifen können. Behandelt Kontextkuratierung als laufende Infrastrukturarbeit.

Um kleine, integrierte Teams herum umstrukturieren. Reduziert den Koordinationsaufwand, indem Ihr kleine Einheiten bildet, in denen eine einzelne Person oder ein kleines Team den gesamten Lebenszyklus von der Entdeckung bis zur Auslieferung verantwortet. Weniger Übergaben bedeuten weniger verlorenen Kontext.

Akzeptieren, dass die Lernkurve echte Arbeit ist. Teams umzustrukturieren, institutionelles Wissen zu kodifizieren und zu lernen, effektiv mit Agenten zu arbeiten, ist organisatorischer Wandel, kein Werkzeugtausch. Es braucht Zeit, diesen Muskel aufzubauen.

IV. Das Wichtigste

Die vielleicht wichtigste Erfahrung ist diese: Die einzige Gewissheit ist Veränderung. In den 2010er Jahren konnten Organisationen jahrelang auf die gleiche Weise arbeiten. Bis 2026 hat sich der Zyklus, in dem man überprüfen sollte, ob die eigenen Arbeitsweisen noch zeitgemäß sind, auf wenige Monate komprimiert.

Die kürzliche Veröffentlichung von Mythos zeigt, dass wir weit vom Ende der Entwicklung entfernt sind. Modelle und Infrastruktur werden sich weiter verbessern, und Selbsttraining (KI, die eingesetzt wird, um sich selbst zu verbessern) wird das Veränderungstempo wahrscheinlich weiter beschleunigen. Frühe Machbarkeitsnachweise von MIT und anderen haben gezeigt, dass dies funktioniert, und ich bin sicher, dass die führenden Modellanbieter bereits ihre eigenen Traces und Modelle nutzen, um ihre Infrastruktur zu verbessern.

Für jede Organisation, die an der Wettbewerbsspitze der Softwareentwicklung bleiben will, ist ständige Neuerfindung kein Wettbewerbsvorteil mehr, sondern der Eintrittspreis. Die Frage ist nicht mehr, ob man sich anpassen sollte. Sondern ob man sich schnell genug anpassen kann.