Software Engineering ist kein Fließtext
KI hat heute vor allem Markdown und Prosa. Software Engineering ist aber ein Geflecht aus Begriffen, Anforderungen und Tests, die aneinanderhängen. Ein Blick auf Googles Open Knowledge Format, SKOS und arknet, ein Werkzeug im Aufbau.
Mein erster Arbeitstag war im Sommer 1999. Ich hab zusammen mit dem Abteilungsleiter einen Schreibtisch in sein Büro getragen. Beim Tragen sagte er: “Das C++-Projekt ist schon vergeben. Aber ich hab ein Java-Projekt, da könntest du helfen.” Ich hatte keine Ahnung von Java. Sein Rat: “Besorg dir ein Buch, arbeite dich zwei Wochen ein, dann geht’s los.”
So hab ich Java gelernt. In meiner Ausbildung kam sowas nicht vor, ich hatte C, SPS und Assembler gelernt, danach in einem längeren Praktikum C++. Vorgehensmodell, Requirements Engineering, Softwarearchitektur, das gab es in meiner Welt bis dahin schlicht nicht. Die Ansätze existierten 1999 sicher schon, nur nicht dort, wo ich unterwegs war. Ich hatte keinen Prozess. Ich hatte ein Buch und zwei Wochen.
Was danach kam, war kein einzelner Moment, in dem alles klick machte. Es waren zwanzig Jahre kleiner Impulse. Lesen. Mit Leuten reden. Workshops. Projekte, in denen etwas schiefging, und ich hab danach verstanden, warum. Am Ende stand nicht mehr Wissen allein. Es stand Zusammenhang: ein Detail in einem Projekt sehen und wissen, mit welchen zehn anderen Dingen es zusammenhängt.
Genau da sehe ich heute die Lücke bei KI. Nicht bei Wissen, davon hat sie reichlich. Was ihr fehlt, sind Artefakte, die diesen Zusammenhang selbst tragen, damit sie eine Entscheidung nachvollziehen kann.
Die These an einem echten Beispiel
KI hat heute vor allem Markdown-Dateien. Agenten bekommen davon massig, in jeder Form, für alles: READMEs, ADRs, Onboarding-Docs, Zusammenfassungen, Notizen. Software Engineering ist aber kein Fließtext, sondern ein Geflecht: ein Begriff hängt an einer Anforderung, eine Anforderung an einem Test, ein Test an dem, was am Ende tatsächlich passiert. Noch eine Zusammenfassung als Markdown kann das Problem verringern oder verschlimmern, gelöst wird es dadurch nicht.
Am 12. Juni 2026 hat Google dafür ein Format veröffentlicht: Open Knowledge Format, OKF. Markdown-Dateien werden darin zu “Concepts”, verlinkt über normale Markdown-Links zu einem Wissensgraph. Ich find das einen guten Schritt, verlinkt ist besser als isoliert. Nur sind die Links untypisiert. Sie sagen, dass zwei Dinge zusammenhängen, nicht wie. Sechs Wochen später, am 25. Juli, kam schon Version 0.2, jetzt mit Feldern für Vertrauen und Herkunft. An der eigentlichen Frage ändert das nichts: die Links selbst bleiben unbenannt. Auch OKF stößt also an die Grenze, um die es hier geht.
Das Problem zieht sich weiter, wenn man es dort sucht, wo Artefakte für KI-Agenten heute am strukturiertesten sind: bei Spec-driven Development, Werkzeugen wie GitHub Spec Kit oder AWS Kiro, die aus einer Spezifikation automatisch Plan und Aufgaben ableiten. Auch dort hängen Spec, Plan und Tasks nur über Dateipfade, Abschnittsüberschriften oder Ausführungsreihenfolge zusammen, nicht über benannte fachliche Beziehungen. Kiro geht am weitesten: Aufgaben kennen sogar, welche Aufgabe auf welche wartet. Aber das ist eine Ausführungsreihenfolge, keine Aussage darüber, wie zwei Begriffe fachlich zusammenhängen.
Und wenn sich eine Spezifikation ändert? Spec Kit hat dafür einen Befehl, der Spec, Plan und Aufgaben noch einmal komplett liest und nach Widersprüchen sucht. Nur ist das wieder ein Prosa-Durchlauf durch ein Sprachmodell, keine Prüfung gegen eine Struktur. Eine zweite Halluzination kann eine erste ebenso gut übersehen wie bestätigen. Einen harten Fakt liefern dort nur ausführbare Tests, aber die prüfen Verhalten, nicht ob eine behauptete Beziehung zwischen zwei Begriffen überhaupt stimmt.
Was OKF versucht, mache ich selbst schon länger, nur nicht mit einem brandneuen Format. Ich nutze SKOS, ein siebzehn Jahre altes W3C-Vokabular für Begriffshierarchien, für die Ordnerstruktur eines meiner eigenen Projekte. Jeder Ordner hat eine README mit ein paar Feldern: was er bedeutet, was nicht reingehört, und wie er zu anderen Ordnern steht, drei verschiedene Relationen: eine Ebene höher, eine Ebene tiefer, oder gleiche Ebene und verwandt. Kein Tool, keine Bibliothek, nur eine Konvention, die ich durchhalte – und die nur trägt, wenn jemand, ich selbst oder eine KI, die SKOS-Bedeutung von “broader” und “narrower” auch kennt.
Der Unterschied zu OKF und zu Spec-driven Development sitzt genau darin. Ein Markdown-Link sagt “das hängt irgendwie zusammen”. Eine benannte Relation sagt, wie: die Relation hat einen Namen, der Name ist Teil der Information.
Was das konkret heißt, zeigt ein reales Beispiel, aus einem kleinen Online-Shop, den ich als Testfall gebaut habe. Zwei Begriffe: “Order” ist einmal erstellt unveränderlich, wird nur storniert, nie bearbeitet. “Payment Authorisation” geht der Order voraus, verfällt, wenn die Order nicht rechtzeitig aufgegeben wird. Die Beziehung zwischen beiden ist selbst benannt, “geht voraus”, kein Link, der nur behauptet, dass irgendwas zusammenhängt. Eine Anforderung benutzt beide Begriffe, mit drei Abnahmekriterien: bei abgelehnter Freigabe entsteht keine Order, ohne vollständige Freigabe entsteht keine Order, der freigegebene Betrag muss exakt dem Bestellwert entsprechen, nie teilweise.
Schreib das als Prosasatz: “Vor der Bestellung muss die Zahlung geprüft werden.” Klingt gleich. Ist aber leer. Was passiert bei Ablehnung? Was ist mit Teilbeträgen? Darf die Order danach noch geändert werden? Genau diese Fakten gehen in der Prosaform verloren, jedes Mal, wenn jemand, Mensch oder KI, den Satz liest und neu interpretieren muss. Präziser aufschreiben ließe sich das zur Not auch in reiner Prosa. Was dabei trotzdem verloren geht, ist der Rückweg: ändert sich “Payment Authorisation”, steht nirgends, welche Anforderungen und Use Cases davon betroffen sind, das muss von Hand gesucht werden. Bei einer benannten Beziehung ist das eine Abfrage.
Wenn nichts verbunden ist
Korrekt formuliert reicht nicht, wenn das Ergebnis mit nichts verbunden ist. Ein Requirements Engineer bei einem Telekommunikationsanbieter hat genau das geliefert: Anforderungen, seitenweise, sprachlich sauber, nach Schema. Trotzdem konnten wir damit nichts anfangen, weil sie ohne die Begriffe kamen, auf die sie sich bezogen, und ohne die Use Cases, die sie hätten einordnen sollen. Wie Methoden ohne Klassen.
Das ist der Extremfall der These von oben: nicht bloß ein unbenannter Link zwischen Anforderung und Begriff, sondern gar keiner. Ohne Verknüpfung nützt saubere Sprache nichts, egal wie druckreif sie klingt. Bei einer KI ist das genauso: sie kann nur auf das zugreifen, was tatsächlich verbunden ist, benannt oder nicht. Verstreute Dokumente bleiben verstreut, ganz gleich, wie präzise jedes einzelne für sich genommen ist.
arknet: Der Versuch
Ich baue gerade selbst an so einem Werkzeug: arknet (github.com/kogn-io/arknet, Diskussionen unter …/discussions). Es hält Begriffe, Anforderungen und Use Cases als geprüfte Fakten mit benannten Beziehungen, so wie das Order/Payment-Beispiel oben zeigt. Seit Kurzem auch Architekturentscheidungen: mit Kontext und Alternativen festgehalten, referenzierbar wie jeder andere Fakt im Graphen, statt als bloße Behauptung im Raum. Ob das im Projektalltag trägt, probiere ich gerade an mir selbst aus.
Ich sag bewusst nicht, dass arknet die These beweist. Es ist der Versuch, sie zu belegen, ein Werkzeug, das gerade erst entsteht, kein fertiges Ergebnis. Aber es ist der ehrlichste Testfall, den ich kenne: entweder es hilft tatsächlich, weil der Zusammenhang zählt, oder es hilft nicht, und dann war die These falsch oder zu einfach gedacht.
Einfache Anwendungen wird KI zunehmend ohne viel Führung bauen, das wird funktionieren. Bei komplexen Projekten trennt sich Vibe Coding von KI-gestützter Entwicklung nicht daran, ob eine KI beteiligt ist, sondern daran, ob der Zusammenhang zwischen den Artefakten erhalten bleibt. Ohne das wird auch ein komplexes Projekt fertig, nur nicht wartbar, ein Wegwerf-Prototyp in Produktion: es funktioniert heute, aber niemand, auch keine KI, kann morgen noch verlässlich sagen, was sich ändert, wenn sich ein einziger Begriff ändert.
Ein Beispiel dafür ist näher, als es klingt. Nimm noch einmal Order und Payment Authorisation von oben. Ein Agent behauptet morgen, die beiden hingen jetzt anders zusammen, die Reihenfolge hätte sich geändert. In einer Welt aus Markdown-Dateien kann das nur beurteilen, wer den Text noch einmal liest, Mensch oder KI, mit derselben Unsicherheit wie beim ersten Mal. In einer Welt mit benannten, typisierten Beziehungen ist das eine Prüfung: passt die neue Behauptung zum Schema, ja oder nein – das sagt, ob sie zulässig ist, nicht ob sie stimmt.
Der Unterschied zwischen einer Behauptung und einem Fakt ist am Ende nicht, wie überzeugend sie klingt. Es ist, ob sie sich prüfen lässt.
Wer das anders sieht: gerne.