Vitalij Bojatschkin

Agent-Workflows im Engineering-Team: 7 Patterns die wirklich produktiv machen

Q: Was ist ein Agent-Workflow im Engineering-Kontext?

Ein Agent-Workflow ist eine standardisierte Abfolge von Tool-Aufrufen (LLM-gestützt), die ein wiederkehrendes Engineering-Problem löst — z.B. Code-Review, Test-Generation, MR-Erstellung. Statt jedes Mal ad-hoc zu prompten, definiert das Team den Workflow einmal und nutzt ihn dann reproduzierbar.

Q: Wann ist ein Agent-Workflow besser als manuelle Arbeit?

Bei wiederkehrenden Tasks mit klarer Input/Output-Spezifikation. Beispiele: jeder PR braucht eine Beschreibung im selben Format → Workflow lohnt. Jedes Bug-Ticket braucht ein Repro-Skript → Workflow lohnt. Einmalige, kreative Architekturentscheidungen → Workflow lohnt selten.

Q: Wie unterscheiden sich asynchrone und interaktive Agent-Workflows?

Interaktive Workflows laufen in einer Coding-Session (Claude Code, Cursor) — der Engineer ist live dabei. Asynchrone Workflows laufen in der CI/CD-Pipeline (oft via Codex Tasks) — der Engineer prüft nur das Ergebnis. Beide haben Sweet Spots; viele Teams nutzen Mischformen.

Q: Welche Workflow-Patterns sollte ein Team zuerst etablieren?

Erstens Code-Review-Automation (höchster ROI, niedriges Risiko). Zweitens Test-Generation für neue Features (skaliert mit Team-Größe). Drittens MR-Beschreibung-Generation aus Diff (hebt PR-Qualität ohne Engineer-Aufwand).

Q: Wie verhindere ich, dass Agent-Workflows ungewollt Production-Code ändern?

Drei Schutzschichten: (1) Permission-Modell des Tools (was darf der Agent), (2) Pre-Hooks die kritische Operationen blockieren, (3) PR-basierter Review-Workflow statt Direct-Push. Kein Workflow sollte ohne menschliche Freigabe auf main mergen.

Was unterscheidet produktive AI-Agent-Workflows von hoffnungsvollen Experimenten? 7 erprobte Patterns für Code-Review, Test-Generation, MR-Automation und mehr — in echten Engineering-Teams.

import BlogFAQ from '../../src/components/BlogFAQ'; import KeyTakeaways from '../../src/components/KeyTakeaways';

<KeyTakeaways items= /

<p data speakable Ein Agent Workflow ist mehr als „ich frage Claude und kriege Code". Es ist eine standardisierte Abfolge von Tool Aufrufen, die ein wiederkehrendes Engineering Problem reproduzierbar löst. Dieser Post zeigt 7 Patterns, die ich in echten Engineering Teams als produktiv erlebt habe — und drei Anti Patterns, die teuer werden. Vendor agnostisch: die Patterns funktionieren in Claude Code, Codex, Cursor und mit eigenen Custom Agents. </p

Was einen guten Agent Workflow ausmacht

Vier Kriterien unterscheiden produktive Workflows von hoffnungsvollen Experimenten:

1. Deterministisches Input. Was geht rein, ist klar definiert (ein Ticket, ein Diff, ein File Pfad). Keine Ambiguität. 2. Strukturiertes Output. Was rauskommt, hat ein erwartbares Format (Markdown Sektionen, JSON, geänderte Files mit Diff). 3. Klare Human in the Loop Punkte. Nicht jeder Schritt braucht Engineer Approval, aber die wichtigen sind klar markiert. 4. Wiederholbar im Team. Ein neuer Engineer kann den Workflow am ersten Tag triggern, ohne tribal knowledge.

Ohne diese vier Kriterien wird der Workflow nach 2 3 Wochen wieder ad hoc Prompting.

Pattern 1: Code Review Automation

Use Case: Jeder PR bekommt einen ersten AI Review, der Style Fehler, offensichtliche Bugs und Coverage Lücken identifiziert. Der Engineer Review fokussiert auf Architektur und Edge Cases.

Setup in Claude Code (Custom Command):

```markdown .claude/commands/review.md

Du bist Code Reviewer für dieses Projekt. Lies die Coding Conventions in CLAUDE.md. Hole den Diff via 'git diff main...HEAD'.

Erstelle einen Review mit Sektionen: Critical (Bugs, Security, Daten Verlust Risiken) Style (Convention Abweichungen, Naming) Suggestions (Refactoring Möglichkeiten, kein Muss) Tests (fehlende Coverage, ungetestete Edge Cases)

Output als Markdown. Keine Kommentare zu Files, die nicht im Diff stehen. ```

Trigger: /project:review in Claude Code. Output in der MR Beschreibung pinned.

Was es spart: Engineer Reviews werden schneller, weil Style Diskussionen schon vorab gelöst sind. Junior PRs profitieren überproportional.

Was es nicht ersetzt: Architektur Reviews, Domain Entscheidungen, Performance Trade offs. Da bleibt der menschliche Review essentiell.

