Ich sage das nicht gern, aber ich sage es, weil es stimmt: Wofür wir früher zwanzig Entwickler gebraucht haben, reichen bald fünf sehr gute Leute mit mehreren Agenten. Kleiner, schneller, und die Kosten pro Funktion sinken massiv.
Erst mal ehrlich
Fakt ist: Das ist keine Vision. Das sehen wir heute in unseren Projekten. Ein Coding Agent liefert in Minuten, wofür ein Entwickler Stunden oder Tage gebraucht hat. Und wir stehen ja erst am Anfang.
Man kann das schlimm finden. Man kann es ignorieren. Oder man kann sich fragen, wie man ein Team so umbaut, dass am Ende fünf Leute da sind, die das System wirklich tragen, und nicht fünf, die zufällig übrig geblieben sind.
Wie es falsch läuft
Der falsche Weg ist der, den ich gerade oft sehe. Ein Unternehmen kauft Coding Agents für alle. Ein paar werden schnell, die meisten nicht. Nach einem Jahr wird gespart, und es gehen die, die am wenigsten kosten oder am wenigsten auffallen.
Was übrig bleibt, ist ein Team, das zufällig zusammengesetzt ist. Vielleicht sind die richtigen dabei. Wahrscheinlich nicht. Und das Wissen darüber, warum das System so gebaut ist, wie es gebaut ist, ist mit den Falschen gegangen.
Wer bleibt, und warum
Die fünf, die bleiben, sind nicht die fünf schnellsten Programmierer. Programmieren wird gerade Massenware.
Es sind die, die das System verstehen. Die wissen, warum eine Schnittstelle so ist. Die entscheiden können, welches Pattern wo gilt. Die Domainwissen haben: Banking, Telekommunikation, Medizin, was immer das Unternehmen tut. Und die es aushalten, dass Agenten den Grossteil des Codes schreiben und sie „nur" noch entscheiden, prüfen und führen.
Das ist oft nicht die Person, die bisher am meisten Zeilen abgeliefert hat. Manchmal ist es die, die im Review immer die unbequemen Fragen gestellt hat.
Der Übergang
Wie macht man das, ohne dass das Team auseinanderfällt? Ich habe dafür keine Formel, aber ein paar Dinge, die funktioniert haben.
Offen sagen, was passiert. Die Leute wissen es sowieso. Wer so tut, als würde nichts passieren, verliert die Guten zuerst, weil die zuerst merken, dass gelogen wird.
Regeln vor Tools. Bevor ein Agent Code schreibt, muss das Team seine Architektur aufschreiben. Das ist Arbeit, die alle zusammen machen, und sie zeigt sehr schnell, wer das System versteht.
Rollen wechseln lassen. Wer heute Code schreibt, kann morgen Contracts schreiben, QS-Regeln definieren, Agenten führen. Nicht jeder will das. Aber jeder soll die Chance haben, es herauszufinden.
Das Wissen retten, bevor die Leute gehen. Wer geht, hinterlässt vorher seine Gründe in einer Form, mit der Agenten arbeiten können. Nicht als Abschiedsdokument, sondern als Regel im System.
Und die anderen fünfzehn?
Das ist die Frage, die niemand stellt, und der ich nicht ausweichen will.
Ein Teil von ihnen wird woanders dasselbe machen, was sie hier gemacht haben, nur bei Unternehmen, die noch nicht so weit sind. Das hält ein paar Jahre.
Ein Teil wird etwas Neues lernen. Nicht programmieren, sondern das, wofür man Programmieren gebraucht hat: Probleme verstehen, Systeme führen, Domainwissen aufbauen. Das ist möglich, und ich habe es gesehen. Aber es passiert nicht von allein.
Und ein Teil wird den Beruf wechseln. Das ist die Wahrheit, und wer etwas anderes sagt, verkauft etwas.
Was ich als Unternehmer tun kann, ist, den Übergang so zu gestalten, dass möglichst viele die Chance auf den zweiten Weg bekommen. Nicht durch Schonung, sondern durch Klarheit und durch Zeit.
Die Teams werden kleiner. Das passiert so oder so. Ob am Ende die richtigen fünf da sind, ist die einzige Entscheidung, die man noch beeinflussen kann. Und sie muss jetzt getroffen werden, nicht wenn gespart wird.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert unser eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal bleibt ein Hüpfer drin. Das ist dann auch von mir.