„Mach mal alles fertig“ ist ein Unfall mit Ansage: Wie man der KI ein Gerüst baut

„Räum dieses Repository mal schön auf.“

Am Morgen danach hatte die KI „schön“ vierzig Dateien umgeschrieben. Lauffähiger Code war auch dabei, alles tadellos. Nur: Auch die Konfigurationsdatei, die man auf keinen Fall löschen darf, war sauber „aufgeräumt“ worden. Restlos weg.

So einen Moment, in dem es einem kalt den Rücken runterläuft – kennst du den?

Warum baut eine eigentlich kluge KI seelenruhig solche Unfälle? Der Grund ist simpel: „klug sein“ und „sicher arbeiten können“ sind zwei völlig verschiedene Dinge. Wie der Neue, der im Test volle Punktzahl holt und am ersten Tag im Aushilfsjob die Kasse zerlegt. Genau das. Kein Können-Problem, sondern ein Gerüst-Problem.

Dieses Gerüst nennt man neuerdings Harness. Heute erkläre ich das – und zwar so weit es geht ohne Fachjargon.

Was ist ein Harness, kurz gesagt?

Ein Harness ist ein kleines Programm, das man „um die KI herum“ legt.

Am leichtesten stellst du es dir vor wie das Sicherungsseil auf der Baustelle oder die Stützräder am Kinderfahrrad. Ein Mechanismus, der das Können der Person unangetastet lässt, aber dafür sorgt, dass sie nicht runterfällt. Bei der KI übernimmt das Gerüst solche Rollen:

• Es entscheidet, was die KI zu sehen bekommt (nicht alles)
• Es entscheidet, was sie produzieren soll (das Ziel klar machen)
• Es entscheidet, wie weit sie allein macht und wo ein Mensch bestätigen muss
• Es prüft maschinell, ob das Ergebnis kaputt ist

„Einen guten Prompt schreiben“ ist davon nur ein winziger Teil. Dass weniger Unfälle passieren, obwohl man nur am Prompt feilt – das wäre, als würde man ohne Stützräder Einrad üben. Geht schief.

Warum bekommt das Thema gerade jetzt so viel Aufmerksamkeit?

Bis vor Kurzem hieß „etwas von der KI verlangen“ ungefähr: „Schreib einen Text“, „Schreib Code“. Der Mensch las das Ergebnis und entschied. Das reichte.

Heute aber überlässt man der KI die Arbeit selbst. Dateien lesen, ein Thema wählen, das sich nicht mit bestehenden Artikeln überschneidet, Änderungen prüfen, sich bei einem externen Dienst anmelden, bei einem Fehler die Ursache melden – an diesem Punkt steht nicht mehr bei jedem Schritt ein Mensch dazwischen. Und genau deshalb ist das Risiko „macht was und baut Mist“ schlagartig gestiegen.

Dass Claude Code so einen guten Ruf hat, liegt nicht so sehr daran, dass das Modell klug ist, sondern daran, dass dieses Gerüst gut gebaut ist. Werkzeuge zum Lesen von Dateien, Werkzeuge zum Suchen, ein Mechanismus, der gefährliche Operationen stoppt, ein Mechanismus, der sich die Projektregeln merkt. Dieses „unscheinbare Drumherum“ sitzt. Was gerade angesagt ist, ist nicht der magische Prompt – es ist dieses unscheinbare Drumherum.

Erst mal laufen lassen: Ein Minimal-Harness in 30 Zeilen

Statt langer Erklärung ist Ausprobieren schneller. Bauen wir das kleinstmögliche Gerüst: Die KI darf nur „lesen und schreiben“, und außerhalb des festgelegten Ordners darf sie auf gar keinen Fall etwas anfassen. Es läuft, wenn du Node.js und einen Anthropic-API-Schlüssel hast.

Zuerst die Vorbereitung.

mkdir harness-demo && cd harness-demo
npm init -y
npm install @anthropic-ai/sdk
mkdir sandbox
echo "# Notiz" > sandbox/note.md

Als Nächstes schreiben wir die „Erlaubnisliste“. Das ist das Herzstück des Harness. Die Ansage: außerhalb von sandbox wird nichts angefasst.

{
  "workspace": "./sandbox",
  "maxSteps": 6
}

Und nun das Hauptprogramm (harness.mjs). Merken musst du dir nur eine einzige Stelle. safePath ist der Türsteher, der „Hand weg“ sagt, sobald jemand aus dem Ordner ausbrechen will. Allein dass es das gibt, verhindert den „40-Dateien-Unfall“ von oben.

import Anthropic from "@anthropic-ai/sdk";
import { readFile, writeFile } from "node:fs/promises";
import path from "node:path";

const client = new Anthropic();
const policy = JSON.parse(await readFile(new URL("./policy.json", import.meta.url), "utf8"));
const root = path.resolve(policy.workspace);

// Türsteher: Will jemand aus dem Arbeitsordner ausbrechen, wird er auf der Stelle gestoppt
function safePath(p) {
  const resolved = path.resolve(root, p);
  if (resolved !== root && !resolved.startsWith(root + path.sep)) {
    throw new Error(`${p} liegt außerhalb des Arbeitsordners. Nur innerhalb von sandbox ist erlaubt.`);
  }
  return resolved;
}

