Das Problem mit Code, den ein LLM Zeile für Zeile schreibt
Ein Sprachmodell erzeugt den wahrscheinlichsten Code, nicht zwangsläufig den richtigen. Auf der Ebene einer Demodatei geht das gut. Auf der Ebene einer Anwendung: ein Datenbankschema, Dutzende Masken, Beziehungen, Regeln: summieren sich die kleinen Fehler: eine Komponenteneigenschaft, die es nicht gibt, eine falsch benannte Beziehung, ein angezeigtes Feld, das keiner Spalte entspricht.
Die Falle ist, dass dieser Code korrekt aussieht. Er liest sich gut, kompiliert manchmal, lässt sich bereitstellen – und bricht im Gebrauch. Dabei ist das einzige Kriterium, das für eine Anwendung zählt, binär: Sie läuft, oder sie läuft nicht.
Verstehen und Bauen trennen
Blueprint Maker verteilt die Arbeit danach, was jede Seite am besten kann. Die KI entwirft das Fachschema: Sie versteht Ihre Domäne, benennt die Entitäten, leitet Beziehungen und Regeln ab. Das ist eine Verständnisaufgabe, und natürliche Sprache glänzt darin.
Aber sie schreibt nicht den Code. Sie erzeugt eine strukturierte Spezifikation – ein Fachschema im JSON-Format. Anschließend verwandelt eine einmal geschriebene und getestete deterministische Engine diese Spezifikation in Code: Prisma-Schema, Next.js-Masken, Routen, Dashboards. Dasselbe Schema als Eingabe erzeugt immer denselben Code als Ausgabe.
- Die KI versteht die Domäne → ein Fachschema (kein Code)
- Die Engine garantiert die technische Konformität → den Code
- Gleiche Eingabe, gleiche Ausgabe: reproduzierbar
Korrekt per Konstruktion
Das ist der Kern der Methode. Die Eigenschaften der Komponenten werden nie vom Modell erraten: Die Engine setzt sie, aus dem Schema, nach festen Regeln. Eine Tabellenspalte, eine Beziehung, ein Datumsformat: alles wird abgeleitet, nicht erraten. Wo ein LLM eine Option erfinden kann, die es nicht gibt, kennt die Engine nur das, was existiert.
Noch bevor überhaupt etwas ausgeliefert wird, durchläuft das Schema ein Validierungstor: Es wird geprüft und, wenn nötig, korrigiert, bis es gültig ist. Wir bauen keinen Code auf wackligem Fundament.
Unter realen Bedingungen validiert, vor der Auslieferung
Richtigen Code zu schreiben genügt nicht: Man muss ihn beweisen. Jede Anwendung wird automatisch gebaut, gestartet und durchlaufen, bevor sie zu Ihnen gelangt: der Code wird kompiliert, die Anwendung echt gestartet, die Navigation Maske für Maske getestet. Das ist unser Laufzeit-Validierungstor, und es ist unser einziges automatisiertes Qualitätskriterium, das nicht lügt.
Der Prozentsatz der Anwendungen, die all diese Prüfungen der letzten sieben Tage bestehen, wird datiert auf unserer Zuverlässigkeitsseite veröffentlicht. Nur wenige KI-App-Generatoren zeigen ein solches Maß: weil nur wenige eine deterministische Möglichkeit haben, es zu erzeugen.
Und ein angezeigter Wert sollte nicht lügen können
Derselbe Anspruch erstreckt sich auf die Daten. Eine Summe, ein Durchschnitt, ein abgeleiteter Status: Diese Werte werden serverseitig aus ihren Eingaben neu berechnet, damit eine angezeigte Zahl dem, woraus sie hervorgeht, nicht widersprechen kann. Die Konsistenz bleibt nicht dem Zufall einer Eingabe überlassen.
Am Ende bekommen Sie echten Standardcode (Next.js + Prisma), der Ihnen gehört, erstellt mit einer Methode, die auf Richtigkeit statt auf Plausibilität zielt. Das ist der ganze Unterschied zwischen einer Anwendung, die auszusehen scheint, als funktioniere sie, und einer, die funktioniert.