Horizontale Skills und vertikale Agenten
Arne Deutsch
8 Min. Lesezeit
Die meisten Teams nutzen KI inzwischen, um Code zu schreiben. Deutlich seltener ist es gelungen, einem Agenten ein echtes, langlaufendes Stück Arbeit zu übergeben und dem Ergebnis zu vertrauen, ohne jeden Schritt zu überwachen. Genau in dieser Lücke – zwischen cleverer Autovervollständigung und einem Agenten, an den man wirklich delegieren kann – liegen die spannenden Fragen.
Seit einigen Monaten entwickle ich Software so, dass die Agenten den Großteil der Arbeit erledigen: Sie laufen über Stunden autonom, nicht nur über Minuten, und kümmern sich nicht nur darum, ob der Code kompiliert, sondern auch darum, ob er gut strukturiert, sicher und performant ist. Ich selbst bleibe dort, wo menschliches Urteilsvermögen wirklich zählt: die Richtung vorgeben, Geschmack einbringen, am Ende abnehmen. Das Ziel ist einfach gesagt: einer einzelnen Person die koordinierte Schlagkraft eines kleinen Teams geben. Das ist ehrgeizig – und es stößt sofort auf zwei grundlegende Grenzen, aus denen alles Weitere folgt.
Zwei Grenzen, an die jeder Agent stößt
Die erste ist der Kontext. Das Arbeitsgedächtnis eines Agenten ist endlich – und, das ist der unangenehme Teil, seine Qualität sinkt, je voller dieses Gedächtnis wird. Je mehr ein Agent gelesen hat (die Design-Dokumente, die Architektur, frühere Reviews, den bisherigen Gesprächsverlauf), desto schlechter wird tendenziell seine nächste Entscheidung. Ein einzelner Agent, der über eine lange Aufgabe alles ansammelt, was er gesehen hat, wird leise, aber stetig schlechter, je länger er läuft.
Die zweite ist die Regelbefolgung. Verlangt man von einem einzigen Agenten, gleichzeitig auf Architektur, Sicherheit, Teststrategie, Codequalität und Produktabsicht zu achten, dann befolgt er ab einer gewissen Menge an Regeln zuverlässig keine davon mehr richtig. Das ist keine Eigenheit von Maschinen – überfrachtet man einen menschlichen Reviewer mit zwölf konkurrierenden Checklisten, passiert genau dasselbe.
Beide Grenzen haben dieselbe Ursache: einen einzigen Agenten, der alles auf einmal erledigen und dabei alles im Kopf behalten soll. Das ist der Flaschenhals. Im Rest dieses Textes geht es darum, ihn aufzulösen.
Hören Sie auf, einen Agenten in allem gut machen zu wollen
Die Lösung besteht darin, gar nicht erst zu versuchen, einen Agenten in allem gut zu machen. Stattdessen teilt man das Urteilsvermögen auf viele schmale Agenten auf, von denen jeder das gesamte Projekt aus einem einzigen Blickwinkel betrachtet. Ein Architektur-Agent denkt nur über Systemzuschnitt, Grenzen und Abhängigkeiten nach. Ein Coder verantwortet die handwerkliche Umsetzung und die Qualität im Detail. Ein Security-Agent schaut nur auf Bedrohungen, Datenverarbeitung und Compliance. Ein Anforderungs-Agent hält Scope und Absicht ehrlich. Ein Prozess-Agent beobachtet den Workflow selbst.
Jeder ist vertikal, weil er von oben bis unten durch die gesamte Codebasis schneidet – aber nur entlang seiner eigenen Zuständigkeit. Je nach Projekt nimmt man Spalten hinzu oder lässt sie weg: Ein Fintech-System rückt Sicherheit und Compliance in den Vordergrund, ein ML-System Datenqualität und Evaluation. Die Aufstellung ist schlicht die Menge der Belange, für die das Projekt Spezialisten einstellen würde, wenn es sie sich leisten könnte.
Die Disziplin ist es, die das Ganze trägt. Jeder Agent trägt nur die Regeln seines eigenen Blickwinkels – und kann sie deshalb auch tatsächlich befolgen. Jeder läuft bei jedem Aufruf in frischem, isoliertem Kontext: Er erbt nie den Ballast aus dem Gespräch des Koordinators, und das hält sowohl sein Gedächtnis klein als auch sein Urteil unabhängig. Jeder ist standardmäßig nur lesend unterwegs und gibt einen festen, kompakten Bericht zurück. Und das Entscheidende: Jeder Agent eskaliert alles, was außerhalb seiner Spur liegt, statt einfach darüber hinwegzugehen und drauflos zu raten. Schmale Regeln, sauberer Kontext, ein festgelegtes Ausgabeformat – das ist das ganze Rezept.
Skills laufen horizontal über die Agenten
Sind die vertikalen Agenten das Urteilsvermögen, dann sind die horizontalen Skills der Workflow – die wiederkehrenden Arbeitsschritte, die über alle Agenten hinweg gleich ablaufen: einen Milestone planen, ein Feature planen, umsetzen, prüfen. Ein Skill verantwortet Reihenfolge, Zustand und Orchestrierung; eigene fachliche Regeln bringt er nicht mit. An jedem Schritt, der ein Urteil verlangt, fächert er die Arbeit parallel an die passenden Agenten auf, sammelt ihre Voten ein, führt sie zu einem gemeinsamen Ergebnis zusammen und eskaliert echte Konflikte an den Menschen – er entscheidet nie stillschweigend selbst.
Stellen Sie sich das Ganze als Matrix vor. Die vertikalen Agenten sind die Spalten – jede steht für einen Aspekt des Urteilsvermögens und reicht durch die gesamte Codebasis. Die horizontalen Skills sind die Zeilen – die Arbeitsphasen, die nacheinander über jede Spalte hinweggehen.
Diese Unabhängigkeit ist der praktische Gewinn: Tauscht man das Set an Skills aus, funktionieren die Agenten weiter; tauscht man die Aufstellung der Agenten aus, funktionieren die Skills weiter. Die Skills sind übertragbares Workflow-Know-how, das man einmal aufbaut; die Aufstellung ist der Teil, den man für jedes Projekt neu zuschneidet. Das macht aus „horizontal × vertikal“ mehr als einen Slogan – nämlich eine Architektur, die sich wirklich wiederverwenden lässt.
Das WAS planen, das WIE aufschieben, durchgehend prüfen
Ein paar Prinzipien halten das Ganze ehrlich. In der Planung entscheidet man das Was vor dem Wie: Ein Milestone benennt, welche Features als Nächstes kommen; ein Feature ist ein Ausschnitt, den ein Mensch tatsächlich benutzen und erleben kann; und erst auf der untersten Ebene – dem Task – legt man sich auf die Details der Umsetzung fest. Und diese Details legt man so spät fest, wie es verantwortbar ist, denn eine zu früh geschriebene Spezifikation beschreibt am Ende ein System, das es bei der Umsetzung längst nicht mehr gibt.
In der Umsetzung bauen die Agenten autonom, aber das Review wartet nicht bis zum Schluss. Jeder Task wird geprüft, während er entsteht; ist das ganze Feature zusammengesetzt, wird es noch einmal als Ganzes geprüft – und darunter laufen bei jedem Commit die günstigen mechanischen Checks: Formatierung, Linting, die Testsuite. Die Berührungspunkte des Menschen sind bewusst wenige: die Richtung vorgeben, bei den seltenen Fragen mitentscheiden, die sich nur beurteilen lassen, wenn man sie sich selbst ansieht, und das fertige Ergebnis abnehmen, bevor es ausgeliefert wird. Alles dazwischen läuft ohne Aufpasser – und weil jeder Schritt in frischem Kontext läuft und seinen Zustand auf die Platte schreibt, statt ihn im Kopf eines Agenten zu halten, kann ein Feature beliebig lange laufen, ohne den langsamen Qualitätsverfall, den die erste Grenze sonst mit sich bringt.
Der größte Teil der Abstimmung passiert vorab in der Planung, damit die Umsetzung danach allein laufen kann. Der Mensch bleibt für Richtung, Geschmack und die finale Abnahme.
Der Prozess verbessert sich selbst
Ein letztes Stück macht das Ganze dauerhaft. Der Workflow selbst – die Skills, die Agenten-Definitionen, die Regeln – liegt als versionierte Dateien vor, wird wie jeder andere Code reviewt und lässt sich zurückrollen. Wird eine Regel bei der echten Arbeit immer wieder übersehen, hält man diese Reibung als nachverfolgtes Issue fest und macht daraus einen besseren Skill, einen schärferen Agenten oder eine strukturelle Änderung, die den Fehler unmöglich macht.
Die Leitidee ist kontraintuitiv: Die Regel-Last ist ein Budget, das man kürzt und nicht aufbläht. Die Standardreaktion auf Fehler lautet „Welche bestehende Regel hätte das fangen müssen?“ und nicht „Fügen wir noch eine Regel hinzu.“ Der Prozess ist dabei nicht am Whiteboard entworfen worden – es ist über rund fünf Monate an einer echten, langlaufenden Codebasis gewachsen, wobei ein nicht zu vernachlässigender Teil des gesamten Aufwands in den Workflow selbst geflossen ist. Entwickelt hat er sich durch die praktische Anwendung und die Beobachtung der Ergebnisse.
Warum das für Enterprise-Software zählt
Nichts davon dreht sich wirklich um ein einzelnes Projekt, und nichts davon geht darum, Entwickler zu ersetzen. Es ist ein Weg, die echten Produktivitätsgewinne zu heben, die allen versprochen werden – ohne das, was meist mitkommt: ungeprüft ausgelieferter Code, ein Friedhof aus Proof-of-Concepts, Qualität, die still gegen Tempo eingetauscht wird. Die Agenten erledigen die Masse; die Menschen behalten Urteil und Übersicht. Architektur, Sicherheit und Performance bekommen je einen eigenen Reviewer, statt erst im Nachhinein bedacht zu werden. Und weil der gesamte Workflow versioniert ist, besitzt ein Team ihn und verbessert ihn weiter – statt eine Blackbox zu mieten.
Genau hier knüpft das an die Arbeit an, die wir bei itemis tun. Wenn KI in einer Organisation wirklich ankommen soll, hängt das weniger am Modell als am Workflow darum herum – an den richtigen Werkzeugen, an der sauberen Integration in bestehende Systeme und Qualitäts-Gates und an Menschen, die ihn weiter gestalten können, wenn die Berater wieder weg sind. Vertikale Agenten und horizontale Skills sind eine konkrete Form, die dieser Workflow annehmen kann. Wenn Sie über clevere Autovervollständigung hinaus zu Agenten kommen wollen, an die Sie wirklich delegieren können – und das, ohne die Ingenieurspraktiken aufzugeben, die Ihre Software überhaupt erst vertrauenswürdig gemacht haben – dann ist das genau die Art Problem, an der wir gern arbeiten.
itemis · AI-Enablement — Wir befähigen Enterprise-Teams, KI in der Softwareentwicklung produktiv zu nutzen – die passenden Werkzeuge und Modelle wählen, sie in bestehende Systeme und Qualitäts-Gates integrieren und agentische Workflows bauen, die Ihre Leute besitzen und weiterentwickeln. Kein Vibe Coding, kein KI-Theater. Mehr über AI-Enablement →



