Der beste Engineer in jeder größeren Org ist selten der originellste. Es ist der, der erkannt hat, dass das Problem vor ihm vor drei Quartalen schon von einem anderen Team gelöst wurde, das Pattern kopiert und am Dienstag geshipped hat. Niemand auf dem All-Hands feiert das. Es ist langweilig. Gefeiert wird die Engineerin, die etwas Neues geschrieben hat.
Die Anreizschicht steht auf dem Kopf. Wiederverwendung verkürzt Zykluszeiten, reduziert Varianz und produziert weniger Wartungsüberraschungen. Greenfield-Arbeit fühlt sich heldenhaft an und ist statistisch schlechter. Trotzdem feiern wir "was hast du erschaffen" und nicht "was hast du nicht erschaffen müssen, weil du es schon gefunden hast".
Agentic Coding macht das schnell schlimmer. Greenfield war früher teuer genug, dass irgendwer in der Kette nachgehakt hat: "Müssen wir das wirklich von Null bauen?" Heute lautet die Antwort: "Klar, ist bis Freitag fertig." Die Reibung, die Wiederverwendung erzwungen hat, ist weg. Jedes Team kann sein eigenes Pattern aufmachen, seine eigene Abstraktion, seine eigene leicht abweichende Version von etwas, das schon dreimal in der Codebase existiert. Der Output sieht produktiv aus. Die Org fragmentiert leise. Eure Codebase auch. Wir sehen einen spürbaren Anstieg an Microservices, die riesige Frameworks hochfahren, viel Speicher fressen, vollen Betriebsaufwand mitschleppen und ein oder zwei triviale Aufgaben erledigen. Jeder einzelne sah für das Team, das ihn baute, nach dem offensichtlichen Build aus.
Die Rechnung kommt in zwei Jahren. Sechs Versionen desselben Dings, keine davon dokumentiert, alle gewartet. Komplexität skaliert linear mit Neuarbeit und kaum mit Wiederverwendung. Je schneller Greenfield wird, desto steiler die Kurve. Zum Glück haben wir KI, die uns damit hilft. Genau das Tool, das den Schlamassel gebaut hat, wird uns nochmal verkauft, um ihn zu verwalten. Eine andere Möglichkeit gegen die Fragmentierung wäre, einen verpflichtenden Check auf Prior Art in der bestehenden Codebase einzubauen. Das ließe sich leicht über ein Custom Skill lösen.
Wenn ihr wollt, dass eure Engineering-Org schneller wird, könnte das Feiern von Originalität dem Fortschritt sogar im Weg stehen. Ich denke, es macht Sinn, zumindest nicht zu vergessen, den Engineer zu belohnen, der sein eigenes Ticket geschlossen hat, indem er auf den PR von jemand anderem vom letzten Jahr gezeigt hat. Das ist relevante Arbeit. Das sollte als Erfolg gelten.
Gedanken dazu? Findet mich auf Bluesky.