Wie Plattform-Teams mit Dokumentation AI-Burnout verhindern können

Warum fühlen wir uns jetzt noch müder?

Die Slack-Benachrichtigungen bei Eficode haben sich in letzter Zeit anders angefühlt. Vor ein paar Wochen ist eine lockere Unterhaltung über „AI-Fatigue“ in eine tiefe Diskussion darüber ausgeartet, warum sich Engineers zunehmend erschöpft fühlen, obwohl sie die leistungsstärksten Tools der Geschichte zur Verfügung haben.

Der Konsens? AI-Tools sind nur so gut wie die Dokumentation und die klaren Rahmenbedingungen in unseren Organisationen. Wenn diese brüchig sind, ist es am Ende der Engineer, der darunter leidet. Schnelle Output-Geschwindigkeit bringt wenig, wenn der Entwickler das System, das er gerade „gebaut“ hat, nicht versteht.

Nach der Auswertung der Diskussion habe ich drei versteckte „Energie-Drains“ identifiziert, auf die jeder Lead und CTO achten sollte, bevor das Team an seine Belastungsgrenze kommt.

1. Die Dokumentationslücke (und die 404-Schleife)

Wir haben es alle schon gesehen: Ein Agent dreht sich im Kreis, weil er versucht, veralteter Dokumentation zu folgen. In einem kürzlichen internen Pilotprojekt bei Eficode haben wir festgestellt, dass Engineers, die LLMs in Projekten mit „veralteter“ Dokumentation nutzen, 30 % mehr Zeit mit dem Debuggen von Halluzinationen verbringen als diejenigen, die mit sauber gepflegten Repositories arbeiten. Ein Team berichtete sogar von einer Schleife, in der die KI eine veraltete Bibliothek 14 Mal in einer einzigen Session vorgeschlagen hat.

Einem LLM beim Kreisen zuzusehen ist anstrengender, als den Code selbst zu schreiben. Wenn wir Agenten für große Codebasen bauen, haben wir eine harte Wahrheit gelernt: Code halluziniert nicht – alles andere vielleicht. Wir erzielen inzwischen deutlich bessere Ergebnisse, indem wir uns weniger auf manuelle Tool-Beschreibungen verlassen und stattdessen echte Abhängigkeiten direkt in den Kontext dekompilieren.

Architekturdokumente sind gut, um Absichten festzuhalten, aber technische Spezifikationen sind oft nur veraltete Vermutungen. Wenn man möchte, dass die KI zuverlässig arbeitet, sollte man ihr die „Ground Truth“ geben: den Code selbst.

2. Die "Denksteuer"

In den „Before Times“ haben wir beim Coden noch mitgedacht. Der Akt des Tippens hat ein bestimmtes Tempo der mentalen Validierung erzwungen. Jetzt, da AI in Sekunden ganze Logikblöcke generiert, müssen wir uns „Denkzeit“ bewusst schaffen.

Wenn wir das nicht tun, rasen wir einfach durch Features, ohne das „Warum“ wirklich zu verstehen. Es ist, als wäre man ständig in einem Code-Review-Modus – man versucht, in den Kopf eines anderen zu kommen, aber der Code war nie wirklich im eigenen drin. Verständnis wird in die Lesephase verschoben, und als Branche müssen wir das durch nachhaltige Entwicklungspraktiken adressieren, die Systemverständnis über reine Ticket-Geschwindigkeit stellen.

Als Industrie müssen wir dies durch nachhaltige Entwicklungspraktiken angehen, ähnlich wie die kognitive Belastung, die in der jüngstenDORA-Forschung hervorgehoben wurde, die dem Systemverständnis Vorrang vor der reinen Ticket-Geschwindigkeit einräumt.

3. Das Burnout-Tempo als Spitzenleistung

KI ermöglicht es den Menschen, in einem Tempo zu arbeiten, das wie Spitzenleistung aussieht, sich aber wie ein Dampfkochtopf anfühlt. Es gibt ein globales FOMO, das einen "Management by Perkele"-Ansatz für KI vorantreibt, ein finnischer Ausdruck für eine harte, autoritäre Führung, die auf ROI- und Lines-of-Code-Kennzahlen drängt, weil die VCs allen im Nacken sitzen.

Diese Verlagerung von der Schaffung solider Grundlagen hin zur Jagd nach sofortigen Erträgen hat echte Innovation eingeschränkt. Es schafft ein ungesundes Umfeld, in dem Ingenieure in der Angst leben, ersetzt zu werden oder an willkürlichen KPI-Metriken zu scheitern.

Der Weg nach vorn: Managet die Methode, nicht den Output

Wenn ihr eine Führungsposition innehabt, solltet ihr aufhören, den Output zu verwalten, sondern die Arbeitsweise managen.

• Verlasst euch nicht auf Kontext, den ihr nicht geprüft habt: Verwendet das Model Context Protocol (MCP) oder skills.md, falls Client-Tools für euren Agenten verfügbar sind, um externe Quellen zu verwalten und Workflows zu automatisieren. Es fungiert als API-Verwaltungsplattform für eure KI und stellt sicher, dass sie nur das sieht", was relevant und verifiziert ist.
• Gebt der Synthese den Vorrang vor der Geschwindigkeit: Ermutigt euer Team, seine Fähigkeiten in der Analyse zu bewahren. Eine hohe Geschwindigkeit ist eine Belastung, wenn niemand im Team die Architektur erklären kann.
• Investiert in KI-Kenntnisse: Geht weg von der "blinden Übernahme". Dienstleistungen wie KI-Schulungen und -Coaching können Teams dabei helfen, zu verstehen, wie diese Tools in einen professionellen CI/CD-Workflow integriert werden können, ohne dass es zu technischen Problemen kommt.

Das Ziel besteht nicht nur darin, mehr zu produzieren. Es geht darum, innovativ zu sein, ohne die Menschen auszubrennen, die diese Innovation möglich machen.