Agentic Coding verändert sich in einer Geschwindigkeit, die selbst für die Maßstäbe der Tech-Welt beispiellos ist. Die online verfügbaren Tutorials und Ressourcen behandeln größtenteils einzelne Features in einfachen Greenfield-Szenarien.

Während der Entwicklung von Bob und im Austausch mit zahllosen Praktikern aus den unterschiedlichsten Branchen hat sich eine Reihe von Konzepten herauskristallisiert, die helfen, die Effektivität und das Gesamterlebnis bei der Nutzung von Bob zu verbessern.

Diese Konzepte gelten auch für komplexe Projekte mit Technologien abseits des Mainstreams.

Konzept 1: Der Zyklus — Explore, Plan, Implement, Verify

Der Explore-, Plan-, Implement-, Verify-Zyklus mit einer äußeren Schleife zur kontinuierlichen Verbesserung von Guides und Sensoren

Das häufigste Fehlermuster im agentenbasierten Software Engineering ist das Fehlen von Struktur. Kohärente Konversationen täuschen Struktur nur vor, und wir sind verleitet, alle Schritte einer Implementierung in eine einzige Chat-Konversation zu packen. Solche Sessions fühlen sich produktiv an, aber die wahren Kosten werden erst beim Review sichtbar.

Das manuelle Schreiben von Code gab eine eigene Struktur vor. Die Implementierung war aufwendig, daher fühlte sich die Planung vor der Umsetzung intuitiv sinnvoll an. Das Verständnis baute sich beim Tippen auf, und falsche Annahmen kamen während dieses Prozesses meist ans Licht. KI-Agenten beseitigen diese Reibung. Code ist heute günstig, und das hat auch unsere Intuition für Struktur geschwächt. Eine Struktur, die früher ein Nebenprodukt von Verlangsamung war, muss heute ganz bewusst geschaffen werden.

Die bewusste Nutzung dieses Zyklus sorgt für die nötige Struktur:

Explore schafft Verständnis
Plan schafft Entscheidungen
Implement schafft Code
Verify schafft Nachweise.

Diesem Zyklus zu folgen hilft dir, fokussiert und strukturiert zu bleiben und deine Ziele schneller und beständiger zu erreichen.

Ein einzelner Durchlauf durch den Zyklus kann zwanzig Minuten oder drei Tage dauern. Ein Durchlauf kann Unterzyklen enthalten, und wie sich die Zeit auf die Phasen verteilt, variiert je nach Aufgabe stark.

Eine detaillierte Beschreibung des Zyklus findest du weiter unten im Abschnitt Deep Dive: Den Zyklus durchlaufen.

Konzept 2: Das Context Window ist die knappe Ressource

Ein bewusster Umgang mit dem Context Window ist die Gewohnheit mit dem größten Hebel.

Was ist das Context Window?

Modelle sind zustandslos. Ein Chat ist keine laufende Session mit Gedächtnis: Jeder Turn sendet alle vorherigen Nachrichten erneut und hängt die neue Antwort hinten an. Das Context Window ist die maximale Eingabemenge, die ein Modell in einem solchen Turn annehmen kann. In Bob V2 sind das 270.000 Tokens (Context-Window-Verwaltung).

Das Window füllt sich bereits vor der ersten Nachricht:

Vorab geladen: Bobs System-Prompt, die Beschreibung des aktiven Modus, die agents.md des Repositories und eine Beschreibung jedes verbundenen Model Context Protocol (MCP)-Tools (MCP in Bob).
Während der Session unsichtbar hinzugefügt: gelesene Dateien, Tool-Ergebnisse, Skill-Dateien, die Bob lädt, und Subagent-Ausgaben.

Das Context Window füllt sich und wird zu einer Zusammenfassung verdichtet

Wenn das Window voll ist, komprimiert Bob die Konversation. Bob ersetzt den bisherigen Gesprächsverlauf durch eine Zusammenfassung, und die Arbeit geht weiter. Das hält die Session am Leben, ist aber naturgemäß verlustbehaftet. Bob entscheidet automatisch, welche Details erhalten bleiben, und nichts markiert die verworfenen Informationen. Eine Session, die zweimal komprimiert wurde, läuft auf einer Zusammenfassung einer Zusammenfassung.

