Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.
Dieser Artikel führt fort, was ich in meinem Buch Le Contexte geschrieben habe. Um es zu lesen, laden Sie es herunter oder kaufen Sie es bei Amazon. Die Amazon-Ausgabe ist nur auf Französisch erhältlich; wenn Sie eine Version in einer anderen Sprache wünschen, kontaktieren Sie mich.
TDD nutzt Tests, um die Entwicklung zu leiten. Was wäre, wenn wir zusätzlich eine Ontologie nutzten, um die fachliche Kohärenz einer Software zu bewahren? Diesem Ansatz gehe ich mit Claude Code nach: vom Code ausgehen, um eine Ontologie aufzubauen, und das Vorgehen dann schrittweise umkehren, damit diese Ontologie die Weiterentwicklung der Software leitet, prüft und begleitet.
Der Code funktioniert. Aber bildet er noch die richtige Fachlichkeit ab?
Mit KI-Agenten wie Claude Code sind wir in eine Phase eingetreten, in der das Schreiben von Code immer weniger Mühe kostet.
Ich beschreibe ein Feature. Der Agent erkundet den bestehenden Code, ändert mehrere Klassen, fügt Funktionen hinzu, passt Schnittstellen an, schreibt Tests. Ein paar Minuten später legt er mir seine Arbeit vor.
Der Code kompiliert. Die Tests laufen durch.
Eine Frage bleibt aber: Hält sich dieser neue Code noch an die Fachlogik meiner Anwendung?
Ein Agent kann eine technisch korrekte Implementierung liefern und dabei eine Inkohärenz ins Fachmodell einschleusen. Er kann zwei Namen für dasselbe Konzept verwenden, einen aufgegebenen Begriff wieder einführen oder eine Regel schaffen, die den bestehenden widerspricht.
Richtig interessant wird das Problem, wenn die Anwendung wächst und KI-Agenten einen immer größeren Teil der Änderungen übernehmen.
Wie gibt man ihnen ein gemeinsames fachliches Referenzwerk? Wie erkennt man eine Drift? Und wie verhindert man, dass dieses Referenzwerk zu noch einer Dokumentation wird, die irgendwann nicht mehr zur Software passt?
Ausgehend von diesen Fragen habe ich in meinen eigenen Projekten mit Claude Code begonnen, mit einem Ansatz zu experimentieren, den ich hier Ontology-Driven Design (ODD) nenne.
Zur Veranschaulichung nehme ich das Beispiel eines fiktiven ERP.
Erster Schritt: die Ontologie aus dem Code gewinnen
Mein Ausgangspunkt war recht einfach.
Ich betrachte den Quellcode als Quelle der Wahrheit für das tatsächlich implementierte Verhalten. Eine Spezifikation beschreibt eine Absicht; der Code zeigt, was die Anwendung wirklich tut.
Also habe ich Claude Code gebeten, den Code meiner Anwendung zu erkunden und daraus eine Darstellung der fachlichen Domäne in einer Markdown-Datei abzuleiten: ontology.md.
Diese Datei beschreibt unter anderem:
- die Fachkonzepte: Kunde, Auftrag, Angebot, Rechnung, Gutschrift … ;
- ihre Eigenschaften und Beziehungen;
- die Fachregeln und die Invarianten;
- die Zustände und ihre Übergänge;
- das Vokabular, mit dem diese Konzepte bezeichnet werden.
In unserem fiktiven ERP ist ein Kundenauftrag einem Kunden zugeordnet. Er hat eine oder mehrere Positionen. Er kann aus einem Angebot hervorgehen. Er kann freigegeben, storniert oder fakturiert werden.
Diese Informationen stehen im Code nicht unbedingt an einer Stelle. Manche Regeln sind ausdrücklich formuliert, andere über mehrere Funktionen verstreut.
Claude Code kann sie suchen und versuchen, sie zu rekonstruieren.
Das Ergebnis ist keine perfekte Spezifikation. Es ist eine strukturierte Deutung der Fachlichkeit auf Grundlage ihrer Implementierung, mit den Grenzen, die das mit sich bringt: Eine implizite Regel kann ihm entgehen, und ein historisch gewachsenes Verhalten kann fälschlich für eine beabsichtigte Regel gehalten werden.
Aber ich erhalte etwas Interessantes: eine Darstellung der Domäne, die von den technischen Details der Implementierung unabhängig ist.
Die Datei ontology.md wird zu einem Bezugspunkt, um die Software zu verstehen.
Zweiter Schritt: neuen Code an der Ontologie prüfen
Sobald diese Ontologie vorlag, habe ich Claude Code gebeten, sie bei der Entwicklung neuer Features heranzuziehen.
Die Idee war, die vorgenommenen Änderungen mit den Konzepten und Regeln aus ontology.md abzugleichen.
Angenommen, die Ontologie legt fest, dass eine freigegebene Rechnung nicht mehr geändert werden darf.
Fügt Claude Code ein Feature hinzu, mit dem sich ihre Positionen nach der Freigabe ändern lassen, muss er diesen Widerspruch melden.
Ebenso gilt: Unterscheidet die Ontologie klar zwischen Angebot und Auftrag, darf der Agent keine Funktion einführen, die die Zuständigkeiten dieser beiden Konzepte ohne ausdrücklichen Grund vermischt.
Das ist ein erstes Sicherheitsnetz.
Aber es hat einen Mangel.
Die Prüfung findet statt, nachdem der Code geschrieben ist.
Der Agent hat seine Arbeit schon erledigt. Vielleicht hat er mehrere Klassen angelegt, Methoden hinzugefügt und Tests rund um ein falsches Verständnis der Fachlichkeit gebaut.
Wir können das Problem erkennen, müssen danach aber den erzeugten Code wieder anfassen.
Anders gesagt: Ich habe eine nachträgliche Prüfung eingeführt. Nützlich, aber nicht ausreichend.
Dritter Schritt: sich von Test-Driven Development inspirieren lassen
An dieser Stelle dachte ich an TDD.
Das Prinzip von Test-Driven Development ist bekannt: Bevor man ein Verhalten implementiert, schreibt man einen Test, der ausdrückt, was man erwartet. Der Test schlägt fehl, man schreibt den Code, der nötig ist, damit er durchläuft, und verbessert dann die Implementierung, ohne dieses Sicherheitsnetz aufzugeben.
Warum nicht eine vergleichbare Logik auf die Ontologie anwenden?
Also habe ich Claude Code gebeten, seinen Ablauf zu ändern.
Bevor er Code schreibt, muss er das gewünschte Feature zuerst mit der bestehenden Ontologie abgleichen.
Die Reihenfolge der Schritte ändert sich.
Nehmen wir eine neue Anfrage:
„Ich möchte, dass ein Kundenauftrag angelegt werden kann, ohne zwingend über ein Angebot zu gehen.“
Legt die Ontologie fest, dass ein Auftrag zwingend aus einem Angebot hervorgehen muss, erkennt der Agent einen Widerspruch, bevor er den Code ändert.
Dieser Widerspruch ist aber nicht zwangsläufig ein Fehler in der Anfrage.
Er kann einer völlig legitimen fachlichen Weiterentwicklung entsprechen.
Der Agent muss also erkennen, dass die Absicht des Entwicklers eine bestehende Regel ändert, deren Weiterentwicklung vorschlagen und die Folgen für die verbundenen Konzepte bestimmen.
Danach kann er das Feature auf Grundlage des überarbeiteten Fachmodells entwickeln.
Der Ablauf wird zu:
- Das gewünschte Feature verstehen.
- Die betroffenen ontologischen Konzepte und Regeln bestimmen.
- Mögliche Widersprüche zwischen Anfrage und bestehendem Modell melden.
- Diese Widersprüche auflösen und dabei gewollte Weiterentwicklung von Entwurfsfehler unterscheiden.
- Das Feature entwickeln.
- Prüfen, dass der erzeugte Code mit dem erwarteten Fachmodell kohärent ist.
Das ist kein TDD im strengen Sinn: Eine Ontologie ist keine Suite automatisierter Tests, und eine Analyse durch ein LLM bietet nicht dieselben Garantien wie eine deterministische Assertion.
Die Philosophie ist aber verwandt: Erwartungen und Rahmenbedingungen festlegen, bevor man implementiert, statt Inkohärenzen hinterher zu entdecken.
Ab diesem Punkt beginnt die Ontologie, in der Entwicklung eine aktive Rolle zu spielen.
Und damit taucht ein neues Problem auf.
Vierter Schritt: eine Ontologie, die sich mit dem Code weiterentwickeln muss
Wenn die Ontologie zum Referenzwerk für die Entwicklung wird, wie hält man sie aktuell?
Ich will auf keinen Fall ein neues Dokument schaffen, an das man bei jeder Weiterentwicklung der Anwendung denken und das man von Hand anpassen muss.
Das hieße, zum Ausgangsproblem zurückzukehren: eine Dokumentation, die sich vom Code entkoppelt.
Der nächste Gedanke ist deshalb, einen mechanischen Anteil in den Ablauf einzubauen.
Ein Skript analysiert die Änderungen am Quellcode, vor allem auf Grundlage von Git, und ermittelt, was hinzugefügt, geändert oder entfernt wurde:
- Funktionen und Methoden;
- Klassen und Schnittstellen;
- Module und Packages;
- Signaturen und API-Verträge;
- über MCP bereitgestellte Tools, Ressourcen und Verträge;
- Beziehungen und fachliches Verhalten, die sich in den Änderungen erkennen lassen.
Das Ziel ist nicht, die Ontologie aus den technischen Details der Anwendung neu aufzubauen.
Im Gegenteil: Ich will von Implementierungsentscheidungen unabhängig bleiben. Eine hexagonale Architektur, Domain-Driven Design oder jede andere Organisation des Codes (auch eine sehr unsaubere) darf der Ontologie ihre Struktur nicht aufzwingen.
Die Ontologie bildet die fachliche Domäne ab, nicht die technische Architektur.
Eine Klasse ist nicht zwangsläufig ein Fachkonzept. Ein neues Package kann bloß eine technische Umstrukturierung sein. Eine Funktion kann eine Fachregel implementieren, ohne selbst ein neues Konzept zu sein.
Man muss also zwei Vorgänge trennen.
Der erste ist mechanisch: genau ermitteln, was sich geändert hat.
Der zweite ist semantisch: verstehen, ob diese Änderungen Fachkonzepte einführen, verändern oder ihnen widersprechen.
Hier kommt das LLM ins Spiel.
Das Skript erstellt eine Bestandsaufnahme der Änderungen. Das LLM gleicht diese Bestandsaufnahme mit der aktuellen Ontologie und mit den Anweisungen ab, die die Entwicklung ausgelöst haben.
Dann sind mehrere Fälle möglich.
Ein neues Fachkonzept taucht auf. Der Agent kann seine Aufnahme in die Ontologie vorschlagen oder vorbereiten, mit seinen Beziehungen und den zugehörigen Regeln.
Ein bestehendes Konzept ändert seine Bedeutung. Es muss geklärt werden, ob es sich um eine gewollte Weiterentwicklung oder um eine Drift handelt.
Zwei Konzepte werden inkohärent. Der Agent meldet den Widerspruch, mit Verweisen auf den betroffenen Code.
Das Vokabular läuft auseinander. Zwei Namen bezeichnen dieselbe fachliche Wirklichkeit, oder ein bestehender Name wird für einen anderen Begriff verwendet.
Die Änderung ist rein technisch. Eine ontologische Änderung ist nicht nötig.
Ein Punkt bleibt entscheidend: Der Code darf nicht automatisch recht haben.
Wenn ein Agent einen Fehler einführt, will ich nicht, dass ein zweiter Agent die Ontologie ändert, um diesen Fehler annehmbar zu machen.
Das Dreieck: Absicht, Code und Ontologie
Hier liegt, glaube ich, die eigentliche Weiterentwicklung des Konzepts.
Code und Ontologie zu vergleichen reicht nicht.
Man muss drei Dinge abgleichen:
Die Absicht: was der Entwickler von Claude Code verlangt hat.
Der Code: was tatsächlich implementiert wurde.
Die Ontologie: die maßgeblichen Fachkonzepte und Fachregeln.
Erst der Vergleich dieser drei Dinge zeigt, welcher Art eine Abweichung ist.
Zurück zu unserem fiktiven ERP.
Die Ontologie legt fest, dass ein Kundenauftrag zwingend aus einem Angebot hervorgeht.
Der Entwickler verlangt ausdrücklich, das Angebot optional zu machen.
Claude Code ändert die betroffenen Funktionen und führt die Möglichkeit ein, einen Auftrag direkt anzulegen.
Ontologie und neuer Code stehen jetzt im Widerspruch. Aber der Code entspricht der Absicht.
Das richtige Ergebnis ist also nicht, die Änderung grundsätzlich abzulehnen. Es besteht darin, die entsprechende Weiterentwicklung der Ontologie vorzuschlagen und dann die anderen Stellen der Software zu suchen, die noch voraussetzen, dass ein Angebot Pflicht ist.
Hätte Claude Code diese Pflicht dagegen entfernt, ohne dass eine Anweisung es verlangt hätte, wäre die Abweichung verdächtig.
Der Unterschied ist grundlegend.
Eine Inkohärenz ist nicht immer ein Bug. Sie kann eine gewollte fachliche Veränderung anzeigen.
Die Aufgabe des Systems ist nicht, Veränderung zu verhindern, sondern sie ausdrücklich, kohärent und nachverfolgbar zu machen.
Hin zu einem echten ontologiegesteuerten Entwicklungszyklus
Ich stelle mir jetzt einen Ablauf vor, der an drei Zeitpunkten greift.
Vor der Entwicklung: die Fachlichkeit verstehen
Geht eine neue Feature-Anfrage ein, bestimmt Claude Code die betroffenen ontologischen Konzepte.
Er muss dafür nicht die ganze Ontologie laden. Er kann die Konzepte, Beziehungen und Regeln auswählen, die für die Anfrage relevant sind.
Dann prüft er, ob das Feature mit diesem Modell vereinbar ist, oder meldet die nötigen Weiterentwicklungen.
So geht die Entwicklung von einem ausdrücklichen Verständnis der Domäne aus.
Während und nach der Entwicklung: Drift erkennen
Ein mechanischer Analysator erfasst die Änderungen am Quellcode.
Werkzeuge wie Tree-sitter ermöglichen es, die syntaktische Struktur zu analysieren und die geänderten Elemente zu bestimmen (das ist mein nächstes Vorhaben). Auch die Änderungen an API-Verträgen und MCP-Schnittstellen geben Auskunft darüber, welche Fähigkeiten die Anwendung nach außen anbietet.
Auf diese Elemente stützt sich das LLM, um nach Inkohärenzen mit der Ontologie zu suchen.
Dieser Schritt ließe sich über Hooks in den Workflow von Claude Code einbinden, etwa nach einer Änderung oder am Ende einer Aufgabe.
Es geht nicht darum, ein LLM bei jeder Änderung blind die ganze Anwendung neu lesen zu lassen, sondern darum, die Analyse auf die betroffenen Elemente zu konzentrieren.
Vor der Integration: die Kohärenz prüfen
Eine letzte Prüfung könnte vor dem Merge des Codes stattfinden.
Sie würde einen Bericht erzeugen mit:
- den neuen oder geänderten Konzepten;
- den möglicherweise betroffenen Fachregeln;
- den erkannten Inkohärenzen;
- den vorgeschlagenen ontologischen Änderungen;
- den Entscheidungen, die eine menschliche Freigabe brauchen.
Ziel ist eine reproduzierbare Prüfung, genau genug, um nützlich zu sein, ohne jede Codeänderung in eine endlose Durchsicht des Fachmodells zu verwandeln.
Die Verbindung zwischen den Konzepten und ihrer Implementierung bewahren
Eine ergänzende Verbesserung bestünde darin, eine Nachverfolgbarkeit zwischen Ontologie und Code zu pflegen.
Ein Konzept wie Invoice könnte mit mehreren Klassen, Funktionen, Events oder API-Operationen verknüpft werden, die an seiner Implementierung mitwirken.
Diese Zuordnungen definieren das Konzept nicht. Sie zeigen, wo es implementiert ist.
Diese Unterscheidung würde interessante Fragen beantwortbar machen.
Wenn ich das Konzept Rechnung ändere, welche Teile des Codes sind dann möglicherweise betroffen?
Wenn eine fachliche Funktion verschwindet, welche ontologische Regel ist dann womöglich nicht mehr implementiert?
Wenn eine neue API-Operation auftaucht, stellt sie ein bestehendes Konzept bereit oder bringt sie einen neuen Begriff zum Vorschein?
Und wenn eine Klasse umbenannt wird, ist das ein bloßes Refactoring oder eine echte Änderung der Domäne?
Diese Zuordnung ließe sich schrittweise pflegen, je nachdem, wie sich der Code weiterentwickelt.
Sie müsste allerdings die Belege jeder Zuordnung aufbewahren: Dateien, Symbole und beobachtete Änderungen. Eine vom LLM abgeleitete Beziehung darf nicht mit einer nachgewiesenen Entsprechung verwechselt werden.
Von ontologischen Invarianten zu automatisierten Tests
Ein weiterer Ansatz besteht darin, einen Teil der Ontologie ausführbar zu machen.
Manche Fachregeln lassen sich als Invarianten formulieren.
Zum Beispiel:
- eine freigegebene Rechnung darf nicht mehr geändert werden;
- eine Rechnung muss mindestens eine Position haben;
- eine Gutschrift verweist auf die Rechnung, die sie korrigiert;
- ein stornierter Auftrag darf nicht versandt werden.
Einige dieser Regeln könnten dazu dienen, automatisierte Tests zu erzeugen oder zu prüfen, ob bestehende Tests sie abdecken.
Man erhielte dann zwei sich ergänzende Ebenen.
Die erste wäre semantisch: Das LLM untersucht die Kohärenz zwischen Absichten, Konzepten und Code.
Die zweite wäre deterministisch: Tests und ausführbare Rahmenbedingungen prüfen das Verhalten, das sich formalisieren lässt.
Die Ontologie würde also weder Unit-Tests noch Integrationstests ersetzen.
Sie könnte helfen zu erklären, warum bestimmte Verhaltensweisen getestet werden müssen, und Fachregeln aufspüren, die noch ohne Prüfung sind.
Eine lebendige Ontologie, aber keine opportunistische
Dieser Ansatz birgt ein großes Risiko.
Ändert sich die Ontologie systematisch, um dem Code zu folgen, ist sie kein Sicherheitsnetz mehr. Sie wird zu einer bloßen Dokumentation, die laufend neu erzeugt wird.
Verbietet sie umgekehrt jede Weiterentwicklung, die ihren aktuellen Regeln widerspricht, hindert sie das Produkt daran, sich zu verändern.
Ontologische Weiterentwicklungen müssen also ausdrücklich gesteuert werden.
Ich unterscheide drei Fälle.
Die Weiterentwicklung ist beabsichtigt und klar. Das System kann eine versionierte Änderung der Ontologie vorbereiten und sie sogar vor der Freigabe in einem Arbeitsbranch anwenden.
Die Änderung wirkt inkohärent mit der Absicht. Das System schlägt eine Korrektur des Codes vor statt einer Aktualisierung der Ontologie.
Die Absicht ist mehrdeutig. Das System fordert eine Entscheidung an, statt eine neue Fachregel zu erfinden.
So wird die Ontologie zu einem sich weiterentwickelnden Vertrag zwischen Absicht und Implementierung.
Das setzt auch voraus, eine Historie zu führen, etwa mit einem kleinen Entscheidungsregister nach dem Vorbild der ADRs. Ein umbenanntes Konzept darf nicht zu zwei unabhängigen Konzepten werden. Eine entfernte Regel muss sich mit der Entscheidung verknüpfen lassen, die ihr Verschwinden begründet hat.
Die Weiterentwicklung der Ontologie muss genauso nachverfolgbar sein wie die des Codes.
Kohärenz messen statt Codezeilen zählen
Dieser Ansatz könnte auch einige interessante Kennzahlen liefern.
Die ontologische Abdeckung würde messen, welcher Anteil der im Code erkannten Fachkonzepte in der Ontologie abgebildet ist.
Die Nachverfolgbarkeit würde messen, wie viele Konzepte über überprüfbare Verweise auf ihre Implementierung verfügen.
Die Zahl der bestätigten und ungelösten Inkohärenzen würde eine Vorstellung von der Drift zwischen Code und Modell geben.
Schließlich könnte der Anteil der Invarianten, denen ausführbare Tests zugeordnet sind, helfen, die Belastbarkeit des Sicherheitsnetzes zu messen.
Diese Zahlen wären keine absoluten Qualitätskennzahlen. Ihr Wert hängt vollständig davon ab, ob das System echte Fachkonzepte von technischem Rauschen unterscheiden kann.
Aber sie könnten etwas beobachtbar machen, das heute weitgehend implizit bleibt: die konzeptionelle Kohärenz einer Software über ihre Weiterentwicklungen hinweg.
Und wenn der Ablauf in beide Richtungen funktionierte?
Anfangs lief bei mir alles in eine Richtung.
Der Code brachte die Ontologie hervor.
Dann habe ich eine Prüfung in umgekehrter Richtung hinzugefügt: Die Ontologie diente dazu, den neuen Code zu prüfen.
Inspiriert von TDD habe ich einen vorgelagerten Schritt eingeführt: die Absichten mit der Ontologie abgleichen, bevor die Entwicklung beginnt.
Der nächste Schritt besteht darin, das Erkennen und Einordnen der Änderungen zu automatisieren, um diese Kohärenz auf Dauer zu erhalten.
Inzwischen sehe ich aber noch eine weitere Möglichkeit.
Der Code könnte die Ontologie weiterentwickeln, und die Ontologie könnte die Weiterentwicklung des Codes leiten.
Lässt eine Codeänderung ein neues Fachkonzept zum Vorschein kommen, schlägt das System vor, es in die Ontologie aufzunehmen.
Bedeutet eine Anfrage die Weiterentwicklung eines bestehenden Konzepts, lassen sich mit der Ontologie die möglicherweise betroffenen Regeln und Implementierungen bestimmen, noch bevor die Arbeit beginnt.
Das Referenzwerk wird nicht mehr nur von der Software hervorgebracht. Es wirkt an ihrer Veränderung mit.
Dieser Kreislauf ist es, der mich interessiert.
Eine alte Idee, eine neu zu erfindende Nutzung
Es wäre falsch, Ontology-Driven Design als völlig neue Idee darzustellen.
Ontologien zum Entwurf von Anwendungen zu nutzen, gibt es schon lange. Pavel Hruby beschrieb bereits 2005 einen Ansatz für Ontology-Based Domain-Driven Design.
In jüngerer Zeit haben Arbeiten wie ODDToolkit untersucht, wie sich Software-Artefakte aus formalen Ontologien erzeugen lassen.
Mein Ansatz ist etwas anders.
Ich will die Software nicht unbedingt aus einer Ontologie erzeugen. Ich will auch nicht OWL, RDF oder einen anderen Formalismus voraussetzen, um anzufangen.
Ich will eine fachliche Ontologie als lebendiges Kohärenz-Referenzwerk für KI-Agenten nutzen, die den Quellcode ändern.
Der Unterschied ist wichtig.
Das Fachmodell ersetzt nicht die Implementierung. Es erhebt nicht den Anspruch, die ganze Komplexität einer Software zu beschreiben. Es garantiert für sich allein nicht, dass es keine Bugs gibt.
Es liefert einen ausdrücklichen Bezugsrahmen, damit nicht jeder Agent bei jeder neuen Aufgabe seine eigene Deutung der Fachlichkeit neu zusammenbaut.
Was noch zu beweisen ist
Ich befinde mich noch in einem persönlichen Experiment.
Ich habe damit begonnen, eine Ontologie aus dem Code zu erzeugen und Claude Code dann zu bitten, seine Änderungen daran zu prüfen. Danach habe ich die Anweisungen weiterentwickelt, um diese Prüfung vor die Entwicklung zu verlegen.
Der mechanische Synchronisationskreislauf, die systematische Nachverfolgbarkeit und die automatisierten Prüfungen sind die nächsten Arbeitsfelder.
Viele Fragen sind noch offen.
Wird der Analysator eine echte fachliche Änderung erkennen können, wenn sich kein Klassenname ändert? Wie viele False Positives wird das LLM erzeugen? Kann JEV diesen Bedarf abdecken? Das ist eine andere Baustelle, die eines Tages anzugehen ist. Wie verhindert man, dass die Ontologie mit technischen Details überfrachtet wird? Wie oft muss man die Entsprechungen zwischen Konzepten und Code überprüfen? Und vor allem: Rechtfertigt der Gewinn an Kohärenz die Ausführungs- und Pflegekosten des Ansatzes?
Dieser Ansatz muss sich an echten Weiterentwicklungen von Software bewähren, mit gewollten fachlichen Änderungen, künstlich eingeschleusten Inkohärenzen und rein technischen Refactorings.
Ich behaupte also nicht, eine neue, validierte Entwicklungsmethode definiert zu haben.
Ich beschreibe eine Richtung, die ich erprobe.
Die Fachlichkeit als Sicherheitsnetz
Die Entwicklungspraktiken haben die Schutzmechanismen nach und nach vervielfacht.
Unit-Tests schützen Verhalten. Integrationstests schützen Zusammenspiel. Typprüfungen und Werkzeuge zur statischen Analyse erkennen bestimmte Fehlerkategorien. Architekturregeln helfen, die Struktur der Software zu bewahren.
Doch wenn KI-Agenten einen wachsenden Teil des Codes schreiben, wird eine andere Frage wichtig:
Wer schützt die Kohärenz des Fachmodells, mit dem diese Agenten arbeiten?
DDD liefert seit Langem einen Teil der Antwort, mit der ubiquitären Sprache, den Domänenmodellen und den Kontextgrenzen. Die hexagonale Architektur hilft, die Fachlichkeit von technischen Belangen zu trennen.
Das Ontology-Driven Design, das ich erkunde, würde versuchen, diesen Prinzipien einen operativen Mechanismus hinzuzufügen: das Fachmodell ausdrücklich machen, es mit den Entwicklungsabsichten abgleichen und dann laufend seine Kohärenz mit dem Code prüfen.
Im Grunde ist mein Ziel nicht, mehr Dokumentation zu produzieren.
Es ist, Claude Code schneller entwickeln zu lassen, ohne dass er bei jedem Feature stillschweigend die Fachlichkeit neu erfindet.
Der Code bleibt die Wahrheit über das implementierte Verhalten. Die Ontologie wird zur Referenz für die fachliche Bedeutung. Die Absicht erklärt, warum sich diese Bedeutung ändern darf.
Und aus ihrem Abgleich könnte ein neues Sicherheitsnetz für die KI-gestützte Entwicklung entstehen.