Wie Engineers bei agentischem Code die Kontrolle behalten

Ist die Architektur falsch aufgesetzt, fehlt dem Agenten eine stabile Grundlage, auf der er Entscheidungen treffen kann. Ist die Verifikation unzureichend, häufen sich technische Probleme schneller an, als Mehrwert geschaffen werden kann.

Diese Engineering-Ebene wird in vielen KI-Debatten kaum thematisiert. Erfahre hier, warum es genau darauf ankommt.

Agentische Coding-Tools sind längst in den Teams angekommen – unabhängig davon, ob es eine offizielle Strategie dafür gibt oder nicht. Die Frage ist deshalb nicht mehr ob, sondern wie der Rahmen für die richtige Nutzung dieser Tools gebaut werden kann. Dieser Rahmen besteht aus drei Bausteinen: Guides, die den Agenten vor dem Handeln steuern, Sensoren, die Lücken im Nachgang erkennen und einer Architektur, die verhindert, dass Änderungen schneller entstehen, als sie verstanden werden können.

In diesem Text geht es genau um diese praktische Ebene. Nicht um Hype, nicht um Headlines. Sondern um Engineering. Dieses Engineering hat einen Namen: Agentic Harness.

Der Unterschied liegt im ‚Harness‘, nicht im Modell

Für Engineering-Teams ist ein entscheidender Perspektivwechsel zentral: Ein Agent ist kein Modell. Vielmehr ist er ist ein Modell verbunden mit allem, was sein Verhalten strukturiert.

Dieser äußere Rahmen – der Harness – lässt sich auf zwei Kategorien runter brechen:

Die Wirkung dieses Zusammenspiels zeigt sich deutlich in den Daten von SWE-bench:

Das ist ein Unterschied von über 20 Prozentpunkten, ohne Modell-Upgrade oder Training. Der entscheidende Hebel ist nicht das Modell, sondern das Umfeld. Der Harness trennt Teams, die verlässliche Ergebnisse liefern, von denen, die keine stabilen Resultate erzielen.

Mehr Zeit in Prompts zu investieren, hilft schneller voranzukommen. Mehr Zeit in Constraints, Architektur und Verifikation zu stecken bringt weiter und zwar nachhaltig.

Architektur für KI-Tauglichkeit: Sinks statt Pipes

Agentenbasierte Programmierung funktioniert in manchen Codebasen erstaunlich gut, in anderen führt sie schnell zu Chaos. Der entscheidende Unterschied liegt fast immer in der Architektur.

Architektur ist die Leitstruktur des Systems. Sie definiert den Rahmen, innerhalb dessen ein Agent arbeitet, unabhängig davon, ob dieser Rahmen bewusst so entworfen wurde oder nicht.

Ein hilfreiches Bild ist die Unterscheidung zwischen Pipes und Sinks.

In rein menschlich geprägten Teams lassen sich pipeline-lastige Architekturen oft noch beherrschen. Kontextwissen entsteht über Zeit, durch Erfahrung und direkte Zusammenarbeit.

In agentischen Systemen kippt dieses Modell. Die verborgene Komplexität wird zum Problem.

Ein Agent verfügt nicht über persistenten Kontext zur Codebasis über Sessions hinweg. Er kann keine Kolleg*innen fragen, keinen historischen Kontext abrufen und nicht nachvollziehen, was einen Incident im letzten Quartal ausgelöst hat. Er arbeitet ausschließlich mit dem, was im aktuellen Kontextfenster sichtbar und explizit ist.

Pipeline-lastige Architekturen verlangsamen Agenten daher nicht nur. Sie erzeugen eine trügerische Oberfläche: scheinbar verständliche Strukturen, hinter denen sich die eigentlichen Abhängigkeiten und Konsequenzen von Änderungen verbergen.

Jede neue Session startet ohne belastbares Verständnis der Codebasis. Wenn das Verständnis einer einzelnen Komponente nur möglich ist, indem Nebenwirkungen über mehrere Dienste hinweg nachverfolgt werden müssen, ist diese Codebasis nicht KI-tauglich. Höchstwahrscheinlich war sie auch schon vor dem Einsatz von KI schwer zu beherrschen.

Was „AI-Readiness“ in der Praxis bedeutet

Der Satz „Architektur ist der Prompt“ bringt das auf den Punkt. Wenn ein System aus versteckten Abhängigkeiten, impliziten Nebenwirkungen, unklaren Abstraktionen und implizitem Stammeswissen besteht, fehlt dem Agenten eine stabile Grundlage für seine Arbeit. Klare Grenzen und sauber definierte Schnittstellen schaffen dagegen die Voraussetzung für sicheres Verhalten.

