Warum Maker die KI nicht bittet, Code zu schreiben.
Anwendungsgeneratoren bitten ein Sprachmodell, Code zu improvisieren. Das Ergebnis ist mitunter brillant, oft fragil — und jede Korrektur riskiert, eine andere zu zerstören. Maker beruht auf einer anderen Rollenverteilung.
Die KI tut, was sie am besten kann: Ihren Bedarf verstehen. Die Builder tun, was eine Maschine am besten kann: einen Plan ausführen, jedes Mal identisch.
DIE ROLLENVERTEILUNG — DAS FUNDAMENT VON MAKERKonzipiert für strukturierte Verwaltungsbereiche.
Überall, wo es Objekte, Abläufe, Status und Kennzahlen gibt, kann Maker den Plan erstellen: Einsätze, Aufträge, Lager, Planungen, Kundenbetreuung.
Was das für Sie ändert. Eine von Maker generierte Anwendung ist keine Improvisation: Sie ist die Ausführung eines Plans, den Sie bestätigt haben. Wenn Sie Ihren Bedarf anpassen, ändert sich der Plan — und der Aufbau folgt, ohne Nebenwirkungen.
Das Design-System ist keine Option. Jede Anwendung wird aus einem professionellen Komponentensystem zusammengesetzt — demselben, das diese Website aufbaut.
Das Eigentum ist nicht verhandelbar. Der erzeugte Code gehört Ihnen ab der Generierung. ZIP-Export, GitHub-Push, Hosting, wo Sie wollen. Maker ist ein Erbauer, kein Vermieter.
the making
Two ways to build an application. Only one holds up over time.
Every generator impresses on the first try. What sets them apart shows up during the making — then later, when something has to change. Here, one and the same request, followed end to end.
first movement — the making
From your idea to the first version.
Same starting request: “a tool to track my technicians' work orders, with a 4-hour deadline to meet”.
a generator that asks the ai to write the code
One sentence, in plain language.
Screens, data, rules: all produced in one shot. You don't see what was decided along the way.
maker — the ai draws up the plan
The same sentence, in your own words.
It lists what it understood: your technicians, your work orders, your 4-hour deadline. Nothing is built yet.
In plain language, not in code. The deadline is 6 hours, not 4? You fix it here, in one line — before a single line of code exists.
this is where the unpredictable stops
no correction loop
The builders apply proven rules: the code holds because it is assembled, not improvised.
They apply fixed rules, replayed identically on every generation. The code holds because it is assembled, not improvised — there is no correction loop.
At its dedicated URL. And the plan you validated stays readable — it's the reference.
second movement — the drift
What the fixes do to your original request.
When the AI re-reads and rewrites its own code several times over, it doesn't replay your request — it replays its last attempt. What you asked for drifts away, with nothing to flag it.
no written reference
The rule changed, and no one saw it. There is no document to compare against: the only trace of your request is the sentence you typed, and the code no longer resembles it.
the plan is the reference
The code can be rebuilt as many times as needed, the rule doesn't move. It isn't in the code: it's in the plan you approved.
third movement — the change
Later, you want to add a status “overdue ”.
This is where the gap shows most.
back to the loop
It re-reads code it has already rewritten several times, and never designed as such.
The code thickens, fixes pile up, and the loop lengthens as the application ages.
back to the plan
The one you validated. It's still there, still readable.
Status “overdue”: when the 4-hour deadline is passed. You re-read, you validate.
the rest of the plan hasn't moved
What didn't change in the plan doesn't change in the application. A late change takes the same effort as an early one.
what this changes for you
| criterion | the ai writes the code | blueprint maker |
|---|---|---|
| Role of the AI | the ai writes the code — Writes and rewrites the code | maker — Draws up the plan, never the code |
| Before delivery | the ai writes the code — Correction rounds, billed | maker — No correction round |
| What you validate | the ai writes the code — Nothing — you discover the result | maker — The plan, in plain language, before making |
| Your original request | the ai writes the code — Drifts with each fix | maker — Stays written, stays the reference |
| A change | the ai writes the code — Restarts the loop on the whole project | maker — Changes one line of the plan |
| Over time | the ai writes the code — Each fix calls for another | maker — The cost of a change doesn't spiral |
| Your code | the ai writes the code — Often kept on the platform | maker — ZIP export, GitHub push, self-hosting |
Unser Ansatz
Was Blueprint von einem gewöhnlichen Anwendungsgenerator trennt.
Das Problem, das fast alle ignorieren
Ein Anwendungsgenerator mit künstlicher Intelligenz schreibt Code. Wenn das Modell sich irrt, irrt es mit derselben Überzeugung wie dann, wenn es recht hat — und nichts im erzeugten Code unterscheidet die beiden.
Wir haben Blueprint auf der Weigerung aufgebaut, diesen Kompromiss einzugehen. Hier sind die Grundsätze, die bestimmen, was unser System tut, und vor allem, was es zu tun ablehnt.
Wofür wir einstehen
Wir generieren keinen Code aufs Geratewohl
Blueprint bittet kein Modell, Ihre Anwendung Zeile für Zeile zu schreiben. Es erzeugt zunächst eine Spezifikation — eine strukturierte und überprüfbare Beschreibung dessen, was die Anwendung sein soll — und fertigt dann den Code aus dieser Spezifikation, auf deterministische Weise.
Die Folge ist einfach: Zweimal dieselbe Spezifikation erzeugt zweimal dieselbe Anwendung. Die Zuverlässigkeit von Blueprint ist beweisbar, nicht wahrscheinlich.
Das Modell ist frei, wo der Fehler harmlos ist, und eingeschränkt, wo er es nicht ist
Nicht alle Fehler sind gleich. Eine Ungeschicklichkeit in der Anordnung eines Formulars ist in einem Augenblick korrigiert. Eine falsche Geschäftsregel pflanzt sich stillschweigend in jede Berechnung fort, die von ihr abhängt.
Wir gewähren der künstlichen Intelligenz ihre Freiheit, wo das Risiko lokal und reparierbar ist; wir schränken sie streng ein, wo ein Fehler unsichtbar und dauerhaft wäre. Der Spielraum des Modells folgt der Schwere des möglichen Fehltritts.
Unsere Zuverlässigkeit hängt nicht vom Modell des Tages ab
Modelle entwickeln sich schnell; sie ändern sich. Blueprint setzt seine Zuverlässigkeit nicht auf das Talent eines bestimmten Modells. Das Fachwissen, das die Richtigkeit Ihrer Anwendungen gewährleistet, liegt in einem von Experten kuratierten Wissen, das das Modell zurate zieht — und nicht im Modell selbst.
Ein besseres Modell macht Blueprint besser. Kein Modell macht Blueprint fehlbar.
Wenn das System es nicht weiß, sagt es Ihnen das
Das ist unsere wichtigste Verpflichtung und das genaue Gegenteil des Standardverhaltens einer generativen KI. Angesichts einer Situation, die es nicht mit Sicherheit feststellen kann, enthält sich Blueprint, statt zu raten. Eine gemeldete Lücke ist ein gesunder Zustand; eine fabrizierte Plausibilität ist ein Fehler — denn Sie könnten sie nicht von einer Tatsache unterscheiden.
Jede Schlussfolgerung trägt ihren Grad an Gewissheit
Wenn Blueprint Ihren Bedarf interpretiert, präsentiert es niemals eine Vermutung mit der Sicherheit einer feststehenden Tatsache. Der Grad des Vertrauens folgt der Information bis zu Ihnen. Sie wissen stets, was gewiss ist und was Ihren Blick erfordert.
Unser Kurs
Über das hinaus, was wir heute garantieren, leiten zwei Ansprüche unsere Arbeit:
- Anwendungen erzeugen, die dem tatsächlichen Anspruch Ihres Fachgebiets gerecht werden — nicht die minimale Struktur, die „funktioniert“, sondern die Tiefe, die Ihre Tätigkeit verdient.
- Dem Bereich treu bleiben, den Sie beschreiben, ohne jemals aus Bequemlichkeit zu einer generischen Lösung abzudriften.
Das sind Richtungen, die wir schrittweise umsetzen und die wir uns weigern, als erreicht anzukündigen, solange sie es nicht sind. Auch das ist eine Art, Wort zu halten.
Blueprint — erst eine Spezifikation, dann eine Anwendung. Nichts dem Zufall überlassen.