Für x-root Software GmbH · April 2026

Agentic AI in der
Softwareentwicklung

Von Autocomplete zu autonomen Agenten —
was das für die tägliche Arbeit bedeutet.

Yann
Agenda

Inhalt dieser Session

1
Was ist ein Agent?
Definition und Autonomie-Spektrum
2
AI-native IDEs
Cursor, Claude Code & Co. im Vergleich
3
Token-Modelle
Packages, BYOK — Vor- und Nachteile
4
Orchestrierung
Multi-Agent oder modulare Skills? Pro & Contra
5
Harness Engineering
Kontext, Constraints, GC — plus probabilistisch vs. deterministisch
6
Kontext & Doku Layer
Rules, Skills, ADRs, Retros
7
Rekursives Context Engineering
Wie Agenten sich selbst optimieren
8
Meta: Wie entstand diese Präsentation?
Live-Beispiel Agentic Workflow
Was ist ein Agent?

Das Autonomie-Spektrum

Autonomie-Spektrum: Autocomplete → Copilot → Agentic AI

Autocomplete
Schlägt das nächste Token vor. Kein Zustand, kein Kontext über Zeilen hinaus.

Copilot / Chat
Reagiert auf Anweisungen. Einzelner Turn. Du gibst an, er führt aus.

Agentic AI
Plant eigenständig, nutzt Tools, iteriert — mehrere Schritte ohne Eingriff.

AI-native IDEs

Welche Umgebungen gibt es?

Tool Typ Modelle Long-Running Agents Besonderheit
Cursor IDE GPT-4.1, o3, o4-mini, Claude Sonnet 4.5, Gemini 2.5 Pro, … ✓ Agenten-Modus Model-Wahl, Rules/Skills, Teams
Claude Code CLI Claude Opus 4.5, Sonnet 4.5 ✓ Nativ Terminal-first, CLAUDE.md
Windsurf IDE GPT-4.1, o3, o4-mini, Claude Sonnet 4.5, … ✓ Cascade-Agent IDE-Integration, Codebase-Reasoning
GitHub Copilot Workspace Web/IDE GPT-4.1, o3, o4-mini, Claude Sonnet 4.5 ✓ Task-basiert Issue → Plan → PR
Devin / SWE-Agent Autonom Proprietär / offen ✓ Vollständig Vollautonome SWE-Agenten
Augment Code IDE Plugin Eigenes Modell ✓ Agenten-Modus Enterprise, große Codebases
Gemini Code Assist IDE Plugin Gemini 2.5 Pro ✓ Agenten-Modus Workspace, IDX, Free Tier
OpenAI Codex CLI CLI GPT-4.1, o3, o4-mini ✓ Agenten-Modus AGENTS.md, lokal ausführbar

Kern-Unterschied: Alle erlauben Chat — nur Agenten-fähige Tools führen eigenständig mehrstufige Aufgaben durch, nutzen Terminal, lesen/schreiben Dateien, laufen ohne kontinuierlichen User-Input.

Long-Running Agents

Was unterscheidet sie von Chat?

Chat / Copilot

  • → Einzelner Prompt, einzelne Antwort
  • → Du gibst jeden Schritt vor
  • → Kein persistenter Zustand
  • → Keine Tool-Nutzung (oder sehr begrenzt)
  • → Fertig nach einer Antwort

Long-Running Agent

  • → Plant eigenständig und führt aus
  • → Nutzt Tools: Terminal, Dateien, Browser, APIs
  • → Iteriert: Fehler erkennen → korrigieren
  • → Delegiert an Sub-Agenten
  • → Läuft Minuten bis Stunden

Praktisch für euch: Ein Agent kann eine GitHub-Issue nehmen, den Code verstehen, Tests schreiben, die Implementierung umsetzen, CI-Fehler debuggen und einen PR öffnen — ohne dass ihr zwischendurch eingreifen müsst.

Token-Modelle

Packages kaufen oder eigene API-Keys mitbringen?

