Was ist Agentic Development?

Agentic Development bedeutet: Man sitzt nicht mehr neben einer KI und tippt gemeinsam Code, sondern übergibt ihr eine Aufgabe – und prüft später das Ergebnis. Aus dem Autovervollständiger wird ein Kollege, der ein Ticket bearbeitet, Tests ausführt und einen Merge Request eröffnet. Dieser Beitrag erklärt Schritt für Schritt, wie das funktioniert: von der Definition eines Agenten über Sandboxes und Fernsteuerung bis zur kompletten Plattform – und wo die echten Herausforderungen liegen.

Inhaltsverzeichnis

• Was ist ein Agent? 🤖
• Die Modi eines Agenten: Wer entscheidet was? 🎛️
• Sandboxes: Sicherheit durch Isolation 🏖️
  • Lokale Sandboxes 💻
  • Remote Sandboxes ☁️
• YOLO-Modus: Volle Autonomie ohne Rückfrage 🎲
• Kommunikation auf Abstand: Ticket und Konsole 🎫
• Langlaufende Aufgaben auslagern ⏳
• Muss man einem Modell erklären, wie Coding geht? 🧠
• Kontext: Was gehört in welcher Form zum Agenten? 📚
• Von einzelnen Agenten zur Plattform 🏗️
• Agenten fortlaufend prüfen und den Harness verbessern 🔄
• Herausforderungen in der Praxis ⚠️
• Häufige Fragen (FAQ) ❓
• Fazit: Vom Assistenten zur Plattform 🎯

Was ist ein Agent? 🤖

Ein Sprachmodell allein beantwortet Fragen: Text rein, Text raus. Ein Agent ist ein Sprachmodell, das in einer Schleife arbeitet und dabei Werkzeuge benutzen darf. Er liest Dateien, führt Befehle aus, ruft Tests auf, schreibt Code und entscheidet nach jedem Schritt selbst, was als Nächstes sinnvoll ist – bis die Aufgabe erledigt ist oder er nicht weiterkommt.

Die Kurzformel:

Agent = Modell + Werkzeuge + Schleife + Kontext

Der Ablauf ist immer derselbe:

Das Modell selbst führt nie etwas aus. Es schlägt Werkzeugaufrufe vor, und die umgebende Software – der sogenannte Harness – führt sie aus und gibt das Ergebnis zurück. Diese Trennung ist der Schlüssel zu Sicherheit und Kontrolle, auf den wir gleich zurückkommen.

Eine ausführlichere Einordnung für Unternehmen findet sich im Beitrag Autonome KI-Agenten für Unternehmen.

Die Modi eines Agenten: Wer entscheidet was? 🎛️

Agenten arbeiten nicht immer gleich frei. Die gängigen Werkzeuge kennen mehrere Modi, die festlegen, wie viel der Agent allein tun darf. Die Bezeichnungen unterscheiden sich je nach Produkt, das Prinzip ist gleich:

Die Faustregel: Je mehr Autonomie, desto stärker muss die Umgebung den Schaden begrenzen. Ein Agent im Plan-Modus kann nichts kaputt machen. Ein autonomer Agent kann es – deshalb gehört er nie ungeschützt auf einen Entwicklerrechner oder gar in die Nähe von Produktivsystemen.

Sandboxes: Sicherheit durch Isolation 🏖️

Ein Agent führt Befehle aus, liest Dateien und hat oft Zugriff auf Netzwerk und Zugangsdaten. Gleichzeitig verarbeitet er Text aus unzuverlässigen Quellen: Issue-Beschreibungen, Webseiten, Abhängigkeiten, Code aus fremden Repositories. Dort kann eine versteckte Anweisung stehen (sogenannte Prompt Injection), die den Agenten zu etwas verleitet, was niemand beabsichtigt hat – etwa Geheimnisse an einen externen Server zu senden.

Das Prinzip dagegen kennt man aus der IT-Sicherheit: Least Privilege. Der Agent bekommt nur die Rechte, die er für die Aufgabe braucht, und arbeitet in einer abgegrenzten Umgebung, der Sandbox. Passiert etwas Unerwartetes, bleibt der Schaden dort.

Lokale Sandboxes 💻

Die Sandbox läuft auf dem eigenen Rechner:

• Dev Container / Docker: Der Agent arbeitet in einem Container mit eingebundenem Projektordner, aber ohne Zugriff auf das restliche Home-Verzeichnis
• Betriebssystem-Sandbox: Dateizugriffe und Netzwerk werden auf Betriebssystemebene eingeschränkt (z. B. nur Schreibzugriff im Projektordner, Netzwerk nur zu freigegebenen Domains)
• Eigene virtuelle Maschine: Stärkste lokale Isolation, dafür mehr Aufwand

