Agenten schreiben den Code.
Den Rahmen baut
das Team.
Wie Teams den Rahmen bauen, in dem KI-Agenten in einem echten Projekt arbeiten können — ohne die Kontrolle über Architektur, Qualität und Verantwortung abzugeben.
- Autor
- Daniel Grobelny, mensch × ki
- Stand
- August 2026
- Für
- Entwicklungsteams, technische Leitung
- Umfang
- 10 Abschnitte, ca. 14 Minuten
Vier Sätze, falls Sie nur diese Seite lesen.
-
01
Der Unterschied zwischen KI-Assistenz und Agentic Engineering ist nicht das Modell, sondern der Rahmen, den das Team baut: Auftrag, Ausführung, Prüfung, Freigabe als geschlossener Kreis.
-
02
Autonomie entsteht nicht durch mehr Freiheit, sondern durch automatisierte Prüfbarkeit. Wo Tests, Typen und Reviews greifen, darf ein Agent mehr tun.
-
03
Ein System aus wenigen, klar begrenzten Rollen ist belastbarer als ein Universal-Agent mit Zugriff auf alles.
-
04
Der Engpass verschiebt sich vom Schreiben zum Prüfen. Wer das nicht mitplant, tauscht Tippzeit gegen Review-Staus.
Drei Reifegrade, die im Alltag ständig verwechselt werden.
Die meisten Teams sind heute auf Stufe 2: Ein Entwickler beschreibt im Chat, was er braucht, kopiert das Ergebnis, prüft es selbst. Die Zeitgewinne sind real, aber sie enden an der Person, die zwischen Modell und Repository sitzt.
Stufe 3 verlagert diese Vermittlungsarbeit in ein System: Der Agent holt sich Kontext selbst, führt Werkzeuge aus, prüft sein Ergebnis gegen Tests und legt es an definierten Punkten dem Menschen vor.
Stufe 3 ersetzt Stufe 2 nicht. In der Praxis laufen beide parallel: Der Chat bleibt für Exploration und Verständnis, der Agenten-Workflow übernimmt wiederkehrende, klar beschreibbare Arbeit.
Jeder Schritt erzeugt ein Ergebnis, das man anhalten kann.
Ein Agent ist kein einmaliger Prompt, sondern eine Schleife. Der entscheidende Teil ist nicht die Ausführung, sondern die Verifikation: Erst wenn ein Schritt maschinell überprüfbar ist, wird aus Modell-Output nachvollziehbare Entwicklungsarbeit. Der Mensch steht an genau zwei Stellen im Kreis — am Anfang und an der Freigabe.
Ziel, Akzeptanzkriterien, betroffener Bereich, erlaubte Werkzeuge.
Relevanten Code lesen, Regeln laden, Vorgehen in kleine Schritte zerlegen.
Änderungen im Feature-Branch, nur über freigegebene Werkzeuge.
Typecheck, Tests, Build, Lint. Befunde sind Daten, nicht Meinung.
Review des Diffs, Entscheidung über Merge. Verantwortung bleibt hier.
Jeder Werkzeugaufruf wird protokolliert. Sie können hinterher rekonstruieren, warum eine Änderung entstanden ist.
Schrittzahl, Laufzeit, Dateiumfang und Werkzeugliste sind gedeckelt. Ein Agent ohne Deckel ist ein Ausfallrisiko.
Ein Abbruch ist ein normales Ergebnis, kein Fehler. Wichtig ist, dass er einen lesbaren Bericht hinterlässt.
Nicht ein Super-Agent. Fünf Schichten mit klaren Zuständigkeiten.
Ein einzelner Agent, der alles darf, wird mit jedem Schritt unschärfer: Der Kontext füllt sich, Ziele verwischen, Fehler pflanzen sich fort. Deshalb trennen wir Verantwortung in Schichten — von oben nach unten immer konkreter, immer stärker eingeschränkt.
Lesen Sie das Bild von unten: Ohne das Fundament — Tests, CI, dokumentierte Entscheidungen — hat keine der oberen Schichten etwas, woran sie sich prüfen kann.
Diese Aufteilung ist werkzeugunabhängig. Sie lässt sich mit gängigen Coding-Harnesses und Agent-SDKs umsetzen; die Wahl des Anbieters ist die letzte Entscheidung, nicht die erste.
Ein Agent ist so gut wie das, was er über Ihr Projekt weiß.
Die häufigste Ursache für schlechte Agenten-Ergebnisse ist nicht das Modell, sondern fehlender oder falscher Kontext: implizite Konventionen, undokumentierte Entscheidungen, ein Ticket, das nur der Autor versteht. Wissen, das nirgends steht, kann kein Agent nutzen — und übrigens auch kein neuer Kollege.
Praktische Konsequenz: Projektwissen gehört in versionierte Dateien neben den Code, nicht in Chat-Verläufe oder Prompt-Sammlungen einzelner Entwickler. Wenn eine Regel dreimal im Review erklärt wurde, ist sie eine Datei wert. Damit profitieren Agenten und Menschen von derselben Quelle.
Kontext ist ein Budget, kein Lager. Mehr Text heißt nicht mehr Verständnis — relevanter Text schon.
Autonomie wird pro Aktion vergeben, nicht pro Agent.
Die Frage „Wie viel darf die KI selbst entscheiden?" ist zu grob gestellt. Sinnvoll ist eine Tabelle: Für jede Aktion wird festgelegt, ob sie autonom laufen darf, ob ein Mensch vorher zustimmt oder ob sie ausgeschlossen ist. Diese Matrix ist ein Dokument, das Sie mit Ihrem Team einmal erstellen und dann pflegen — sie ist die eigentliche Governance.
Beispielbelegung aus Pilotprojekten — kein Standard. Die Zuordnung hängt von Ihrer Testabdeckung, Ihrer Domäne und Ihren regulatorischen Anforderungen ab. Wichtig ist, dass sie explizit ist und dass Sie sie mit steigendem Vertrauen bewusst verschieben.
Qualität entscheidet die Pipeline, nicht die Zuversicht des Modells.
Ein Agent, der behauptet, fertig zu sein, ist kein Nachweis. Jede Änderung läuft durch dieselben Tore wie menschlicher Code — nur öfter und früher. Je dichter diese Tore sind, desto mehr Autonomie können Sie gefahrlos zulassen. Die Investition in Testbarkeit zahlt sich hier doppelt aus.
Diff bleibt im vereinbarten Bereich und in vertretbarer Größe.
Typecheck, Lint, Formatierung, verbotene Muster.
Bestehende Tests grün, neue Tests belegen die Änderung.
Build, Migrationen, Zusammenspiel der Komponenten.
Review von Absicht, Architektur und Angemessenheit.
Protokoll, Begründung und Doku liegen bei der Änderung.
Klein anfangen, messbar bleiben, bewusst erweitern.
Agentic Engineering scheitert selten an Technik, sondern an der Einführung: zu großer erster Schritt, kein Vergleichsmaßstab, kein Zuständiger. Der folgende Ablauf hat sich als Rahmen bewährt — die Dauer verschiebt sich je nach Reifegrad Ihres Projekts.
Wir sehen uns Repository, Tests, CI und Review-Praxis an und suchen die Stellen, an denen Arbeit wiederkehrend und prüfbar ist.
- ×Kandidaten-Aufgaben sammeln und bewerten
- ×Baseline messen: Durchlaufzeit, Review-Aufwand, Fehlerquote
- ×Rechte-Matrix in erster Fassung
Ein Team, ein Aufgabentyp, ein echter Branch. Wir bauen den Loop, die Guardrails und die fehlenden Prüfungen — und arbeiten damit im Alltag.
- ×Projektregeln als versionierte Dateien anlegen
- ×Rollen, Werkzeuge und Gates in die CI einhängen
- ×Wöchentliche Auswertung: Was ging schief, und warum
Was belastbar war, wird zum Standard: weitere Aufgabentypen, weitere Teams, mehr Autonomie an den Stellen, die sich bewährt haben.
- ×Rechte-Matrix nachziehen, Grenzen begründet lockern
- ×Team befähigen: Arbeitsweise, Review, Fehlerbilder
- ×Betrieb und Zuständigkeit intern übergeben
Vier Kennzahlen, gemessen vor und nach dem Pilot.
Wir nennen hier absichtlich keine Prozentzahlen. Zeitgewinne hängen von Codebasis, Testlage und Aufgabentyp ab; jede pauschale Zahl wäre Werbung. Belastbar wird es, wenn Sie Ihre eigene Baseline kennen.
Was in der Praxis regelmäßig nicht funktioniert.
Diese fünf Muster sehen wir am häufigsten. Sie sind alle vermeidbar, aber keines löst sich durch ein besseres Modell.
Ein Agent soll ein ganzes Feature bauen. Das Ergebnis ist ein Diff, den niemand mehr sinnvoll prüfen kann — und damit unbrauchbar, unabhängig von seiner Qualität.
In einer Codebasis ohne Tests kann kein Agent belegen, dass er nichts kaputt gemacht hat. Dann ist die erste Maßnahme nicht der Agent, sondern die Prüfschicht.
Wenn Projektwissen in persönlichen Chat-Verläufen liegt, entsteht kein System, sondern eine Abhängigkeit von einzelnen Personen. Regeln gehören ins Repository.
Wenn Agenten mehr Änderungen produzieren, als das Team prüfen kann, wird durchgewinkt. Die Kapazität für Reviews ist Teil der Planung, nicht ein Rest.
Die Entscheidung für ein Produkt ersetzt keine Klärung von Rollen, Rechten und Qualitätsanforderungen. Der Prozess bestimmt das Werkzeug, nicht umgekehrt.
Alle fünf Muster haben eine gemeinsame Ursache: Es wurde ein Werkzeug eingeführt, aber kein Arbeitsmodell vereinbart.
Die Arbeit verschwindet nicht. Sie verschiebt sich nach vorn.
Wer heute gute Software baut, wird in diesem Modell wichtiger, nicht überflüssig: Aufgaben präzise schneiden, Grenzen festlegen, Ergebnisse beurteilen. Das ist Senior-Arbeit — und für viele Teams die eigentliche Umstellung.
Sprechen wir über Ihren konkreten Entwicklungsprozess.
Ein Erstgespräch dauert 30 Minuten und kostet nichts. Wir schauen uns an, wie Ihr Team heute arbeitet, und sagen offen, ob und wo ein Agenten-Workflow bei Ihnen Sinn ergibt — auch dann, wenn die Antwort „noch nicht" ist.
Ihr Team versteht Loop, Rollen und Guardrails und bewertet eigene Aufgaben auf Eignung.
Wir bauen den Workflow gemeinsam im echten Projekt auf und messen gegen Ihre Baseline.
Schulung, Review-Praxis und Übergabe, damit der Betrieb ohne uns weiterläuft.