Learning Log 2: Guidance through Harness and Specs

In meinem letzten Beitrag habe ich über TDD im Zeitalter von KI geschrieben und versprochen, mich als nächstes mit zwei Themen zu beschäftigen: was ein Harness ist und wie man heute mit Spec-Dateien arbeitet. In diesem Beitrag geht es darum, was ich darüber gelernt habe.

Alles über Harnesses

Es muss etwa Mitte Mai 2026 gewesen sein, als ich über Hacker News von Pi gehört habe. Pi beschreibt sich selbst als "... a minimal terminal coding harness". Seitdem habe ich mich gefragt, was damit eigentlich gemeint ist. Wieder einmal hilft Birgitta Böckeler weiter. In ihrem Blogbeitrag über Harness Engineering erklärt sie, was diese Werkzeuge tun und warum man sie überhaupt braucht. Hier ihr Beitrag in meinen eigenen Worten:

Warum das Wort "Harness": Der Begriff kommt aus der Welt der Pferde und der Kletterausrüstung. Ein Harness ist die Ausrüstung, mit der man etwas Kraftvolles lenkt, ohne selbst dieses Kraftvolle zu sein. Das Modell ist der starke, unberechenbare Teil. Der Harness ist alles drumherum, was es in eine sinnvolle Richtung lenkt.

Die Definition: Tools wie Claude Code bringen schon einen eingebauten Harness mit. Für die eigene Codebasis ergänzt man einen äußeren Harness. Er besteht aus zwei Arten von Kontrollen:

• Guides (Feedforward) steuern den Agenten, bevor er handelt. Beispiele sind AGENTS.md, Skills, Codemods und Language Server.
• Sensors (Feedback) prüfen, nachdem er gehandelt hat, damit sich der Agent selbst korrigieren kann. Beispiele sind Linter, Tests, Strukturtests und KI-Review-Agenten.

Beide Arten können computational sein (deterministisch und schnell, wie Linter und Type Checker) oder inferential (LLM-basiert und teurer, wie Review-Agenten).

Agent = Model + Harness

Claude Code, Codex und Copilot werden oft einfach Coding Agents genannt. Genau genommen installiert man aber den Harness. Er steuert die Schleife, gibt dem Modell seine Werkzeuge und entscheidet, was es tun darf. Erst zusammen mit einem Modell wird daraus ein Agent. Bei Pi sieht man das sehr deutlich. Man wählt das Modell selbst aus und kann den Harness an die eigenen Bedürfnisse anpassen. Ich will Pi und OpenCode ausprobieren und in einem späteren Learning Log darüber schreiben. OpenCode wurde sogar im aktuellen Technology Radar Vol 35 vorgestellt.

Jetzt, wo ich verstehe, was ein Harness ist, kommt die nächste große offene Frage: Was ist Spec-Driven Development?

Specs als Kontextdateien

Bei DNAstack hatte ich einen Kollegen, der über mehrere Tage einen SQL-Treiber aus einer Spec gebaut hat. Damals war ich nicht überzeugt. Neue Features auf diese Weise hinzuzufügen, schien mir schwierig. Man müsste völlig eindeutig sein, um alles richtig hinzubekommen und wie stellt man überhaupt sicher, dass der Code am Ende keine Bugs hat? Code immer wieder aus Spec-Dateien neu zu generieren, kam mir auch nicht plausibel vor, würde den immer der gleiche Code dabei herauskommen? Wie hat sich die Technik also seit "specify → plan → tasks" entwickelt? Ziemlich stark, wie sich herausstellt.

Birgitta Böckeler hat im Oktober 2025 darüber geschrieben. Sie hat sich Kiro, Spec Kit und Tessl angesehen und drei Stufen von Spec-Driven Development (SDD) unterschieden:

• Spec-first: Zuerst wird eine Spec geschrieben und für die aktuelle Aufgabe genutzt. Kiro und Spec Kit haben so funktioniert.
• Spec-anchored: Die Spec bleibt nach der Aufgabe erhalten und entwickelt sich mit dem Feature weiter.
• Spec-as-source: Die Spec ist das Hauptartefakt. Menschen bearbeiten nur die Spec, nie den Code.