Vorteil: Schnell, kostenlos, Code verlässt den Rechner nicht. Nachteil: Der Agent läuft nur, solange der Rechner läuft, und eine falsch konfigurierte Sandbox schützt nur scheinbar.

Remote Sandboxes ☁️

Die Sandbox läuft auf einem Server oder in der Cloud – oft als kurzlebiger Container oder MicroVM, der pro Aufgabe neu entsteht und danach verworfen wird:

• Frische Umgebung pro Aufgabe: Kein Zustand bleibt zurück, keine Altlasten
• Keine echten Geheimnisse: Der Agent erhält nur zeitlich begrenzte, eng geschnittene Tokens statt der Zugangsdaten des Entwicklers
• Netzwerk-Allowlist: Nur benötigte Ziele (Paketquellen, Git-Server) sind erreichbar
• Skalierung: Viele Agenten laufen parallel, ohne den eigenen Rechner zu belasten

Vorteil: Wirklich entkoppelt und parallelisierbar. Nachteil: Der Code liegt auf fremder oder zusätzlicher Infrastruktur – im DACH-Raum eine Frage für Datenschutz und Compliance. Betreibt man die Remote-Umgebung selbst, etwa auf einem Kubernetes-Cluster im eigenen Rechenzentrum, bleibt die Datenhoheit erhalten.

Wichtig: Eine Sandbox ersetzt kein Review. Sie begrenzt den Schaden während der Ausführung. Ob der erzeugte Code gut und sicher ist, klärt erst die Prüfung danach – mit Tests, Security-Scans und menschlichem Review.

YOLO-Modus: Volle Autonomie ohne Rückfrage 🎲

Im sogenannten YOLO-Modus („You Only Live Once“) führt der Agent alles aus, ohne vorher nachzufragen: Dateien ändern, Befehle starten, Pakete installieren, Tests laufen lassen. Je nach Werkzeug heißt das „Auto-Approve“, „Bypass Permissions“ oder – in der Kommandozeile – ein Parameter wie --dangerously-skip-permissions. Der Name ist bewusst ein Warnhinweis.

Warum man ihn trotzdem will – die Vorteile:

• Tempo: Keine Unterbrechung bei jedem Befehl. Aufgaben laufen in Minuten statt mit ständigem Klicken durch
• Echte Delegation: Man kann den Agenten starten und sich anderem widmen – die Grundlage für langlaufende Aufgaben und parallele Agenten
• Weniger Freigabe-Müdigkeit: Wer hundertmal „Ja“ klickt, bestätigt irgendwann blind – auch das gefährliche Kommando. Ständige Rückfragen erzeugen Scheinsicherheit
• Bessere Ergebnisse bei klaren Aufgaben: Der Agent kann testen, fehlschlagen, korrigieren und wiederholen, ohne dass jemand ihn bremst

Was dagegen spricht – die Nachteile:

• Keine Bremse: Ein Fehlverständnis, eine Endlosschleife oder ein falscher Befehl wird sofort ausgeführt
• Zerstörerische Befehle: Löschen, Überschreiben, Force-Push oder Änderungen an Konfigurationen passieren ohne Vorwarnung
• Prompt Injection wirkt direkt: Eine versteckte Anweisung in einem Ticket, einer Webseite oder einer Abhängigkeit wird ohne menschliche Prüfung befolgt
• Zugriff auf alles, was erreichbar ist: Dateien, Umgebungsvariablen, Zugangsdaten, Netzwerk – so weit die Rechte des Benutzers reichen
• Kosten und Laufzeit: Ohne Limits kann ein Agent stundenlang Tokens verbrauchen

Auf einem normalen Entwicklerrechner mit vollem Zugriff auf Home-Verzeichnis, SSH-Schlüssel und Cloud-Zugänge ist der YOLO-Modus keine gute Idee.

Warum die Sandbox ihn erst vertretbar macht:

Die Sandbox beantwortet die Frage „Was kann im schlimmsten Fall passieren?“ neu. Statt jeden Schritt zu prüfen, begrenzt man vorab den Schaden:

• Dateisystem begrenzt: Der Agent sieht nur das Projekt, nicht den Rest des Rechners. Ein rm -rf trifft höchstens die Wegwerf-Umgebung
• Netzwerk begrenzt: Nur freigegebene Ziele sind erreichbar, Daten lassen sich nicht beliebig versenden
• Keine echten Geheimnisse: Die Umgebung enthält keine privaten Schlüssel, sondern nur eng geschnittene, kurzlebige Zugangsdaten
• Wegwerfbar: Läuft etwas schief, verwirft man die Umgebung und startet neu