Ein einzelner MCP-Aufruf kann Zehntausende Tokens zurückgeben, und eine Folge von Dateilesevorgängen verwässert das, was früher in der Session besprochen wurde. Mode-Beschreibungen, Rules-Dateien und MCP-Server tun dies langsamer und weniger sichtbar. Bob schlüsselt das Window nach Quelle auf, und es lohnt sich, diese Aufschlüsselung bei wachsendem Setup regelmäßig zu prüfen.

Bobs Context-Window-Anzeige, erweitert zur Darstellung der aktuellen Session aufgeschlüsselt nach Quelle

Bobcoins werden hauptsächlich pro Token berechnet. Daher steigen die Kosten einer Konversation im Verhältnis zu ihrer Länge quadratisch an. Längere Konversationen kosten wesentlich mehr Bobcoins als kurze Konversationen! (Bobcoins-Dokumentation)

Mit dem Context Window arbeiten statt dagegen

Teile die Arbeit auf separate Konversationen auf. Eine Aufgabe, eine Session. Das folgt demselben Prinzip wie Single Responsibility im Code. Eine Konversation sollte einen einzigen Existenzgrund haben, wie etwa „erstelle ein Architekturdiagramm von Komponente X“ oder „erstelle einen Implementierungsplan für Feature Y“. Alles im Context Window beeinflusst die folgenden Schritte — auch Ansätze, die nicht funktioniert haben. Eine Session, die feststeckt, bleibt meist feststecken, weil die fehlgeschlagenen Versuche immer noch vorhanden sind und das Modell sie als Referenz für das Aussehen der Aufgabe interpretiert (Context Poisoning).
Rollback statt Diskussionen mit Bob. Wenn eine Konversation in unerwünschtes Verhalten abdriftet, führe einen Rollback zur letzten guten Nachricht durch, passe die Nachricht an und mache von dort aus weiter. Dadurch werden auch alle lokalen Änderungen von Bob rückgängig gemacht, was das Context Window klein und sauber hält (Rollback).
Behalte alles Wichtige in einer Datei, nicht im Chat. Pläne, Erkenntnisse und Entscheidungen gehören in eine Datei. Ein Kollege kann ein Markdown-Dokument reviewen und an eine neue Session übergeben; ein Chat-Protokoll kann keines von beidem.
Subagents halten umfangreiche Arbeit aus dem Context Window fern. Bob entscheidet, wann ein Subagent ausgeführt wird, und nur die Ergebnisse fließen zurück. Du kannst auch direkt nach einem fragen, wenn eine Aufgabe Ausgaben erzeugt, die niemand im Detail lesen muss (Subagents).
Achte darauf, was in das Context Window gelangt und ob es Mehrwert bringt. Überprüfe deine Guides und Sensoren regelmäßig (wie im nächsten Thema beschrieben) und investiere Zeit in deren Verbesserung.

Konzept 3: Zwei Arten von Bausteinen — Guides und Sensoren

In einem langen Projekt hängt die Qualität der Codebasis weniger von Bob selbst ab als davon, was seine Arbeit lenkt und seine Ergebnisse überprüft. Es stehen viele Bausteine zur Verfügung: Rules, Skills, Modes, Hooks, Subagents, externe Linter und Review Agents. Fast alle erfüllen eine von zwei Aufgaben:

Guides steuern Bob vor oder während der Arbeit (Feedforward). Rules, Skills und Modes sind Guides.
Sensors melden Ergebnisse zurück, nachdem Bob agiert hat (Feedback). Tests, Linter, Type Checker sowie interaktive Browser-Sessions und Review Agents sind Sensoren.

Ein Mensch am Laptop richtet einen Pfeil auf Bob, und Bob richtet einen Pfeil auf den Code. Ein Pfeil namens „guides“ trifft von oben auf Bob, beschriftet mit Rules, Skills und Modes. Ein Pfeil namens „sensors“ führt vom Code zurück zu Bob, beschriftet mit Tests, Lintern und Review Agents.

