Ok, gelesen: Ich lese solche Artikel, damit du es nicht musst. Dieser hier ist lang, hat viele Diagramme und ein neues Wort: Harness Engineering. HackerNoon selber hängt ihm zwei Etiketten an, Meinung und KI-unterstützt. Das merkt man. Er ist nicht falsch. Er ist nur zu achtzig Prozent bekanntes Ingenieurhandwerk mit neuen Namen. Und zu zwanzig Prozent ein Punkt, der stimmt.
Was er sagt
Das Reisegelaber auf das Minimum reduziert: Der Agent bekommt eine Aufgabe. Er bekommt Kontext. Er macht einen Plan. Er benutzt definierte Fähigkeiten, keine rohen Scripts. Er führt aus. Das Ergebnis wird geprüft. Ein Mensch greift ein, wenn es riskant ist. Alles wird protokolliert.
Im Artikel heisst das Intent, Context, Plan, Skill, Execute, Validate, Review, Feedback. Und darüber liegt eine Architektur in fünf Schichten, von der Geschäftsabsicht oben bis zur Laufzeit unten, mit dem „Harness" als Kontrollschicht dazwischen. Dazu sieben Tore, bevor etwas in die Produktion darf, drei Sorten Beweise und ein Stufenmodell für Risiko: klein läuft automatisch, gross braucht eine Unterschrift.
Was daran stimmt
Zwei Dinge, und die sind wichtig genug, dass ich den Artikel deshalb nicht wegwerfe.
Das Modell ist nicht das System. Der Agent soll die Werkzeuge nicht direkt aufrufen. Dazwischen sitzt eine Schicht mit Rechten, Kontext, Prüfung, Beobachtung und Rückgängig. Das ist genau die Regel, die ich hier seit einem Jahr wiederhole: Die KI schlägt vor, die Software entscheidet. Und es ist der Grund, warum ich beim MCP Artikel geschrieben habe, dass die Werkzeuge in Scripts gehören, nicht in den Kontext des Modells.
Ein Skill ist kein Prompt. Ein Prompt ist eine Anweisung. Ein Skill hat einen definierten Eingang, Kontext, Regeln, Ausführung, Prüfung, Rückgängig und Ausgang. Wer das nicht trennt, bekommt statt „Menschen schreiben Wegwerfscripts" nur „die KI schreibt Wegwerfscripts". Der Satz ist gut. Den hätte ich gern selber geschrieben.
Die Frage, die fehlt
Der Artikel beantwortet eine Frage: Wie kontrollieren wir Agenten? Das ist die richtige Frage für heute. Aber er hört dort auf, wo es für mich interessant wird. Sein Feedback sind Logs, Metriken, Fehler und Freigaben, die zum Agenten zurückgehen. Ein Kreis. Jeder Durchlauf fängt wieder bei null an.
Was er nicht fragt: Was lernen wir aus der Reihenfolge? Ein Projekt sieht in Wirklichkeit so aus: Erster Prompt, Plan A, Code A, Test rot. Prompt geändert, Plan B, Code B, Test halb grün. Der Agent bekommt eine zusätzliche Quelle, der Kontext ändert sich, Plan C. Ein Mensch korrigiert eine Architekturentscheidung, das Arbeitspaket ändert sich. Build grün. Diese Kette ist wertvoller als jeder einzelne Durchlauf. Sie zeigt, wie ein Projekt konvergiert. Und wer sie aufzeichnet, hat einen Trainingsdatensatz, den es sonst nirgends gibt.
Was bleibt
Lies den Artikel, wenn du jemandem erklären musst, warum ein Agent nicht direkt an die Datenbank darf. Die Diagramme dafür sind brauchbar. Überspring die Teile über Snowflake und Databricks, das ist Marktbeobachtung. Und wenn du das Wort Harness Engineering in einem Meeting hörst, weisst du jetzt, was gemeint ist: Ingenieurhandwerk. Das, was du schon kannst.
Achtzig Prozent neue Namen für alte Mechanismen. Zwanzig Prozent, die stimmen: Das Modell ist nicht das System, und ein Skill ist kein Prompt. Und eine Frage, die fehlt: Agenten brauchen kein weiteres Geschirr. Sie brauchen ein Gedächtnis.
Quelle: Nie Lifeng, „Rebuilding Data Engineering with Harness Engineering: A New Paradigm for the Agent Era", HackerNoon, 27. September 2026. Von HackerNoon als Meinung und KI-unterstützt gekennzeichnet. hackernoon.com
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert ein eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal wird daraus ein Mix. Ich lese natürlich alles nochmal, aber niemand ist unfehlbar. Was drin bleibt, ist dann auch von mir.