Aus „bei jedem Schritt fragen“ wird so „Rahmen vorab festlegen, innerhalb des Rahmens frei arbeiten lassen“.

Welche Risiken auch mit Sandbox bleiben:

Kurz gesagt: Die Sandbox macht den YOLO-Modus sicher genug für den Betrieb des Agenten, aber nicht sicher genug für das Ergebnis. Alles, was darüber hinausgeht – Rechte, Netzwerk, Qualität, Kosten, Nachvollziehbarkeit –, ist genau das, was eine Agentic Development Platform systematisch löst, damit man dem Agenten die Zügel loslassen kann, ohne die Kontrolle zu verlieren.

Kommunikation auf Abstand: Ticket und Konsole 🎫

Der eigentliche Produktivitätssprung entsteht, wenn man den Agenten nicht mehr beobachten muss. Dafür braucht es Kanäle, über die man Aufgaben übergibt und Rückmeldungen erhält.

Ticketsystem (Forgejo, GitLab, GitHub, Jira):

1. Man beschreibt die Aufgabe im Ticket – mit Ziel und Akzeptanzkriterien
2. Ein Label oder ein Kommentar (z. B. @agent) startet den Agenten
3. Der Agent legt einen Branch an, arbeitet in seiner Sandbox und eröffnet einen Merge Request
4. Rückfragen stellt er als Kommentar im Ticket
5. Der Mensch prüft den Merge Request, kommentiert – der Agent arbeitet das Feedback ein

Konsole (CLI):

• Der Agent läuft in einer Terminalsitzung, die man starten, abtrennen und später wieder aufnehmen kann
• Mit Headless-Modi lassen sich Agenten per Skript oder Pipeline starten, ganz ohne interaktive Oberfläche
• Per Push-Benachrichtigung (Chat, E-Mail) meldet sich der Agent, wenn er fertig ist oder eine Entscheidung braucht

Das Ticketsystem hat einen großen Vorteil: Es gibt bereits Rollen, Historie und Nachvollziehbarkeit. Jede Aktion des Agenten ist dokumentiert, und der Arbeitsfluss unterscheidet sich kaum von dem eines menschlichen Teammitglieds.

Langlaufende Aufgaben auslagern ⏳

Manche Aufgaben dauern Stunden: ein Framework-Update, die Migration von hundert Dateien, das Schließen von Testlücken. Bei direkter Zusammenarbeit blockiert das den Entwickler. Mit Agentic Development ändert sich die Rollenverteilung:

• Delegieren: Aufgabe sauber beschreiben, Agent in der Sandbox starten, mit der eigenen Arbeit weitermachen
• Parallelisieren: Mehrere Agenten bearbeiten mehrere Tickets gleichzeitig – jeder auf eigenem Branch, jeder in eigener Sandbox
• Nur das Ergebnis prüfen: Man bewertet den Merge Request, die Testergebnisse und die Zusammenfassung – nicht jeden einzelnen Zwischenschritt

Damit das funktioniert, braucht ein Agent eine objektive Fertig-Definition: Tests müssen grün sein, Linter fehlerfrei, Build erfolgreich. Ohne prüfbares Kriterium meldet ein Agent gern „fertig“, obwohl nur der Anschein stimmt. Je besser die automatische Prüfung, desto länger kann man einen Agenten allein arbeiten lassen.

Zusätzlich helfen Mechanismen für lange Läufe:

• Zwischenstände speichern (Commits, Notizdatei), damit der Agent nach Abbruch weitermachen kann
• Grenzen setzen für Laufzeit, Kosten und Anzahl der Schritte
• Eskalation definieren: Wenn der Agent nach X Versuchen nicht weiterkommt, stoppt er und fragt nach

Muss man einem Modell erklären, wie Coding geht? 🧠

Nein. Moderne Modelle haben Programmieren, gängige Frameworks, Muster und Fehlerbilder bereits gelernt. Man muss ihnen nicht erklären, was eine Schleife ist, wie man einen REST-Endpunkt schreibt oder wie Git funktioniert. Seitenlange „Du bist ein erfahrener Senior-Entwickler …“-Vorträge bringen kaum etwas.

Was das Modell nicht weiß, ist Ihr Projekt:

• Wie wird gebaut und getestet? (./gradlew test, nicht „irgendein Testlauf“)
• Welche Architekturentscheidungen gelten und warum?
• Welche Konventionen, Namensschemata und Verbote gibt es?
• Was bedeutet die Fachdomäne – und welche Begriffe sind intern anders belegt?
• Was gilt als „fertig“ und was als gefährlich (z. B. „niemals Datenbankmigrationen ohne Rückfrage“)?

Der Unterschied lässt sich gut so zusammenfassen: Das allgemeine Handwerk bringt das Modell mit, das lokale Wissen muss man liefern. Und es gilt: lieber wenige, präzise Hinweise als viele vage. Jede überflüssige Zeile kostet Aufmerksamkeit und Geld.

Ein typisches Beispiel für gut investierten Kontext:

# AGENTS.md (Auszug)

## Build und Test
- Build: `./gradlew build`
- Tests: `./gradlew test` – muss vor jedem Merge Request grün sein

## Regeln
- Keine neuen Abhängigkeiten ohne Begründung im Merge Request
- Datenbankänderungen nur per Flyway-Migration in `src/main/resources/db/migration`
- Öffentliche Schnittstellen nie ohne Rückfrage ändern

Kontext: Was gehört in welcher Form zum Agenten? 📚

Das Modell sieht pro Lauf nur ein begrenztes Kontextfenster. Es hat kein Gedächtnis über Sitzungen hinweg – alles, was es wissen soll, muss im Kontext stehen oder von ihm gefunden werden. Die Kunst liegt darin, die richtige Information in der richtigen Form bereitzustellen:

Die wichtigsten Grundsätze:

• Immer geladen nur das Nötigste. Alles Weitere lädt der Agent erst bei Bedarf nach (Progressive Disclosure)
• Beschreiben, was gilt – nicht alles, was möglich ist. Klare Regeln statt Romane
• Prüfbares statt Meinungen. „Tests laufen mit Befehl X“ ist besser als „achte auf gute Qualität“
• Wiederholte Korrekturen in die Projektregeln überführen. Muss man dem Agenten dasselbe dreimal sagen, gehört es in die Datei

Wie sich Kontext in großen Projekten skalieren lässt, zeigt der Beitrag agents.md zu groß? MCP als Lösung.

Von einzelnen Agenten zur Plattform 🏗️

Für einen Entwickler und ein Projekt genügt oft ein Agent mit lokaler Sandbox. Sobald mehrere Personen mehrere Agenten für mehrere Projekte nutzen, braucht es eine gemeinsame Grundlage – eine Agentic Development Platform. Sie bündelt in Kurzform:

• Aufträge: Annahme über Ticketsysteme, Warteschlange, Limits
• Sandboxes: frische, isolierte Umgebung pro Aufgabe, kurzlebige Zugangsdaten
• Kontext: zentral gepflegte Projektregeln, Skills und MCP-Werkzeuge
• Qualitätssicherung: Tests, Security-Scans und menschliches Review vor jedem Merge
• Beobachtbarkeit: Logs, Kosten und Audit-Trail

Man muss nicht mit allem gleichzeitig beginnen: erst ein Agent lokal in einer Sandbox, dann Start über Tickets, dann Remote-Sandboxes, dann Orchestrierung mehrerer Agenten. Aufbau, Funktionen, Herausforderungen, Pflege und Zielgruppen einer solchen Plattform erklärt der Beitrag Agentic Development Platform erklärt im Detail.

Agenten fortlaufend prüfen und den Harness verbessern 🔄

Ein Agent ist kein Produkt, das man einmal einrichtet. Modelle ändern sich, Projekte wachsen, Aufgaben variieren. Die Stellschraube ist der Harness – Anweisungen, Werkzeuge, Berechtigungen, Kontextregeln und Prüfschritte –, nicht das Modell. Das Grundprinzip:

• Messen: Wie viele Merge Requests werden ohne Nacharbeit übernommen? Was kosten sie?
• Aus Ablehnungen lernen: Jeder abgelehnte Merge Request zeigt eine Lücke in Regeln, Werkzeugen oder Fertig-Definition
• Harness anpassen: Wiederkehrende Korrekturen gehören in die Projektregeln, nicht in jede neue Anweisung
• Absichern: Typische Aufgaben mit bekannter guter Lösung („Evals“) laufen nach jeder Änderung erneut

Wie sich dieser Kreislauf mit Kennzahlen, Evaluation und spezialisierten Agenten dauerhaft betreiben lässt, steht im Beitrag Agentic Development Platform erklärt unter „Fortlaufende Pflege“.

Herausforderungen in der Praxis ⚠️

Agentic Development ist kein Selbstläufer. Typische Stolpersteine:

