Prinzipien · Stand Juni 2026
Agentic Coding: Effektiv entwickeln jenseits von Vibe Coding.
Einen Coding-Agent zu installieren ist einfach. Ihn effektiv zu nutzen ist schwer. Diese Seite sammelt die Prinzipien, die aus einem Agent-Spielzeug ein Produktivitäts-Werkzeug machen — unabhängig davon welche Harness du verwendest.
“Vibe Coding lässt dich schnell prototypen. Agentic Coding lässt dich Produkte bauen.”
Spec-Driven Development
Die Spezifikation ist das Artefakt, nicht der Code. Bevor ein Agent eine Zeile schreibt, muss klar sein was gebaut wird — und wie der Erfolg gemessen wird. Der Prompt ist nicht die Spec. Die Spec ist ein separates, versioniertes Dokument.
In der Praxis
Schreibe die Spec in einer eigenen Datei (SPEC.md). Lass den Agent daraus Issues/PRs ableiten. Prüfe die Spec bevor du Code generieren lässt.
Eval-First, Code Second
Tests sind keine nachträgliche Qualitätssicherung — sie definieren was "fertig" bedeutet. Ohne Eval-Rahmen kann kein Agent wissen wann er gut genug gearbeitet hat. Das gilt für Unit-Tests, Integrationstests und vor allem für Assertion-basierte Evaluierungen.
In der Praxis
Schreibe vor dem ersten Code: Tests für den Erfolgsfall, Tests für die Ränder, Tests für Fehlerfälle. Der Agent soll bestehende Tests vor Änderungen grün sehen und nach Änderungen alle Tests bestanden haben.
Context Engineering
Die Qualität deines Outputs wird durch die Qualität deines Inputs begrenzt. Garbage in, garbage out gilt auch für Coding-Agents. Der Kontext ist nicht nur der aktuelle Prompt — es sind Projektstruktur, Architektur-Dokumente, Coding-Guidelines, bestehende Patterns und Fehlerhistorie.
In der Praxis
Baue einen systematischen Kontext: Projekt-README, ARCHITECTURE.md, CODING_GUIDELINES.md, CHANGELOG.md. Der Agent soll bei Start wissen wo er ist und was er beachten muss. Nutze MCP für dynamischen Kontextzugriff.
Write Control, Read Autonomy
Ein Agent sollte lesen können was er braucht — aber schreiben nur was er darf. Write Control bedeutet: klare Grenzen welche Dateien geändert werden dürfen, Review vor Commit, keine unkontrollierten Side-Effects. Read Autonomy bedeutet: der Agent kann Architektur-Dokumente, bestehenden Code, Fehlerlogs und Doku lesen um fundierte Entscheidungen zu treffen.
In der Praxis
Konfiguriere Write Control pro Projekt: Welche Dateien/Ordner sind tabu? Wo ist Review nötig? Nutze MCP-Permissions und Harness-Governance-Features (Cline, Claude Code). Der Agent soll alles lesen können — aber nur das schreiben was du freigibst.
Plan, Work, Review, Compound
Der Vibe-Coding-Fehler: Einem Agent einen großen Prompt geben und hoffen. Der richtige Weg: Planen → Arbeiten → Prüfen → Compound. Jeder Zyklus produziert ein Zwischenergebnis, das reviewt wird bevor es weitergeht. Compounding heißt: Erkenntnisse aus dem Zyklus werden für den nächsten Zyklus nutzbar gemacht.
In der Praxis
Starte mit Plan (der Agent schreibt einen Plan → du reviewst). Dann Arbeit (der Agent implementiert). Dann Review (Tests, Code-Review). Dann Compound (Was hat der Agent gelernt? Was steht im Log?). Für komplexe Tasks: Subagenten parallel arbeiten lassen.
Parallelisierung & Orchestrierung
Ein einzelner Agent ist ein Assistent. Mehrere Agents orchestriert sind ein Team. Die Kunst ist nicht jeden Agent einzeln zu optimieren, sondern die Arbeit so aufzuteilen dass Agents parallel arbeiten können ohne sich zu stören. Das erfordert klare Schnittstellen, geteilte Konventionen und einen Orchestrator der den Überblick behält.
In der Praxis
Aufteilung nach Domänen (Frontend-Agent, Backend-Agent, Test-Agent) oder nach Arbeitsschritten (Recherche-Agent, Implementierungs-Agent, Review-Agent). Nutze Pi-Subagents, LangGraph oder CrewAI für Orchestrierung. Wichtig: Ein menschlicher Reviewer bleibt im Loop.
Build for Replacement
Der beste Code ist der, den ein anderer Agent in sechs Monaten verstehen und ersetzen kann. Agentic Coding produziert Code der von Agents geschrieben wurde — aber auch von Agents gelesen, gewartet und refactored werden muss. Code-Klarheit, Dokumentation und Testabdeckung sind nicht optional.
In der Praxis
Jeder Code-Block den ein Agent schreibt, muss von einem anderen Agent (oder Menschen) verstanden werden können ohne den Autor zu fragen. Setze auf: klare Namen, keine Magic Numbers, Types (TypeScript), dokumentierte Schnittstellen, Tests als lebende Dokumentation. Frage dich: "Würde dieser Code Review durch einen Kollegen bestehen?"
Welche Harness setzt diese Prinzipien um?
Keine Harness kann alles. Aber jede hat Stärken in bestimmten Bereichen.
MCP-Unterstützung, Safety-Features, Permission-System — stärkste Write-Control. Spec-Driven nativ durch Claude-Arbeitsweise.
Schrittweise Approval in VS-Code — beste Governance. Gut für Test-getriebene Entwicklung durch Sandboxing.
Subagents, Advisors, Council — stärkste Multi-Agent-Orchestrierung. Open Source ermöglicht maximale Context-Kontrolle.
Composer-Mode und Diff-Ansicht machen den Review-Zyklus sichtbar. Gut für visuelle Planung und schnelle Iterationen.
Mit wem sich Agentic Coding gut besprechen lässt
Developer im Team
Welche Prinzipien fehlen euch — und was nervt an eurem aktuellen Workflow?
Fellow Developer (extern)
Wie handhabst du Specs, Review und Context mit deinem Agent?
Product Owner
Wie verändert Agentic Coding die Definition of Done?
Wie führt ihr Agentic Coding im Team ein?
Die Prinzipien sind klar — aber jedes Team hat andere Ausgangsbedingungen. Wenn ihr Unterstützung braucht die richtige Harness und den passenden Workflow zu finden, sprecht mich an.
Gespräch vereinbaren