Blickwinkel

Ein Product Manager mit einem Code-Assistenten produziert in vier Tagen, wofür er einen Monat gebraucht hätte, und dieses Tempo sagt nichts darüber, was er bauen darf. Das sagt der Zustand des Geländes, auf dem er seine Arbeit aufsetzt: Ein aktueller Katalog interner APIs erspart ihm die Umwege, aus denen Inkohärenz entsteht; Tests, die die fachliche Absicht tragen, geben ihm Zugriff auf Code, den er nicht gelesen hat; eine Codebase mit lesbarer Fachsprache entscheidet allein, ob er mit vorhandenen Bausteinen arbeitet oder neben dem Produkt bastelt; und automatische Sicherheitskontrollen halten die einzige Anforderung ein, über die weder nach Tragweite noch nach Termin verhandelt wird. Wo diese vier Bausteine fehlen, bringt dieselbe Person mit derselben Kompetenz und demselben Werkzeug nur Objekte hervor, die sie weder erklären noch reparieren kann – und ihre technische Kompetenz, sofern sie welche hat, schiebt nur den Moment hinaus, in dem das sichtbar wird. Das Gelände bestimmt also zugleich den erlaubten Spielraum und das erreichbare Tempo, und damit gehört die Öffnung des Codes für Produktleute zu den Architekturentscheidungen, bevor sie eine Frage der Berechtigung wird.

Zusammenfassung

Einzeln betrachtet beschreibt jede Notiz ein Stück des Problems: das Tempo, die Mängel, die der Assistent von selbst erzeugt, die Erlaubnis, das Review, die Tests, die Leitplanken, die Rolle der Entwickler. Gemeinsam zeigen sie, dass sich die Größe verschiebt, nach der entschieden wird. Die übliche Diskussion dreht sich um die Person – hat sie genug technischen Hintergrund, braucht es ein Mindestniveau, sollte man es Leuten ohne Technikhintergrund verbieten. Jede Notiz verweist, von ihrer Seite her, woandershin: auf das, was vor ihr vorbereitet wurde.

Der Mechanismus ist jedes Mal derselbe und beruht auf einer Eigenschaft des Assistenten: Er errät nicht, was nirgends geschrieben steht. Er kennt die realen Datenmengen nicht, also entwirft er für die Testdaten. Er kennt die legitimen Einstiegspunkte nicht, also erfindet er welche. Er behält nicht, was man ihm gestern korrigiert hat, also fängt er von vorn an. Keine dieser Lücken schließt die Kompetenz dessen, der steuert; alle schließt eine Information, die in der Umgebung hinterlegt ist – und deshalb kippt die Verantwortung auf die Seite derer, die diese Umgebung pflegen.

Daraus folgt etwas weniger Erwartetes. Die technische Kompetenz dessen, der steuert, bleibt nützlich, aber ihr Einsatz ändert sich: Sie dient nicht mehr dem Produzieren, sondern dem Erkennen – sehen, dass eine Datei zu groß wird, spüren, dass sich eine Schicht mit einer anderen vermischt, merken, dass eine API-Antwort der Last nicht standhalten wird. Für diese Fähigkeit gibt es keinen automatischen Ersatz, und sie ist das Einzige, was das Gelände nicht liefert. Sie erklärt, warum die Frage nach dem Spielraum nicht verschwindet: Ein hervorragendes Gelände erweitert, was machbar ist, ohne den, der es bedient, zu befähigen, das Produzierte zu beurteilen.

Bleibt, was dieser Blickwinkel die Organisation kostet. Die Entscheidung auf das Gelände zu verlagern, heißt, dass die Öffnung des Codes für andere Funktionen zuerst mit Architekturarbeit bezahlt wird – saubere APIs, eingehaltene Konventionen, sichere Umgebungen, automatische Kontrollen –, also mit Ausgaben ohne für den Kunden sichtbares Ergebnis. Das ist die Position, die sich am leichtesten streichen lässt, und doch entscheidet gerade sie, ob die Öffnung Entlastung bringt oder Bastelei. Die Frage „Können Product Manager entwickeln?“ hat daher keine allgemeine Antwort: Sie hat eine pro Unternehmen, und diese Antwort wurde geschrieben, bevor man die Frage stellte – im Zustand seiner Codebase.

Spannungen / Widersprüche

Diese Notizen sind sich nicht einig, wie viel die individuelle Kompetenz tatsächlich wiegt. Diejenigen, die die Entscheidung auf das Gelände verlagern, setzen voraus, dass die Umgebung die Lücken des Assistenten schließt; die Notiz über den Betrieb eines Werkzeugs erinnert daran, dass die Fähigkeit, einen Ausfall zu diagnostizieren, in keinem API-Katalog steht. Ist dieser Anteil groß, ist das Gelände nur eine notwendige Bedingung, und die Kompetenz bleibt der begrenzende Faktor.

Schärfer ist der Gegensatz zwischen zwei Lesarten der Beschleunigung. Der hier vertretene Blickwinkel behandelt das Tempo als Nutzen, den es zu rahmen gilt, und geht davon aus, dass die verlorenen Mechanismen über das Gelände wiederhergestellt werden. Die an anderer Stelle entwickelte Lesart darüber, wie Kompetenz entsteht, hält dagegen, dass manche dieser Mechanismen – der analysierbare Fehler, die erste Stufe, der Preis jedes Handgriffs – sich durch kein Werkzeug wiederherstellen lassen, weil sie voraussetzten, dass man für das Ergebnis verantwortlich war. Nichts hier entscheidet das: Ein Gelände, das die Umwege beseitigt, beseitigt auch die Gelegenheiten, sie erkennen zu lernen.

Schließlich vertragen sich die nicht abgestufte Sicherheitsanforderung und das erleichterte Review für Wegwerfobjekte in der Praxis schlecht: Sie verlangen von derselben Organisation, eine menschliche Kontrolle zu lockern und eine automatische aufrechtzuerhalten, was ein Werkzeug voraussetzt, das gerade die Organisationen, die das Review lockern, oft nicht haben.

Fragen

• Welcher Teil des Geländes muss vor der Öffnung gebaut sein, und welcher entsteht als Antwort auf die ersten Nutzungen – mit dem Risiko, die in der Zwischenzeit gebauten Objekte durchzulassen?
• Laufen ein für Assistenten entworfenes Gelände und eines für menschliche Entwickler auseinander, und ab wann muss man zwei pflegen?
• Wie beurteilt eine Organisation den Zustand ihres eigenen Geländes vor der Öffnung, anders als im Nachhinein an dem, was produziert wurde?
• Worauf stützt sich die Entscheidung, in diese Architekturarbeit zu investieren, wenn sich ihr Nutzen an Inkohärenzen bemisst, die nicht eingetreten sind?