1. Guides

Alles, was Bob zur Steuerung der Arbeit bereitgestellt wird, ist ein Guide. Es gibt drei Hauptbausteine, die dir dabei helfen. Sie funktionieren, indem sie zusätzlich zu dem von dir eingegebenen Prompt Text in das Context Window einfügen. Sie unterscheiden sich darin, wann dieser Text eintrifft und wodurch er ausgelöst wird.

Rules sind immer aktiv, Modes werden vom Nutzer aktiviert, Skills werden von Bob aktiviert

Rules sind immer aktiv. agents.md im Repo-Root ist die wichtigste davon, und der beste Ratschlag dazu lautet: halte sie kurz. Jede Zeile konkurriert in jedem einzelnen Turn um Aufmerksamkeit; eine lange Rules-Datei führt also dazu, dass Bob einzelne Regeln schlechter befolgt (Rules).
Modes werden vom Nutzer aktiviert. Die integrierten Modes sind: Ask ist schreibgeschützt (Read-only). Plan führt durch einen Planungsprozess und übergibt das Ergebnis an Agent, welcher Aktionen ausführt. Eigene Modes können einfach hinzugefügt werden (Modes, Custom Mode hinzufügen).
Skills aktiviert Bob, wenn es sie für relevant hält. Nur eine kurze Skill-Beschreibung ist immer aktiv. Der Hauptteil des Skills wird erst bei Bedarf in den Kontext geladen. Das macht Skills sehr token-effizient (Skills).

Alles in der Rules-Datei verbraucht in jedem Turn Tokens, unabhängig davon, ob der jeweilige Turn es benötigt. Halte sie daher minimal und lade den Rest erst, wenn er gebraucht wird.

2. Sensors

Alles, was Bob Feedback zur erstellten Arbeit gibt, ist ein Sensor. Welche Signale nützlich sind, hängt von der Codebasis und dem Stack ab. Das sinnvolle Set unterscheidet sich daher von Projekt zu Projekt und erfordert echte Arbeit beim Aufbau. Die wertvollsten Sensoren sind maschinell ausführbar und werden von Bob während der Implementierungsphase ausgeführt. Sensoren lassen sich in zwei Kategorien unterteilen:

Rechnerische Sensoren sind deterministisch: Tests, Linter, Type Checker, Compiler. Ergebnisse sind exakt und wiederholbar und so kostengünstig, dass Bob sie häufig ausführen kann. Die Abdeckung wird durch die Systeme begrenzt, die ein Team aufgebaut hat und pflegt.
KI-basierte Sensoren sind flexibel und nicht-deterministisch. Ein Review Agent prüft auf Intention und auf Dinge, für die ein Linter keine Regel hat. Die Ausgabe ist ein Urteil, keine Messung. Sie variiert zwischen den Durchläufen; Kosten und Dauer begrenzen, wie oft sie eingesetzt werden können (Code Reviews).

Für die Einbindung gibt es mehrere Optionen, geordnet nach Aufwand:

Hooks sind die deterministische Option mit dem geringsten Reibungsverlust. Ein Check läuft jedes Mal an einem festen Punkt, unabhängig davon, ob Bob ihn für relevant hielt. Siehe die Hooks-Dokumentation.
Skills werden oft als Guides genutzt, aber ein Skill, der ein Review ausführt, ist ein Sensor — und der einfachste Weg, einen nicht-deterministischen Check hinzuzufügen. Siehe die Skills-Dokumentation.
Continuous Integration (CI) bindet einen Reviewer Agent in die Pipeline ein — bei jedem Pull Request, für das gesamte Team statt nur für einen einzelnen Entwickler. Siehe den PR Review Agent in Aktion.

Deep Dive: Den Zyklus durchlaufen

Die Phasengrenzen sind auch Kontextgrenzen. Das ist der praktische Grund, sie getrennt zu halten: Erkundungsgespräche haben in der Konversation, in der der Code geschrieben wird, nichts zu suchen.

