Human in the Loop reicht nicht!

MENSCH & KI
FIELD NOTE 003

Ein persönliches Experiment über moderne Softwareentwicklung, Coding Agents – und darüber, was passiert, wenn Mensch und KI tatsächlich anfangen, gemeinsam zu arbeiten.

Was ich beim Bau eines Boards für die Zusammenarbeit zwischen Menschen, KI und Agenten über Kontrolle, Transparenz und ziemlich gut gemeinte Umwege gelernt habe.

Eigentlich war die Idee ziemlich simpel.

Ich wollte bei der Entwicklung nicht ständig daneben sitzen und einer KI dabei zuschauen, wie sie Code produziert.

Aufgabe geben. Arbeiten lassen. Prüfen lassen. An den richtigen Stellen selbst entscheiden.

Klingt vernünftig.

Also brauchten wir einen Workflow.

Und weil ich offenbar noch nicht genug Probleme hatte, bauten wir dafür ein Board.

Das Board sollte alles einfacher machen

Die Idee dahinter finde ich bis heute richtig.

Wenn Menschen und KI-Agenten gemeinsam an Software arbeiten, muss irgendwann jemand eine ziemlich einfache Frage beantworten können:

Wo stehen wir eigentlich gerade?

Nicht ungefähr.

Nicht: „Die KI sagt, sie ist fertig.“

Sondern wirklich.

Ist die Aufgabe klar? Wurde implementiert? Sind die Tests gelaufen? Hat ein unabhängiger Agent die Implementierung geprüft? Gibt es einen Pull Request? Ist dort wirklich der geprüfte Code enthalten? Kann ich ihn guten Gewissens mergen?

Und vor allem:

Wer ist jetzt eigentlich dran?

Also entstand ein Workflow, der genau diese Übergaben sichtbar machen sollte.

Vereinfacht ungefähr so:

Backlog → Architecture → Implementation → Verification → PR Review → Merged

Der Agent arbeitet. Andere Agenten prüfen. Das System sammelt technische Nachweise.

Und wenn eine Entscheidung tatsächlich bei mir liegt, holt mich das Board wieder dazu.

Ich sehe, wo die Aufgabe steht, was passiert ist, was geprüft wurde und was jetzt von mir erwartet wird. Dann kann ich entscheiden und die Aufgabe selbst weiterschieben.

Human in the Loop.

Sehr schön.

Zumindest auf dem Whiteboard.

Dann kam die Realität

Das Problem mit Softwarearchitektur ist bekanntlich, dass sie erstaunlich gut funktioniert, solange man sie nicht implementiert.

Unser Board machte da keine Ausnahme.

Je mehr wir automatisierten, desto wichtiger wurde eine eigentlich banale Frage:

Stimmt das, was das Board anzeigt, überhaupt mit dem überein, was technisch passiert ist?

Denn ein hübsches grünes Kästchen mit Merged ist vollkommen wertlos, wenn der entsprechende Code gar nicht auf main liegt.

Also brauchten wir Evidenz.

Welcher Commit gehört zur Implementierung? Welcher Pull Request dazu? Enthält dieser tatsächlich die geprüfte Implementierung? Wurde er gemergt? Ist der Merge wirklich auf main angekommen?

Plötzlich war aus einem Kanban-Board eine kleine Beweisführung geworden.

Und technisch ist das sogar richtig.

Nur leider hatte ich irgendwann ungefähr diese Situation:

Das Board sagte etwas.

Git sagte etwas anderes.

GitHub hatte auch eine Meinung.

Der Agent war überzeugt, fertig zu sein.

Und ich saß davor und durfte herausfinden, wer von den vieren gerade recht hatte.

Genau dafür hatten wir das Board gebaut.

Human in the Loop – nur anders als gedacht

Da wurde mir klar, dass wir einen Denkfehler gemacht hatten.

Wir hatten den Menschen sauber in den Prozess eingebaut.

Wir hatten nur noch nicht sauber definiert, was er dort wissen muss, um entscheiden zu können.

Human in the Loop bedeutet nicht:

Der Mensch darf jetzt die technischen Zustände von fünf Systemen miteinander vergleichen.

Es bedeutet auch nicht:

Wenn die Automatisierung nicht weiterweiß, werfen wir das Problem einfach über den Zaun zum Menschen.

Aber das Gegenteil ist genauso falsch.

