Software nach AI: Der Beginn des Harness-Zeitalters

• Das Ende des Software-Zeitalters ist der Beginn des Harness-Zeitalters, und SaaS, das mit festen Workflows und verwalteten Datenbanken betrieben wurde, wird derzeit durch intelligente AI ersetzt
• AI ist mächtig, aber wie ein Wildpferd noch ungezähmt; um ihre Kraft zu nutzen, ist systematische Kontrolle (domestication) erforderlich
• Das Harness für AI-Agenten wird durch 7 zentrale Komponenten definiert, die ein zentrales LLM umgeben; jede davon bestimmt Zuverlässigkeit und Performance auf Produktionsniveau
• In einer Ära, in der alle Unternehmen Zugang zu denselben Modellen haben, gewinnt nicht das Modell selbst, sondern die Seite, die das Harness besser entwirft und betreibt (best rider)
• Tausende voneinander getrennte Märkte, die von den großen Labs nicht priorisiert werden, bleiben eine Chance für Startups

---

Die Bedeutung des Harness-Zeitalters

• AI ersetzt die auf festen Workflows basierende SaaS und verwaltete Datenbanken durch Intelligenz (intelligence) und definiert damit das Software-Paradigma neu
• AI wird mit einem Mustang verglichen: kraftvoll, aber rau und in dieser Form nicht direkt einsetzbar; dieses Zähmen ist das Harness
• Das Wesen dieser Zähmung ist eine Architektur, bei der das LLM im Zentrum steht und sieben Komponenten radial darum angeordnet sind

Die 7 Komponenten des Harness für AI-Agenten

• 1. Context & Memory (Kontext und Speicher)

  • Universelle Modelle benötigen maßgeschneiderte Retrieval-Systeme (bespoke retrieval) je nach Anwendungszweck; ein Kontext-Retrieval-System für Radiologen kann nicht dasselbe sein wie eines für juristische Assistenzen
  • Kurzzeitgedächtnis ("Was hat der Agent vor 45 Sekunden getan?"), groß angelegte Bildsuche (Radiologie/Bilderzeugung), Keyword-Suche über Milliarden Dokumente hinweg – je nach Fall ist ein anderes System nötig
  • Neben dem Retrieval liegt eine Kontext-Datenbank, die als „Rezeptbuch“ dafür dient, wie ein Unternehmen tatsächlich arbeitet
    • Standard Operating Procedures (SOPs), die Menschen im Kopf mit zur Arbeit bringen, sind genau diese Rezepte
    • Die anfängliche Erfassung und die Weiterentwicklung durch Veränderungen bei Menschen und Prozessen bilden den Kern der Kontext-Datenbank

• 2. Tools & Action (Tools und Aktionen)

  • Tools sind das Mittel, mit dem der Agent auf die Außenwelt einwirkt; wenn die Rezepte in der Kontext-Datenbank festlegen, „was zu tun ist“, dann sind Tools die Zutaten und Instrumente, um es tatsächlich auszuführen
  • Moderne Harnesses stellen Tools über eine Registry bereit, validieren die vom Modell übergebenen Argumente, dispatchen Aufrufe, leiten sensible Vorgänge durch Approval-Gates und parsen die Ergebnisse zurück in den Agenten-Loop
  • MCP entwickelt sich zum connective tissue für Tool-Anbindungen
  • Die Qualität eines Harnesses wird davon bestimmt, wie viele Tools sicher exponiert werden können und wie sauber mit Fehlern umgegangen wird

• 3. Orchestration & Loop (Orchestrierung und Loop)

  • Der Agenten-Loop folgt der Struktur think → act → observe → repeat
  • Planung, Aufgabenzerlegung, Sub-Agenten, Retries und Abbruchbedingungen definieren, wie Arbeit ausgeführt wird
  • Das System sollte sich mit der Nutzung verbessern; Closed-Loop-Patterns, die aus jeder Ausführung lernen, sind ein Differenzierungsmerkmal zwischen Anbietern

• 4. State & Persistence (Zustand und Persistenz)

  • In großen Enterprise-Umgebungen, in denen viele Personen das System gleichzeitig nutzen, ist Resilienz (resilient) unverzichtbar
  • Wenn das Harness bei Schritt 7 eines 10-stufigen Ablaufs abstürzt, muss es bei Schritt 8 wieder aufnehmen statt von vorne zu beginnen
  • Dateisysteme, Checkpoints, Session-Threads und Artifact Stores sind Mechanismen, die Arbeitsverlust verhindern

• 5. Sandbox & Compute (Sandbox und Compute)

  • Jeder Agent benötigt einen isolierten Arbeitsbereich (Sandbox)
  • Isolierte Unix-Workspaces, kontrollierter Netzwerk-Egress und Credentials, die außerhalb des Modells gespeichert werden, gewährleisten Sicherheit, Vertraulichkeit und Geschwindigkeit im großen Maßstab

• 6. Observability & Governance (Observability und Governance)

  • „Was man nicht sehen kann, kann man nicht vertrauen“ – das Nachverfolgen jedes Schritts, das Logging jedes Tool-Calls, das Ausführen von Evals als Regressionstests und Human-in-the-Loop bei Entscheidungen mit höchstem Risiko verwandeln eine Demo in ein Produktionssystem
  • Guardrails setzen Policies durch, Evals erkennen Regressionen vor den Kunden

