Was zum Teufel macht ein Harness Engineer & warum ist der Job so wichtig?

AAI Jason
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00Vielen Dank an HubSpot für das Sponsoring dieses Videos.
00:00:03Im Dezember 2025 ist tatsächlich etwas wirklich Großes passiert.
00:00:07Und die meisten Leute haben es nicht einmal bemerkt.
00:00:09Andrew Cupsey hat letzte Woche darüber getwittert.
00:00:10„Es ist schwer zu vermitteln, wie sehr sich das Programmieren durch KI in den letzten zwei Monaten verändert hat,
00:00:15insbesondere seit letztem Dezember."
00:00:17Und auch Greg von OpenAI hat darüber gesprochen.
00:00:20Seit Dezember gibt es sprunghafte Verbesserungen bei den Fähigkeiten des Modells und der Tools.
00:00:24Einige Ingenieure erzählten ihm, dass sich ihr Job seit Dezember 2025
00:00:28grundlegend verändert hat.
00:00:29Was ist also im Dezember 2025 eigentlich passiert?
00:00:32Kurz gesagt: Das neueste Modell, das damals eingeführt wurde, ist endlich bereit für vollautonome,
00:00:37lang laufende Aufgaben.
00:00:38Bei KI war der ultimative Traum schon immer, dass die KI vollautonom rund um die Uhr arbeiten kann,
00:00:43während wir schlafen.
00:00:46Sogar im Jahr 2023 hieß das bekannteste Projekt, falls Sie sich erinnern, AutoGPT.
00:00:50Damals wurden diese vollautonomen Agentensysteme zum ersten Mal vorgestellt.
00:00:54Sie hatten eine recht einfache Architektur, die GPT-4 als Modell nutzte, um Aufgaben basierend auf dem Nutzerziel
00:00:59selbstständig zu zerlegen, und einen einfachen Speicher besaß,
00:01:03um die Ergebnisse zu sichern.
00:01:04Die Leute haben ziemlich verrückte Dinge ausprobiert, wie zum Beispiel das Ziel vorzugeben, 100.000 Dollar zu verdienen,
00:01:08und die KI die Aufgaben endlos wiederholen zu lassen, bis das Ziel erreicht ist.
00:01:11Damals scheiterte das System kläglich, weil das Modell einfach noch nicht bereit war.
00:01:15Aber seit letztem Dezember hat sich das wirklich geändert.
00:01:18Die Modelle haben eine deutlich höhere Qualität, langfristige Kohärenz und können
00:01:22viel größere und längere Aufgaben bewältigen.
00:01:24Und wir haben alle möglichen Experimente aus der Branche gesehen.
00:01:28Zuerst gab es ab Januar dieses brandheiße Konzept namens „Rough Loop“ – eine sehr einfache
00:01:33Agenten-Iterationsschleife, um das Modell zu zwingen, länger zu arbeiten,
00:01:37damit es komplexere Aufgaben bewältigen kann.
00:01:38Wir haben das Modell einfach mit ein paar einfachen Bedingungsprüfungen in eine Schleife geschickt, aber wir sahen bereits
00:01:42den Unterschied.
00:01:43Und eine Woche später veröffentlichte Cursor ein Experiment, bei dem sie GPT-5.2 nutzten,
00:01:49um autonom einen Browser mit 3 Millionen Zeilen Code von Grund auf zu erstellen.
00:01:52Anthropic veröffentlichte ebenfalls ein Experiment, bei dem ein Team von „Cloud Codes“
00:01:57zwei Wochen lang autonom an einem C-Compiler von Grund auf arbeitete.
00:02:01Am Ende lieferten sie eine funktionale Version ohne jegliche manuelle Codierung ab.
00:02:05Man kann darin sogar das Spiel Doom ausführen.
00:02:08Gleichzeitig begann OpenClaw Aufmerksamkeit zu erregen und erlebte ein explosives Wachstum,
00:02:13wie wir es noch nie zuvor gesehen hatten.
00:02:14Es war schwer zu verstehen, was bei OpenClaw vorging, denn von außen betrachtet
00:02:18könnte man es leicht als ein weiteres Programm abstempeln, das auf dem Computer lebt
00:02:23und auf das man auch über Telegram zugreifen kann.
00:02:27Warum also ist das so populär?
00:02:29Erst nachdem ich es intensiv genutzt habe, wurde mir klar, dass der wahre Unterschied darin liegt, dass OpenClaw
00:02:35diesen Typ von immer aktiven, lang laufenden und vollautonomen Agenten repräsentiert.
00:02:40Das unterscheidet sich stark von früheren Systemen, bei denen der Mensch der Haupttreiber war,
00:02:45der den nächsten Schritt anstoßen musste.
00:02:46OpenClaw ist immer an und agiert proaktiv.
00:02:49Dieses autonome Gefühl entsteht durch eine recht einfache Architektur mit einer
00:02:53Speicher-Kontext-Ebene, Triggern und Cron-Jobs, um automatisch Aktionen auszuführen,
00:02:58und vollem Computerzugriff – eine mächtige Umgebung.
00:03:02Ich glaube, OpenClaw ist das erste Projekt, das den großen Paradigmenwechsel im Jahr 2026 eingeleitet hat,
00:03:06weg von einfachen Copilot-Systemen hin zu diesen lang laufenden,
00:03:13vollautonomen Agenten.
00:03:15Etwas, das immer aktiv ist und selbstständig hochkomplexe, koordinierte Arbeit liefert.
00:03:20Das ist ein entscheidender Wandel, den man verstehen muss.
00:03:22Die heutigen Modelle sind viel leistungsfähiger als man denkt, solange man das richtige
00:03:27System entwirft, um dieses Potenzial freizusetzen.
00:03:28Und das ist der Kern dessen, worüber ich heute sprechen möchte.
00:03:30Das „Harness Engineering“, um lang laufende autonome Systeme zu ermöglichen.
00:03:34Falls Sie den Begriff „Harness Engineering“ zum ersten Mal hören: Es ist die Weiterentwicklung
00:03:38von dem, was wir bisher Context Engineering oder Prompt Engineering genannt haben.
00:03:41Bisher haben wir uns darauf konzentriert, die Prompts innerhalb des Kontextfensters zu optimieren,
00:03:46um die beste Leistung für eine einzelne Sitzung zu erzielen.
00:03:49Beim Harness Engineering geht es jedoch um lang laufende Aufgaben, also darum,
00:03:53ein System zu entwerfen, das über verschiedene Sitzungen und mehrere Agenten hinweg funktioniert.
00:03:57Wie gestaltet man den Workflow so, dass für jede Sitzung der relevante Kontext abgerufen wird
00:04:01und die richtigen Werkzeuge bereitstehen, um das Maximum aus den Modellen herauszuholen?
00:04:05Das ist ein recht neues Konzept, aber das Gute ist, dass sich die Branche bereits
00:04:09auf einige Best Practices von Anthropic, Vercel, LangChain und vielen anderen geeinigt hat.
00:04:14Wir werden diese nacheinander durchgehen, damit Sie die Muster erkennen können.
00:04:16Doch bevor wir eintauchen: Mit diesem Wechsel zu autonomen Agenten liegt eine der größten
00:04:21Chancen der nächsten 6 bis 12 Monate darin, ein „OpenClaw“ für eine bestimmte Branche zu bauen.
00:04:25Das bedeutet, den End-to-End-Workflow eines bestimmten Sektors tiefgreifend zu verstehen
00:04:29und einen autonomen Agenten mit der passenden Umgebung zu entwickeln, der den Prozess komplett übernimmt.
00:04:34Deshalb möchte ich Ihnen diese großartige Studie von HubSpot über die
00:04:39KI-Adoption im E-Mail-Marketing vorstellen.
00:04:40Es ist ein faszinierender Bericht, um zu verstehen, wo Menschen in einer Branche wie dem E-Mail-Marketing
00:04:44heute tatsächlich KI einsetzen und wo noch Lücken klaffen.
00:04:47Dieser Bericht zeigt klare Workflows und Möglichkeiten im E-Mail-Marketing auf,
00:04:51die man potenziell automatisieren kann.
00:04:52Es wurden Hunderte von E-Mail-Marketern aus Top-Unternehmen befragt, um genau zu verstehen, wie KI
00:04:57ihre Arbeitsabläufe verändert.
00:04:58Es wird thematisiert, warum Marketer immer noch viel manuell nachbearbeiten,
00:05:03woran das liegt und welches die größten Herausforderungen bei der Implementierung von KI
00:05:06im E-Mail-Marketing sind.
00:05:07Jede dieser Herausforderungen ist eine Chance für Sie, einen vollautonomen Agenten zu bauen.
00:05:11Der Bericht geht sogar auf spezifische KPIs ein, die besonders wichtig sind und bei denen KI
00:05:15nachweislich Ergebnisse geliefert hat.
00:05:16Sowie darauf, was genau E-Mail-Marketer sich wirklich von der KI wünschen.
00:05:20Wenn Sie also ein Entwickler sind, der über das nächste große Agenten-Produkt nachdenkt,
00:05:24kann ich Ihnen diese Ressource nur wärmstens empfehlen.
00:05:27Ich habe den Link zum kostenlosen Download in die Beschreibung gepackt.
00:05:30Und danke an HubSpot für das Sponsoring dieses Videos.
00:05:32Kommen wir zurück zum Harness Engineering für lang laufende Agentensysteme.
00:05:36Es gibt im Wesentlichen drei Erkenntnisse, die ich daraus mitgenommen habe.
00:05:39Erstens: Für lang laufende Agenten ist der entscheidende Teil des Systemdesigns die Schaffung
00:05:44einer „lesbaren Umgebung“, in der jeder Sub-Agent oder jede Sitzung genau versteht,
00:05:49wie der aktuelle Stand ist.
00:05:50Es gibt wahrscheinlich Workflows, die man nutzen kann, um die Lesbarkeit der Umgebung zu erzwingen.
00:05:54Das werde ich gleich noch näher erläutern.
00:05:56Zweitens ist die Verifizierung entscheidend.
00:05:58Sie können die Systemausgabe erheblich verbessern, indem Sie dem System ermöglichen,
00:06:03seine Arbeit durch schnellere Feedbackschleifen effektiv zu überprüfen.
00:06:04Und drittens müssen wir dem Modell mehr vertrauen, anstatt spezialisierte Werkzeuge zu bauen,
00:06:08die zu viel Logik und Reasoning vorzeitig vorwegnehmen.
00:06:11Wir sollten dem Modell maximalen Kontext mit generischen Werkzeugen geben, die es nativ versteht,
00:06:16und es wie einen Menschen explorieren lassen.
00:06:17Ich werde diese drei Punkte nun einzeln aufschlüsseln.
00:06:20Zuerst Anthropics Blogbeitrag über effektive Strukturen für lang laufende Agenten.
00:06:24Sie haben mit dem Cloud Code SDK experimentiert, um einen spezialisierten Agenten für extrem
00:06:29lang laufende Aufgaben zu bauen, wie zum Beispiel den Klon der Website cloud.ai.
00:06:32Die ersten Misserfolge, die sie beobachteten, waren erstens: Agenten neigen dazu, zu viel auf einmal zu wollen.
00:06:37Im Grunde versuchen sie immer, die gesamte App in einem Rutsch zu erledigen.
00:06:40Das führte dazu, dass dem Modell mitten in der Implementierung der Kontext ausging
00:06:45und die nächste Sitzung mit einer halb fertigen oder schlecht dokumentierten Funktion beginnen musste.
00:06:49Der Agent musste dann raten, was eigentlich passiert war, und verbrachte viel Zeit damit,
00:06:52die Basis-App überhaupt wieder zum Laufen zu bringen.
00:06:55Der zweite Fehler war, dass Agenten dazu neigen, Aufgaben vorzeitig als erledigt zu markieren.
00:07:00Das haben Sie wahrscheinlich selbst auch schon erlebt.
00:07:02Das Tool behauptet dann einfach, das Projekt oder die Funktion sei fertig.
00:07:05Aber sobald man es testet, merkt man, dass es gar nicht funktioniert.
00:07:07Ihre Lösung für dieses Standard-Fehlverhalten des Modells war erstens, eine initiale
00:07:12Umgebung aufzubauen, die das Fundament für alle geforderten Funktionen legt.
00:07:16Das bringt den Agenten dazu, Schritt für Schritt und Funktion für Funktion vorzugehen.
00:07:20Das ähnelt dem Planungs- oder PRD-Ansatz, den wir normalerweise verfolgen.
00:07:23Zweitens begannen sie, jeden Agenten so zu instruieren, dass er inkrementelle Fortschritte macht
00:07:27und die Umgebung am Ende jeder Sitzung in einem sauberen Zustand hinterlässt.
00:07:32Dafür entwickelten sie eine zweiteilige Lösung.
00:07:35Sie nutzen einen „Initializer Agent“, der das Modell über einen speziellen Prompt auffordert,
00:07:40die Startumgebung mit einem „init.sh“-Skript einzurichten, das zum Beispiel den Dev-Server startet,
00:07:45damit sich das nächste Modell nicht mehr darum kümmern muss.
00:07:48Außerdem gibt es eine Datei namens „cloud progress.txt“, die protokolliert, was der Agent getan hat,
00:07:53sowie einen initialen Git-Commit, der zeigt, welche Dateien hinzugefügt wurden.
00:07:55Danach wird für jede weitere Sitzung ein „Coding Agent“ eingesetzt, der inkrementelle Fortschritte macht
00:08:01und strukturierte Updates hinterlässt.
00:08:02All diese Bemühungen dienen dem Zweck, eine Umgebung zu definieren,
00:08:07in der Agenten den Arbeitsstand sofort verstehen können, wenn sie mit einem frischen
00:08:11Kontextfenster starten.
00:08:13Der Workflow sieht so aus: Der Initializer Agent versucht zuerst, eine Umgebung oder
00:08:17ein Dokumentationssystem einzurichten, um den Gesamtplan zu verfolgen.
00:08:21Dazu gehört erstens ein Dokument mit einer Liste aller Funktionen, um zu verhindern,
00:08:25dass der Agent alles auf einmal probiert oder das Projekt voreilig als beendet ansieht.
00:08:30Der Initializer Agent bricht das Projekt in über 200 Einzelfunktionen auf
00:08:34und protokolliert diese in einer lokalen JSON-Datei, die etwa so aussieht, wobei jede Aufgabe
00:08:39eine detaillierte Spezifikation sowie einen Status (bestanden/fehlgeschlagen) hat.
00:08:41Standardmäßig sind alle Aufgaben als fehlgeschlagen markiert.
00:08:43Das zwingt das Modell, immer auf das Gesamtziel und den Fortschritt zu schauen,
00:08:49die wichtigste Aufgabe auszuwählen und den nächsten Schritt zu machen.
00:08:50Damit dieser Workflow funktioniert, müssen sie das Modell auch dazu bringen, die Umgebung
00:08:55nach Codeänderungen sauber zu hinterlassen. In ihren Experimenten fanden sie heraus,
00:08:59dass der beste Weg darin besteht, das Modell aufzufordern, Fortschritte mit einer aussagekräftigen
00:09:05Commit-Nachricht in Git zu speichern und eine Zusammenfassung in der Progress-Datei zu schreiben.
00:09:08Aber Dokumentation und Kontext allein reichen nicht aus, da Modelle dazu neigen,
00:09:13Dinge ohne richtige Tests als erledigt zu markieren. Anfangs haben sie den Code
00:09:17einfach dazu aufgefordert, nach Änderungen Unit-Tests oder API-Tests
00:09:22für den Dev-Server durchzuführen.
00:09:23Das reichte oft nicht aus, um zu erkennen, ob eine Funktion wirklich durchgängig funktioniert.
00:09:27Die Dinge änderte sich erst grundlegend, als sie dem Modell die richtigen Werkzeuge gaben,
00:09:30um End-to-End-Tests selbst durchzuführen – etwa Puppeteer oder Chrome DevTools.
00:09:35Damit konnte der Agent Fehler finden und beheben, die im Code allein nicht offensichtlich waren.
00:09:39Im Grunde bauen sie also eine Struktur auf, in der der Initializer Agent das Nutzerziel
00:09:43in eine Liste von Funktionen zerlegt, ergänzt durch „init.sh“ zum Starten des Dev-Servers
00:09:47und Progress-Dateien.
00:09:49Der nächste Coding Agent kann dann einfach die Feature-Liste lesen, um den Gesamtplan zu verstehen,
00:09:53die wichtigste Aufgabe auswählen und in der Progress-Datei nachsehen,
00:09:57wie der Stand der Dinge ist.
00:09:59Dann startet er „init.sh“, um sofort den Dev-Server zu haben, und führt End-to-End-Tests durch,
00:10:04um sicherzustellen, dass die Umgebung sauber ist. Das ermöglicht ein klares Bild
00:10:09und schnelle Feedbackschleifen trotz neuer Sitzungen und Kontextfenster.
00:10:10Im Blog von OpenAI liest man über sehr ähnliche Ansätze.
00:10:13Man muss sicherstellen, dass die Anwendungsumgebung lesbar ist.
00:10:16Sie machen das gesamte Repository zum Wissensspeicher oder System.
00:10:19Zuerst versuchten sie es mit einer riesigen „agents.md“-Datei, was erwartungsgemäß scheiterte,
00:10:23da es einfach zu viel Kontext für einen Agenten war.
00:10:27Also entwarfen sie eine richtige Dokumentationsstruktur und nutzten „agents.md“ nur als
00:10:32Inhaltsverzeichnis.
00:10:33Sie bauten ein System auf, das von Architektur und Design-Docs bis hin zu Ausführungsplänen,
00:10:37DB-Schemas, Produktspezifikationen, Frontend-Plänen und Sicherheit alles abdeckte,
00:10:42und verknüpften dies in der „agents.md“, sodass der Agent bei Bedarf gezielt Informationen
00:10:47abrufen konnte.
00:10:49Das ermöglicht eine schrittweise Offenlegung von Informationen, und OpenAI geht sogar noch weiter.
00:10:53Sie versuchen, nicht nur das Codewissen, sondern auch Google Docs, Slack-Nachrichten und andere
00:10:58fragmentierte Informationen in das Repository einzuspielen,
00:11:03als lokale Artefakte.
00:11:04So kann der Agent auch darauf zugreifen. Denn aus der Sicht des Agenten existiert nichts,
00:11:09auf das er in seiner Umgebung nicht zugreifen kann.
00:11:11Aber Dokumentation allein hält eine von Agenten generierte Codebasis nicht konsistent.
00:11:16Sie führten auch bestimmte programmatische Workflows ein, um Regeln zu erzwingen.
00:11:20Zum Beispiel unterteilten sie die Architektur in Domänen mit klaren Grenzen,
00:11:25was es ihnen ermöglichte, Regeln durch Custom-Checks, Linter und Struktur-Tests zu erzwingen,
00:11:29die automatisch bei jedem Git-Pre-Commit ausgelöst werden.
00:11:33Solch eine Architektur führt man in klassischen Firmen normalerweise erst ein, wenn man Hunderte Ingenieure hat,
00:11:37aber für Coding-Agenten ist das eine frühe Voraussetzung.
00:11:41Innerhalb dieser Grenzen gewährt man den Teams und Agenten große Freiheit bei der Lösungssuche,
00:11:46ohne sie mikrozumanagen oder Angst vor einer abweichenden Architektur haben zu müssen.
00:11:49Gleichzeitig verbesserten sie die Codebasis erheblich.
00:11:52Sie machten die App zum Beispiel pro Git-Worktree startfähig, sodass der Agent einfach
00:11:55viele verschiedene Instanzen starten konnte.
00:11:57Zudem binden sie das Chrome-Dev-Protokoll in die Laufzeit des Agenten ein, damit dieser
00:12:01Fehler reproduzieren und Korrekturen via DOM-Snapshots und Screenshots validieren kann.
00:12:05Mit diesem Setup erreichte das Repository schließlich die Schwelle,
00:12:09an der Agenten eine neue Funktion komplett eigenständig umsetzen konnten.
00:12:13Jedes Mal, wenn der Agent einen Prompt erhält, validiert er den aktuellen Stand des Codes,
00:12:17reproduziert einen gemeldeten Fehler und nimmt ein Video auf, um das Scheitern zu zeigen.
00:12:21Dann implementiert er den Fix, validiert ihn durch die App, nimmt ein zweites Video zur Bestätigung
00:12:25der Lösung auf und mergt schließlich die Änderung.
00:12:29Diese beiden Beispiele zeigen wertvolle Erkenntnisse und die notwendigen Strukturen,
00:12:32die man für ein vollautonomes System schaffen muss.
00:12:34Es gibt jedoch noch weitere Lehren.
00:12:36Oft neigen wir dazu, beim Bau von Agenten – besonders für Nischen –
00:12:40hochspezialisierte Werkzeuge für domänenspezifische Aufgaben zu entwickeln.
00:12:43Die Erfahrung zeigt jedoch: Große Sprachmodelle funktionieren fast immer besser mit generischen Tools,
00:12:47die sie nativ verstehen.
00:12:49Vercel veröffentlichte einen Artikel darüber, wie sie ihre „Text-to-SQL“-Agenten umgestaltet haben.
00:12:53Sie verbrachten Monate damit, ein komplexes System mit speziellen Tools,
00:12:58aufwendigem Prompt-Engineering und Kontextmanagement zu bauen.
00:13:02Wie viele von uns schon erfahren haben, funktionierte das zwar irgendwie, war aber instabil,
00:13:06langsam und wartungsintensiv.
00:13:09Bei jedem neuen Sonderfall musste man dem Agenten einen neuen Prompt hinzufügen.
00:13:12Dann probierten sie etwas aus, das alles änderte.
00:13:15Sie löschten fast alle Spezialwerkzeuge und ließen nur noch ein einziges Batch-Befehls-Tool übrig.
00:13:20Mit dieser viel einfacheren Architektur arbeitete der Agent 3,5-mal schneller,
00:13:25verbrauchte 37 % weniger Token und die Erfolgsquote stieg von 80 % auf 100 %.
00:13:30Ähnliche Erfahrungen teilte das Team von Anthropic. Sie sprachen davon,
00:13:34dass sie statt spezialisierter Such- und Ausführungswerkzeuge nur noch ein Batch-Tool nutzen,
00:13:38mit dem sie grep, tail oder npm run lint ausführen können.
00:13:41Im Grunde liegt das wohl daran, dass große Sprachmodelle viel vertrauter mit diesen
00:13:45Code-nativen Tools sind, für die es Milliarden von Trainings-Token gibt, im Vergleich zu
00:13:49maßgeschneiderten JSON-Tool-Aufrufen.
00:13:51Darüber habe ich bereits in meinem Video über programmatische Tool-Aufrufe letzte Woche gesprochen.
00:13:55Ich glaube, hier gelten ähnliche Prinzipien. Die Basis für diese einfache Architektur
00:13:59ist wieder eine gute Kontext- und Dokumentationsumgebung, in der das Modell generische Werkzeuge nutzen kann,
00:14:05um Kontext schrittweise abzurufen.
00:14:06Das ist auch bei OpenClaw der Fall.
00:14:09Ein Grund, warum OpenClaw so interessant ist, ist ihre überraschend einfache, aber effektive
00:14:13Kontext-Umgebung.
00:14:15Sie haben eine Liste von Dokumenten, um Kerninformationen zu speichern.
00:14:18Damit nutzen sie nur grundlegende Tools wie Dateien lesen, schreiben, bearbeiten, Batch-Befehle ausführen
00:14:23und Nachrichten senden.
00:14:24Der Rest kommt daher, dass dem Agenten eine Umgebung gegeben wird, um relevanten Kontext abzurufen,
00:14:29plus eine große Bibliothek an Skills, um die Fähigkeiten zu erweitern.
00:14:31Das sind also drei praktische Erkenntnisse über „Harness Engineering“ für lang laufende,
00:14:35komplexe Agenten.
00:14:36Indem man eine lesbare Kontextumgebung schafft, in der jede Sitzung effektiv Informationen abgreifen kann,
00:14:41die richtigen Workflows und Tools zur Verifizierung etabliert, schnellere Feedbackschleifen nutzt
00:14:46und dem Agenten mit generischen, nativ verständlichen Tools vertraut.
00:14:50Wenn Sie interessiert sind, werde ich noch genauer zeigen, wie ich diese Erkenntnisse
00:14:54in einen Entwicklungsprozess umsetze.
00:14:58Im AI Builder Club haben wir Kurse zu „Vibe Coding“ und dem Bau von produktionsreifen
00:15:02Agenten.
00:15:03Jede Woche teilen ich und Branchenexperten die neuesten praktischen Erfahrungen.
00:15:08Wenn Sie also lernen möchten, was ich jeden Tag lerne, klicken Sie auf den Link
00:15:12unten, um der Community beizutreten.
00:15:13Ich hoffe, Ihnen hat dieses Video gefallen.
00:15:14Vielen Dank und bis zum nächsten Mal.

Key Takeaway

Der Paradigmenwechsel des Jahres 2026 führt weg von einfachen KI-Copiloten hin zu autonomen Agenten-Systemen, die durch präzises Harness Engineering und strukturierte Umgebungen komplexe Projekte eigenständig umsetzen.

Highlights

Der Aufstieg von "Harness Engineering" als entscheidende Weiterentwicklung von Prompt Engineering für vollautonome, lang laufende KI-Systeme.

Ein technologischer Wendepunkt im Dezember 2025, der KI-Modelle befähigte, komplexe Aufgaben über Wochen hinweg ohne menschliches Eingreifen zu bewältigen.

Die Bedeutung einer "lesbaren Umgebung" für Agenten, damit neue Sitzungen nahtlos am vorherigen Arbeitsstand anknüpfen können.

Abkehr von hochspezialisierten Nischen-Werkzeugen hin zu generischen, Code-nativen Tools wie Batch-Befehlen, die von LLMs besser verstanden werden.

Nutzung von End-to-End-Tests (z. B. Puppeteer) und automatisierten Verifizierungs-Schleifen, um voreilige Erfolgsmeldungen der KI zu verhindern.

Die Transformation von Repositories in Wissensspeicher, die Dokumentation, Slack-Nachrichten und Architekturpläne als lokale Artefakte für die KI bereithalten.

Timeline

Der Wendepunkt im Dezember 2025

Das Video beginnt mit der Analyse eines massiven Umbruchs in der KI-Welt, der sich Ende 2025 vollzog und die Art des Programmierens grundlegend veränderte. Während frühere Projekte wie AutoGPT im Jahr 2023 noch an mangelnder Modell-Kohärenz scheiterten, sind moderne Modelle nun bereit für vollautonome, lang laufende Aufgaben. Experten wie Andrew Cupsey und Greg von OpenAI bestätigen, dass die Werkzeuge seither sprunghafte Verbesserungen bei der Bewältigung komplexer Ziele gezeigt haben. Dieser Abschnitt verdeutlicht, dass der Traum von der KI, die rund um die Uhr proaktiv arbeitet, nun technische Realität geworden ist. Die Modelle besitzen heute die notwendige langfristige Kohärenz, um über Tage hinweg an einem konsistenten Ziel zu arbeiten.

Durchbrüche bei autonomen Experimenten

Der Sprecher beleuchtet bahnbrechende Experimente von Firmen wie Cursor und Anthropic, die das Potenzial autonomer Agenten demonstrieren. So gelang es GPT-5.2, einen Browser mit 3 Millionen Zeilen Code von Grund auf zu erstellen, während Anthropic-Agenten autonom einen funktionsfähigen C-Compiler entwickelten. Ein zentraler Akteur in dieser Entwicklung ist "OpenClaw", ein System, das sich durch proaktives Handeln und ständige Verfügbarkeit von klassischen Copilot-Tools abhebt. Der Erfolg dieser Systeme basiert auf einer Architektur aus Speicherebenen, Triggern und vollem Computerzugriff, was einen massiven Paradigmenwechsel einläutet. Es wird klar, dass nicht nur das Modell selbst, sondern das Design des umgebenden Systems entscheidend für die Freisetzung dieser Kräfte ist.

Einführung in das Harness Engineering

In diesem Teil wird der Begriff "Harness Engineering" als die strategische Weiterentwicklung des Prompt Engineering definiert. Es geht dabei nicht mehr um die Optimierung einzelner Sitzungen, sondern um den Entwurf von Workflows, die über viele Sitzungen und Agenten hinweg stabil funktionieren. Der Sprecher weist auf die enorme Marktchance hin, spezialisierte autonome Agenten für bestimmte Branchen zu entwickeln, die End-to-End-Prozesse übernehmen. Als Beispiel dient eine Studie von HubSpot zum E-Mail-Marketing, die aufzeigt, wo KI heute noch an manuellen Nachbearbeitungen scheitert und wo Automatisierungslücken klaffen. Entwickler werden ermutigt, diese Herausforderungen als Basis für neue Agenten-Produkte zu nutzen, um reale Geschäftsprobleme autonom zu lösen.

Strukturen für lang laufende Agenten

Die technischen Kernprinzipien für erfolgreiche Agenten-Systeme werden anhand von drei zentralen Erkenntnissen aufgeschlüsselt. Erstens ist die Schaffung einer lesbaren Umgebung essenziell, damit jeder Sub-Agent sofort versteht, welcher Fortschritt bereits erzielt wurde. Zweitens ist eine strikte Verifizierung durch Feedbackschleifen nötig, um zu verhindern, dass die KI Aufgaben fälschlicherweise als erledigt markiert. Drittens sollten Entwickler dem Modell mehr vertrauen und ihm generische Werkzeuge zur Exploration zur Verfügung stellen, anstatt es durch starre Logik einzuengen. Anthropic-Experimente zeigen, dass Agenten ohne diese Strukturen oft versuchen, zu viel auf einmal zu lösen, was letztlich zum Scheitern führt. Eine saubere Dokumentation und inkrementelle Fortschritte sind daher die Grundpfeiler für die Stabilität des gesamten Systems.

Methoden zur Umgebungs-Initialisierung

Der Sprecher erklärt detailliert den Einsatz von spezialisierten Agenten-Rollen wie dem "Initializer Agent" und dem "Coding Agent". Der Initializer Agent bereitet das Fundament vor, indem er ein Projekt in über 200 Einzelfunktionen zerlegt und diese in einer Status-Datei protokolliert. Dies zwingt das nachfolgende Modell, Schritt für Schritt vorzugehen und den Gesamtplan niemals aus den Augen zu verlieren. Ein wichtiger Aspekt ist die Nutzung von Git-Commits und Fortschrittsberichten am Ende jeder Sitzung, um den Kontext für den nächsten Agenten zu sichern. Durch den Einsatz von End-to-End-Test-Tools wie Chrome DevTools kann der Agent zudem eigenständig validieren, ob seine Änderungen in der realen Umgebung tatsächlich funktionieren.

Optimierung durch generische Werkzeuge

Ein überraschendes Ergebnis aus der Praxis ist, dass einfache, generische Werkzeuge oft besser funktionieren als hochkomplexe Spezial-Tools. Vercel konnte die Effizienz ihrer SQL-Agenten drastisch steigern, indem sie spezialisierte JSON-Tools durch ein einfaches Batch-Befehls-Tool ersetzten, das nativ vom Modell verstanden wird. Dies führte zu einer höheren Erfolgsquote bei gleichzeitig geringerem Token-Verbrauch und schnellerer Ausführung. OpenAI verfolgt einen ähnlichen Ansatz, indem das gesamte Repository inklusive Architektur-Docs und Slack-Verläufen als Wissensbasis dient. Durch automatisierte Linter und Struktur-Tests bei jedem Commit wird die Konsistenz der Codebasis gewahrt, ohne den Agenten in seinem kreativen Lösungsprozess mikrozumanagen.

Fazit und Ausblick auf Vibe Coding

Zum Abschluss fasst das Video die drei Säulen des Harness Engineering zusammen: lesbare Kontextumgebungen, effektive Verifizierungs-Workflows und das Vertrauen in nativ verständliche Tools. Diese Elemente ermöglichen es, die volle Leistung moderner Sprachmodelle für produktionsreife Anwendungen zu entfesseln. Der Sprecher gibt einen Ausblick auf Konzepte wie "Vibe Coding" und lädt die Zuschauer ein, tiefer in die Welt der autonomen Systeme einzutauchen. Es wird deutlich, dass die Rolle des Ingenieurs sich massiv wandelt – weg vom reinen Codierer hin zum Architekten von autonomen Arbeitsumgebungen. Das Video endet mit einem Dank an den Sponsor HubSpot und der Aufforderung, die neuen Möglichkeiten der Agenten-Technologie aktiv zu gestalten.

Community Posts

View all posts