Ein Harness, der Coding-Agenten erklärt, wie Ihr Code funktioniert

• Anweisungen für jedes Repository, knapp genug, dass ein Agent sie befolgt
• Befehle, mit denen der Agent das Projekt in einem frisch geklonten Repository bauen und seine Tests ausführen kann
• Ein klarer Rahmen für Kontext und Tools: welche Dienste, Dateien und Endpunkte der Agent nutzen darf
• Regeln dafür, welche Shell-Befehle, Dateiänderungen und Netzwerkzugriffe erlaubt sind und welche eine Freigabe brauchen
• Tests, Hooks und Review-Schritte, die Probleme in der Arbeit des Agenten finden, bevor jemand aus Ihrem Team sie sich ansieht

Wenn niemand einem Agenten zusieht, sind es seine Grenzen, die ihn im Rahmen halten. Jeder Lauf bekommt Berechtigungen, die zu seiner Aufgabe passen, einen eigenen isolierten Workspace und Zugangsdaten, die nur für diesen Lauf gelten. Gemergt wird erst, wenn das Review bestanden ist. Wie das genau aussieht, unterscheidet sich je nach Tool und Infrastruktur, deshalb legen wir es mit Ihrem Security-Team fest.

Harness-Dateien werden versioniert wie Code. Für jede Datei gibt es eine verantwortliche Person und einen vereinbarten Weg, sie zu ändern. Fehlt das, ergänzt jeder Engineer eigene Einstellungen, und die Repositories laufen auseinander. Gemeinsam mit Ihnen legen wir fest, welche Teile alle Repositories teilen und welche lokal bleiben, und woran Sie eine solche Drift erkennen.

Jede Änderung betrifft nur einen Teil des Harness, und wir messen sie an Aufgaben, die für Ihre Arbeit typisch sind. Wenn zwei Setups verglichen werden müssen, nutzen wir Evaluierungen auf Ihren eigenen Repositories. Die Konfigurationsdateien und schriftlichen Runbooks gehen an Ihre Engineers, damit sie den Harness auch ohne uns weiter anpassen können.

Beim Context Engineering im Repository geht es darum, festzulegen, was der Agent zu Beginn mitbekommt und was er sich unterwegs zusätzlich holen darf. Dazu gehören die Befehle für Builds und Tests, die Anweisungsdateien, die Dokumente, die er öffnen kann, und die Tools, die er aufrufen darf. Mehr ist nicht besser. Anweisungen, die mit jeder Anfrage geladen werden, nehmen der eigentlichen Aufgabe Platz weg. Diesen Teil halten wir knapp. Alles andere kommt in Dateien, die erst geladen werden, wenn eine Aufgabe sie braucht, etwa Skills oder Regeln, die an einen Pfad gebunden sind.

Änderungen am Kontext durchlaufen denselben Prozess wie jede andere Änderung am Harness. Wir nehmen jede einzeln vor und testen sie an einem festen Satz von Beispielaufgaben. Danach halten wir fest, ob akzeptierte Änderungen und Review-Aufwand steigen oder sinken.

Mehrere veröffentlichte Workflows verändern, wie ein Agent eine Aufgabe abarbeitet. Einer davon ist die Ralph-Technik, die Geoffrey Huntley im Juli 2025 beschrieben hat. Der Agent bekommt in einer Schleife immer wieder denselben Prompt und beginnt jede Runde mit frischem Kontext. Zwischen den Runden wird der Fortschritt in Dateien festgehalten, etwa in einem Plan und in Specs. Für Claude Code bietet Anthropic das Plugin ralph-wiggum an. Es hält die Schleife innerhalb einer einzigen Session und beendet sie bei einer Abschlussphrase oder, falls Sie eines setzen, nach einem Iterationslimit. Nach Huntleys Einschätzung eignet sich die Technik für neue Projekte, und er rät davon ab, sie auf eine bestehende Codebasis anzuwenden.

Superpowers von Jesse Vincent und Prime Radiant beginnt mit einem Brainstorming und einem schriftlichen Plan. Danach erledigen Subagenten die Arbeit testgetrieben, und ein Review gehört fest zum Ablauf. Das Compound-Engineering-Plugin von Every durchläuft Brainstorming, Planung, Umsetzung, Vereinfachung und Review. Anschließend hält es fest, was dabei gelernt wurde, damit spätere Aufgaben davon profitieren. pstack von Lauren Tan, ein Plugin für Cursor, leitet jede Aufgabe an ein passendes Playbook weiter und lässt das Ergebnis von mehreren Modellen prüfen.

Diese Workflows geben dem Agenten Anweisungen. Keiner von ihnen setzt etwas durch. Eine Schleife, die stundenlang weiterläuft, braucht dieselben Sicherungen wie jeder Lauf, bei dem kein Mensch zusieht. Das heißt: Iterationen und Budget begrenzen, den Workspace isolieren, die Tests vor Änderungen durch den Agenten schützen und vor jedem Merge ein Review durchführen. Bevor ein Team einen Workflow übernimmt, testen wir ihn an Ihrem Repository und gleichen ihn mit Ihren Kontrollen ab. Außerdem lassen wir ihn bei identischen Aufgaben neben Ihrem bisherigen Setup laufen.

Unser Leitfaden zu pstack · Spec-Driven Development in der Praxis · Wie wir Workflows vergleichen

