Vor zwei Jahren war “agentic” noch ein Konferenz-Buzzword. Heute schreibt unsere Engineering-Crew Migrations-Skripte, indem sie einem Agenten zwei Sätze diktiert. Dieser Beitrag sortiert, was sich für ein Mittelstands-Software-Team davon real lohnt — und wo wir auf die Nase gefallen sind.
Was “Agentic” wirklich heißt
Ein Agent ist kein Chatbot. Der Unterschied: Ein Chatbot generiert Text. Ein Agent plant, handelt, beobachtet das Resultat und iteriert. Konkret bedeutet das eine Schleife:
- Modell bekommt ein Ziel (“Migriere alle Composer-Pakete auf Symfony 7”)
- Wählt ein Tool (
read_file,grep,bash,edit) - Wertet die Ausgabe aus
- Entscheidet den nächsten Schritt
- Wiederholt, bis das Ziel erreicht oder ein Limit überschritten ist
# Stark vereinfachter Agent-Loop
while not goal_reached and steps < MAX_STEPS:
plan = model.generate(goal, history)
tool_call = parse_tool_call(plan)
result = execute(tool_call) # bash, edit, search ...
history.append((plan, result))
goal_reached = model.evaluate(history, goal)Der entscheidende Punkt liegt in Zeile 4: Die Ausgabe eines Tools wird wieder ins Modell gefüttert. Genau diese Feedback-Schleife unterscheidet einen Agenten von einem Autocomplete-System wie der ersten Generation von Copilot.
Was im Mittelstand sofort zieht
Wir haben drei Anwendungsfälle, die nach drei Wochen Pilotierung Geld auf dem Tisch ließen:
- Codemod-Migrationen: Refactorings über Hunderte Dateien (PHP 7 → PHP 8.3, Vue 2 → Vue 3 Composition API). Der Agent zieht die Migrations-RFC, schreibt die Änderungen, lässt die Tests laufen, fixt Restfehler. Was vorher ein 3-Sprint-Backlog war, ist jetzt eine PR pro Modul.
- Issue-Triage: Eingehende Tickets bekommen automatisch Labels, betroffene Komponenten, Vorschläge für Owner. Wir reviewen das, statt es selbst zu schreiben.
- Dokumentations-Drift: Ein Nightly-Agent prüft, ob die in
docs/referenzierten Code-Stellen noch existieren und ob Public-API-Änderungen ohne CHANGELOG-Eintrag durchgegangen sind.
“Der ROI kommt nicht aus den 5 Minuten, die der Agent pro Task spart. Er kommt daraus, dass plötzlich Arbeit gemacht wird, die wir vorher schlicht weggelassen hätten.”
Wo wir auf die Nase gefallen sind
Drei harte Lektionen aus dem ersten Quartal:
1. Tool-Surface ist die ganze Kunst
Ein Agent ist nur so gut wie die Tools, die er anrufen darf. Wir hatten anfangs einen “Universal-Bash”-Tool und wunderten uns, warum der Agent sich in find / -name "*.log" verirrte. Die Lösung war wenige, schmale, dokumentierte Tools:
| Tool | Was es kann | Was es nicht kann |
|---|---|---|
read_file(path) | UTF-8 lesen, max 4 MB | binär, Symlinks |
grep(pattern, path) | ripgrep-Wrapper | regex ohne Anchor |
apply_patch(diff) | unified diff anwenden | freie Dateierstellung |
run_tests(suite) | gefilterte Pytest-Runs | full CI |
Der Agent ist schneller, vorhersagbarer und sicherer, wenn er sich aus einem kleinen, klar getrennten Werkzeugkasten bedient.
2. Kontextfenster ist nicht gleich Kontext
128k Token klingt nach viel. In der Praxis pasen ein großes Repo, drei Issue-Threads und die letzten 80 Tool-Calls schon nicht mehr rein. Aktive Kontextverwaltung ist kein nice-to-have — sie ist die Differenz zwischen einem Agenten, der funktioniert, und einem, der nach 30 Minuten halluziniert. Wir verwenden Tag-basiertes Summarising: ältere Tool-Outputs werden komprimiert, sobald sie nicht mehr referenziert werden.
3. Reviews sind nicht optional
Die Versuchung, einen Agenten “über Nacht” laufen zu lassen, ist groß. Wir machen das nicht für produktionsnahen Code. Jede PR durchläuft denselben Review-Prozess wie eine PR von einer menschlichen Entwicklerin. Der Grund ist nicht Misstrauen — es ist Auditierbarkeit. Wenn nächstes Jahr in einem Deployment etwas schiefgeht, müssen wir nachvollziehen können, wer die Änderung wann mit welcher Begründung gemacht hat.
Was wir 2026 anders machen werden
Drei Vorhaben für das nächste Halbjahr:
- Agent-Telemetrie: Wir loggen jeden Tool-Call mit Token-Verbrauch, Latenz und Ergebnis. Daraus bauen wir ein Dashboard, das zeigt, welche Tasks sich für Agenten lohnen und welche nicht.
- Multi-Agent-Workflows: Statt eines Allzweck-Agenten mehrere spezialisierte (Review-Agent, Migrations-Agent, Doc-Agent). Frühe Erfahrungen zeigen besseren Output bei geringerem Token-Verbrauch.
- Eval-Suite: Reproduzierbare Test-Tasks, die wir bei jedem Modell-Update durchlaufen lassen. Sonst weiß man bei jedem Sprung von Claude 4.6 auf 4.7 nicht, ob die Pipeline besser oder schlechter geworden ist.
Fazit
Agentic Engineering ist kein Tool, das man einkauft. Es ist ein Arbeitsmodell, in dem Engineering-Zeit zunehmend in die Definition von Tools, Kontextstrategien und Evaluations fließt — und immer weniger in die direkte Code-Produktion. Für Mittelständler, die heute mit überfüllten Backlogs leben, ist genau das der relevante Hebel: Nicht “mehr Code schneller”, sondern “Arbeit anpacken, die wir uns vorher nicht leisten konnten”.