Cursor (Package)

  • ✓ Viele Modelle wählbar (GPT-4.1, o3, o4-mini, Claude Sonnet 4.5, Gemini 2.5 Pro)
  • ✓ Einfach: Pro-Plan inkl. Token-Budget
  • ✓ Team-Features, Regeln, Skills
  • ✓ BYOK alternativ möglich
  • ✗ Tokens laufen aus (Fast Request Limit)
  • ✗ Kosten können skalieren

Claude Code (Max-Plan)

  • ✓ Anthropic-Modelle tief integriert
  • ✓ Claude Opus 4.5 und Sonnet 4.5 nativ
  • ✓ Terminal-first, CLAUDE.md-System
  • ✓ Max-Plan: $100/Mo, großzügige Limits
  • ✗ Primär auf Anthropic festgelegt
  • ✗ CLI, kein vollwertiges IDE-Erlebnis

BYOK (Bring Your Own Key)

  • ✓ Volle Kostentransparenz
  • ✓ Kein Vendor-Lock-in
  • ✓ Neuste Modelle sofort verfügbar
  • ✗ Abrechnungsrisiko bei unkontrollierter Nutzung
  • ✗ Key-Management-Aufwand
  • ✗ Keine gebündelten Team-Features

Empfehlung für Einstieg: Cursor Pro oder Claude Max-Plan — sofort produktiv, überschaubare Kosten, BYOK als Option wenn ihr Kontrolle wollt.

Agentenorchestrierung

Das Team-Lead-Muster

Team Lead delegiert an Rollen-Agenten

Team Lead: Orchestriert, delegiert, konsolidiert — macht KEINEN operativen Code selbst.

Parallelisierung: Unabhängige Aufgaben laufen gleichzeitig in separaten Agenten-Threads.

Rollen: BackendEng, FrontendEng, Architect, QA, SecurityExpert — jeder hat seinen Fokus.

Orchestrierung

Team-Orchestrierung in der Praxis: Pro und Contra

Vorteile

  • ✓ Klare Zuständigkeiten — Review ist nie gleich Implementierung
  • ✓ Parallelisierung: unabhängige Aufgaben laufen gleichzeitig
  • ✓ Governance eingebaut (AgileCoach als Watchdog, SecurityExpert, QA)
  • ✓ Skaliert bei großen Projekten mit vielen Moving Parts

Nachteile & Learnings

  • ✗ Hoher Overhead — Delegation-Zeremonie, Kontextwechsel zwischen Agenten
  • ✗ Jeder Sub-Agent braucht eigenen Kontext → Token-Kosten multiplizieren sich
  • ✗ Für kleine/mittlere Tasks Over-Engineering
  • ✗ Rollenexplosion: 9 Rollen definiert, selten mehr als 2–3 gleichzeitig gebraucht
  • ✗ Governance-Rules (alwaysApply) belasten jeden Turn — auch wenn kein Team gebraucht wird

Konsequenz: Team-Orchestrierung jetzt on-demand — nur noch wenn explizit angefordert. Für den Alltag genügt ein fähiger Agent mit dem richtigen Kontext.

Build Skills, not Agents

Anthropics Leitspruch vs. Multi-Agent-Orchester

Der Skills-Ansatz

  • Ein fähiger Agent + modulare Skills statt starrer Rollenverteilung
  • Skills = wiederverwendbare, komponierbare Fähigkeiten (SKILL.md)
  • Agent lädt, was er braucht — on demand, kein alwaysApply-Overhead
  • Skills evolvieren unabhängig vom Agenten — keine Rollenregeln nötig
  • Weniger Overhead, gleiche (oder bessere) Qualität

Multi-Agent-Orchester

Team von 9 Rollen, hoher Zeremonie-Aufwand

Stark bei komplexer Parallelisierung in Grossprojekten

Skill-basierter Agent

Ein Agent + Skills-Bibliothek, minimal Overhead

