Eine alte Idee, die plötzlich wieder passt

Seit vielen Jahren erzähle ich meinen Mitarbeitern und Kollegen dasselbe, wenn es um Dokumentation geht: Wir dokumentieren nicht um der Dokumentation willen. Wir dokumentieren die Landkarte.

Gemeint ist das grobe Bild eines Systems. Welche Teile gibt es? Wie hängen sie zusammen? Wie sind die Daten aufgebaut, und wie fließen sie? Wo befinde ich mich gerade, wenn ich an einer bestimmten Stelle arbeite?

Wer diese Landkarte hat, findet sich in jedem Detail zurecht. Wer sie nicht hat, verirrt sich auch in perfekt kommentiertem Code. Seitenlange Beschreibungen einzelner Methoden veralten schnell und liest kaum jemand. Eine gute Landkarte dagegen wird jeden Tag gebraucht.

In den letzten Monaten ist mir aufgefallen, wie gut diese alte Idee zu einer Entwicklung passt, die uns gerade alle beschäftigt: Software, die zu einem immer größeren Teil von KI geschrieben wird.

Senior-Entwickler als Vollzeit-Reviewer

Viele erfahrene Entwickler kennen gerade dasselbe Gefühl: Der eigene Arbeitstag besteht immer mehr aus Reviews. Die KI erzeugt Code in hohem Tempo, und am Ende landet alles auf dem Tisch derjenigen, die verstehen sollen, ob das so passt.

Das ist nicht nur ein Gefühl. Der AI Productivity Paradox Report von Faros AI hat 2025 Daten von über 10.000 Entwicklern in 1.255 Teams ausgewertet. Teams mit hoher KI-Nutzung erledigten 21 % mehr Aufgaben und mergten 98 % mehr Pull Requests. Gleichzeitig stieg die Review-Zeit um 91 %, und auf Unternehmensebene war kein messbarer Effekt zu sehen.

Ein Jahr später hat sich das Problem nicht gelöst, sondern verschoben. Der Speed-Trap-Report vom September 2026 basiert auf Telemetrie von 22.000 Entwicklern in 4.000 Teams. Pull Requests sind dort im Schnitt 71,8 % größer, die Zeit in der QA ist um 300,6 % gestiegen und die Zahl monatlicher Incidents um 125,4 %. Besonders aufschlussreich finde ich eine Zahl: Pull Requests, die ganz ohne Review gemergt werden, haben um 76,3 % zugenommen.

Mit anderen Worten: Wo das Review nicht mehr hinterherkommt, wird es zunehmend einfach weggelassen. Genau das müssen wir vermeiden. Nicht weil jede Zeile gelesen werden muss, sondern weil an die Stelle des Zeile-für-Zeile-Reviews etwas anderes treten muss und nicht einfach nichts.

Das überrascht eigentlich nicht. Ein System ist nur so schnell wie sein langsamster Teil. Wenn wir die Codeproduktion beschleunigen, aber weiterhin jede Zeile so prüfen wie früher, haben wir nicht die Softwareentwicklung beschleunigt. Wir haben nur die Warteschlange vor dem Review verlängert.

Weniger Code lesen, mehr System verstehen

Meine aktuelle Antwort darauf: Wir müssen aufhören, vollständiges Verständnis mit dem Lesen jeder einzelnen Codezeile gleichzusetzen. Wir müssen anfangen, die Landkarte zu verstehen.

Das ist eine Verschiebung auf eine höhere Abstraktionsebene. Früher entstand Systemkenntnis ganz nebenbei. Wer Code schrieb, reviewte und debuggte, wusste irgendwann, wie das System funktioniert. Dieses Nebenprodukt fällt weg, wenn die KI den Großteil schreibt. Wir müssen Systemkenntnis deshalb bewusst herstellen, sonst prüfen wir am Ende Systeme, die niemand mehr versteht.

Ich sehe dafür drei Schritte, und die Reihenfolge ist entscheidend:

  1. Die Landkarte kennen. Grobe Struktur, Datenmodell, Datenflüsse, Abhängigkeiten, Verhalten bei Fehlern.
  2. Die kritischen Gebiete erkennen. Das geht nur mit der Landkarte. Wer die Struktur nicht kennt, weiß auch nicht, wo es gefährlich wird.
  3. Dort tief einsteigen. Gezielt lesen, verstehen und erklären können.

Wir zoomen also heraus, aber nicht überall gleich weit.

Wo man hineinzoomen muss

Welche Gebiete sind kritisch? Mir hilft eine einfache Frage: Würden wir einen Fehler hier durch einen Test bemerken, und könnten wir ihn folgenlos zurückdrehen? Lautet eine der beiden Antworten nein, muss es jemand im Team wirklich verstehen.

