Deterministische Leitplanken

Was „deterministisch" heißt

Deterministisch bedeutet: Der gleiche Input führt immer zum gleichen Output. Genau das gilt für Sprachmodelle in der Regel nicht. Dieselbe Aufgabenstellung kann bei zwei Durchläufen zu unterschiedlichen Implementierungen führen. Als Auftraggeber stellt sich damit eine naheliegende Frage:

Gibt es für mein Problem nicht eine Lösung, die besser ist als die anderen?

Doch, sehr oft. Das Problem beginnt dort, wo das Sprachmodell selbst entscheiden soll, was „gut" ist. Denn auch dieses Urteil ist nicht deterministisch.

Wer mit agentischer Softwareentwicklung industrielle Qualität erreichen will, braucht deshalb mehr als Vibe-Coding. Es braucht ein System aus zwei Mechanismen: Lenken schränkt mit Context Engineering, Architekturvorgaben, Projektwissen und klaren Regeln den Lösungsraum ein. Prüfen lässt deterministische, automatisierte Tests entscheiden, ob das Ergebnis unseren Qualitätsanforderungen entspricht.

Die eigentliche Herausforderung ist deshalb nicht, ein Sprachmodell Code schreiben zu lassen. Sie besteht darin, eine Architektur und ein Framework zu schaffen, in denen nicht-deterministische KI zu deterministisch überprüfbarer Softwarequalität führt.

Lenken: den Lösungsraum verkleinern

Ein Sprachmodell kann viele mögliche Lösungen erzeugen. Unsere Aufgabe ist es, die Wahrscheinlichkeit guter Lösungen zu erhöhen. Dafür arbeitet die KI nicht nur mit einer Aufgabenbeschreibung, sondern innerhalb einer definierten Architektur mit klaren Schichten, Modulen, Verantwortlichkeiten und technischen Regeln. Zusätzlich erhält sie relevantes Projektwissen als Kontext. Je besser dieser Kontext ist, desto kleiner wird der Raum möglicher Fehlentscheidungen.

Das ist für uns Context Engineering: die Arbeitsumgebung der KI so zu gestalten, dass gute Entscheidungen wahrscheinlicher werden.

Eine Garantie ist das nicht. Deshalb reicht Lenken allein nicht aus.

Prüfen: Qualität muss reproduzierbar sein

Ob eine Lösung korrekt ist, darf nicht davon abhängen, ob ein Sprachmodell sie überzeugend findet. Deshalb übernehmen deterministische Systeme die Entscheidung: Compiler, statische Analysen und automatisierte Tests urteilen bei gleichem Code immer gleich.

Ist eine verbindliche Prüfung rot, geht die Änderung nicht weiter.

Die KI darf schnell und kreativ arbeiten. Die Qualitätskontrolle darf nicht kreativ sein.

Drei Ebenen der Prüfung

Softwarequalität lässt sich nicht mit einem einzigen Test absichern. Deshalb prüfen wir auf mehreren Ebenen.

Erstes Tor: Compiler und statische Regeln

Bevor ein Test läuft, prüft der Compiler den Code: Typfehler, ungültige Aufrufe und viele strukturelle Probleme werden sofort sichtbar. Zusätzliche statische Regeln stellen sicher, dass Architektur- und Projektvorgaben eingehalten werden.

Ebene 1: Fachlogik isoliert

Hier prüfen wir die eigentliche Fachlogik ohne Datenbank und möglichst ohne externe Infrastruktur: Berechnungen, Geschäftsregeln, Zustandsübergänge, Grenzfälle. Diese Tests laufen sehr schnell und können deshalb nach praktisch jeder Änderung ausgeführt werden.

Ebene 2: mit echter Datenbank

Viele Fehler entstehen erst beim Zusammenspiel mit der Datenbank. Deshalb testen wir auf dieser Ebene unter anderem Abfragen, Beziehungen, Transaktionen, Constraints, Migrationen und das Verhalten mit realen Datenmengen. Die entscheidende Frage lautet:

Funktioniert unsere Annahme auch mit echter Datenbanklogik?

Ebene 3: Gesamtsystem und Performance

Auf der höchsten Ebene testen wir vollständige Abläufe über mehrere Schichten und Module hinweg. Eine Eingabe durchläuft denselben Weg wie im realen System: von der Schnittstelle über Fachlogik und Datenzugriff bis zum gespeicherten Ergebnis. Dabei prüfen wir nicht nur, ob der Ablauf funktioniert, sondern auch, ob er schnell und stabil genug funktioniert.

Dazu gehören Performance-Tests für Antwortzeiten kritischer Abläufe, größere Datenmengen, parallele Zugriffe, Ressourcenverbrauch, Engpässe und Performance-Regressionen. Denn Software kann fachlich korrekt sein und trotzdem in der Praxis zu langsam oder unter Last instabil werden.

Architektur macht Qualität prüfbar

Diese Prüfungen funktionieren nur, wenn die Software entsprechend aufgebaut ist. Sind Fachlogik, Datenzugriff und Infrastruktur eng miteinander vermischt, lassen sich einzelne Teile kaum zuverlässig testen. Architektur ist für uns deshalb kein Selbstzweck: Sie schafft die Voraussetzung dafür, Qualität automatisiert prüfen zu können. Klare Grenzen zwischen Modulen und Schichten ermöglichen es, Fachlogik isoliert, Datenzugriffe realistisch und das Gesamtsystem vollständig zu testen.

Jeder Fehler verbessert das System

Ein Fehler, der einmal gefunden wurde, sollte möglichst nicht ein zweites Mal auftreten. Deshalb beheben wir nicht nur den konkreten Fehler, sondern fragen auch, welche Leitplanke gefehlt hat. Daraus entsteht ein neuer Test, eine zusätzliche Architekturregel, eine statische Prüfung, besserer Kontext für die KI oder eine Verbesserung am Framework.

So verbessert jeder erkannte Schwachpunkt nicht nur das Produkt, sondern auch das Entwicklungssystem selbst.

Der Unterschied zu Vibe-Coding

Beim Vibe-Coding steht meist das schnelle Erzeugen einer scheinbar funktionierenden Lösung im Vordergrund: Prompt eingeben, Code erzeugen, kurz ausprobieren, weiter. Für Prototypen kann das hervorragend funktionieren. Für Software, die über Jahre betrieben, erweitert und gewartet werden soll, reicht es nicht.

Agentische Softwareentwicklung auf industriellem Niveau bedeutet deshalb nicht, möglichst viel Verantwortung an die KI abzugeben. Im Gegenteil: Wir nutzen die KI dort, wo sie stark ist, beim schnellen Erzeugen, Analysieren und Verändern von Code. Und wir begrenzen sie dort, wo Verlässlichkeit wichtiger ist als Kreativität.

Die KI erzeugt Lösungen. Das System entscheidet, welche davon akzeptabel sind.

Was das für Sie bedeutet

Qualität ist bei uns kein Versprechen, sondern ein Prüfergebnis. Wenn eine Geschäftsregel abgesichert ist, gibt es dafür einen Test. Wenn eine Architekturregel verbindlich ist, kann sie automatisiert geprüft werden. Wenn ein kritischer Ablauf funktionieren muss, kann er reproduzierbar durchlaufen werden. Und wenn Performance wichtig ist, wird auch sie messbar geprüft.

So verbinden wir die Geschwindigkeit moderner KI mit einem Entwicklungssystem, das Qualität reproduzierbar kontrolliert. Wie solche Leitplanken für Ihr konkretes Vorhaben aussehen, klären wir in einer kurzen Anfrage.