Man kann die Oberfläche so weit vereinfachen, dass am Ende nur noch ein grüner Knopf übrig bleibt:

Approve

Warum?

Keine Ahnung.

Wird schon passen.

Das ist keine gute Mensch-KI-Zusammenarbeit.

Das ist digitales Gottvertrauen mit Button.

Wenn ich entscheiden soll, muss ich wissen: Was wurde gemacht? Was wurde geprüft? Gab es Probleme? Welche Risiken sind noch offen? Und was passiert, wenn ich jetzt freigebe?

Ich brauche dafür keine komplette Git-Historie und möchte auch nicht erst drei PowerShell-Befehle ausführen.

Komplexität darf verschwinden. Entscheidungsrelevante Information nicht.

Warum plötzlich ADRs wichtig wurden

Währenddessen zeigte sich noch ein anderes Problem.

Je mehr Entscheidungen wir während der Entwicklung trafen, desto schwieriger wurde es für einen Agenten zu erkennen, warum etwas so gebaut worden war.

Code zeigt ziemlich gut, was ein System macht.

Er zeigt deutlich schlechter, warum wir uns dafür entschieden haben.

Dafür nutzen wir Architecture Decision Records – ADRs.

Ein ADR hält fest, welches Problem gelöst werden sollte, welche Entscheidung getroffen wurde, welche Alternativen betrachtet oder verworfen wurden und welche Konsequenzen daraus entstehen.

Das klingt zunächst nach Dokumentation.

Für die Zusammenarbeit mit KI wird daraus aber etwas anderes:

Kontext für den nächsten Agenten.

Denn ohne diesen Kontext kann ein Agent völlig korrekt feststellen:

„Das könnte man einfacher bauen.“

Stimmt vielleicht sogar.

Nur wurde genau diese einfachere Variante möglicherweise drei Wochen vorher aus einem ziemlich guten Grund verworfen.

Wenn dieser Grund nur noch in meinem Kopf steckt, haben wir kein KI-Problem.

Dann haben wir ein Wissensproblem.

Und mein Kopf ist zwar vieles, aber definitiv keine hochverfügbare Datenbank.

Git wurde zur Beweisquelle

Auch Git bekam plötzlich eine andere Rolle.

Früher war es für mich hauptsächlich Versionsverwaltung.

Jetzt wurde Git zusätzlich zur Evidenz.

Ein Agent kann behaupten, eine Aufgabe erledigt zu haben.

Das Board kann einen Status anzeigen.

Ein Commit ist weniger gesprächig. Er ist entweder da oder nicht.

Und wir können technisch prüfen, ob die geprüfte Implementierung tatsächlich Bestandteil des Pull Requests war und schließlich auf main angekommen ist.

Der Status einer Aufgabe sollte möglichst wenig davon abhängen, was ein Agent behauptet.

Er sollte sich daraus ergeben, was nachweisbar passiert ist.

Das klingt banal.

Bis man versucht, es konsequent umzusetzen.

Dann landet man irgendwann bei Implementation Anchors, Commit-Ancestry, PR-Evidenz und Finalisierung.

Begriffe, bei denen jeder normale Mensch vollkommen zu Recht fragt:

„Ich wollte eigentlich nur wissen, ob ich jetzt auf Merge drücken kann.“

Und genau damit hat er recht.

Die Technik darf kompliziert sein

Unter der Oberfläche dürfen Zustandsautomaten laufen, APIs Voraussetzungen prüfen, Git Evidenz liefern, Tests Verhalten validieren und Agenten andere Agenten kontrollieren.

Der Mensch muss das nicht alles bedienen.

Er muss aber das Ergebnis verstehen können.

Am Ende sollte aus all dieser Technik etwas entstehen wie:

Implementation abgeschlossen.
Tests erfolgreich.
Unabhängiger Review erfolgreich.
Pull Request geprüft.
Keine offenen Blocker.

Diese Änderungen werden mit deiner Freigabe übernommen.

→ Merge freigeben?

Jetzt kann ich entscheiden.

Nicht weil der Button grün ist.

Sondern weil ich verstehe, warum er grün ist.

Und dann kamen noch Windows und PowerShell

Natürlich blieb es nicht beim fachlichen Workflow.

Eine lokale KI-gestützte Entwicklungsumgebung braucht schließlich auch eine Runtime.