• 7. Cost & Workflow Optimization (Kosten- und Workflow-Optimierung)

  • Der siebte Punkt ist architektonisches Urteilsvermögen (architectural judgment)
  • Die Unterscheidung, was deterministisch vs. nicht deterministisch verarbeitet werden sollte, die Auswahl des passenden Modells pro Schritt (State of the Art, mittelgroß, klein, Fine-Tuning) sowie die Entscheidung, ob Wissen in Skills oder im Speicher liegen sollte

Neue Wettbewerbsdynamik

• Das Ergebnis ist eine neue Wettbewerbsdynamik in Software, die nicht in jeder Kategorie gleichermaßen gilt
• Märkte, die von den Major Labs (führenden AI-Forschungslaboren) priorisiert werden, profitieren von schnellerer Umsetzung und direkter Modellkontrolle
• Darüber hinaus stehen jedoch Tausende eigenständige Märkte Startups offen
• In einer Zeit, in der alle Unternehmen dieselben Modelle nutzen können, gewinnen die „best riders“ – also diejenigen mit der stärksten Kompetenz beim Entwurf und Betrieb des Harnesses

[junghan0611]

pi ist sehr leichtgewichtig, daher nutze ich es gern als Agent-Tool. Zusätzlich wollte ich auch Claude Code und Gemini anbinden, deshalb habe ich pi-shell-acp gebaut und nutze es ebenfalls gut. Ich erstelle und verwende mehrere Skills, und je mehr ich damit ausprobiere, desto besser gefällt mir die Anpassung an meinen eigenen Stil. Wenn ich Claude Code, Codex usw. direkt benutze, schalte ich im Yolo-Modus alle Built-in-Tools bis auf das Niveau von pi praktisch komplett aus. Wie mit einem Gummihammer eingeschlagen: Neue Funktionen sofort auf off.

[runai]

Ich habe alle Harness-Einstellungen, die ich hatte, entfernt.
Je weiter sich Modelle entwickeln, desto mehr wirkt ein Harness als Faktor, der die Leistung des Modells einschränkt.
Halbgare Harness-Einstellungen führen im Gegenteil sogar zu schlechteren Ergebnissen.
Die Harness-Einstellungen, die bereits unter 4.7 und darunter vorhanden waren, haben in 4.8 keine Bedeutung mehr
und sind selbst bei GPT 5.5 nur noch hinderlich.

[hanje3765]

Die im Text erwähnten Harness-Komponenten sind nichts, was sich einfach dadurch lösen ließe, dass die Intelligenz von LLMs steigt.

Wenn Sie vom Harness aus einer Zeit sprechen, in der die Definition von Harness noch unklar war, kann ich das nachvollziehen. Wenn aber das im Text gemeinte Harness gemeint ist, wirkt es wie ein Bereich, der auch künftig kontinuierlich gepflegt werden muss.

[runai]

Weniger als um die Frage der Intelligenz geht es darum, dass die Modelle zusätzlich zur Intelligenz auch Fähigkeiten in Bereichen wie Orchestrierung und dem Einsatz von Tools entwickeln. Gerade der Bereich Orchestrierung war eines der Kernstücke von Harness, inzwischen wird aber selbst das unterstützt. Wenn es also zum jetzigen Zeitpunkt sowohl zusammengebastelte Orchestrierung als auch vollwertige Orchestrierung gibt: Was sollte man dann verwenden?

[kaydash]

Ich stimme zu. Wir müssen gemeinsam entsprechend entwickeln.

[emptybynature]

Auf der OpenAI-Website gibt es einen offiziell veröffentlichten Beitrag über Harnessing. Darin werden Erfahrungsberichte und Tipps dazu geteilt, wie Harnessing intern bei OpenAI eingesetzt wurde. Das heißt, selbst OpenAI nutzt Harnessing für eigene interne Projekte. Harnessing ist definitiv notwendig und hat direkten Einfluss auf die Qualität der finalen Umsetzung. Vor allem kann es die Anzahl der Tokens, die für die Umsetzung eines Ergebnisses in derselben Qualität benötigt werden, sogar um bis zu die Hälfte reduzieren. Man kann damit sowohl Performance als auch Kosten optimieren — es gibt also keinen Grund, es nicht zu nutzen.

[runai]

In Opus 4.8 wurde ultracode effort hinzugefügt, und das löst die Aufgaben, die zuvor der handgebaute Harness-Modus von Entwicklern übernommen hat, besser. Daher halte ich es zum jetzigen Zeitpunkt für sinnvoller, im bisher verwendeten Harness-Modus den Orchestrierungs-Teil zu entfernen.

[gulbi135]

Ich stimme zu. Ich habe für 4.7 ebenfalls handgemachte Orchestrierung oder das Aufzwingen ausufernder Planung entfernt, weil das in 4.8 eher hinderlich ist.
Allerdings liegt in Codebasen mit mehreren hunderttausend Zeilen, die über Jahre gewartet wurden, der eigentliche Wert eines Harness nicht in der Orchestrierung, sondern in den Schichten, die ultracode nicht ersetzen kann (Wissensgraph, Domain-Konventionen, Validierungsinvarianten). Deshalb habe ich diese Kontextschicht beibehalten und nur wirklich unabhängige Bereiche per Workflow parallelisiert.
Umgekehrt halte ich bei neuen Projekten ultracode auch ohne Harness für passend. Letztlich scheint es also keine Frage von „entfernen vs. beibehalten“ zu sein, sondern eine, die sich je nach Alter der Codebasis und Grad der Kopplung unterschiedlich entscheidet.

[runai]

Ja, genau. Auch der Teil ohne Orchestrierung bleibt weiterhin wertvoll.