Anthropic-Empfehlung — stark bei Solo/Kleinteam-Arbeit

In der Praxis: Skills als Default — Team-Orchestrierung als Spezialfall für komplexe Parallelisierung, wenn sie wirklich gebraucht wird.

Harness Engineering

Das Harness: Agenten in geordneten Bahnen

1 — Context Engineering

Wissensbasis im Codebase: Rules, Skills, ADRs, Retros, Co-Evolution. Was der Agent wissen muss — maschinenlesbar, versioniert.

2 — Architektonische Constraints

Deterministische Linter, Strukturtests, Design-Tokens als SSoT. Nicht nur das LLM prüft — auch der Build prüft.

3 — Garbage Collection

Periodische Agenten suchen Inkonsistenzen, Drift und Constraint-Verletzungen. Entropie wird aktiv bekämpft — nicht erst bei nächstem Bug.

Warum "Harness"?

  • Agenten sind mächtig, aber ohne Führung unzuverlässig
  • Ein Harness gibt dem Agenten den Rahmen, nicht die Freiheit zu entscheiden, was Architektur ist
  • "Garbage in, garbage out": Harness = systematisch guten Input sicherstellen
  • Iterativ: Wenn der Agent kämpft → Harness verbessern, nicht Modell wechseln
  • OpenAIs Codex-Team: "5 Monate, 1 Mio. Zeilen Code — kein manuell getippter Code"

Quelle: Fowler/Thoughtworks & OpenAI Codex-Team — martinfowler.com/articles/exploring-gen-ai/harness-engineering.html

Probabilistisch vs. Deterministisch

Zwei Prinzipien — ein Harness verbindet sie

Probabilistisch

LLM-Seite

  • Gleiche Eingabe → potenziell andere Ausgabe
  • Stärke: Kreative Lösungen, Kontext-Sensitivität, Sprachverstehen
  • Schwäche: Nicht reproduzierbar, schwer testbar, Halluzination-Risiko
  • Einsatz: Planung, Code-Generierung, Interpretation, Reasoning

Deterministisch

Workflow-Seite

  • Gleiche Eingabe → immer gleiche Ausgabe
  • Stärke: 100 % reproduzierbar, automatisch testbar, auditierbar
  • Schwäche: Unflexibel bei unvorhergesehenen Inputs
  • Einsatz: Validierung, Routing, State Management, Retry-Logik, Tests

Das Harness kombiniert beides: LLM entscheidet — deterministischer Rahmen kontrolliert, validiert und korrigiert. Keins allein ist ausreichend.

Workflow-Engines

Deterministischer Rahmen um probabilistische Schritte

Tool Typ Einsatz Determinismus Besonderheit
LangGraph Graph-Engine LLM-Agenten-Flows Hoch (Graph-Routing) Cycles, State, bedingte Kanten
Temporal Durable Execution Long-running Workflows Sehr hoch (Replay) Fehlertoleranz, History-Replay
Prefect / Airflow Pipeline Batch, Data-Engineering Hoch Scheduling, Retries, Monitoring
CrewAI / AutoGen Multi-Agent Rollen, Coding, Research Mittel Abstraktion hoch, Microsoft-Ökosystem
n8n / Zapier Low-Code Integrationen, Trigger Hoch Visuell, kein Code nötig
Dify / Flowise LLM-Pipeline RAG, Chatbots Mittel No-Code, LLM-first, visuelle Flows

Faustregel: Je höher die Fehlerkosten, desto mehr deterministischen Rahmen braucht ihr. Temporal für Business-kritische Flows — LangGraph für flexible Agenten-Pipelines.

Kontext-Layer

Was steckt in .cursor/?

Kontext-Layer Struktur

Rules: alwaysApply (jeder Turn) oder Glob-triggered (nur bei relevanten Dateien). Token-Budget bewusst einsetzen.

