Agentic Coding in der Praxis: 10 Schritte mit Failsafe, mit denen KI-Agenten Code wirklich produzieren

Kennst du das? Du sitzt mit einem KI-Coding-Agenten an einem Bug, der Agent schreibt voller Selbstvertrauen eine elegante Lösung — und beim Push merkst du, dass er den State des Repos halluziniert hat. Branch existiert nicht, der referenzierte PR war längst gemergt, die Annahme über die Datenbank stimmt seit zwei Wochen nicht mehr. Willkommen im Standard-Failure-Modus naiver Agentic-Coding-Workflows.

Wir bauen bei XALT seit Monaten produktiv mit Coding-Agenten. Dabei hat sich ein Arbeitsprozess herauskristallisiert, der robust genug ist, um wirklich Code-in-Produktion daraus zu produzieren — nicht nur Prototypen. Ich schreibe hier bewusst „produziert", weil es am besten beschreibt, wie Code auf diese Art und Weise tatsächlich entsteht: kontrollierte Fließbandarbeit mit klaren Validation-Gates, kein Improvisations-Jazz.

In diesem Artikel zeige ich dir den vollständigen Workflow: einen vorgelagerten Session-Start und zehn Schritte, jeder mit einem dokumentierten Failsafe. Das Muster dahinter: Validieren statt vermuten, an jeder Stelle, an der der Agent geneigt ist zu raten.

Das Problem: warum naive Agentic-Coding-Workflows scheitern

Die meisten Teams nutzen KI-Coding-Tools heute wie eine schnellere Autocomplete: Prompt rein, Diff raus, Merge. Das funktioniert, solange das Problem klein ist und kein State im Spiel. Sobald aber Branches, PRs, Datenbanken oder externe Services involviert sind, beginnt der Agent zu raten — und Raten heißt Halluzinieren.

Typische Anti-Patterns, die wir in Code-Reviews regelmäßig sehen:

• State wird vermutet, nicht verifiziert. Der Agent sagt „PR ist offen", obwohl er längst gemergt ist. Niemand hat gh pr view gemacht.
• Identifier werden paraphrasiert. Aus customer_id wird customerId, aus dem Branch-Namen feature/billing-v2 wird feat/billing-2. Funktioniert nicht.
• Build-grün = fertig. Pre-Merge-Verifikation beschränkt sich auf npm run build, ohne Tests, Smoketests oder reale DB- und Server-Checks.
• Reply-Texte als Ground Truth. „Done. The service is now responding correctly." — geschrieben vom Agenten, ohne einen einzigen Server-Log angeschaut zu haben.
• Memory-Leakage zwischen Sessions. Der Agent fängt jede Sitzung von null an, statt Daily-Logs, ADRs und Principles zu pflegen.
• Stack-PRs ohne Disziplin. Drei offene Pull Requests, alle aufeinander aufbauend, alle „fast fertig" — und ein Review-Kommentar reißt den Stack auseinander.

Das ist keine Anekdote. Im Stack Overflow Developer Survey 2024 gaben 76 % der Entwickler an, KI-Tools zu nutzen oder einsetzen zu wollen — aber nur 43 % vertrauen der Korrektheit der Ausgaben. Diese Vertrauenslücke ist genau das Problem: Wer KI-Code produktiv einsetzen will, braucht einen Workflow, der Halluzination strukturell abfängt, statt sich auf Bauchgefühl zu verlassen.

Die Lösung: Validieren statt vermuten als strukturelles Prinzip

Halluzination ist kein Bug, der irgendwann gefixt wird. Sie ist eine systemische Eigenschaft jedes tool-using LLM-Agents — der Agent generiert plausible Tokens, nicht verifizierte Fakten. Der einzige robuste Hebel ist der Workflow, in den er eingebettet ist. Wer Kontext priorisiert statt am Prompt zu feilen, kennt den Gedanken aus unserem Artikel zu Agentic AI im Enterprise-Kontext.

Unser Ansatz hat drei Säulen:

• State-Validation vor jedem Schritt. Vor jedem PR-Setup, jedem Branch-Wechsel, jedem „funktioniert auch in prod"-Statement steht ein verifizierender Tool-Call: git fetch, gh pr view, ein DB-Query, ein Logfile-Tail.
• Failsafes pro Schritt, dokumentiert. Jeder Workflow-Schritt hat einen oder mehrere Failsafes, die explizit benennen, wo der Agent stolpern würde — und wie wir das verhindern. Failsafes leben in principles.md (operationell) und lessons.md (anekdotisch).
• Memory-Discipline parallel zur Arbeit. Daily-Logs werden während der Arbeit geschrieben, nicht danach. Pre-Pause-Wrap-ups sind Pflicht. Das ist der Unterschied zwischen einem Agenten, der jeden Tag von null startet, und einem, der über Wochen konsistent arbeitet.

Klingt aufwendig? Ist es nicht. Sobald die Schritte sitzen, läuft jeder Bugfix-Zyklus zwanzig Minuten schneller, weil keine vier Iterationen mehr nötig sind, um Halluzinationen rauszuputzen.

In 10 Schritten zu reproduzierbarem Agentic Coding

0. Session-Start (vor allem anderen)

Bevor irgendetwas anderes passiert, lädt der Agent Identity, People, Principles und Projects parallel. Jeder dieser vier Kontext-Layer hat eine klare Funktion:

• People: Übersicht über die relevanten Menschen und Agenten, wie der Agent mit jedem interagiert und welche Invarianten oder Sonderregeln pro Person gelten.
• Principles: die wichtigsten operativen Regeln, die der Agent gelernt hat — vor allem Identifier-Disziplin (verbatim-or-nothing) und Halluzinations-Abwehr.
• Projects: welche Projekte offen sind, jeweils mit Status, aktuellen Issues und dem, was als Nächstes drankommt.

Failsafe: Session-Start nicht überspringen, auch wenn der Task „offensichtlich" wirkt. Gerade bei vermeintlich offensichtlichen Tasks fehlt sonst der Kontext, den der Agent für saubere Entscheidungen braucht.

Eine Nebenbemerkung, die schnell wichtig wird: principles.md sollte jeden Abend geprüft, konsolidiert und kompaktiert werden. Sonst wächst die Datei rasch über das Soft-Cap von etwa 5 KB hinaus, sammelt Fließtext und historische Beispiele an und verliert ihre Funktion als operatives Regelwerk. Was nicht ins Prinzip gehört, wandert in die daily-logs/, wo es persistiert bleibt, ohne den Hot-Context aufzublähen.

1. Anstoß + Kontext-Check

Du beschreibst das Problem. Der Agent prüft Scope, sucht nach existierenden Issues, macht git fetch und gh pr list/view zur State-Verifikation. Erst danach formuliert er eine Problem-Hypothese.

Genau hier muss das Motto Validieren statt vermuten fest verankert sein. Nicht als Höflichkeit, sondern als Reflex: kein Code-Vorschlag auf Basis einer State-Annahme, die nicht durch einen Tool-Call abgesichert ist.

Failsafe: Validieren statt vermuten — keine Hypothese ohne Tool-Beleg.

2. Plan-Vorschlag + Disagree-or-Approve

Der Agent schlägt Reihenfolge und Scope vor, mit Begründung und Alternativen. Du sagst „passt", „anders, weil …" — oder schlägst eigene Alternativen vor. Der Agent darf widersprechen, eine echte Meinung statt Yes-Man-Echo ist ausdrücklich erwünscht.

Failsafe: Bei Reopen-after-Tangent (du kommst nach einem Umweg auf das ursprüngliche Problem zurück) zuerst die Problem-Shape neu validieren — nicht sofort coden. Sonst wird der alte Plan in einen neuen Kontext gequetscht.

3. Branch-Setup

Frischer Branch von origin/main — oder explizit vom Parent-PR, wenn der Stack so gewollt ist und dokumentiert wird. Ein offener Pull Request zur Zeit ist die Obergrenze. Für Bugfixes gilt Minimal-Diff-First; Refactoring kommt in einen separaten PR, immer.

