Interviewfragen zu Harness Engineering: 22 Fragen mit Antworten für KI-Ingenieure

Wie Sie sich vorbereiten

Interviewfragen zu Harness Engineering gehen meist vom Allgemeinen zum Speziellen: Was ist ein Harness, woraus besteht es, wie diagnostizieren Sie ein Problem, wie messen Sie die Wirkung? Der Interviewer sucht nach ingenieurmäßigem Denken: der Fähigkeit, ein Modellproblem von einem Umgebungsproblem zu unterscheiden und eine prüfbare Lösung vorzuschlagen. Im Folgenden finden Sie 22 Fragen mit Antworten, nach Themen gruppiert.

Grundlagen

1. Was ist ein Agent-Harness?

Das Harness ist die gesamte Umgebung, in der ein KI-Agent arbeitet, außer dem Modell selbst: Anweisungen, Werkzeuge, Ausführungsumgebung, Zustandsspeicherung und Rückkopplungsschleifen. Das Modell trifft die Entscheidungen, das Harness bestimmt, was es weiß, was es tun kann und wie es vom Ergebnis erfährt. Dasselbe Modell zeigt in verschiedenen Harnesses eine sehr unterschiedliche Qualität.

2. Worin unterscheidet sich Harness Engineering von Prompt- und Context-Engineering?

Prompt-Engineering arbeitet mit der Formulierung einer einzelnen Anfrage, Context-Engineering mit dem, was bei jedem Schritt ins Fenster des Modells gelangt. Harness Engineering umfasst beides und ergänzt, was sich nicht durch Text lösen lässt: Zugriff auf Werkzeuge, eine reproduzierbare Umgebung, Zustand zwischen Sitzungen und maschinelle Prüfung des Ergebnisses.

3. Nennen Sie die fünf Teilsysteme des Harness.

Anweisungen (AGENTS.md, CLAUDE.md, Skills, Dokumente), Werkzeuge (Shell, Tests, Linter, Browser, MCP), Umgebung (Abhängigkeiten, Laufzeit, Docker, Worktree), Zustand (PROGRESS.md, Feature-Liste, Entscheidungen) und Rückmeldung (make check, E2E, Hooks, Bewerter). Das Fehlen eines Teils führt nicht zu „etwas schlechteren“ Ergebnissen, sondern zu einer systematischen Klasse von Fehlschlägen.

4. Warum hilft der Austausch des Modells gegen ein stärkeres oft nicht?

Weil viele Fehlschläge nichts mit der Intelligenz des Modells zu tun haben. Ein starkes Modell erhält keinen Zugriff auf einen Befehl, den es nicht bekommen hat, erinnert sich ohne Zustandsdatei nicht an die letzte Sitzung und erfährt nichts von einer defekten Migration, wenn sie niemand ausgeführt hat. Die Konventionen eines konkreten Teams errät das Modell ebenfalls nicht.

Diagnose

5. Der Agent verletzt eine Regel aus der CLAUDE.md. Was tun Sie?

Zuerst prüfen, ob der Agent die Regel überhaupt findet: Eine lange Datei mit Dutzenden Punkten verwässert die wichtige. Kürzen Sie die Einstiegsdatei auf ein Inhaltsverzeichnis und lagern Sie die Details in Dokumente aus, die unter einer Bedingung geladen werden. Ist die Regel kritisch, machen Sie sie zu einer ausführbaren Prüfung — Linter, Test, grep-Guard oder Hook —, dann wird der Verstoß maschinell sichtbar und hängt nicht von der Aufmerksamkeit des Modells ab.

6. Wie erkennen Sie anhand eines Symptoms, welches Teilsystem defekt ist?

Verletzte bekannte Konventionen weisen auf die Anweisungen hin. Der Agent „will, kann aber nicht“ verweist auf die Werkzeuge. Beginnt jede Sitzung mit der Reparatur der Umgebung, liegt es an der Umgebung. Weiß eine neue Sitzung nicht, wo es aufgehört hat, liegt es am Zustand. „Fertig“, das nicht der Realität entspricht, verweist auf die Rückmeldung.

7. Mit welchem Teilsystem beginnen Sie beim Aufbau des Harness, und warum?

Mit der Rückmeldung. Solange es keinen Befehl gibt, der maschinell antwortet „funktioniert oder nicht“, lässt sich die Wirkung jeder anderen Änderung nicht messen. Danach folgen meist Anweisungen, Zustand, Umgebung und Werkzeuge, doch die Reihenfolge ist empirisch und hängt davon ab, was am stärksten defekt ist.

8. Wie messen Sie den Beitrag einer einzelnen Komponente des Harness?

Mit einer Ablation: Modell und Aufgabenmenge bleiben fest, dann schalten Sie jeweils ein Teilsystem ab und beobachten den Einbruch. Besser beginnt man aber mit einem nach Ebenen gekennzeichneten Fehlerprotokoll — es zeigt den Engpass schneller. Ein Einbruch von null bedeutet nicht, dass die Komponente nutzlos ist: Sie wird von diesen Aufgaben vielleicht nicht beansprucht oder ist redundant.

Anweisungen und Kontext

9. Wie gestalten Sie eine gute AGENTS.md?

Als Router, nicht als Lehrbuch: was das Projekt ist, wie es gestartet und geprüft wird, die Definition of Done und eine kurze Liste verpflichtender Einschränkungen. Details stehen in eigenen Dokumenten, verlinkt mit Hinweisen wie „lesen, wenn die Aufgabe Zahlungen betrifft“. Die Datei formuliert Invarianten („Daten werden an der Grenze validiert“), statt Umsetzung und Bibliotheken Zeile für Zeile vorzuschreiben.

10. Wozu brauchen Sie Sub-Agenten?

Zur Isolation des Kontexts. Eine Nebenaufgabe — Suche in der Codebasis, Review, Prüfung — läuft in einem eigenen Kontext und liefert nur ihr Ergebnis zurück. Der Hauptstrang bleibt sauber, und ein prüfender Sub-Agent übernimmt nicht die Überlegungen des Ausführenden, was für eine ehrliche Bewertung wichtig ist.

11. Was ist Harness-Schuld?

Die angesammelte Abweichung des Harness von der Wirklichkeit: veraltete Regeln, Befehle, die nicht mehr funktionieren, Dokumente über Module, die es nicht mehr gibt. Sie verhält sich wie technische Schuld — sie wächst unbemerkt und wird mit Ausfällen des Agenten bezahlt. Das Harness muss regelmäßig überprüft werden, nicht nur einmal eingerichtet.

Zustand und Sitzungen

12. Wie bekämpfen Sie die Amnesie des Agenten zwischen Sitzungen?

Speichern Sie den Zustand im Repository: PROGRESS.md (Stand, Erledigtes, Blocker, nächste Schritte), DECISIONS.md (Entscheidung, Begründung, verworfene Optionen), eine Feature-Liste mit Status, häufige Commits. In den Anweisungen legen Sie die Startreihenfolge fest: den Fortschritt lesen, das Skript zur Prüfung der Umgebung starten, das aktive Feature übernehmen.

13. Wozu die Regel WIP=1?

Beginnt der Agent mehrere Features gleichzeitig, verschwimmt der Zustand: keines ist fertig, Änderungen sind vermischt, ein Rollback wird schwierig. Ein aktives Feature ergibt einen klaren Prüfpunkt, saubere Commits und eine einfache Wiederherstellung nach einem Ausfall.

14. Was ist ein Kaltstart-Test?

Eine Prüfung, ob eine neue Sitzung ohne Hinweise eines Menschen grundlegende Fragen beantworten kann: Was ist das Projekt, wo ist man stehen geblieben, welches Feature ist aktiv, wie prüft man, dass alles in Ordnung ist. Antwortet der Agent aus den Dateien ohne zu raten, funktioniert das Teilsystem Zustand.

Verifikation

15. Warum beweisen grüne Unit-Tests nicht, dass das Feature funktioniert?

Ein Unit-Test isoliert ein Modul und mockt seine Abhängigkeiten, deshalb sieht er die Nahtstellen nicht: nicht passende Schnittstellen, Ausbreitung des Zustands (das Schema hat sich geändert, der Cache ist veraltet), Ressourcenlecks, Probleme mit Konfiguration und Umgebung. Die Defekte, die Unit-Tests finden, sind eine Teilmenge derer, die Integrationstests finden, und diese wiederum eine Teilmenge dessen, was E2E findet.

16. Was ist die Verifikationslücke und wie berechnen Sie sie?

Der Anteil der Aufgaben, die der Agent als fertig gemeldet hat, die aber eine unabhängige Prüfung nicht bestätigt hat. Man nimmt 10 Aufgaben hintereinander und markiert bei jeder beide Fakten. Die Metrik liefert eine Ausgangsbasis: Nach Änderungen am Harness wird sie auf einem ähnlichen Aufgabensatz neu berechnet.

17. Wie schreiben Sie eine Definition of Done für einen Agenten?

In AGENTS.md als Liste prüfbarer Punkte: Die Prüfbefehle endeten mit Code 0, es gibt einen E2E-Test für das Szenario, die Migrationen laufen durch, der Fortschritt ist aktualisiert. Hilfreich ist es, ausdrücklich festzuhalten, was nicht als fertig gilt: „sieht richtig aus“, „Unit-Tests laufen durch“, „bei mir lokal funktioniert es“.

18. Warum darf der Agent den Status „fertig“ nicht selbst setzen?

Modelle neigen dazu, die eigene Arbeit zu überschätzen, und die Selbstbewertung findet im selben Kontext statt, in dem die Entscheidung getroffen wurde. Den Status passing muss ein Prüfskript anhand der Ergebnisse der Läufe setzen und den Commit-Hash als Beleg festhalten.

19. Wie richten Sie einen unabhängigen Bewerter ein?

Ein eigener Agent oder eine eigene Sitzung, die nur die Anforderung, den Diff und die Ergebnisse der Läufe sieht, nicht aber die Überlegungen des Ausführenden. Er bewertet nach einem Raster (Korrektheit, Architektur, Tests, Fehlerbehandlung), und jede Bewertung verweist auf eine Datei, eine Zeile oder ein Log. Am besten verwendet man ein anderes Modell, damit sich die blinden Flecken nicht decken.

20. Wie machen Sie eine Architekturregel ausführbar?

Auf drei Ebenen: grep-Guard (schnell, musterbasiert), eine Linter-Regel, die den Importgraphen versteht (import-linter, dependency-cruiser), und ein Architekturtest im CI. Alle werden in make check eingebunden, schlagen mit einem Exit-Code ungleich null fehl und geben WARUM und FIX aus, damit der Agent den Verstoß selbst behebt. Auslöser für eine neue Prüfung ist der zweite gleichlautende Kommentar im Review.

Autonome Arbeit

21. Was braucht es, damit Sie einen Agenten stundenlang arbeiten lassen können?

Ein eindeutiges Ziel, eine monoton wachsende Fortschrittsmetrik (zum Beispiel die Zahl der Features im Status passing), ein Budget pro Feature in Zeit und Versuchen, automatischen Rollback bei Regressionen und eine Liste von Aktionen, die einen Menschen erfordern: Migrationen, Infrastruktur, Geld. Dazu Isolation: eine Sandbox oder ein eigener Git-Worktree, damit ein Fehler die Arbeitsumgebung nicht berührt.

22. Wann reicht ein einziger Agentenzyklus nicht, und wie bauen Sie einen Graphen von Rollen auf?

Wenn der Ausführende beginnt, sich selbst zu prüfen, und hängen bleibt. Dann wird die Aufgabe in Rollen zerlegt: Umsetzung, Review, Tests, Merge. Das Review erhält einen sauberen Kontext und ein Raster, der Merge wird vom Code ausgeführt, wenn review == pass gilt. Schlägt das Review fehl, geht das Feature zurück zur Umsetzung, und nach mehreren Fehlschlägen wird es mit einem sauberen Kontext neu gestartet — das heißt, das Problem liegt im Verständnis der Aufgabe, nicht im Code.

Fazit

In Interviews zu Harness Engineering überzeugt am meisten, wer über Prüfbares spricht: welche Dateien, welche Befehle, welche Metrik. Behalten Sie die fünf Teilsysteme, die Verifikationslücke und die Regel „der Status wird durch ein Skript gesetzt“ im Kopf. Alle diese Themen fließen im Kurs zum Harness Engineering an einem durchgängigen Projekt zu einem einheitlichen Harness zusammen.