Hauptgedanke

Den von einem Agenten erzeugten Code nachträglich an einer fachlichen Ontologie zu prüfen, funktioniert, aber zu spät: Der Agent hat schon Klassen angelegt, Methoden hinzugefügt und Tests rund um eine falsche Lesart der Fachlichkeit geschrieben, und all das muss man wieder anfassen.

TDD hat dasselbe Problem für das Verhalten gelöst: Man schreibt den Test vor dem Code. Auf das Fachmodell übertragen, ergibt das für den Agenten eine andere Reihenfolge. Bevor er eine Zeile schreibt, bestimmt er die Konzepte und Regeln der Ontologie, die die Anfrage berührt, meldet die Widersprüche zwischen Anfrage und Modell, lässt sie auflösen, entwickelt dann und prüft schließlich, ob der erzeugte Code zum erwarteten Modell passt.

In einem ERP, in dem jeder Auftrag zwingend aus einem Angebot hervorgeht, stößt die Anfrage „einen Auftrag ohne Angebot ermöglichen“ auf eine Regel, bevor auch nur eine Datei geändert ist. Der Widerspruch wird in dem Moment sichtbar, in dem er nur eine Entscheidung kostet.

Warum das wichtig ist

Die Prüfung hört auf, eine Korrektur zu sein, und wird zur Rahmung. Der Agent geht von einem ausdrücklichen Verständnis der Domäne aus statt von seiner eigenen Deutung, und die fachlichen Entscheidungen werden getroffen, bevor sie in Code gegossen sind.

Der Agent muss dafür nicht die ganze Ontologie laden: Er wählt die Konzepte, Beziehungen und Regeln aus, die die Anfrage berührt.

Nuancen und Grenzen

Die Analogie zu TDD hat eine klare Grenze: Eine Ontologie ist keine Testsuite, und eine Analyse durch ein LLM bietet nicht die Garantie einer deterministischen Assertion. Übernommen wird die Reihenfolge der Schritte, nicht die Gewissheit des Urteils.

Ein vorab gemeldeter Widerspruch ist nicht zwangsläufig ein Fehler der Anfrage: Er kann eine gewollte fachliche Weiterentwicklung ankündigen.

Offene Fragen

• Wie viele der vom Agenten vorab gemeldeten Widersprüche erweisen sich bei näherem Hinsehen als False Positives?