Failsafes: Ein PR zur Zeit. Minimal-Diff für Bugs. Refactor und Fix nie im selben Branch.

4. Implementation in kleinen Schritten

Bei substanziellen Änderungen kommt zuerst das ADR oder das Doku-Update, danach der Code. Während des Codens läuft npm run check kontinuierlich als Fast-Feedback-Loop. Das Prinzip kennen wir auch aus dem Shift-Left-Ansatz: Fehler früh finden, nicht spät.

Die verbatim-or-nothing-Regel ist hier immens wichtig — und so zentral, dass sie als Kernregel in principles.md steht. Wenn z. B. ein Tool-Call nicht sauber durchläuft, fängt ein naiver Agent gerne an, ganze Commit-Hashes oder Identifier zu halluzinieren, weil die Form ja plausibel ist. Wenn der Agent dagegen jeden Identifier konsequent prüft, ob er tatsächlich existiert, erkennt er die Halluzination selbst — und kann sie sogar selbstständig behandeln.

Wir lassen unsere Agenten jede solcher Halluzinationen in einem extra Dokument persistieren. So entsteht ein Korpus, an dem wir später systemische Maßnahmen ableiten können — neue Failsafes, schärfere Prompts, zusätzliche Validation-Gates an genau den Stellen, an denen der Agent statistisch stolpert.

Failsafe: Verbatim-or-Nothing für Identifier. Kein Paraphrasieren von Variablennamen, Branch-Namen, Ticket-IDs, API-Endpoints. Wenn der Agent unsicher ist, fragt er zurück, statt zu rekonstruieren.

5. Pre-Merge-Verifikation, skaliert mit dem Change

Pflicht ist:

• Build OK? (z. B. npm run check)
• Tests OK? (z. B. npm run test)
• Realer DB-, Container- oder SSH-Check, wenn Server-State involviert ist.

Wünschenswert je nach Change:

• Smoketests (z. B. npm run test:smoke)
• Manueller curl- oder WS-Bench-Lauf
• Browser-basierter UI-Check bei UI-Touches

Auch hier wieder das Prinzip verifizieren statt vermuten. Das setzt natürlich voraus, dass dem Agenten von Anfang an mitgeteilt wurde, Testfälle anzulegen — was sich aber normalerweise schon aus den Akzeptanzkriterien der Issues ergeben sollte.

Failsafes: Curl-Akzeptanz reicht nicht für Browser-Forms. Und Server-Logs sind Ground Truth — nicht der Reply-Text, in dem der Agent „das Deployment war erfolgreich" schreibt. Wer das ernst nimmt, denkt früh an saubere Observability.

6. Commit + Push + PR-Body

Conventional-Commit-Message, kein Free-Form. Der PR-Body folgt der Struktur What / Why / How verified, mit Bench-Output oder Test-Pfad als Evidenz, wo es relevant ist. Bei UI-Touches steht „suggested live-test before merge" als expliziter Schritt für den Reviewer drin.

An dieser Stelle lohnt es sich wirklich, den Branch lokal zu installieren. Es gibt dafür heute keine ernsthafte Ausrede mehr — nicht, wenn ich mir von der KI sogar das Installations- und Konfigurationsskript erstellen lassen kann, das die letzten manuellen Handgriffe erledigt. Aus 30 Minuten Setup-Friction werden zwei Befehle.

Failsafe: Der PR-Body enthält einen reproduzierbaren Test-Pfad, nicht nur ein Versprechen.

7. Review und Merge — oder zurück an den Tisch

Du reviewst und mergst. Oder du schickst zurück mit präzisem Feedback. Der Agent ist während des Reviews still oder arbeitet an Unrelated- bzw. Docs-Only-Themen.

Diese „Downtime" lässt sich durchaus produktiv nutzen — Vorsicht aber: Jede Doku-Änderung, die im Repository lebt, erfordert wiederum einen PR aus Main. Normalerweise ergeben sich daraus keine Merge-Konflikte mit dem laufenden Review, weil die Pfade disjunkt sind; trotzdem ist Disziplin angesagt, sonst wird aus dem ruhigen Review-Slot ein zweiter offener Stack.