Bei uns unter anderem mit Python, APIs, Git, GitHub, PowerShell und Windows Task Scheduler.

Was soll da schon passieren?

Nun.

Execution Policies. Python-Pfade. Git-Identitäten. Prozesse, die laufen, aber nicht gesund sind. Services, die gesund aussehen, bis man sie tatsächlich braucht.

Mein persönlicher Favorit:

Ein System automatisiert einen Prozess erfolgreich – bis die Automatisierung eine Git-Identität benötigt.

Dann steht die künstliche Intelligenz sinngemäß vor der Tür und sagt:

„Ich weiß, was zu tun ist. Aber ich weiß nicht, wer ich bin.“

Fairer Punkt.

Kenne ich aus manchen Meetings.

Mehr Kontrolle ist nicht automatisch bessere Kontrolle

Auch das hat uns das Board beigebracht.

Wir wollten Sicherheit durch kontrollierte Zustände schaffen.

Das funktioniert.

Bis zu einem gewissen Punkt.

Danach erzeugt jeder zusätzliche Status neue Übergänge. Übergänge brauchen Regeln. Regeln brauchen Prüfungen. Prüfungen produzieren Fehlerzustände.

Und irgendwann beschäftigt sich der Mensch hauptsächlich damit, den Prozess zu bedienen, der ihn eigentlich entlasten sollte.

Das Problem kenne ich übrigens nicht nur aus der Softwareentwicklung.

Wer einmal einen Freigabeworkflow mit 14 Statuswerten in einem HR-System gesehen hat, weiß:

Wir Menschen brauchen keine KI, um Prozesse vollkommen zu ruinieren.

Das schaffen wir seit Jahrzehnten zuverlässig selbst.

Also Board wieder abschaffen?

Nein.

Die Transparenz brauchen wir.

Die technischen Nachweise brauchen wir.

Die unabhängigen Reviews brauchen wir.

Und bei bestimmten Entscheidungen will ich ganz bewusst selbst im Prozess bleiben.

Aber inzwischen stellen wir eine andere Frage.

Nicht:

Welche technischen Schritte müssen wir noch im Board abbilden?

Sondern:

Was muss der Mensch an dieser Stelle wissen, damit er verantwortlich entscheiden kann?

Darunter können zwanzig technische Prüfungen stattfinden.

Wenn alles funktioniert, muss ich sie nicht einzeln bedienen.

Wenn etwas schiefläuft, muss ich aber verstehen können, was passiert ist und welche Konsequenz das hat.

Das ist keine Vereinfachung um jeden Preis.

Es ist Verdichtung.

Was davon hängen bleibt

Nach einigen Umwegen sind für mich vor allem drei Dinge hängen geblieben.

1. Human in the Loop ist kein Freigabeknopf.

Wenn ein Mensch entscheiden soll, muss das System ihn vorher so weit ins Bild setzen, dass er diese Entscheidung auch verantworten kann.

2. Automatisierung sollte Komplexität verdichten, nicht verstecken.

Ich muss nicht jeden Commit, API-Call oder Prüfschritt sehen. Aber ich muss wissen, was passiert ist, was geprüft wurde, wo Unsicherheit besteht und welche Konsequenz meine Entscheidung hat.

3. Je mehr KI übernimmt, desto wichtiger wird das Warum.

Code zeigt, was gebaut wurde. Tests zeigen, ob es funktioniert. Git zeigt, was tatsächlich passiert ist. ADRs helfen zu verstehen, warum wir diesen Weg überhaupt gewählt haben.

Vielleicht ist genau das eine der schwierigsten Aufgaben bei der Gestaltung von Mensch-KI-Zusammenarbeit:

Die Maschine darf die Komplexität übernehmen.
Der Mensch darf dabei nicht den Überblick verlieren.

Denn wenn am Ende nur noch ein grüner Button übrig bleibt, dessen Vorgeschichte niemand mehr versteht, haben wir den Menschen nicht sinnvoll eingebunden.

Dann haben wir keinen Human in the Loop.

Dann haben wir einen Menschen als Bestätigungsdialog.

Quellen

Liming Zhu et al. – Designing Meaningful Human Oversight in AI – Springer
van de Sande et al. – Meaningful Oversight of Medical AI Beyond Human in the Loop – Nature
NIST – AI Risk Management and Human-AI Interaction – NIST
Martin Fowler – Architecture Decision Record – Martin Fowler