Eine Spec-Datei ist eine Markdown-Datei, in der man ein Feature so detailliert wie möglich beschreibt. Die Akzeptanzkriterien darin führen den Agenten zu einem ausreichenden Ergebnis. In Harness-Begriffen ist eine Spec Feedforward. Ob das Ergebnis vollständig ist, hängt vom Kontextfenster und der Qualität des Modells ab. Böckeler hat das selbst erlebt. Trotz aller Dateien, Vorlagen und Checklisten hat der Agent oft nicht alle Anweisungen befolgt.

Seit ihrem Blogpost haben sich die Tools stark verändert.

Tessl hat Specs hinter sich gelassen. Das Unternehmen ist von Specs auf Skills gewechselt, also von einer Art Guide zu einer anderen. Heute verkauft es eine Plattform, mit der man Skills verwalten, versionieren und absichern kann, genau wie Bibliotheken. Heute bietet kein bekanntes Tool mehr Spec-as-source an soweit ich das feststellen konnte. Die radikalste Idee scheint als Produkt nicht überlebt zu haben.

Spec Kit hat Skills ebenfalls hinzugefügt. Im August 2026 erschien Version 1.0. Ursprünglich hat Spec Kit für jeden Agenten eigene Befehlsdateien erzeugt, weil Copilot, Claude Code, Cursor und Gemini jeweils ein eigenes Format hatten. Agent Skills ist inzwischen ein offenes Format, das die meisten von ihnen lesen. Ein Paket funktioniert also überall. Deshalb hat Spec Kit einen Skills-Modus mit Unterstützung für über 30 Agenten eingeführt.

OpenSpec: Im Rückblick war der SQL-Treiber perfekt für eine Spec geeignet. Protokoll und Schnittstelle waren klar definiert. Ein Feature zu einer bestehenden Codebasis hinzuzufügen, ist ein anderes Problem. Eine Änderung beschreibt nur, was hinzugefügt, geändert oder entfernt wird. Die Spec-Datei wächst mit dem Code, statt alles im Voraus zu beschreiben. Damit ist sie spec-anchored. OpenSpec bringt außerdem Skills für Agenten-Tools mit.

Kiro prüft jetzt auch. Böckeler fand, mit Kiro schieße man mit Kanonen auf Spatzen, als sie es für einen kleinen Bug benutzte. Inzwischen hat Kiro verschiedene Workflows wie z.B. Bugfix-Specs, eine schnelle Spec ohne Freigabeschritte und einen Schritt, der Anforderungen vor dem Design auf Mehrdeutigkeiten und Lücken prüft. Außerdem macht Kiro aus Anforderungen Property-based Tests. Damit ist es das erste Spec-Tool, das mir begegnet ist, das den Agenten nicht nur führt, sondern auch das Ergebnis prüft.

Dazu kommt, dass die meisten Coding Agents inzwischen einen Plan-Modus haben, der vor dem Coden einen Plan schreibt. Das ist die leichtgewichtige Version derselben Idee, ohne die zusätzlichen Stunden, die ein kompletter Spec-Workflow kostet.

Spec-Dateien sind also immer noch überall. Kiro ist das einzige große Tool, das sie direkt ins Produkt einbaut. Spec Kit und OpenSpec bringen sie zu fast jedem anderen Coding Agent. Genau genommen braucht man meiner Meinung nach keins dieser Tools. Jeder Coding Agent kann heute mit Specs arbeiten. Ein Skill, der den eigenen Spec-Workflow beschreibt, reicht aus, damit der Agent ihm folgt. Ich hatte noch keine Zeit, eines dieser Tools im Detail auszuprobieren. Sobald ich mehr über Token Economics gelernt habe, werde ich die Tools näher unter die Lupe nehmen. Vorher erzähle ich dir aber, was ich über Acceptance Test Driven Development gelernt habe, das Dave Farley die Zukunft des Programmierens mit KI nennt.

Bleibt dran, Leute.