const tools = [
  { name: "read_file", description: "Text innerhalb von sandbox lesen",
    input_schema: { type: "object", properties: { path: { type: "string" } }, required: ["path"] } },
  { name: "write_file", description: "Text innerhalb von sandbox schreiben",
    input_schema: { type: "object", properties: { path: { type: "string" }, content: { type: "string" } }, required: ["path", "content"] } },
];

async function useTool(name, input) {
  if (name === "read_file") return await readFile(safePath(input.path), "utf8");
  if (name === "write_file") { await writeFile(safePath(input.path), input.content, "utf8"); return "Geschrieben, OK"; }
  throw new Error(`Unbekanntes Werkzeug: ${name}`);
}

const messages = [{ role: "user", content: process.argv.slice(2).join(" ") || "Lies note.md und schreib eine Zusammenfassung in summary.md." }];

for (let step = 0; step < policy.maxSteps; step++) {
  const res = await client.messages.create({
    model: process.env.ANTHROPIC_MODEL || "claude-sonnet-4-6",
    max_tokens: 1024,
    tools,
    system: "Du bist ein vorsichtiger Dateiverwalter. Nutze Werkzeuge nur, wenn nötig, und arbeite ausschließlich innerhalb von sandbox.",
    messages,
  });
  messages.push({ role: "assistant", content: res.content });

  const calls = res.content.filter((b) => b.type === "tool_use");
  if (calls.length === 0) { console.log(res.content.find((b) => b.type === "text")?.text ?? ""); break; }

  const results = [];
  for (const c of calls) {
    try { results.push({ type: "tool_result", tool_use_id: c.id, content: String(await useTool(c.name, c.input)).slice(0, 4000) }); }
    catch (e) { results.push({ type: "tool_result", tool_use_id: c.id, is_error: true, content: e.message }); }
  }
  messages.push({ role: "user", content: results });
}

Ausgeführt wird so.

node harness.mjs

Es sind nur ein paar Dutzend Zeilen, aber schon jetzt sind „die KI selbst“, „die verfügbaren Werkzeuge“, „der erlaubte Bereich“, „die Obergrenze für Wiederholungen“ und „der Stopp bei Schaden“ sauber getrennt. Das ist das Skelett eines Harness. Setzt du nun Suche, Testlauf, Freigabe-Warteschleife und Benachrichtigungen darauf, wächst es nach und nach zu etwas, das aussieht wie Claude Code.

In diesen Situationen zahlt es sich aus (drei)

1. Die Massenkontrolle bei Artikeln und Material Wenn du es bei „Schreib einen Blogartikel“ belässt, produziert die KI seelenruhig dünne Artikel und „fast dasselbe Thema“ am Fließband. Also gibst du dem Harness den Ablauf vor: „Bestehende Titel lesen → ein Thema ohne Überschneidung wählen → den Text schreiben → Zeichenzahl und Links maschinell prüfen“. Dann muss kein Mensch lange grübeln, ob der Artikel gut ist – der Türsteher fischt den dünnen Artikel schon vorher raus. Bei mir landen seither jeden Monat mehrere Entwürfe noch vor der Veröffentlichung im Stopp. Das Gefühl ist: „Gut, dass er stehen geblieben ist.“

2. Anfragen sortieren „Lies die eingegangenen Anfragen und sag mir nur die, aus denen ein Geschäft werden könnte.“ Das Lesen darf automatisch laufen. Aber die Eintragung in die Kundenliste bleibt liegen, bis ein Mensch den Knopf drückt – das erzwingt das Harness. Lesen automatisch, Schreiben als Entwurf (dry run), nur die finale Eintragung durch den Menschen. Damit verschwindet der Unfall, dass eine falsch einsortierte Kundin einfach so in die echte Datenbank wandert.

3. Einmal durchatmen vor dem Deployment Bevor jemand den Veröffentlichen-Knopf drückt, lässt du prüfen: Läuft der Build durch, sind alle Umgebungsvariablen da, sieht das Diff wie erwartet aus, gibt es einen Weg zurück? Die KI neigt dazu, nur die „letzte Zeile“ des Fehlerlogs zu lesen und dann am falschen Ende zu reparieren. Deshalb der Trick: vorher festlegen, „wo man hinschaut“. Nicht das ganze Log übergeben, sondern auf die paar Dutzend relevanten Zeilen eingrenzen. Schon das senkt die Zahl daneben gegriffener Reparaturen deutlich.

Drei Dinge, die man sich von Claude Code „abschauen“ kann

Wenn du selbst ein Harness baust, musst du nicht bei null anfangen. Claude Code ist eine Fundgrube an Vorlagen. Du musst nicht alles nachbauen – schon diese drei Dinge früh zu übernehmen, macht es auf einen Schlag stabiler.