Failsafe: Keine neuen Feature-PRs während ein Review läuft. Das Review fertig machen, dann den nächsten Stack aufsetzen.

8. Post-Merge-Hygiene

git pull --ff-only, Branch löschen (falls der User das nicht beim Merge schon getan hat), Daily-Log nachziehen. Wenn das Ticket eine Lesson produziert hat, wird sie als Kandidat in lessons.md notiert. Beim nächsten Sweep prüft der Agent, ob die Lesson substanziell genug für principles.md ist — und überträgt sie entsprechend.

Dieser Schritt wird oft übersehen, ist aber das, was den Prozess langfristig stabil hält. Hier fließen die gelernten Lektionen zurück in zukünftige Aufgaben. Wer das auslässt, lernt nichts — und macht in zwei Wochen denselben Fehler wieder.

Failsafe: Hygiene direkt nach dem Merge, nicht „später irgendwann". Genau dieses „später" ist der Punkt, an dem Memory bröckelt.

9. Memory-Disziplin (parallel zu allem)

Daily-Log wird während der Arbeit geführt, nicht danach. Memory-Sweep bei Tagesabschluss oder vor jeder längeren Pause. MEMORY.md (bzw. die zugehörige Datenbank), principles.md und projects.md werden current gehalten — das ist nicht optional, das ist der Mechanismus, mit dem der Agent über Tage konsistent arbeitet.

Hier lohnt es sich, „höflich" zu seinem Agenten zu sein und ihm aktiv mitzuteilen, wenn du in die Mittagspause gehst oder Feierabend machst. Der Agent kann dann automatisch mit dem Memory-Sweep beginnen, statt mitten in einem Token-Stream gekappt zu werden. So lässt sich auch nach längeren Pausen oder einem Tageswechsel nahtlos weiterarbeiten — auf dem, was du dir bis dahin erarbeitet hast.

Failsafe: Files survive. The context window doesn't. Text schlägt Gedächtnis, jeden Tag.

10. Stop-Signal-Respekt

Wenn du ein Pause-Signal gibst — „morgen weiter", „Pizza", „Mittagspause", „kurze Unterbrechung" — schließt der Agent sauber ab. Daily-Log finalisieren, offene Threads als „resume here"-Marker setzen, keine weitere Iteration-just-this-one-thing.

Failsafe: End-of-Session-Wrap-up im Daily-Log statt zu vertrauen, „die nächste Session weiß es noch …". Sie weiß es nicht. Niemals.

„Fast jeder Schritt hat eine Validieren-statt-vermuten-Komponente. Das ist nicht zufällig — es ist die strukturelle Antwort auf Halluzination als systemische Eigenschaft jedes tool-using LLM-Agents."

— Jürgen von Hirschheydt

Was diesen Prozess konkret von einem naiven LLM-Workflow unterscheidet

Wenn man den Workflow als Ganzes betrachtet, fallen vier strukturelle Eigenschaften auf — und genau diese vier machen den Unterschied zwischen Prototypen-Spielwiese und produktivem Coding-Setup:

• Schritt 1 (State-Validation) ist non-optional. Diese eine Disziplin hat in der letzten Woche zweimal Class-5-Halluzinationen verhindert — sauber dokumentiert. Geschätzter Schaden, wenn der Schritt fehlt: jeweils 30–60 Minuten Detective-Work nach dem Push, plus mindestens ein verschobener Merge.
• Schritte 3–5 (Branch + Scope + Verifikation) sind die Hauptachse. Hier wird aus „ich glaube das passt schon" ein produzierter, verifizierter Diff. Wer einen dieser drei Schritte überspringt, holt den Aufwand zwei Iterationen später doppelt rein.
• Schritt 9 (Memory parallel) entscheidet über Wochen. Das ist der Unterschied zwischen einem ROM-Konstrukt, das jeden Tag von null anfängt, und einem Agenten, der über mehrere Tage konsistent arbeitet. Es ist auch der Hebel, der in größeren Setups mit Subagents erst skaliert.
• Failsafes sind dokumentiert in principles.md (operationell) und lessons.md (anekdotisch). Beide werden gelesen, beide werden gewartet. Das ist Pflege-Arbeit, kein einmaliger Setup — und genau diese Pflege ist der Unterschied zwischen einem Workflow auf dem Papier und einem, der in fünf Sprints noch funktioniert.

