Hauptgedanke

Die Lesbarkeit eines Repositorys — konsistente Benennung, klare Struktur, nützliche Kommentare, eine verwertbare Historie der Merge Requests — wurde lange mit einem einzigen Argument verteidigt: Sie senkt die Kosten, wenn Entwickler eingreifen müssen. Das ist ein Argument innerhalb des Technikteams, und es verliert jede Abwägung, in der es gegen einen Liefertermin antritt.

Sobald das Repository dazu dient, eine Support-Dokumentation, einen Changelog oder eine Spezifikation neu aufzubauen, bestimmt seine Lesbarkeit die Qualität dieser Ergebnisse. Undurchsichtiger Code erzeugt keine undurchsichtige Dokumentation: Er erzeugt eine falsche, plausible und unentdeckbare, denn niemand wird die Quelle noch einmal lesen, um sie zu prüfen.

Sauberer Code wird damit zu einer Produktvariablen. Er ist kein Teamkomfort mehr, den man gegen Zeit eintauschen kann, sondern die Voraussetzung dafür, dass es eine ganze Familie von Artefakten für den Kunden überhaupt gibt.

Ebene beigetragen von „Vier Tage vibe coding als eingerosteter PM“ (2026-07-28). Eine zweite Nutzung des Repositorys bewirkt dieselbe Verschiebung, und sie ist anspruchsvoller: Wird die Codebase zum Gelände, auf dem jemand, der kein Entwickler ist, mit einem Assistenten baut, entscheidet ihre Lesbarkeit darüber, was dort machbar ist. In einer Codebase, deren interne APIs dokumentiert, deren Fachbegriffe lesbar und deren Komponenten stabil sind, setzt ein Product Manager ein Modul oder einen Ablauf aus vorhandenen Bausteinen zusammen. In einer schlecht gefassten Codebase können dieselbe Person und derselbe Assistent nur ein separates Objekt herstellen, das von außen angeschlossen wird — die Bastelei ist dann kein Methodenfehler, sondern der einzige Modus, den das Gelände zulässt.

Warum das wichtig ist

Das gibt einem Product Manager einen Grund, in seinen eigenen Begriffen formuliert, eine Investition in Refactoring zu verteidigen — die bisher nur von Entwicklern verteidigt und deshalb als Handwerkervorliebe gehört wurde.

Es setzt auch eine ehrliche Zugangsbedingung: Der Ansatz, die Artefakte aus dem Repository neu zu erzeugen, steht nicht überall zur Verfügung. Auf einer unlesbaren Basis verschlechtert er das Ergebnis nicht, er macht es irreführend.

Nuancen und Grenzen

„Sauber“ hat keine verbindliche Definition. Ein Repository kann für einen Entwickler tadellos strukturiert sein und trotzdem nichts über das Fachvokabular verraten, das eine Support-Dokumentation gerade braucht.

Und die Anforderung kann sich gegen sich selbst wenden: Wer das Repository zur Grundlage für Generierung macht, riskiert, dass darin Kommentare für die Maschine statt für den Pflegenden geschrieben werden.

Offene Fragen

• Wer trägt die Abwägung über die Lesbarkeit eines Repositorys, wenn die Kosten beim Technikteam anfallen und der Nutzen anderswo verbucht wird?