1. Explore

Die Exploration variiert stark je nach deiner Rolle und der jeweiligen Aufgabe. Sie kann das Onboarding in eine neue Codebasis bedeuten oder die Abschätzung des Radius für ein größeres Refactoring. Einige Beispiele:

Lass Bob ein Architekturdiagramm erstellen, bevor du etwas am bestehenden System änderst. Siehe das Tutorial zum Erstellen von Architekturdiagrammen oder dasselbe als Video.
Frage nach einer maßgeschneiderten Einführung aus zwei Blickwinkeln: einmal als Nutzer, der sich durch das Produkt bewegt, und einmal als Entwickler, der sich durch den Code bewegt. Angaben zu deinen Vorkenntnissen und deiner Aufgabe helfen dabei, das Dokument genau anzupassen (Codebasis untersuchen).
Auf IBM Z und IBM i nutzt du die plattformspezifischen Optionen. Die Exploration auf diesen Systemen ist anders gelagert und profitiert stark von den spezialisierten Tools in den Premium-Paketen. Siehe Premium Package für Z (Docs) und das Premium Package für IBM i (Docs).

Exploration kann auch bedeuten, Dinge zu bauen, die du wieder löschen willst. Die Implementierung ist heute günstig, daher ist ein kleiner Prototyp der schnellste Weg herauszufinden, ob ein Ansatz dem Kontakt mit der Codebasis standhält. Kent Beck nannte dies vor fünfundzwanzig Jahren eine Spike-Implementierung, und die Disziplin ist dieselbe: Baue es, um etwas zu lernen, behalte die Erkenntnisse und wirf den Code weg.

Günstige Implementierung erhöht den Wert von Architektur und Codequalität, anstatt ihn zu senken. Es ist heute leicht, große Mengen an Code zu erzeugen, der zwar funktioniert, aber falsch konzipiert ist.

2. Plan

In der Planungsphase liegt der größte Hebel. Alles, was der Plan richtig macht, zahlt sich doppelt aus: einmal bei der Implementierung und noch einmal, wenn die Änderung die Hände des Autors verlässt und ein Kollege sie reviewen muss.

Was ein guter Plan braucht:

Kurz und präzise, beides. Pläne müssen gelesen werden.
Explizit bezüglich des beabsichtigten Ergebnisses, einschließlich der unsicheren Teile. Zu wissen, was unbekannt ist, ist der Großteil der Arbeit; der Rest ist das Herausfinden.
In einer Datei. Pläne sollten nicht in einer Chat-Session verbleiben.

Es gibt viele Wege, einen Plan zu erstellen, aber der integrierte Plan-Modus ist der einfachste Einstiegspunkt (wie in diesem Tutorial). Der Plan-Modus ist darauf ausgelegt, kooperativ zu sein, und neigt dazu, Lücken selbst zu füllen. Während dies in vielen Fällen schnelle Iterationen ermöglicht, ist manchmal mehr Strenge erforderlich. Er baut möglicherweise einen soliden Plan um eine falsche Annahme herum, ohne diese Annahme zu hinterfragen. Ein dedizierter Skill, der den Plan hinterfragt — wie etwa grill-me von Matt Pocock — ist der kostengünstigste Weg für eine gründliche Prüfung, bevor die Annahme zu Code wird.

Zu Spec-Driven Development (SDD): Der Begriff deckt vieles ab und ist noch im Wandel. Viele behandeln ihn als Ja-Nein-Entscheidung, aber er gleicht eher einem Spektrum:

Spec-first: Der Plan entsteht vor der Implementierung. Dies ist nahezu unverzichtbar.
Spec-anchored: Die Spezifikation bleibt nach der Implementierung als Dokumentation und als Standard erhalten, den Implementierungen erfüllen müssen.
Spec-as-source: Die Spezifikation ist die Quelldatei. Der Mensch bearbeitet die Spezifikation; der Mensch bearbeitet nicht den Code.

