O determinismo explicado
Porque é que uma aplicação gerada pelo Maker não se estraga quando a ajusta, em linguagem não técnica.
O problema dos geradores clássicos
Quando uma IA escreve diretamente o código de uma aplicação, cada correção é uma nova redação. Pedir uma pequena alteração pode estragar outra noutro sítio, sem avisar. É a origem dos «ciclos de correção»: corrige-se, estraga-se, volta-se a corrigir.
A abordagem do Maker: app = builders(especificação)
No Maker, a IA não escreve a estrutura da aplicação. Concebe uma especificação: a lista de entidades, as regras de negócio, os indicadores. São depois builders determinísticos: programas, não uma IA, que transformam essa especificação em base de dados, rotas de API, formulários e navegação.
«Determinístico» significa: a mesma especificação produz sempre a mesma estrutura. Aí não há improvisação nem código alucinado.
Alguns blocos de ecrã, esses sim, são escritos por um modelo: o painel, as zonas de síntese das listas, os dados de exemplo e as vistas de assinatura no nível Masterpiece. São delimitados, o número de chamadas é fixado à partida e têm de passar a compilação e a validação em execução — caso contrário são substituídos pela sua versão determinística. É a diferença entre confiar a um modelo uma peça sob controlo e confiar-lhe a aplicação inteira.
O fluxo, passo a passo
- O seu prompt, em linguagem natural.
- A especificação: concebida pela IA (entidades, regras, indicadores).
- A estrutura — base de dados, rotas de API, formulários, navegação — escrita por builders determinísticos a partir da especificação.
- Os blocos de ecrã confiados a um modelo, validados pela compilação e depois em execução antes de serem mantidos.
O que isso muda para si
Ajustar a sua aplicação equivale a ajustar a especificação e depois deixar os builders reconstruir. O comportamento mantém-se previsível: sem regressão surpresa, sem ciclo de correção faturado a cada tentativa. Itera com confiança.