Porque é que o Maker não pede à IA para escrever código.
Os geradores de aplicações pedem a um modelo de linguagem que improvise código. O resultado é por vezes brilhante, muitas vezes frágil — e cada correção arrisca-se a quebrar outra. O Maker assenta numa repartição de papéis diferente.
A IA faz o que faz melhor: compreender a sua necessidade. Os builders fazem o que uma máquina faz melhor: executar um plano, de forma idêntica, sempre.
A REPARTIÇÃO DOS PAPÉIS — FUNDAMENTO DO MAKERConcebido para os negócios de gestão estruturada.
Sempre que há entidades, fluxos, estados e indicadores, o Maker sabe estabelecer o plano: intervenções, encomendas, stocks, planeamentos, acompanhamento de clientes.
O que isto muda para si. Uma aplicação gerada pelo Maker não é uma improvisação: é a execução de um plano que validou. Quando ajusta a sua necessidade, o plano muda — e a construção acompanha, sem efeitos secundários.
O design system não é uma opção. Cada aplicação é montada a partir de um sistema de componentes profissional — o mesmo que constrói este site.
A propriedade não é negociável. O código produzido pertence-lhe desde a geração. Exportação ZIP, push GitHub, alojamento onde quiser. O Maker é um construtor, não um senhorio.
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 |
A nossa abordagem
O que separa o Blueprint de um gerador de aplicações comum.
O problema que quase toda a gente ignora
Um gerador de aplicações por inteligência artificial escreve código. Quando o modelo se engana, engana-se com a mesma segurança com que acerta — e nada, no código produzido, distingue os dois.
Construímos o Blueprint sobre a recusa deste compromisso. Eis os princípios que governam o que o nosso sistema faz e, sobretudo, o que se recusa a fazer.
O que garantimos
Não geramos código ao acaso
O Blueprint não pede a um modelo que escreva a sua aplicação linha a linha. Produz primeiro uma especificação — uma descrição estruturada e verificável do que a aplicação deve ser — e depois fabrica o código a partir dessa especificação, de forma determinista.
A consequência é simples: duas vezes a mesma especificação produzem duas vezes a mesma aplicação. A fiabilidade do Blueprint é demonstrável, não provável.
O modelo é livre onde o erro é benigno, limitado onde não o é
Nem todos os erros são iguais. Uma imperfeição na disposição de um formulário corrige-se num instante. Uma regra de negócio errada propaga-se silenciosamente em cada cálculo que dela depende.
Concedemos à inteligência artificial a sua liberdade onde o risco é local e reparável; limitamo-la estritamente onde um erro seria invisível e duradouro. A margem de manobra do modelo acompanha a gravidade da falha possível.
A nossa fiabilidade não depende do modelo do momento
Os modelos progridem depressa; mudam. O Blueprint não aposta a sua fiabilidade no talento de um modelo em particular. O conhecimento de negócio que garante a exatidão das suas aplicações reside num conhecimento curado por especialistas, que o modelo consulta — e não no próprio modelo.
Um modelo melhor torna o Blueprint melhor. Nenhum modelo torna o Blueprint falível.
Quando o sistema não sabe, di-lo
É o nosso compromisso mais importante, e o exato oposto do comportamento por defeito de uma IA generativa. Perante uma situação que não consegue estabelecer com certeza, o Blueprint abstém-se em vez de adivinhar. Um vazio assinalado é um estado saudável; uma plausibilidade fabricada é uma falha — porque não a conseguiria distinguir de um facto.
Cada inferência transporta o seu grau de certeza
Quando o Blueprint interpreta a sua necessidade, nunca apresenta uma suposição com a segurança de um facto estabelecido. O grau de confiança acompanha a informação até si. Sabe sempre o que é certo e o que exige a sua atenção.
O nosso rumo
Para além do que garantimos hoje, duas exigências guiam o nosso trabalho:
- Produzir aplicações à altura real do seu negócio — não a estrutura mínima que « funciona », mas a profundidade que a sua atividade merece.
- Manter-nos fiéis ao domínio que descreve, sem nunca derivar para uma solução genérica por facilidade.
São direções que instrumentamos progressivamente, e que nos recusamos a anunciar como adquiridas enquanto não o forem. É, também, uma forma de cumprir a palavra dada.
Blueprint — uma especificação primeiro, uma aplicação depois. Nada ao acaso.