Welches Level passt, hängt vom Team, der Kritikalität/Reife der Codebasis und der Branche ab. Der Overhead höherer SDD-Stufen kann schnellen Iterationen im Weg stehen. In der Automobilindustrie, wo Spec-Driven Development der KI um Jahrzehnte vorausgeht, passt SDD hervorragend zu bestehenden Praktiken.

3. Implement

Die Implementierung ist die unkomplizierte Phase, und Bob übernimmt fast alles davon.

Bob bei der Arbeit zuzusehen und bei Bedarf zur Klärung zu unterbrechen, ist optional und oft nützlich. Nutze die Häufigkeit als Signal: Ständige Unterbrechungen bedeuten, dass das Problem im Plan liegt und die Lösung darin besteht, zurückzugehen, anstatt fortlaufend nachzukorrigieren.

Zögere nicht, eine gesamte Implementierung zu verwerfen und in den Plan-Modus zurückzukehren. Der Code ist der günstige Teil.

4. Verify

Die Verifizierung unterteilt sich in zwei verschiedene Kategorien: automatisierte Verifizierung und manuelle Verifizierung.

Automatisierte Verifizierung wird durch die Sensoren gesteuert, die Bob zur Verfügung stehen oder die über Hooks erzwungen werden. Sie werden während der Implementierungsphase häufig und ohne menschliches Eingreifen ausgeführt. Die Hauptkategorien mit typischen Beispielen sind:

Gültigkeit (Validity): Kompiliert es, besteht der Typecheck, lässt es sich parsen?
- Gemessen: Bestanden/Fehlgeschlagen, Typabdeckung
- Tools: tsc, mypy, cargo check, javac
Verhalten (Behaviour): Tut es das Richtige?
- Gemessen: Erfolgsquote, Zweigabdeckung (Branch Coverage)
- Unit-Tests, Integrationstests, End-to-End-Tests
- Tools: pytest, Jest, Playwright, Stryker
Wartbarkeit (Maintainability): Lohnt es sich, diesen Code zu behalten?
- Gemessen: Komplexität, Duplizierung, Architektur-/Grenzverletzungen
- Tools: ESLint, Ruff, Lizard, ArchUnit
Sicherheit (Security): Ist dieser Code sicher?
- Gemessen: Befunde nach Schweregrad, CVEs
- Tools: Semgrep, CodeQL, gitleaks, npm audit

Sie ermöglichen es Bob, eigene Fehler zu erkennen und die Qualität während der Implementierungsphase zu verbessern. Eine gute Testabdeckung ist ein wesentlicher Schutz vor Regressionen: Sie stellt sicher, dass Bob nichts beschädigt hat.

In diesem Zyklus wird die Verifizierung als separate Phase am Ende der Schleife aufgeführt, was sich hauptsächlich auf die manuelle Verifizierung bezieht. Die manuelle Verifizierung beginnt damit, die Änderung auszuführen und das beobachtete Verhalten mit dem im Plan festgelegten Verhalten zu vergleichen. Eine Abweichung lässt sich meist auf eine von zwei Ursachen zurückführen:

Die Implementierung weicht vom Plan ab. Die Korrektur erfolgt im Code.
Der Plan spiegelt nicht wider, was du eigentlich bauen wolltest. Der Plan muss verfeinert werden. Das kommt weitaus häufiger vor.

Die manuelle Inspektion testet daher den Plan und die Implementierung gleichzeitig.

Zusätzliche Verifizierungen sollten in CI/CD-Pipelines stattfinden. Dies ist eine etablierte Praxis im Software Engineering, kann aber durch den Einsatz von Headless-Coding-Agenten verbessert werden. Ein Beispiel: Ein automatisierter Review bei jedem Pull Request über Bob Shell unterstützt menschliche Reviewer, anstatt sie zu ersetzen. Siehe das Video des PR Review Agents in Aktion und die Docs zur nicht-interaktiven Nutzung von Bob Shell.

Im Team arbeiten

