Sim, de duas formas complementares: regenerar a aplicação a partir de uma descrição enriquecida: a via sem código, adequada às evoluções de estrutura: ou recuperar o código-fonte e fazê-lo evoluir como qualquer projeto, por si próprio ou através de um programador. A segunda via pressupõe uma condição muitas vezes negligenciada: que o código gerado seja padrão e legível, não um emaranhado que ninguém se atreve a tocar.
«Gerada por IA» abrange duas realidades muito diferentes
Tudo depende do QUE a IA escreveu. Na geração «IA pura», um grande modelo de linguagem escreve o próprio código, linha a linha: duas gerações da mesma necessidade produzem dois códigos diferentes, plausíveis mas nunca garantidos. A modificação herda essa fragilidade: cada retoque volta a passar pelo modelo, que pode reescrever pelo caminho o que funcionava, e ninguém sabe de antemão que código sairá.
O Blueprint Maker faz o oposto: a IA não escreve o código, escreve a ESPECIFICAÇÃO, a lista estruturada das suas entidades, ecrãs e indicadores, que valida como um plano. Builders determinísticos traduzem depois esse plano em código: o mesmo plano produz sempre o mesmo código, com as mesmas convenções. É essa separação que torna seguras as duas vias abaixo: regenerar não reinventa a sua aplicação, e o código exportado continua legível para qualquer programador.
Primeira via: regenerar a partir da descrição
A necessidade evolui? A descrição evolui com ela. Acrescenta «cada intervenção tem agora um técnico atribuído e um nível de urgência», relança a geração, valida o novo plano: a aplicação regenerada integra a entidade, os ecrãs e os indicadores correspondentes. É o modo de evolução natural do Blueprint Maker, sem escrever uma linha.
Esta via é a certa para as evoluções estruturais: novas entidades, novos estados, novos indicadores. A descrição continua a ser a fonte única: documenta a sua ferramenta em linguagem simples, e o pipeline determinístico garante que um mesmo plano validado produz uma mesma aplicação.
Segunda via: fazer evoluir o código exportado
Para o que ultrapassa o perímetro gerado: uma necessidade muito específica, uma integração particular, a saída de emergência é o próprio código. As aplicações Blueprint Maker exportam-se em ZIP ou enviam-se para o seu GitHub: um projeto Next.js + Prisma padrão, a estrutura que todo o programador web conhece.
É aqui que pesa o método de geração: um código escrito livremente por um modelo é muitas vezes ilegível e frágil de modificar; um código escrito por builders determinísticos é homogéneo de uma aplicação para outra: as mesmas convenções, as mesmas estruturas. Como o código é exportável e padrão, um programador pode acrescentar-lhe o que a geração não cobre.
Escolher a via consoante a mudança
As duas vias não se excluem; cada uma tem o seu terreno.
- Acrescentar uma entidade, um estado, um indicador: regenerar a partir da descrição enriquecida.
- Ajustar um perímetro ainda em movimento: regenerar enquanto a estrutura não estabilizar.
- Integrar um sistema externo ou uma necessidade fora do perímetro: fazer evoluir o código exportado com um programador.
- Retomar o controlo da ferramenta de forma duradoura internamente: passar para o código, o URL dedicado ou o seu próprio alojamento, à escolha.