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 todas as necessidades 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.
intervenções
stocks
acompanhamento de clientes
a sua necessidade
encomendas
planeamentos
indicadores
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.
a fabricação
Duas formas de construir uma aplicação. Só uma resiste ao tempo.
Todos os geradores impressionam à primeira tentativa. O que os distingue aparece durante a fabricação: e mais tarde, quando é preciso modificar. Aqui, um mesmo pedido, seguido de ponta a ponta.
primeiro tempo: a fabricação
Da sua ideia à primeira versão.
Mesmo pedido de partida: «uma ferramenta para acompanhar as intervenções dos meus técnicos, com um prazo de 4 horas a cumprir».
um gerador que pede à ia para escrever o código
Uma frase, em linguagem natural.
Ecrãs, dados, regras: tudo produzido de uma só vez. Não vê o que foi decidido pelo caminho.
maker: a ia estabelece o plano
A mesma frase, com as suas próprias palavras.
Enumera o que compreendeu: os seus técnicos, as suas intervenções, o seu prazo de 4 horas. Nada está ainda fabricado.
Em linguagem natural, não em código. O prazo é de 6 horas e não de 4? Corrige aqui, numa linha, antes de existir uma única linha de código.
é aqui que o imprevisível para
nenhum ciclo de correção
Os builders aplicam regras comprovadas: o código aguenta porque é montado, não improvisado.
Aplicam regras fixas, reproduzidas de forma idêntica em cada geração. O código aguenta porque é montado, não improvisado, não há ciclo de correção.
No seu URL dedicado. E o plano que validou continua consultável, é a referência.
segundo tempo: o desvio
O que as correções fazem ao seu pedido inicial.
Quando a IA relê e reescreve o seu próprio código várias vezes seguidas, não reproduz o seu pedido, reproduz a sua última tentativa. O que tinha pedido deforma-se progressivamente, sem que nada o assinale.
sem referência escrita
A regra mudou, ninguém deu por isso. Não existe nenhum documento para comparar: o único vestígio do seu pedido é a frase que escreveu, e o código já não se parece com ela.
o plano é a referência
O código pode ser refabricado as vezes que forem precisas, a regra não se mexe. Não está no código: está no plano que aprovou.
terceiro tempo: a modificação
Mais tarde, quer adicionar um estado «em atraso ».
É aqui que a diferença se torna mais visível.
volta-se ao ciclo
Relê um código que já reescreveu várias vezes, e que não concebeu tal como está.
O código engrossa, as correções acumulam-se, e o ciclo alonga-se à medida que a aplicação envelhece.
volta-se ao plano
Aquele que tinha validado. Continua lá, continua legível.
Estado «em atraso»: quando o prazo de 4 horas é ultrapassado. Relê, valida.
o resto do plano não se mexeu
O que não mudou no plano não muda na aplicação. Uma modificação tardia exige o mesmo esforço que uma precoce.
o que isto muda para si
| critério | a ia escreve o código | blueprint maker |
|---|---|---|
| Papel da IA | a ia escreve o código: Escreve e reescreve o código | maker: Estabelece o plano; a estrutura é compilada, não escrita |
| Antes da entrega | a ia escreve o código: Voltas de correção, faturadas | maker: Nenhuma volta de correção |
| O que valida | a ia escreve o código: Nada: descobre o resultado | maker: O plano, em linguagem natural, antes de fabricar |
| O seu pedido inicial | a ia escreve o código: Deforma-se a cada correção | maker: Fica escrito, continua a ser a referência |
| Uma modificação | a ia escreve o código: Relança o ciclo sobre todo o projeto | maker: Muda uma linha do plano |
| Com o tempo | a ia escreve o código: Cada correção chama outra | maker: O custo de uma modificação não dispara |
| O seu código | a ia escreve o código: Muitas vezes retido na plataforma | maker: Exportação ZIP, push GitHub, alojamento onde quiser |
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.