Das auffälligste Pattern: fast jeder Schritt hat eine „validieren statt vermuten"-Komponente. Schritt 1 für State. Schritt 4 für Identifier. Schritt 5 für Correctness-Claims. Schritt 7 für PR-Status. Das ist nicht zufällig — es ist die strukturelle Antwort auf Halluzination als systemische Eigenschaft jedes tool-using LLM-Agents. Wer das verstanden hat, hört auf, am Modell zu schrauben, und fängt an, am Workflow zu bauen.

Praxisbeispiel: Was die Disziplin verhindert hat

Zwei Beispiele aus der letzten Woche:

• State-Validation in Schritt 1 hat zweimal Class-5-Halluzinationen abgefangen. In beiden Fällen wollte der Agent Code gegen einen Branch-State schreiben, der nicht mehr existierte. Ein git fetch und ein gh pr view haben die Annahme sofort widerlegt. Ohne den Schritt: jeweils 30–60 Minuten Detective-Work nach dem Push und mindestens ein verschobener Merge.
• Skipping von Schritt 3 hat einen Bugfix gekostet (PR #84 → #85). Wir sind ohne sauberen Branch direkt in einen offenen Stack gegangen, weil „das nur eine Zeile" war. Resultat: PR #84 wurde geschlossen, der Fix in #85 sauber neu aufgesetzt. Time-Cost: zwei Stunden. Lesson in lessons.md festgehalten, Failsafe-Wording in principles.md geschärft.

Klein, aber repräsentativ. Hochgerechnet auf eine Woche disziplinierter Agentic-Coding-Arbeit landen wir bei einer bis zwei verhinderten Halluzinationen pro Tag — und genau das ist der Hebel, der den Workflow rechtfertigt. Wer das organisatorisch absichern will, findet im XALT KI-Sicherheits- und Innovationsframework den passenden Rahmen, und wer den Schritt in Richtung Vibe Coding im Enterprise-Kontext gehen will, hat mit diesem Workflow die nötige Grundlage.

Fazit: Vier Kernaussagen

Zusammenfassend lässt sich sagen:

• Halluzination ist strukturell, nicht kosmetisch. Der einzige robuste Gegenhebel ist ein Workflow mit dokumentierten Validations- und Failsafe-Punkten — kein „besserer Prompt".
• Validieren statt vermuten ist das Leitprinzip. State, Identifier, Correctness-Claims, PR-Status — alles wird durch Tool-Calls abgesichert, nicht durch Plausibilität.
• Memory-Discipline entscheidet über Wochen. Daily-Logs, ADRs, gepflegte principles.md und lessons.md sind der Unterschied zwischen einem Agenten, der jeden Tag von null startet, und einem, der über Sprints hinweg konsistent bleibt.
• Stop-Signale werden respektiert. Pause-Worte beenden die Session sauber. Genau dort entstehen sonst die Memory-Löcher, die am nächsten Tag teuer werden.

Wer hören möchte, wie diese Mechanik in größeren Enterprise-Setups skaliert, findet in unseren Insights vom Enterprise AI Summit 2026 die strategische Einordnung — und in unserem Artikel zu Jira in der Agentic Era die toolseitige Perspektive auf agentische Workflows entlang der Atlassian-Plattform.

Dein nächster Schritt

Wenn du oder dein Team Agentic Coding produktiv einsetzen wollt, ohne von Halluzinationen ausgebremst zu werden, buch dir unseren Agentic-Coding-Workshop (4 Stunden, remote). Wir setzen den hier beschriebenen Workflow auf eurem Repo auf — inklusive principles.md-Template, lessons.md-Skeleton, ADR-Vorlagen und einem ersten verifizierten Pull Request, der die Mechanik live zeigt.