Coding-Agents sind ein Problem der Organisations­gestaltung

Was das Interview zeigt und was die Belege stützen

Hier spricht ein Praktiker. Patrick Debois beschreibt, was Coding-Agents an den Routinen eines Teams, an den Aufgaben der Plattform, an Eigentümerschaft, Recruiting und Messung ändern und an der Frage, wie viel Autonomie man ihnen gibt. Das ist das Modell eines erfahrenen Menschen dafür, wie sich die Arbeit neu sortiert. Ein Beweis, dass derselbe Zuschnitt in jede Organisation passt, ist es nicht. Als Arbeitshypothese ist es brauchbar, und als solche sollte man es testen und benennen.

DORAs Forschung von 2025 stützt eine engere Aussage. KI-gestützte Entwicklung verstärkt das System, das sie umgibt. Damit aus lokaler Geschwindigkeit gelieferter Wert wird, braucht ein Team eine gesunde Plattform, klare Regeln und verlässliches Feedback. Dieser Zusammenhang spricht für die Richtung, in die Debois argumentiert. Jede einzelne Empfehlung weiter unten bestätigt er nicht, und Zusammenhänge aus Umfragen isolieren keine einzelne Ursache. Nehmt die Ebenen als Gerüst, das ihr anpasst, und messt das Ergebnis in eurem eigenen System.

Das Muster dahinter ist einfach. Wird lokale Generierung billiger, wandert der Engpass: weg vom Tippen, hinein in Teampraxis, gemeinsame Plattform, Governance und Lernen. Debois ordnet die Antwort darauf in vier Ebenen.

Ebene Agent: am Loop arbeiten statt am Output

Auf der ersten Ebene stehen der Agent und sein Harness: der Kontext, den er liest, die Tools, die er aufrufen kann, die Umgebung, in der er läuft, und das Feedback, das zu ihm zurückkommt. Enttäuscht ein Ergebnis, greift man reflexhaft zum generierten Code und bessert ihn nach. Debois hält einen anderen Reflex für richtig. Verbessert Kontext, Tools, Umgebung, Feedback und Harness, damit das nächste Ergebnis schon im Ansatz besser ausfällt.

Ein Patch am Output behebt eine Änderung. Eine Verbesserung am Loop behebt die ganze Klasse. Die Harness-Technik selbst wird womöglich zur Massenware, wenn sich die Anbieter mit ihren Funktionen annähern. Übrig bleibt technisches Handwerk: Kontext zusammenstellen, Tools anbinden, die Umgebung gestalten und den Feedback-Loop schließen, sodass ein Agent brauchbare Arbeit liefert, ohne dass jemand sie jedes Mal neu schreibt.

Ebene Team: Arbeit verteilen, Korrekturen behalten

Auf Teamebene gehört der Harness dem Team, und das Team entwickelt ihn weiter. Das meiste Gewicht liegt auf zwei Praktiken.

In der Planung entscheidet das Team, wohin die Arbeit geht. Klare, abgegrenzte Aufgaben mit prüfbarer Definition bekommen die Agents. Mehrdeutige Arbeit behalten Menschen, also alles, bei dem die Anforderung noch offen oder die Wirkung auf das System unklar ist. Das Team teilt bewusst auf, statt standardmäßig alles an den Agent zu geben.

In der Retrospektive werden wiederkehrende Korrekturen zu dauerhaften Bausteinen. Was eine Reviewerin zweimal korrigiert, wird Kontext, ein Test, eine Regel oder ein Stück Tooling, damit der Agent den Fehler nicht wiederholt. Schnellerer Output beseitigt den Engpass nicht, er verlagert ihn. Wenn Generierung billig ist, taucht die Grenze bei Anforderungen, Review, Produktentscheidungen und Go-to-Market auf, und bei den Nutzern, die die Änderung aufnehmen müssen.

Ebene Plattform: teilen, was sich verzinst

Die dritte Ebene macht das, was ein Team gewonnen hat, für andere wiederverwendbar. Debois zählt Plattformaufgaben auf, die nicht jedes Team für sich neu bauen sollte: Model-Routing, ein MCP-Gateway oder ein anders geregelter Tool-Zugang, isolierte Agent-Ausführung oder Sandboxes, Register wiederverwendbarer Skills und Harness-Bausteine, Evaluationssysteme, Guardrails und Security-Scanning sowie Kostentransparenz.

Links und rechts davon liegt je ein Fehlermodus. Eine zentrale Plattform, die ohne Input der Entwickler:innen gebaut wird, bleibt ungenutzt. Lokaler Wildwuchs, bei dem jedes Team seine eigenen Tools verdrahtet, lässt sich weder absichern noch verbessern. Zentrale Plattform und Developer Experience müssen zusammenfinden. Dem Wildwuchs begegnet Debois mit Eigentümerschaft: Bausteine mit benannten Verantwortlichen, die testbar, modular, wiederverwendbar und sicherheitsgeprüft sind.

Das Mittel dafür sind Paved Roads, bequeme Standardwege statt Käfige. Mehrere unterstützte Optionen dürfen nebeneinander bestehen. Ein Team, das den Weg verlassen muss, kann das tun, solange jemand die Alternative verantwortet.

Ebene Organisation: Verantwortung und Budget jenseits der Lizenzen

An der vierten Ebene bleiben die meisten Einführungen hängen. Lizenzen, Hackathons, Champions, Lunch-and-Learns und Schulungen bringen alle etwas voran, doch keines davon genügt für sich. Was dabei entsteht, ist Aktivität ohne bleibende Eigentümerschaft.

Debois argumentiert, dass die Fähigkeit eine benannte verantwortliche Person und ein Budget braucht, ob in der Teamleitung, in der Plattformgruppe oder bei Developer Experience. Für Harness, geteilte Bausteine und Evaluationen muss jemand geradestehen, genau wie für jedes Produktionssystem. Weiterbildung bleibt dabei. Sie setzt auf Infrastruktur auf, die jemandem gehört, und ersetzt sie nicht.

Zwei Frühindikatoren, die keine Ergebnisse sind

Debois schlägt vor, zwei frühe Signale im Blick zu behalten.

Das erste ist die Zahl menschlicher Eingriffe pro akzeptierter Änderung, aufgeschlüsselt nach Risiko oder Art der Änderung. Weniger Handkorrekturen bei einer Klasse von Arbeit sprechen dafür, dass der Loop für diese Klasse besser wird. Das zweite ist, wie stark geteilte Kontexte, Skills und Harness-Bausteine übernommen und wiederverwendet werden. Wiederverwendung spricht dafür, dass sich die Plattform verzinst, statt nur Dekoration zu sein.

Beide sind Frühindikatoren, keiner ist ein Ergebnis. Optimiert man einen davon allein, führt er in die Irre. Eingriffe lassen sich drücken, indem man die Messlatte senkt, und Wiederverwendung lässt sich aufblähen, indem man Importe zählt, auf die sich niemand verlässt. Stellt beide deshalb neben die Ergebnisse, auf die es ankommt: Fluss, Qualität, Wiederherstellung, Vertrauen, Kosten und das Geschäftsergebnis. Die Indikatoren zeigen, dass sich die Maschine verändert. Ob die Veränderung gut ist, zeigen die Ergebnisse.

Autonomie nach Umkehrbarkeit statt Licht aus

Für Debois ist Autonomie ein Spektrum und kein Schalter. Die Fertigung kennt die Dark Factory, die ohne Licht läuft. Software ist mit einer Dim Factory besser bedient: Dort richten sich die menschlichen Gates danach, wie umkehrbar eine Änderung ist und wie viel sie bewirkt.

Ein lokaler Refactor, der keinen öffentlichen Vertrag berührt, kann automatische Gates durchlaufen und gemergt werden. Eine Schemaänderung, eine öffentliche API, eine Berechtigungsgrenze oder eine Migration von Produktionsdaten verdient einen Menschen, denn eine Fehlentscheidung ist dort teuer rückgängig zu machen. Dazwischen liegt eine Bandbreite von enger Aufsicht bis zur automatischen Freigabe. Bewegen kann man sich darauf mit Wissen um die Herkunft, mit Verifizierern, die akzeptables Verhalten belegen, und mit einem Gespür dafür, was die Änderung berührt.

Recruiting, Teamzuschnitt und die Fähigkeit, die bleibt

Neue Jobtitel sagen wenig aus. Debois warnt davor, eine Welle agentennaher Titel als Beweis für ein neues Betriebsmodell zu nehmen. Schaut euch die Fähigkeiten dahinter einzeln an: wie gut jemand mit Agents arbeitet, wie die Person technische Probleme durchdenkt und ob sie Praktiken teilen, Anforderungen verstehen und die Wirkung einer Änderung auf das System erkennen kann.

Für den Teamzuschnitt gilt dieselbe Vorsicht. Die These, Agents schrumpften ein Team auf ein oder zwei Personen, ist nicht belegt. Ergänzende Kapazität bleibt wichtig: Produkt, Design, Betrieb, Junior-Entwickler:innen, aus denen die nächsten Seniors werden, und Luft für den Fall, dass etwas kaputtgeht.

Unter allen vier Ebenen liegt eine Fähigkeit, die bleibt: kontinuierliches Lernen. Was sich verzinst, ist wiederverwendbares Wissen der Organisation, festgehalten in Kontext, Skills und Harnesses. Einen Vorsprung halten die Organisationen, die ändern können, was sie bauen und wie sie es bauen, und dabei verlässlich bleiben. Diese Fähigkeit gilt es zu schützen, und für sie gibt es die vier Ebenen.