In der Praxis betrifft das vor allem, aber nicht nur:

  • Datenmodell und Migrationen. Daten leben länger als Code, und ein Rollback rettet keine kaputten Daten.
  • Transaktionen und Konsistenz. Was passiert bei einem Abbruch mittendrin?
  • Nebenläufigkeit. Race Conditions sind der Klassiker für Tests, die zufällig grün sind.
  • Security und Mandantentrennung. Tests zeigen, dass die bekannten Prüfungen da sind, aber nicht, dass es keine Lücke gibt.
  • Fehler- und Wiederanlaufverhalten. Genau das Wissen, das man nachts beim Incident braucht.
  • Fachliche Kernlogik. Überall, wo fast richtig falsch ist, etwa bei Geld oder Fristen.

Hier wird weiter gelesen, verstanden und diskutiert, so genau wie eh und je. Mit einem Unterschied: Weil wir den Rest nicht mehr Zeile für Zeile prüfen, haben wir dafür endlich die Zeit.

Und der Rest? Loslassen und Eigenschaften statt Zeilen prüfen

Der Großteil des Codes liegt zwischen diesen kritischen Gebieten: Mappings, Glue Code, UI, Boilerplate, Refactorings. Dort liegt der eigentliche Produktivitätsgewinn, und dort dürfen wir loslassen.

Loslassen heißt aber nicht, blind zu vertrauen. Statt jede Zeile zu lesen, prüfen wir, ob das Ergebnis die vereinbarten Eigenschaften erfüllt. Hält es die Architekturregeln ein? Bleiben die Schnittstellen stabil? Liegt die Performance im Budget? Sind Logging und Monitoring vorhanden?

Dafür braucht es allerdings nicht weniger technisches Verständnis, sondern möglicherweise sogar mehr. Nur wer Datenbanken, Transaktionen, Architektur, Nebenläufigkeit, Security oder verteilte Systeme versteht, kann die richtigen technischen Eigenschaften formulieren und beurteilen, welche Evidenz tatsächlich belastbar ist.

Einen großen Teil dieser Prüfung kann wiederum die KI übernehmen. Entscheidend ist, dass sie dabei nicht nur behauptet, dass alles passt, sondern Evidenz liefert: ausgeführte Tests, gemessene Laufzeiten, Ergebnisse von Architektur- und Contract-Tests. Und diese Evidenz sollte unabhängig entstehen. Wenn dieselbe KI Code und Tests schreibt, bestätigen die Tests im Zweifel nur ihr eigenes Missverständnis.

Die Aufgabe des Menschen verschiebt sich damit: weg vom Prüfen jeder Zeile, hin zum Bewerten der Regeln und der Evidenz.

Die KI zeichnet die Karte, der Mensch muss sie lesen können

Das Schöne ist: Die KI hilft nicht nur beim Code, sondern auch bei der Landkarte. Das alte Problem von Architekturdokumentation war, dass sie veraltet, weil niemand Zeit hat, sie zu pflegen. Ein Agent kann sie bei jeder größeren Änderung aus dem Code ableiten und aktuell halten.

Verstanden ist sie damit aber noch nicht. Eine generierte Landkarte ist eine Behauptung, genau wie generierter Code. Das Verständnis entsteht erst, wenn jemand mit ihr arbeitet: sie gegen das System hält, Fragen stellt und sie anderen erklären kann. Ein guter Test dafür ist, das Modul einem Kollegen zurückzuerklären oder das Runbook selbst zu schreiben. Wo das hakt, fehlt Verständnis.

Und noch etwas hat mich überrascht: Die Landkarte ist inzwischen auch für die Agents selbst wichtig. Coding Agents arbeiten deutlich besser, wenn sie Architektur, Modulgrenzen und Regeln als Kontext bekommen. Dieselbe Karte, die einem neuen Mitarbeiter Orientierung gibt, gibt sie auch der KI. Gute Orientierungsdokumentation zahlt also doppelt ein.

Das deckt sich mit der Empfehlung aus dem Speed-Trap-Report: Der größte Hebel liegt beim Erstellen des Codes, also darin, den Agents vor dem Schreiben besseren Kontext zu geben. Eine gute Landkarte ist genau dieser Kontext.

Eine Erkenntnis auf dem Weg, kein fertiges Rezept

Ich will ehrlich sein: Ich verantworte seit über 20 Jahren Softwaresysteme, als Architekt wie als Entwicklungsleiter, und trotzdem habe ich auf diesen Wandel noch keine fertige Antwort. Das Feld verändert sich gerade so schnell, dass sich auch mein Verständnis laufend verschiebt. Was ich heute schreibe, werde ich in einem Jahr vermutlich an einigen Stellen anders sehen.

Aber die Richtung scheint mir klar. Der Weg führt weg vom Lesen jeder einzelnen Codezeile und hin zu drei Dingen: die Landkarte verstehen, an den kritischen Stellen tief einsteigen und den Rest über Eigenschaften und Evidenz prüfen.

Das ist nicht weniger Engineering, sondern Engineering auf einer anderen Ebene. Und für mich persönlich ist es eine schöne Pointe, dass ausgerechnet die Landkarte, die ich meinem Team seit Jahren predige, jetzt zum Kern dieser neuen Arbeitsweise wird.

Quellen

GESCHRIEBEN VONMarco Gruosso

Softwareentwicklung, Engineering Leadership und Technologie.

← Zurück zu Notizen & Fundstücke