O código não é alucinado, é produzido, e provamo-lo continuamente.
Cada aplicação gerada pelo Blueprint Maker passa pelo K-15, uma validação em tempo de execução automatizada: a app compila, arranca, serve os seus dados e navega-se, ou não é publicada. Eis, à vista e com data, a percentagem de apps que passam as 5 portas nos últimos 7 dias. Nenhum outro gerador de apps com IA publica este número, porque nenhum tem uma porta determinística.
Número lido da base de dados no momento do carregamento.
As 5 portas do K-15
A app compila para produção (next build), sem erros.
O CSS está presente e transporta os tokens de design (var(--bpm-*)).
A renderização visual passa no controlo (captura de ecrã, sem ecrã partido).
O seed é executado e a app serve dados reais, não um ecrã vazio.
As secções carregam e navegam-se sem erros em tempo de execução.
Porque é que este número existe (e porque é único)
O Blueprint Maker separa a compreensão do negócio (o LLM produz um AppSpec) da produção do código (builders determinísticos). O LLM não escreve a estrutura da aplicação: ela é compilada, não alucinada. Os blocos de ecrã que um modelo escreve — painel, zonas de síntese — são delimitados e têm de passar a compilação e a validação em execução.
Como resultado, a correção técnica é garantida por construção, não remendada a posteriori. O K-15 é o juiz automatizado dessa promessa.
As falhas recentes do setor (bases de dados expostas, endpoints sem autenticação, um agente que apaga uma base de dados de produção) nascem todas da mesma escolha: deixar um modelo probabilístico escrever a aplicação inteira, esquema de base de dados e rotas incluídos. Nós fizemos a escolha oposta.
Metodologia
Health Score = percentagem de apps que passam as 5 portas do K-15 (build, design, visual, dados, navegação), calculada sobre as apps geradas e testadas nos últimos 7 dias móveis. Os rascunhos e as apps do tipo nota (validação sintética) são excluídos do cálculo. Mesma fonte de verdade que o nosso painel de qualidade interno.