Ir para o conteúdo principal

Nos bastidores

Porquê um motor determinista em vez de código escrito pela IA

Fazer um modelo de linguagem escrever uma aplicação inteira dá um resultado plausível, raramente um resultado garantido. O Blueprint Maker aborda o problema ao contrário: a IA concebe, um motor determinista fabrica.

O problema do código escrito linha a linha por um LLM

Um modelo de linguagem produz o código mais provável, não necessariamente o correto. À escala de um ficheiro de demonstração, resulta. À escala de uma aplicação: um esquema de base de dados, dezenas de ecrãs, relações, regras: os pequenos erros acumulam-se: uma propriedade de componente que não existe, uma relação mal nomeada, um campo apresentado que não corresponde a nenhuma coluna.

A armadilha é que este código parece correto. Lê-se bem, às vezes compila, é implementado, e falha no uso. Ora, o único critério que conta para uma aplicação é binário: funciona, ou não funciona.

Separar a compreensão da fabricação

O Blueprint Maker reparte o trabalho conforme aquilo que cada parte sabe fazer melhor. A IA concebe o esquema de negócio: compreende o seu domínio, nomeia as entidades, deduz as relações e as regras. É um trabalho de compreensão, e a linguagem natural destaca-se nele.

Mas não redige o código. Produz uma especificação estruturada, um esquema de negócio em formato JSON. Depois, um motor determinista, escrito uma vez e testado, transforma essa especificação em código: esquema Prisma, ecrãs Next.js, rotas, painéis. O mesmo esquema à entrada produz sempre o mesmo código à saída.

  • A IA compreende o domínio → um esquema de negócio (não código)
  • O motor garante a conformidade técnica → o código
  • Mesma entrada, mesma saída: reproduzível

Correto por construção

É o cerne do método. As propriedades dos componentes nunca são adivinhadas pelo modelo: é o motor que as define, a partir do esquema, segundo regras fixas. Uma coluna de tabela, uma relação, um formato de data: tudo é derivado, não inferido. Onde um LLM pode inventar uma opção que não existe, o motor conhece apenas o que existe.

Antes mesmo de sair, o esquema passa por uma porta de validação: é verificado e, se necessário, corrigido, até ser válido. Não se fabrica código sobre uma base instável.

Validado em condições reais antes da entrega

Escrever código correto não basta: é preciso prová-lo. Cada aplicação é construída, iniciada e percorrida automaticamente antes de chegar até si: o código é compilado, a aplicação lançada a sério, a navegação testada ecrã a ecrã. É a nossa porta de validação em tempo de execução, e é o nosso único critério de qualidade automatizado que não mente.

A percentagem de aplicações que passam o conjunto destas verificações nos últimos sete dias é publicada, datada, na nossa página de Fiabilidade. Poucos geradores de aplicações com IA mostram uma medida destas, porque poucos têm uma forma determinista de a produzir.

E um valor apresentado não deveria poder mentir

A mesma exigência estende-se aos dados. Um total, uma média, um estado derivado: estes valores são recalculados no servidor a partir das suas entradas, para que um número apresentado não possa contradizer aquilo de que decorre. A coerência não é deixada ao acaso de um registo.

No fim, o que recebe é código-padrão real (Next.js + Prisma) que lhe pertence, fabricado por um método que visa a correção em vez da verosimilhança. É toda a diferença entre uma aplicação que parece funcionar e uma aplicação que funciona.

Ler a seguir

Descreva a sua aplicação, julgue o resultado