Skills: On-Demand geladen. Domänen-Wissen als Checklisten — Agent liest sie wenn nötig, nicht immer.

  • context/-Konvention: maschinenlesbarer Zustand (Ledgers, Register) getrennt von menschlicher Doku in docs/.
  • context-compression: mehrstufige Pipeline bei knappem Kontext-Budget; prompt-cache-stability: stabile Prompt-Struktur für bessere Cache-Hits.
  • output-discipline: Modi wie standard / compact / minimal — Token-Budget pro Session-Typ.
Kontext-Layer · Claude Code

Und in CLAUDE.md / .claude/?

Claude Code Kontext-Layer Struktur

CLAUDE.md & .claude/: CLAUDE.md wird bei jedem Turn gelesen (Projekt-Gedächtnis); .claude/ hält Skills und Commands pro Projekt.

Skills & Commands: On-Demand geladen (Skill-Beschreibung matcht Task); Slash-Commands als wiederverwendbare Playbooks.

  • MCP-Server: Tools und Datenquellen pro Projekt via .mcp.json — Browser, Filesystem, projekt-eigene APIs.
  • Hooks: .claude/hooks/ — Pre-/PostToolUse, SessionStart, Stop — Guardrails und Automationen am selben Ort wie Rules.
  • Gleiche Idee wie Cursor: persistenter Projekt-Kontext plus on-demand geladenes Domänen-Wissen; der Agent trägt Kontext über Sessions, nicht der Mensch.
Doku Layer

Warum Dokumente Agenten besser machen

ADRs — Architecture Decision Records

  • → "Warum haben wir das so gebaut?"
  • → Agent trifft keine veralteten Entscheidungen erneut
  • → Kontext für neue Team-Mitglieder (menschlich + KI)
ADR-013: Co-Evolution
ADR-018: Drei-Schichten-Architektur
ADR-020: CI-Strategie

Retros — Was wurde gelernt?

  • → Append-only Log nach jeder Session
  • → "Was lief gut / schlecht / welche Maßnahmen?"
  • → Fließt in Session-Learnings → verbessert Rules

Co-Evolution

  • → Doku ist Co-Produkt jeder Änderung
  • → Doku wächst kontinuierlich mit dem Code
  • → Agent pflegt Doku automatisch mit

Open Loops

  • → Operatives Backlog: offene Punkte sessions-übergreifend
  • → Verknüpfung zu Strategie (/evolve, Priorisierung)
  • → Ergänzt ADRs und Retros um die laufende Arbeit

Praktisch: Ein Agent der ADRs kennt, wiederholt keine alten Fehler. Ein Agent der Retros und Open Loops liest, wendet Lerneffekte und Backlog-Priorität an — ohne dass der Entwickler es erklären muss.

Kontext & Doku Layer

Das Zusammenspiel: bidirektional & automatisch

Kontext-Layer und Doku Layer im Zusammenspiel

Kontext → Doku: Rules erzwingen Co-Evolution-Checkliste. Agent pflegt ADRs, Retros, Vault automatisch mit.

Doku → Kontext: ADRs und Retros fließen als Skills und Session-Learnings zurück in den Kontext-Layer.

Rekursives Context Engineering

Agenten optimieren ihren eigenen Kontext

Rekursiver Optimierungskreislauf des Kontext-Layers

Schlüsselidee: Audit-Skills laufen periodisch via CI (Cron) oder on-demand. Sie analysieren den Kontext-Layer, finden Token-Verschwendung, Overlap und tote Configs — und erzeugen Verbesserungs-PRs.

  • LLM Recovery Ladder: gestufte Wiederherstellung nach Modell- oder Tool-Fehlern (Fallback-Kette).
  • agent-peer-review-gate: zweiter Agent im frischen Kontext prüft die Ausgabe des ersten (Quality Gate).
Harness Engineering

Das Harness im Überblick — und was euch das angeht

Was ihr gerade gesehen habt — ist bereits ein Harness

1

Context Engineering

Rules, Skills, ADRs, Retros, Co-Evolution, Session-Learnings