• Verantwortung bleibt beim Menschen. Der Agent liefert Vorschläge, haftbar ist das Team. „Der Agent hat es geschrieben“ ist kein Argument gegenüber Kunden oder Auditoren
• Review-Flaschenhals. Agenten erzeugen schneller Code, als Menschen ihn prüfen können. Ohne gute automatische Prüfung verschiebt sich der Engpass nur
• Plausibel, aber falsch. Modelle formulieren überzeugend, auch wenn die Lösung nicht stimmt. Nur Tests und Messungen schaffen Vertrauen
• Sicherheit. Prompt Injection, zu weitreichende Rechte, abfließende Geheimnisse, kompromittierte Abhängigkeiten – siehe Supply Chain Security
• Kontextpflege. Veraltete Projektregeln sind schlimmer als keine. Der Kontext braucht Eigentümer und Pflege wie Code
• Kosten. Lange, autonome Läufe verbrauchen viele Tokens. Ohne Limits und Monitoring entstehen unangenehme Überraschungen
• Wartbarkeit. Schnell generierter Code ohne Architekturvorgabe wird zum Chaos – das Thema des Beitrags Vibe Coding vs. Software Engineering
• Datenschutz und Regulierung. Wohin gehen Code und Daten? Dazu kommen Anforderungen wie der EU AI Act und bei Lieferketten NIS2
• Kompetenzverschiebung. Entwickler schreiben weniger Code und formulieren, prüfen und entscheiden mehr. Das erfordert Training und neue Routinen
• Nicht jede Aufgabe eignet sich. Klar umrissene, prüfbare Aufgaben funktionieren gut. Unscharfe Anforderungen, Architekturentscheidungen oder Neuland brauchen weiterhin Menschen

Häufige Fragen (FAQ) ❓

Was ist der Unterschied zwischen einem Chatbot und einem Agenten? Ein Chatbot antwortet mit Text. Ein Agent handelt: Er nutzt Werkzeuge, führt Befehle aus und arbeitet in einer Schleife, bis die Aufgabe erledigt ist.

Was ist ein Harness? Der Harness ist die Software und Konfiguration um das Modell herum: Werkzeuge, Berechtigungen, Anweisungen, Kontextverwaltung und Prüfschritte. Er bestimmt, wie zuverlässig und sicher ein Agent arbeitet – oft stärker als die Wahl des Modells.

Ist der YOLO-Modus grundsätzlich gefährlich? Auf dem ungeschützten Entwicklerrechner ja. In einer isolierten Sandbox mit begrenztem Netzwerk, ohne echte Geheimnisse und mit Pflicht-Pipeline vor dem Merge ist er für klar umrissene Aufgaben ein bewährtes Vorgehen.

Reicht eine lokale Sandbox aus? Für einzelne Entwickler und unkritische Projekte oft ja. Für parallele, langlaufende oder weitgehend autonome Agenten sind Remote-Sandboxes mit eigener Identität und Netzwerkregeln die bessere Wahl.

Wie groß sollte eine Aufgabe für einen Agenten sein? So groß, dass sie sich in einem Merge Request prüfen lässt und ein objektives Fertig-Kriterium hat. Große Vorhaben zerlegt man in mehrere Tickets.

Ersetzen Agenten Entwickler? Nach aktueller Praxis nicht. Sie übernehmen klar umrissene Fleißarbeit, während Menschen Anforderungen klären, Architektur entscheiden und Ergebnisse verantworten.

Wie startet man am besten? Mit einem Agenten, einer Sandbox, einer kurzen AGENTS.md und einer Aufgabe mit guter Testabdeckung. Erst wenn das zuverlässig läuft, lohnt der Ausbau zur Plattform.

Fazit: Vom Assistenten zur Plattform 🎯

Agentic Development verschiebt die Arbeit: weg vom Schreiben jeder Zeile, hin zum Formulieren von Aufgaben, Bereitstellen von Kontext und Prüfen von Ergebnissen. Das Modell bringt das Programmierhandwerk mit – das Wissen über das eigene Projekt, die Sicherheitsgrenzen und die Qualitätskriterien muss die Umgebung liefern. Wer Sandboxes, Ticket-Anbindung, prüfbare Fertig-Definitionen und eine Pipeline für Tests und Security sauber aufsetzt, kann Agenten verlässlich Aufgaben übergeben und sich auf das konzentrieren, was bleibt: Entscheidungen und Verantwortung.

Wer Agentic Development im eigenen Unternehmen einführen oder eine sichere Plattform aufbauen möchte, findet in einem unverbindlichen Gespräch den passenden Einstieg – hier Kontakt aufnehmen.