AI Readiness in der Praxis bedeutet

Keines dieser Prinzipien ist neu. Neu ist die Konsequenz, mit der agentisches Programmieren sie sichtbar macht. Es bestraft Mehrdeutigkeit. Es verstärkt versteckte Kopplung. Es legt schwache Tests und unsaubere Berechtigungsmodelle offen. Damit ist es weniger ein Ersatz für technische Disziplin, sondern ein Stresstest dafür, ob diese Disziplin tatsächlich vorhanden ist.

Verifikation wird wichtiger denn je

Wenn Code im Überfluss entsteht, wird Verifikation zur knappen Ressource. Genau hier greift die Sensorebene des Test-Harness. Und genau hier stoßen viele Teams aktuell an Grenzen.

Die „State of Code Developer Survey 2026“ von Sonar zeigt ein klares Spannungsfeld:

Der Aufwand verschwindet also nicht. Er verlagert sich in spätere Prozessschritte, wo er weniger sichtbar und schwerer kontrollierbar wird.

In Microservices-Architekturen kann eine scheinbar kleine, isolierte Änderung an einem Backend-Service weitreichende Folgen haben. Sie kann nachgelagerte Dienste beeinträchtigen oder gemeinsam genutzte Datenbankschemata beschädigen. Ein KI-unterstützter Entwickler erzeugt heute schnell fünf bis sechs Pull Requests pro Tag. Wenn jede dieser Änderungen rund 30 Minuten Validierung in einer geteilten Staging-Umgebung erfordert, verlagert sich der Arbeitsschwerpunkt: weg von der Entwicklung, hin zur Verwaltung einer Deployment-Warteschlange.

Wenn die Produktionsmenge schneller wächst als die Kapazitäten zur Validierung, entsteht Verifikationsschuld. Diese zeigt sich in verzögerten Releases, oberflächlichen Reviews, steigenden Incident-Risiken und einem trügerischen Gefühl von Geschwindigkeit.

Eine praktische Routine vor dem Merge:

Verifikation bedeutet heute mehr als eine Testsuite. Sie umfasst: ausführbare Akzeptanzkriterien, statische Analyse, Abhängigkeits- und Secret-Scanning, Policy-Gates, menschliche Freigabeprozesse, getrennte Umgebungen, Observability, Rollback-Fähigkeit und Produktionsmonitoring.

Ein schnelles Team im KI-Zeitalter ist nicht das Team, welches den meisten Code erzeugt. Es ist das Team, das Änderungen schnell, wiederholbar und sicher validieren kann.

Sicherheit: Wenn Agenten handeln, ändert sich das Riskio

Das Sicherheitskapitel ist nicht optional. Agentenbasierte Systeme erzeugen nicht nur Text, sie handeln. Das Kontrollsystem muss genau das abbilden. Richtlinien und Sensoren reichen nicht aus, wenn ein Agent uneingeschränkten Zugriff auf Tools, Umgebungen und externe Systeme hat.

Zwei Vorfälle zeigen, was das in der Praxis bedeutet.

Der eigentliche Einstiegspunkt war weder eine kompromittierte Abhängigkeit noch ein gestohlenes Passwort. Es war ein präparierter GitHub-Issue-Titel, der vom KI-Triage-Bot gelesen, als Instruktion interpretiert und ausgeführt wurde.

Sobald Agenten in Systemen aktiv handeln dürfen, ist Prompt Injection kein reiner Modellfehler mehr. Sie wird zu einem direkten Ausführungsweg in die Infrastruktur.

Beiden Vorfällen liegt ein Muster zugrunde, das sich als Checkliste lesen lässt. Das Risiko steigt, wenn drei Bedingungen gleichzeitig erfüllt sind:

Bevor einem Agenten erweiterte Berechtigungen eingeräumt werden, sollten für alle drei Bedingungen klare Kontrollmechanismen existieren, nicht nur für einzelne davon.

Ein zusätzlicher Punkt zu Tooling von Anbietern: Aussagen zu Datenisolation, Inhaltsfiltern oder dem Scannen von anfälligem Code sind relevant, aber nur als Teil der Lösung zu verstehen, nicht als vollständige Absicherung. Entscheidend ist das Kleingedruckte. Viele Systeme enthalten Ausnahmen, und selbst ausgeschlossene Inhalte können indirekt über semantische Kontexte Wirkung entfalten. Sicherheitskonzepte dürfen sich daher nicht auf Anbieter-Checkboxen verlassen.

Sichere Gewohnheiten im Entwicklungszyklus

Über Architektur und Sicherheit hinaus hängt zuverlässige KI-gestützte Entwicklung weniger von Prompt-Techniken ab als von einem konsistenten Prozess, der wie folgt aussieht:

Diese Gewohnheiten bilden bei konsequenter Anwendung zugleich die Grundlage für ein weiterführendes Muster: das sogenannte Loop Engineering. Dabei werden Programme entwickelt, die KI-Agenten anhand eines festgelegten Zeitplans mit klar definierten Zielen und Abbruchkriterien steuern, anstatt sie manuell zu prompten.

Während Leitplanken und Sensoren eine einzelne Agentensitzung begrenzen, überführt eine Loop diese Vorgaben in ein selbstständig laufendes System: Ein Trigger startet den Agenten, ein überprüfbares Ziel definiert den Endpunkt und Mechanismen wie Iterationslimits oder Kostenbudgets verhindern einen unbegrenzten Betrieb.

Welche Aktionen ein Agent innerhalb eines solchen Loops in einer konkreten Umgebung ausführen darf, erfordert jedoch weiterhin dieselben architektonischen und sicherheitsrelevanten Überlegungen wie jede andere Agentensitzung.

Wie sich die Rolle von Entwickler*innen verändert

Der größte Mehrwert in einer agentischen Entwicklungsumgebung entsteht nicht durch die schnellsten Prompts. Sondern durch die Fähigkeit, Probleme präzise zu definieren, sauber zu zerlegen, den Wirkungskreis zu begrenzen und einen belastbaren Weg in die Produktion zu gestalten.

Entwickler*innen, die versuchen, jeden einzelnen Arbeitsschritt selbst zu kontrollieren, werden zum Engpass. Wer dagegen lernt, den Prozess zu steuern, ohne ihn im Detail zu managen, hat den entscheidenden Hebel. Das ist keine Abwertung der Rolle, sondern eine Erweiterung der Verantwortung. Umsetzung wird zur Koordination, individueller Beitrag wird skalierbar.

Für Teams, die über Einstiegs-Level nachdenken, ergibt sich eine zentrale Herausforderung:

Entsprechend braucht es bewusst gestaltete Lernpfade rund um Debugging, Produktionslogik, Incident-Analyse und systemisches Denken. Diese Fähigkeiten entstehen nicht automatisch durch Ticketarbeit, sie müssen gezielt aufgebaut werden.

Die Entwickler*innen, die am schnellsten weiterkommen, sind jene, die generierten Code kritisch lesen, architektonische Kompromisse bewerten und Verantwortung für Systemverhalten übernehmen, nicht nur für die Erledigung einzelner Aufgaben.  Von denselben Entwickler*innen wird künftig zunehmend erwartet werden, nicht nur die Agentensitzungen selbst zu gestalten, sondern auch die automatisierten Loops zu entwickeln, die ihre Agenten ausführen.

Die Rolle verschwindet nicht durch Automatisierung. Sie wird neu definiert und das nicht graduell, sondern strukturell. Die Frage lautet nicht mehr, wie guter Code geschrieben wird. Sie lautet, wie Bedingungen geschaffen werden, unter denen guter Code zuverlässig generiert, geprüft und als vertrauenswürdig eingestuft werden kann. Urteilsvermögen, Architektur und Verifikationsdisziplin rücken damit ins Zentrum der Arbeit. Das ist keine kleinere Rolle. Es ist eine mit deutlich größerer Tragweite.

Zusammenfassung

Das Ziel ist nicht Bürokratie, sondern verhältnismäßige Kontrolle.

Es müssen zunächst Rahmenbedingungen – the Agentic Harness – geschaffen werden, bevor die Autonomie erhöht werden kann. Die Architektur muss klar definiert werden, bevor Agenten darauf arbeiten sollten. Es muss im Entwicklungs-Loop geprüft werden, nicht erst im Nachhinein. Es empfiehlt sich erst den Wirkungskreis festzulegen, bevor der erste Commit erfolgt.

Organisationen, die das konsequent umsetzen, werden nicht die sein, die am meisten KI einsetzen. Es sind die, deren KI-generierte Änderungen vertrauenswürdig, nachvollziehbar, rückgängig machbar und als Lernbasis nutzbar sind.

Geschwindigkeit ohne dieses Vertrauenssystem ist kein Vorteil. Sie ist aufgeschobenes Risiko.

Bei IBM iX sehen wir ein wiederkehrendes Muster: Teams, die die Potenziale agentischen Programmierens wirklich ausschöpfen, unterscheiden sich klar von denen, die ins Stocken geraten. Der Unterschied ist einfach, das Gerüst kam zuerst. Die technische Grundlage ist das, was den Geschäftserfolg überhaupt erst ermöglicht.

Teilen