Pattern 2: Test Generation aus Code Diff

Use Case: Wenn ein neuer Feature Branch fertig ist, generiert ein Workflow automatisch Test Stubs für die neuen/geänderten Funktionen.

Workflow (vereinfacht):

1. Workflow nimmt den Diff seit Branch Start 2. Identifiziert geänderte/neue Funktionen, Klassen, Endpoints 3. Generiert pro Funktion einen Test Stub mit Happy Path + 2 3 Edge Cases 4. Engineer prüft und vervollständigt

Wichtig: Test Stubs sind ein Startpunkt, kein fertiger Test. Der Engineer entscheidet, welche tatsächlich aussagekräftig sind und welche gelöscht werden.

ROI: Test Coverage steigt messbar, weil der „Test schreiben" Hürde Effekt verschwindet. Skaliert besonders mit Team Größe — Juniors haben weniger Ausreden.

Pattern 3: MR Beschreibung aus Diff generieren

Use Case: Jeder MR braucht eine vernünftige Beschreibung (Was, Warum, Wie getestet). In der Realität kopiert der Engineer drei Stichworte und fertig. Ein Workflow generiert die Beschreibung aus Diff + Commit Messages + zugehörigem Ticket.

Setup (Codex Task oder Custom Command):

ROI: MR Reviews werden schneller, weil Reviewer sofort wissen, was sie anschauen. Engineering Manager kriegen messbar bessere Sicht auf die Arbeit des Teams.

Pattern 4: Inzident Repro Skript Generation

Use Case: Wenn ein Bug Ticket kommt, generiert ein Workflow ein erstes Repro Skript basierend auf Logs, Ticket Beschreibung und betroffener Code Region.

Setup: MCP Server für Jira + ein Custom Command, der:

1. Ticket holt 2. Relevante Logs aus dem letzten Stunden Window zieht 3. Code Region identifiziert 4. Minimalen Repro Versuch schreibt

Realismus: Repro Skript funktioniert vielleicht in 40 60% der Fälle direkt. Aber selbst wenn nicht: der Engineer hat einen viel besseren Einstiegspunkt als „kannst du dir das Ticket mal anschauen".

Pattern 5: Doc Sync nach Code Änderung

Use Case: Wenn eine API Route geändert wird, soll die zugehörige Dokumentation aktualisiert werden. In der Praxis passiert das selten — die Doku driftet.

Workflow:

Post Edit Hook erkennt: API File wurde geändert Hook triggert Custom Command, der den Diff analysiert und Doc Updates vorschlägt Engineer prüft Vorschlag, akzeptiert oder ignoriert

Wichtig: Workflow soll nicht autonom die Doku ändern — das führt zu inkorrekten Docs ohne Engineer Sicht. Vorschlag ist der richtige Mittelweg.

Pattern 6: Multi File Refactoring mit Plan First Ansatz

Use Case: Refactoring, das mehrere Files betrifft (z.B. eine Funktion umbenennen, ein Interface ändern). Hier sind die meisten AI Tools schlecht — sie ändern wild, ohne den Gesamteffekt zu prüfen.

Workflow (in Claude Code mit Plan Mode):

1. Plan Modus aktivieren: Claude erstellt erst einen Plan (welche Files, welche Änderungen) 2. Engineer prüft den Plan 3. Plan Mode beenden, Änderungen ausführen 4. Type Check + Tests laufen lassen (via Post Edit Hook)

Schlüssel: Der Plan First Schritt verhindert die meisten „Refactor läuft ins Leere" Szenarien. Ein Plan Review dauert 30 Sekunden, ein zerschossenes Refactor 30 Minuten.

Pattern 7: Dependency Upgrade Triage

Use Case: Renovate/Dependabot eröffnen 20 PRs pro Woche. Manuell zu prüfen ist Zeitfresser. Ein Workflow triage t: welche sind safe (Patch Update, Tests grün), welche brauchen Engineer Sicht (Major Update, Breaking Changes).

Setup:

Workflow läuft als nightly Codex Task Iteriert über alle offenen Dependency PRs Pro PR: holt Changelog, checkt Test Suite Status, klassifiziert Generiert Triage Liste mit Empfehlung: auto merge / manual review / hold

ROI: Dependency Hygiene bleibt aktuell, ohne dass Engineers wöchentlich 2 3 Stunden in PR Prüfung versenken.

Drei Anti Patterns, die teuer werden

Anti Pattern 1: „Der Agent macht das alles autonom" Vollautomatische Workflows ohne Human in the Loop führen früher oder später zu Production Inzidenten. Sweet Spot: Agent macht Vorschläge, Engineer entscheidet an Schlüsselstellen (Code Merge, Deploy, DB Migration).

Anti Pattern 2: „Jeder Engineer hat eigene Workflows" Wenn fünf Engineers fünf unterschiedliche Custom Commands für Code Review schreiben, gewinnt niemand. Standardisierung im Team Repo (CLAUDE.md, .claude/commands/) ist die Lösung.