Harness Engineering wird zum Beruf – was wirklich dazugehört

In den letzten zwei Jahren drehte sich der Karriereratschlag rund um KI-Agenten meist darum, ihnen gutes Prompting beizubringen. Das ist längst nicht mehr die knappe Fähigkeit. Die knappe Fähigkeit besteht darin, das Gerüst zu bauen, in dem ein Agent operiert – das, was zunehmend als Harness bezeichnet wird –, und das ist spezifisch genug und schwierig genug, dass daraus eine eigene Stellenbeschreibung wird, statt eine Nebenaufgabe der „KI-Person" im Team zu bleiben.

Die klarste öffentliche Schritt-für-Schritt-Darstellung dessen, was das tatsächlich bedeutet, stammt von Lenny's Newsletter, der dokumentiert, wie das Produktmanagement-Tool ChatPRD eine Harness gebaut hat, um Sentry-Bugs automatisch zu debuggen. Der Artikel lohnt sich in voller Länge, wenn man erwägt, sich hierauf zu spezialisieren, denn er macht einen Punkt deutlich, der leicht übersehen wird: Das Modell war nie der Engpass. Das Team nutzte das Claude Agent SDK als Grundlage und steckte den Großteil seines technischen Aufwands dann in eine eigene Terminal-Oberfläche sowie eine Reihe von Adaptern, die den Agenten mit Sentry, Linear, GitHub und Vercel verbinden. Das ist die Aufgabe im Kleinen. Vier Systeme, vier verschiedene Auth-Schemata, vier verschiedene Datenformate und eine Oberfläche, die es einem Menschen erlaubt, zuzusehen und einzugreifen, ohne bei jedem Schritt Wache stehen zu müssen.

Woraus „Harness" sich eigentlich zusammensetzt

Wer herausfinden möchte, ob es sich lohnt, dieses Skillset aufzubauen, dem hilft es, es in Teile zu zerlegen, für die getrennt eingestellt wird – oder die zumindest in einem Vorstellungsgespräch getrennt bewertet werden:

• Berechtigungsdesign. Festlegen, was ein Agent unbeaufsichtigt tun darf (ein Ticket lesen, einen PR entwerfen) im Gegensatz zu dem, wofür ein Mensch im Loop gebraucht wird (mergen, deployen, löschen, Geld ausgeben) – und das als tatsächliche Policy im Code kodieren, nicht als Prompt-Anweisung, die das Modell unter Druck ignorieren könnte. Das ist eher Access-Control-Engineering als Prompt-Schreiben.
• Tool-Adapter. Schlanke, gut getestete Wrapper um jedes externe System (Sentry, Linear, GitHub, Vercel oder was auch immer im Stack des Unternehmens steckt), die die Absicht des Agenten in einen sicheren, validierten API-Aufruf übersetzen und die Antwort wiederum in etwas übersetzen, worüber das Modell nachdenken kann. Das ist gewöhnliches Software-Engineering – Fehlerbehandlung, Retries, Schema-Validierung –, nur angewandt auf einen neuen Konsumenten.
• Terminal- oder Konsolen-UI. Eine Möglichkeit für einen Menschen zu sehen, was der Agent tut, Aktionen zu genehmigen oder abzulehnen und einzugreifen, wenn er stecken bleibt. ChatPRD hat eine eigene gebaut; viele Teams werden stattdessen auf fertige Agent-Konsolen zurückgreifen, aber jemand muss trotzdem entscheiden, was angezeigt wird, was verborgen bleibt und was einen Klick erfordert, bevor es geschieht.
• Tool-Auswahl im großen Maßstab. Ein Beitrag von Machine Learning Mastery weist auf etwas hin, das wichtig zu wissen ist, sobald man mehr als eine Demo baut: Die Genauigkeit von Agenten bei Tool-Aufrufen tendiert dazu, sich zu verschlechtern, sobald der Tool-Katalog etwa ein Dutzend Optionen überschreitet – das Modell fängt an, Tools falsch aufzurufen, Parameter zu halluzinieren oder bei fehlerhaften Aufrufen hängenzubleiben. Die dort aufgeführten Gegenmaßnahmen (steuern, welche Tools in einem bestimmten Kontext überhaupt sichtbar sind, retrieval-basiertes Tool-Lookup, Weiterleitung an spezialisierte Sub-Agenten, explizite Planungsschritte, Fallback-Logik und Benchmark-Harnesses zum Abfangen von Regressionen) sind selbst eine Checkliste von Dingen, die ein Harness-Engineer nicht nur kennen, sondern auch umsetzen können muss.
• Context- und Memory-Engineering. Dieselbe Quelle trifft eine Unterscheidung, die es sich zu verinnerlichen lohnt: Context Engineering (was in einen einzelnen Inferenzaufruf einfließt, und wo) und Memory Engineering (was über Sitzungen hinweg erhalten bleibt, wie es gespeichert und wie es abgerufen wird) sind unterschiedliche Disziplinen mit unterschiedlichen Fehlermodi. Ihre These lautet, dass die meisten Ausfälle bei lang laufenden, sitzungsübergreifenden Agenten darauf zurückgehen, dass beides vermischt wird – Sitzungsgedächtnis wird behandelt, als wäre es einfach nur mehr Kontext, oder umgekehrt –, insbesondere an dem Punkt, an dem das System entscheidet, was abgerufen wird.

Die Belege dafür, dass dies eine echte, finanzierbare Rolle ist – keine bloße Hobbynische

Skeptiker werden zu Recht fragen, ob „Harness Engineer" ein eigener Job ist oder nur eine Aufgabe innerhalb eines anderen Jobs. Zwei Datenpunkte aus der Zusammenstellung deuten darauf hin, dass es sich in Richtung Ersteres entwickelt. Erstens nutzte das Aspire-Team von Microsoft – eine zehnköpfige Gruppe – GitHubs Agentic Workflows, um repoübergreifende Dokumentations-PRs zu automatisieren, und mergte über zwei Releases hinweg 82 PRs mit einem Median von 44,8 Stunden nach dem Erscheinen des jeweiligen Produkt-PRs, ohne zusätzliches Personal und ohne Prozessumschulung. Das ist ein kleines Team, das überproportionale Hebelwirkung erzielt, gerade weil jemand in das Gerüst investiert hat (die Workflow-Definitionen, das Review-Routing, die Trigger-Logik), statt Ingenieure die Doku-PRs von Hand schreiben zu lassen. Zweitens behandelt das SkillOpt-Projekt von Microsoft Research Agenten-„Skill"-Dateien – die Anweisungen und Einschränkungen, die bestimmen, wie sich ein Agent in seiner Harness verhält – als etwas, das systematisch optimiert statt von Hand bearbeitet werden sollte, und berichtet, dass es in allen 52 Zellen eines Benchmark-Rasters (sechs Benchmarks, sieben Modelle, drei Ausführungsmodi) am besten oder gleichauf am besten abschnitt, wobei die optimierten Skills sich über verschiedene Modelle und verschiedene Harnesses hinweg übertragen ließen. Ob dieses spezielle Tool zum Standard wird oder nicht, es signalisiert, dass die Branche beginnt, Harness-Konfiguration als technisches Artefakt mit eigenem Tooling und eigenen Benchmarks zu behandeln – dieselbe Entwicklung, die „DevOps" von einer Ansammlung von Ad-hoc-Skripten zu einer eigenen Disziplin gemacht hat.

Zudem wird inzwischen explizit Infrastruktur für diese Ebene gebaut. Googles neu angekündigte „Managed Agents"-Funktionen in der Gemini-API – Hintergrund- und asynchrone Ausführung, Integration entfernter MCP-Server, benutzerdefinierte Function-Calls, Credential-Refresh über mehrere Interaktionen hinweg – sind im Grunde vorgefertigte Verrohrung für genau die Probleme, die das ChatPRD-Team von Hand gelöst hat. Das ist ein normales Muster: Was ein Team dieses Jahr maßgeschneidert baut, macht ein Plattformanbieter nächstes Jahr zum Produkt. Das schafft die Rolle des Harness-Engineers nicht ab; es hebt die Untergrenze an und verschiebt die Aufgabe hin zum Integrieren und Konfigurieren verwalteter Bausteine, statt jeden Adapter von Grund auf zu schreiben – ähnlich wie Cloud-Infrastruktur Ops-Ingenieure nicht überflüssig gemacht, sondern verändert hat, womit sie ihre Zeit verbringen.

Was das bedeutet, wenn man auf diese Rolle hinarbeitet

Ein paar konkrete, überprüfbare Dinge fürs Portfolio oder den Lebenslauf, um für diese Arbeit glaubwürdig zu sein: einen Adapter durchgängig gegen eine echte API bauen, die man nicht selbst kontrolliert (inklusive Auth, Fehlerbehandlung, Rate Limits, nicht nur eine Happy-Path-Demo); ein Berechtigungsmodell für einen Agenten entwerfen und dokumentieren, das zwischen Lese-, Vorschlags- und Handlungsaktionen unterscheidet und zeigt, warum jede Grenze dort verläuft, wo sie verläuft; sowie eine Review-Oberfläche bauen oder konfigurieren, in der ein Mensch Agenten-Aktionen genehmigt, bevor sie ausgeführt werden, da das der Teil ist, auf den die meisten Unternehmen bestehen werden, bevor sie einen Agenten an die Produktion lassen. Wer ein Stellenangebot als Harness Engineer bewertet oder die eigenen Zuständigkeiten abgrenzt, sollte gezielt fragen, wer das Berechtigungsmodell verantwortet, wer die Adapter verantwortet und wer die Human-Review-Oberfläche verantwortet – bei vielen Teams haben diese drei Dinge derzeit keinen klaren Verantwortlichen, und genau diese Lücke soll die Rolle füllen.

Ein Vorbehalt, den man klar aussprechen sollte: Keine der obigen Quellen liefert eine belastbare Zahl zum Arbeitsmarkt für diesen konkreten Titel, und „Harness Engineer" ist noch kein Jobtitel, den man in Stellenanzeigen findet – er taucht innerhalb von Titeln wie „AI Infrastructure Engineer", „Agent Platform Engineer" oder schlicht „Senior Backend Engineer, AI Systems" auf. Man sollte das als Skillset betrachten, das es aufzubauen und akkurat zu beschreiben gilt, nicht als Titel, nach dem man bei LinkedIn sucht.