2

Architektonische Constraints

Design Tokens als SSoT, Cross-Impact-Manifest, Terminologie-Guards, Hooks

3

Garbage Collection

Audit-Skills, CI-Cron (doc-health), Freshness-Checks, Drift-Erkennung

4

Strategische Steuerung

Strategist KB → Evolution-Graph (ROI) → /evolve-all → Execution & Commit

chacha ist ein Harness. Iterativ gewachsen — Folie für Folie.

Fowlers Fragen an euch

  • Was ist euer Harness heute? Pre-Commit-Hook? Custom Linter?
  • Welche architektonischen Constraints wollt ihr erzwingen?
  • Könnten Service-Templates zu Harness-Templates werden?
  • Welche eurer Apps würdet ihr gerne rückwirkend harnessen?

Einstieg: Wer heute mit Rules + ADRs anfängt, hat schon ein Minimal-Harness — ohne 5 Monate Aufwand.

Live-Beispiel

chacha: ein echter Agentic-AI-Workflow

Der Kreislauf in der Praxis

1 Rule doc-co-evolution.mdc läuft bei jeder Session
2 Agent macht ADR → schreibt Entscheidung nach docs/decisions/
3 Retro in docs/audits/: Was lief gut/schlecht?
4 Erkenntnisse → .cursor/session-learnings.md
5 Nächste Session startet mit besserem Kontext → bessere Ergebnisse
6 /evolve-all: Graph-ROI priorisiert → Grind bis die Queue leer ist → Commit

Metrik-Typen & Transparenz (chacha)

  • Token-Einsparung: Glob-Rules vs. alwaysApply (Messgröße: Tokens/Turn)
  • ADR-Anzahl und Retro-Anzahl als laufende Bestandsmetriken (wachsen mit dem Projekt)
  • Open-Loops-Register: operative Backlog-Tiefe (OL-IDs, Status)
  • CI-Cron plus Grind-Kommandos: doc-health, Freshness, /evolve-all
  • Token Analytics Dashboard: Kosten- und Nutzungstransparenz pro Modell/Session
  • Metrik-Drift: Abgleich Vault-Index vs. Ist-Dokumentation (Alarm bei Divergenz)

Für euch relevant ist weniger das Produkt chacha — und vielmehr die Art der Arbeit, die dabei möglich wird.

Meta

Diese Präsentation: selbst mit Agentic AI erstellt

Der Workflow

Team Lead (Cursor) → liest Plan, delegiert parallel an 3 Agenten
↓
Agent A
Design System CSS
Agent B
Kontext/Doku Layer
Agent C
SVG-Diagramme
↓
Agent D → HTML-Präsentation mit allen 21 Folien
↓
Review-Agent → Qualitätssicherung

Paradigmen die dabei galten

  • Delegation Team Lead = nur Orchestrierung, null eigener Code
  • Kontext Design Tokens, SVG-Skills, Stil-Rules als Steuerung
  • Parallelisierung 3 unabhängige Agenten gleichzeitig
  • Co-Evolution Doku-Layer (ADRs) parallel zur Präsentation erstellt
  • Werkzeug-Nutzung SVG-Generator aus chacha wiederverwendet

Die Präsentation ist ihr eigenes bestes Beispiel: In ~1h von Idee bis fertigem Output — mit Agenten als Co-Autoren.

Takeaways

Was mitzunehmen ist

  • 01 Agenten wirken als autonome Mitarbeiter: planen, führen mehrstufige Aufgaben aus, nutzen Tools, halten Kontext über viele Schritte.
  • 02 Context Engineering ist die Kerndisziplin — nicht Prompt Engineering.
  • 03 ADRs und Retros lohnen sich: sie machen Agenten produktiver.
  • 04 Der Kontext-Layer optimiert sich selbst — Agenten verbessern ihre eigenen Rules.
  • 05 Cursor Pro oder Claude Max: Einfach anfangen, nicht perfektionieren.
Fragen?