Erstens: Regeln in Schichten aufteilen. Verabredungen, die sich nie ändern, kommen in die Konfigurationsdatei; Anweisungen nur für dieses eine Mal in eine Notiz vor Ort; langfristige Vorlieben an einen separaten Platz. Schreibst du alles jedes Mal in den Prompt, wird er lang und die Genauigkeit fällt.

Zweitens: Deterministische Arbeit an Kommandos delegieren. Formatieren, Prüfen, Testen – das läuft über ein Kommando wie npm test schneller und zuverlässiger, als wenn man die KI darum bittet. Der KI bleibt nur das „Denken“.

Drittens: Schwere Recherche an einen anderen Zuständigen auslagern. Lange Logs oder das Einlesen riesiger Dateimengen in das Hauptgespräch zu kippen, vernebelt die eigentliche Entscheidung. Lass die Vorrecherche von einem separaten Prozess machen und nimm nur das Fazit entgegen. Allein das bringt die Schärfe der Entscheidung zurück.

Drei Fehler, die ich selbst gebaut habe

Ehrlich gesagt: Mein erstes Harness war ein einziger Unfall.

Der erste: Ich habe zu viele Werkzeuge in die Hand gegeben. In der Annahme, viel hilft viel, hatte ich rund dreißig Werkzeuge bereitgestellt – und die KI fragte sich „Welches denn jetzt?“ und traf reihenweise seltsame Entscheidungen. Heute begrenze ich es anfangs auf fünf bis zehn.

Der zweite: Die Fehlermeldungen waren unfreundlich. Wenn ich nur Error: failed zurückgab, konnte die KI nichts reparieren. Erst als ich es so zurückgab wie „README.md nicht gefunden. In sandbox liegt nur note.md“ – also Ursache und nächster Schritt mit dazu –, fing sie plötzlich an, sich selbst zu helfen.

Der dritte: Ich habe die Kontrolle allein dem menschlichen Auge überlassen. „Am Ende schau ich ja selbst drüber“ – das bricht an einem vollen Tag garantiert zusammen. Erst als ich maschinell prüfbare Türsteher einbaute – Zeichenzahl, tote Links, Typfehler –, wurden die nächtlichen Kontrollen deutlich weniger.

Wenn du anfangen willst, dann hier

Bau nicht gleich „den voll autonomen, klugen Agenten“. Wähl eine kleine Aufgabe, bei der ein Fehler reversibel ist. Die Kontrolle eines Artikelentwurfs, die erste Durchsicht eines PRs, das Sortieren von Anfragen, der Check vor der Staging-Veröffentlichung. Diese Größenordnung ist genau richtig.

Die Reihenfolge ist immer dieselbe. ① Den Lesebereich eng festlegen → ② das Ziel (das Ergebnis) klar machen → ③ die Kontrolle so weit wie möglich Kommandos überlassen → ④ gefährliche Operationen (Löschen, Produktions-DB, Bezahlung, Force-Push) anfangs allesamt auf „den Menschen fragen“ stellen. Nur die Operationen, die sich als sicher erwiesen haben, stuft man später auf automatisch hoch. Allein wenn du diese Reihenfolge einhältst, sinkt die Zahl der Unfälle erstaunlich.

Wie man Berechtigungen festlegt, steht im Leitfaden zu Claude-Code-Berechtigungen; wie man die Grundlage für den Einsatz im Team legt, in den CLAUDE.md-Best-Practices. Wer lange Arbeit aufteilen will, schaut zusätzlich in die Muster für Subagenten. Die offizielle Denkweise findest du als Primärquelle in der Dokumentation zum Claude Agent SDK.

Was beim Ausprobieren herauskam

Seit dem „40-Dateien-Unfall“ am Anfang habe ich aufgehört, mich mit der Frage „Soll ich der KI vertrauen oder nicht“ herumzuschlagen. Worauf ich stattdessen schaue, ist: an welchem Türsteher es gestoppt hat. Ein einziges safePath mehr im Minimal-Harness, und die Unfälle außerhalb des Ordners gingen auf null. Eine automatische Prüfung von Zeichenzahl und Links dazu, und dünne Artikel bleiben vor der Veröffentlichung stehen. Statt nach der klügeren KI zu suchen, baut man besser zuerst ein Gerüst, an dem man sich beim Hinfallen nicht verletzt. Sieht nach Umweg aus, ist aber der schnellste Weg – das ist mein heutiges Gefühl.

Fazit

Harness Engineering ist keine Technik, um Prompts hübsch zu verzieren. Es ist die Technik, zu gestalten, was man der KI zeigt, was man sie tun lässt, wo man sie stoppt und wie man prüft. Lass zuerst die 30 Zeilen oben laufen und fang damit an, deiner eigenen Arbeit einen einzigen „Türsteher“ hinzuzufügen. Die Qualität der KI-Arbeit entscheidet sich nicht an der Klugheit des Modells, sondern am Gerüst drumherum.

Wer KI systematischer und sicher in die eigenen Abläufe einbauen will, schaut in die Übersicht über Lernmaterial und Vorlagen; wer im ganzen Team Berechtigungen, Reviews und Verifikation aufsetzen will, in Schulung und Einführungsberatung.