# Wenn die Agenten den Code schreiben, prüft der Mensch sich selbst [1/2]

## Teil 1: Das Setup, oder wie agentisches Entwickeln wirklich funktioniert

*(Serie in zwei Teilen. Teil 1 beschreibt, wie ein funktionierendes agentisches Setup aussieht. Teil 2 zeigt, welchen Preis der Mensch dafür zahlt und wie er ihn in den Griff bekommt. Beide Teile lassen sich unabhängig lesen.)*

9:34 Uhr. Mein Setup ist warm. Vier Agenten laufen.

Einer hat einen Refactor fertig und fragt, ob er committen darf. Der zweite hat siebzehn E2E-Tests grün gezogen, einen roten gemeldet und wartet auf meine Diagnose. Der dritte schlägt einen Architektur-Wechsel vor, mit drei Optionen. Der vierte will wissen, ob er beim Logging weiter Slf4j benutzt oder auf etwas neueres umstellt.

Vier Entscheidungen, bevor mein Kaffee kalt ist. Und das ist der ruhige Anfang.

Die meisten Texte über agentisches Entwickeln verkaufen Tempo. Schneller Liefern. Mehr Output pro Tag. Weniger Tipparbeit. Stimmt alles. Wird nur selten zu Ende erzählt, weil die andere Hälfte unangenehmer ist: das, was beim Menschen ankommt, der die Agenten beaufsichtigt. Bevor ich in Teil 2 zu dieser unangenehmen Hälfte komme, lohnt sich der Blick auf das, was tatsächlich funktioniert.

Ich arbeite seit Jahren agentisch. Das Setup verschiebt sich allerdings ständig, weil die Technologie sich bewegt. Was vor ein paar Jahren hieß „die KI macht einen Code-Vorschlag, ich übernehme oder lehne ab“, heißt heute „mehrere spezialisierte Subagents arbeiten parallel an Features, und ich bin derjenige, der prüft, freigibt, korrigiert und priorisiert“. Mit jeder Stufe entstehen neue Probleme im Kopf des Menschen. Über die heutige Stufe schreibe ich hier.

## Was meine ich mit agentischem Entwickeln, und was nicht?

Erst eine Begriffstrennung: Vibe Coding heißt, „Du beschreibst auf Zuruf, die KI baut, du übernimmst was klingt“. Schnell, kreativ, riskant, und in seriösen Code-Basen meistens nicht produktionstauglich. Agentisches Entwickeln meint etwas anderes: ein orchestriertes Setup aus mehreren Subagents, jeder mit klarem Auftrag, gegen eine Repository-Basis mit guter E2E-Testabdeckung, und ein Mensch, der die strategische Schicht hält. Beide werden gerade in einen Topf geworfen. Skeptiker sehen Vibe-Output und schließen auf die Methode. Beifallspender feiern Vibe-Output und nennen es Engineering. Beides geht am Punkt vorbei.

In meinem Setup laufen aktiv drei Modelle nebeneinander, jedes mit klarem Auftrag. Ein großes Reasoning-Modell für das, was wirklich Tiefe braucht: Architekturvorschläge, größere Refactorings, schwer eingrenzbare Bugs. Ein mittleres Modell für die alltägliche Implementierung. Ein kleines, schnelles Modell für alles, was eigentlich Routine ist: Formatierung, Code-Kommentare, Recherche-Zusammenfassungen, Doku-Updates.

Warum drei und nicht eins? Weil sich mehrere Effekte gleichzeitig einstellen. Qualität, weil das passende Modell für die jeweilige Aufgabe das Ergebnis spürbar verbessert. Das große Modell liefert die Tiefe, die ein Architektur-Vorschlag oder ein schwieriger Bug braucht. Das kleine bleibt bei Routine und versucht nicht, eine zweizeilige Doku-Korrektur in eine Architekturdebatte zu verwandeln. Geschwindigkeit, weil das kleine Modell in Sekunden antwortet, wo das große Minuten braucht; wenn der Großteil deiner Anfragen klein bleibt, ist dein Tag spürbar schneller. Kosten, weil der Preisunterschied pro Token bei einer Größenordnung oder mehr liegt; jeden Code-Kommentar zum Preis einer Architektur-Anfrage zu generieren ist ökonomisch unsinnig. Und Klimabilanz, weil größere Modelle real mehr Rechenleistung, mehr Energie und mehr Wasser für die Kühlung brauchen. Eine fachbegutachtete Studie von Luccioni und Kollegen aus dem Jahr 2024 vergleicht den Energieverbrauch bei der Modellausführung über 88 Modelle und 30 Datensätze und findet dabei Unterschiede von mehreren Größenordnungen zwischen kleinen und großen Modellen für dieselbe Aufgabe [2]. Wer hier nicht differenziert, treibt den Energieverbrauch seines Setups ohne Not nach oben.

Welches Modell konkret welche Aufgabe übernimmt, ist Geschmackssache und ändert sich mit jeder neuen Release. Was bleibt, ist die Trennung. Refactorings kosten in dieser Welt fast nichts mehr, weil ein Agent sie in zwanzig Minuten macht, gegen die E2E-Suite verifiziert und einen Diff abliefert, den ich lese. Die alte Faustregel „make the change easy, then make the easy change“ [1] wird ökonomisch tragfähig. Und ich behalte zwei Achsen explizit beim Menschen: das Planen vorher und den Gefühls-Check nachher. Was gebaut wird, entscheide ich. Ob es sich richtig anfühlt, entscheide ich. Den Rest mache ich nicht.

## Warum das die eigentliche Kompetenzverschiebung ist

Wer diesen Aufbau ernst nimmt, merkt schnell: Die Arbeit verschwindet nicht, sie verlagert sich. Weg vom Tippen, hin zum Beurteilen. Die Agenten produzieren in derselben Zeit ein Vielfaches des Materials, das früher entstanden ist. Jede Zeile davon will bewertet werden. Das ist genau die Kompetenz, die gute Tester und erfahrene Reviewer schon immer hatten: Kontext halten, Qualität einschätzen, Risiko abwägen. Sie verschwindet in einer agentischen Welt nicht. Sie wird zentraler.

Genau hier fängt der spannende Teil an. Denn dieser Aufbau funktioniert erst dann dauerhaft, wenn man den Preis kennt, den er dem Menschen abverlangt. Wo früher in zwei Stunden vielleicht acht bewusste Entscheidungen fielen, sind es jetzt gefühlt vierzig. Das Tippen war nicht das Anstrengende. Das Beurteilen ist es.

Über diesen Preis, die drei kognitiven Bottlenecks dahinter und die konkreten Schutzwälle dagegen geht es in Teil 2.

## Quellenverzeichnis

Jörg Amelunxen

Jörg Amelunxen ist AI Solutions Architect bei mgm mit Schwerpunkt auf KI- und agentengetriebener Softwareentwicklung. Als erfahrener Entwickler und technischer Projektleiter arbeitet er im projektübergreifenden mgm AI & Data Engineering Team daran, agentische Softwareentwicklung im Enterprise-Umfeld zu etablieren. Über einen Austausch zu diesen Themen freut er sich, am einfachsten auf LinkedIn.

Veröffentlicht: 07.2026

< Zurück zur Übersicht