In OpenCode werden Provider und Modell-Endpunkt in der Konfiguration festgelegt. Das klären wir als Erstes, gemeinsam mit den Verantwortlichen für Ihre Daten und Ihre Verträge. Diese Einstellung bestimmt, wohin Ihre Prompts und Ihr Code-Kontext gehen, welche Bedingungen dafür gelten und wer die Rechnung bekommt. Wenn der Traffic über ein Gateway läuft, haben Sie Zuordnung und Richtlinien an einer Stelle. Das Gateway ist allerdings ein weiteres System mit Zugriff auf diesen Traffic. Ob Session-Sharing aktiviert ist, entscheiden wir ebenfalls gemeinsam.

Abgesehen vom Format unterscheidet sich die Arbeit am Harness nicht von anderen Tools: Sie wird einfach in der Konfiguration von OpenCode geschrieben. Wir dokumentieren den Weg Ihrer Daten von den Entwicklerrechnern über ein etwaiges Gateway bis zum Provider. Außerdem erhalten Sie ein Runbook, das erklärt, wie Sie Provider oder Modell zu einem späteren Zeitpunkt wechseln. Aufbewahrungsfristen ergeben sich aus Ihren Verträgen und aus den Bedingungen, die der jeweilige Provider aktuell veröffentlicht. Wir halten sie für jeden Provider fest, den Sie nutzen.

Kilo lässt sich im Editor, als CLI und in der Cloud nutzen. Zuerst erfassen wir, welche Kilo-Oberflächen und -Versionen in Ihren Teams im Einsatz sind und welche Provider Ihre Organisation zulässt. Diese Kombination testen wir auf Ihrem Code, bevor andere Teams etwas davon übernehmen. Die Desktop-App ist eine Beta-Version, deshalb nehmen wir sie nur für Teams auf, die schon auf sie angewiesen sind. Der Client ist Open Source und läuft lokal, doch das sagt nichts darüber aus, welche Server Prompts und Code-Kontext erhalten. Das entscheiden der Provider, den Sie konfigurieren, und jedes Gateway, über das der Datenverkehr läuft, auch das von Kilo, falls Sie es nutzen.

Jeder eigene Agent, jede Repository-Regel, jeder Skill und jeder Befehl liegt in der Versionskontrolle und hat einen Owner. Die aktuelle Erweiterung baut auf der CLI auf und liest eigene Agenten aus Markdown-Dateien. Ältere Installationen lesen noch Custom Modes, das Legacy-Format. Für jede installierte Version prüfen wir, welches Format sie liest, und nach einer Migration wiederholen wir die Abnahmeaufgaben. All diese Dateien sagen dem Agenten, was er tun soll. Was er tatsächlich tun kann, begrenzen seine Berechtigungen und sein MCP-Zugriff, die wir für jeden Agenten einzeln einstellen. Wie weit Sie Modelle einschränken können, hängt von Ihrem Plan ab. Die Kontrolle für Organisationen, die Kilo dokumentiert, ist eine Blocklist im Enterprise-Plan. Neue Provider und Modelle bleiben nutzbar, bis jemand sie sperrt. Deshalb braucht die freigegebene Auswahl eine Person, die sie verantwortet und jeden Neuzugang prüft. Außerdem klären wir, welcher Mechanismus die Auswahl in Ihrem Plan durchsetzt.

• Die Oberflächen, Versionen und Provider Ihrer Teams, getestet an Ihrem eigenen Code
• Gemeinsame Agenten, Befehle, Regeln und Skills in der Versionskontrolle, jeweils mit einer namentlich benannten verantwortlichen Person, gespeichert in dem Format, das Ihre installierten Versionen verstehen
• MCP-Server und Berechtigungen, beschränkt auf den Zweck des jeweiligen Agenten
• Modelle und Provider, gemessen an akzeptierten Änderungen, Review-Aufwand und Wiederholungen, dazu eine verantwortliche Person für die freigegebene Liste

Einführung mit freier Wahl des Providers · Wie wir Workflows vergleichen · Was Multi-Agent-Workflows kosten · Kilo-Dokumentation zum Anpassen von Agenten

Läuft der Agent in der Cloud des Anbieters, muss der Harness auch in dieser Umgebung eingerichtet sein. Alles, was das Projekt auf einem Entwicklerrechner zum Laufen bringt, muss dort nachgebaut werden. Dazu gehören die Installation der Abhängigkeiten, der Start der Dienste, das Laden der Testdaten und die Bereitstellung von Secrets, die auf die Aufgabe begrenzt sind. Anschließend öffnen wir eine neue Session und prüfen, ob sich das Projekt bauen lässt und seine Tests laufen. Außerdem prüfen wir, ob Git-, MCP- und Netzwerkzugriff zur Aufgabe passen. Was sich dort durchsetzen lässt, bestimmen Produkt und Plan. Wie Aufgaben ausgewählt werden, wer das Review verantwortet und wie der Pilot abläuft, beschreibt der Abschnitt zu Devin auf unserer Seite zur Einführung von Coding-Agenten.

Arbeit an Devin übergeben

• Der Anteil der ersten Versuche des Agenten, die Ihre Checks bestehen
• Wie viele Review-Runden Pull Requests von Agenten brauchen und wie viel Nacharbeit
• Jede Änderung am Harness, gemessen an einem unveränderten Satz von Aufgaben, bevor sie übernommen wird