Alles in den vorherigen Abschnitten beschreibt die innere Schleife eines einzelnen Entwicklers. Die äußere Schleife beginnt, wenn die Änderungen in die Review-Queue gelangen. Jedes Diff trifft jetzt schneller und mit weniger erklärendem Kontext ein, während der Reviewer mehr lesen muss und weniger Kontext dafür hat.

Nachweise müssen zusammen mit der Arbeit übergeben werden. Das Warum ist im Verhältnis zum Wie wichtiger als früher, da das Wie nicht mehr der aufwendige Teil der Erstellung ist.

In der Praxis bedeutet das, dass der Plan mit der Änderung mitwandert: Teams hängen ihn an den Pull Request an oder fügen ihn zusammen mit dem Review wieder dem ursprünglichen Issue bei. Der genaue Mechanismus hängt von den verwendeten Tools ab.

Welche Auswirkungen die äußere Schleife auf die Prozesse eines Teams hat, ist ein eigenes Thema für einen späteren Beitrag.

Einige Gedanken zum Prompting

In den vergangenen Jahren lag ein großer Schwerpunkt auf dem richtigen Prompting von LLMs, woraus sogar ein eigenes Berufsbild als „Prompt Engineer“ entstand. Mittlerweile wird ein Großteil des Promptings im Harness selbst abgewickelt. Die Bedeutung spezialisierter Prompting-Techniken ist zugunsten eines methodischen Ansatzes in den Hintergrund getreten. Hier sind einige Richtlinien:

Iterieren schlägt Prompting. Wenn Bob etwas anderes tut als gewünscht, führe einen Rollback durch und schreibe die auslösende Nachricht um. Nachkorrekturen im Chat belassen die falsche Antwort, die Reklamation und den erneuten Versuch alle im Window.
Methodik schlägt Prompting. Ein Prompt ist auf eine Session beschränkt. Eine Rules-Datei oder ein Check, den Bob selbst ausführen kann, wirkt in jeder Session nach derjenigen, in der er erstellt wurde — die einzige Art von Investition, die sich hier kumuliert.
Gib Bob das Briefing, das ein Senior Engineer bekommen würde. Ein kompetenter Kollege, der eine vage Aufgabe erhält, fragt nach den Erfolgskriterien und dem erlaubten Rahmen. Bob fragt nicht — packe daher beides direkt in die Nachricht.
Sag, was getan werden soll, nicht was nicht getan werden soll. „Verwende keine Klassenkomponenten“ schließt eine Option aus und lässt den Rest offen — Bob wählt aus dem Verbleibenden, was ein weiteres Raten bedeutet. Stattdessen das Ziel direkt zu benennen — Funktionskomponenten mit Hooks — schließt die Frage in einem Turn ab.
Jede Anweisung, die mehr als zweimal gegeben wird, gehört in eine Datei. Genau dafür sind agents.md und Skills da.
Detailliertere Anleitungen zum Prompting findest du im Tutorial zum Schreiben effektiver Prompts.

Wichtigste Erkenntnisse

Das Fehlen von Struktur ist das größte Problem. Dem Zyklus Explore → Plan → Implement → Verify zu folgen, hilft dir, fokussiert zu bleiben und deine Ziele schneller und beständiger zu erreichen.
Kontext ist die knappe Ressource, und Phasen sind Kontextgrenzen. Nimm Erkundungsgespräche nicht mit in die Implementierung.
Der Plan ist das Review-Artefakt. Einen Plan zu reviewen ist effektiver als ein Diff zu reviewen — für den Autor wie für den Reviewer.
Alles, was es wert ist behalten zu werden, verlässt den Chat. Pläne, Entscheidungen und Erkenntnisse gehören in eine Datei. Dateien lassen sich vergleichen (diffen), reviewen, versionieren und an andere Agenten übergeben.
Verifizierung sollte maschinell ausführbar sein, was bedeutet, dass du sie bereits während der Planung entwerfen musst und nicht erst im Nachhinein entdeckst.

Quellen und weiterführende Literatur

Simon Willison, Agentic engineering patterns
Birgitta Böckeler, Harness engineering

IBM Bob Dokumentation und Tutorials: