O plano que salta é a falha que vai ter de resolver mais tarde
Todos os métodos de engenharia de software dizem para avançar depressa, lançar cedo, iterar em produção. Para sites gerados por IA, isso está ao contrário. O builder aqui recusa-se a gerar código diretamente a partir do seu pedido — pára, escreve um plano e espera que o analise — e essa recusa é a única decisão à volta da qual tudo o resto neste processo é construído. Mais lento no início, mais barato em tudo depois. Aceito essa troca sempre que possível, e acho que a maioria das pessoas que defende o oposto nunca viu, na prática, quanto custa uma suposição errada mais à frente.
Eis o cenário de falha que o plano existe para evitar. Escreve "um site de marcações para o meu estúdio" e avança. O sistema tem de adivinhar o que significa "marcações" — um widget de calendário, uma integração de terceiros, um sistema de reservas real com verificação de conflitos — e tem de adivinhar antes de escrever seja o que for, porque não há outra ordem possível. Errar dentro de um plano e a correção é uma frase, cinco segundos, resolvido. Errar dentro do código já gerado e já não está a editar uma frase, está a desfazer dez ficheiros que já dependem da suposição errada. Já vi as duas situações acontecerem. A correção na fase de plano é uma troca de mensagens. A mudança de rumo pós-geração sobre a mesma ambiguidade é descartar e reconstruir.
O plano também não é apenas uma lista de tarefas, e esta é a parte que as pessoas não percebem. É um contrato, e o sistema cumpre-o: um verificador de conformidade, um dos agentes que tem de dar o seu aval antes de uma compilação ser lançada, compara o site terminado com o plano que aprovou. Foram criadas todas as páginas planeadas? A lista de funcionalidades corresponde ao que foi lançado? "Concluído" não é uma sensação aqui — é relativo a uma promessa escrita, verificável linha a linha. É uma garantia mais forte do que "o código funciona", e só a consegue porque há um documento com o qual comparar. Retire o plano e retira a régua de medição.
Onde isto realmente compensa
A sua influência como pessoa que conduz a construção está concentrada no início, quer a exerça quer não. Se se importa com a arquitetura da informação, a estrutura das páginas, quais funcionalidades entram na v1 versus v2 — esse rigor vale dez vezes mais na revisão do plano do que depois da primeira passagem de geração. Quatro minutos extra a reler um plano valem mais do que uma troca de mensagens a corrigir uma compilação que já correu mal.
O exemplo mais claro é o tipo de produto — site estático simples, app instalável, compilação de framework, app com backend em servidor com persistência real. Parece uma lista pendente. Não é. É a escolha mais estrutural de todo o processo, porque decide silenciosamente uma dúzia de coisas que não têm nada a ver com o aspeto do site.
| Tipo de produto | Pré-visualização | Publicar | Contas / base de dados |
|---|---|---|---|
| Site estático simples | Instantâneo, por serem apenas ficheiros estáticos | O resultado estático copia-se sem problemas | Não é possível — pedir início de sessão é pedir algo que este tipo estruturalmente não consegue fazer |
| Compilação de framework | Compila primeiro; uma compilação com falhas surge como "sem pré-visualização", não como "página avariada" | O mesmo processo limpo de cópia estática, depois de compilado | Não é possível |
| App com backend em servidor | — | Precisa de um sítio onde realmente correr um processo, o que falha de forma diferente — um processo que crashou, não um ficheiro em falta | O único tipo onde contas e bases de dados existem, de facto |
E não pode fazer upgrade de tipo mais tarde de forma casual. Passar de um site simples para uma aplicação com servidor não é ligar uma opção — é quase uma segunda construção, porque metade dos pressupostos do plano (como as páginas carregam, onde os dados residem, o que "publicar" significa) foram feitos com base no tipo antigo. Por isso diga-o na fase de planeamento, mesmo que só ache: "há uma hipótese de precisar de contas." Planear para uma aplicação com servidor e usar apenas as partes estáticas não custa nada. Descobrir que precisava de uma depois do facto custa uma reconstrução.
Onde os críticos têm razão
Nada disto é grátis, e não vou fingir que é. Espaços de trabalho isolados por execução significam que os seus ficheiros de conhecimento são copiados de novo, e nada é reenviado para a sua máquina — bom para si se o portátil avariar a meio da construção, mau para a latência, porque provisionar um espaço de trabalho e, em construções com frameworks, executar uma instalação real de dependências dentro de um limite de contentor demora tempo real. Esse limite de contentor existe porque uma construção com framework executa `npm install` e scripts de build arbitrários — código que não escreveu, a executar com privilégios de build — e fazer isso num anfitrião partilhado sem isolamento está a um ataque de dependency-confusion de tocar nos dados de outro inquilino. A opção rápida-mas-insegura estava disponível. Simplesmente não era uma troca que valesse a pena fazer.
O mesmo se aplica à verificação. Uma construção terminada não sai do pipeline quando a geração para; sai quando um conjunto de verificadores independentes deixa de encontrar coisas que valham a pena bloquear:
- Revisão de código
- Segurança
- Ligações e SEO
- Acessibilidade
- Conformidade
- Uma execução real no browser
Isso não é uma única passagem, é sinalizar-corrigir-reverificar, em ciclo até já ninguém ter nada a apontar, porque uma única passagem de linter pode não detetar uma regressão introduzida pela sua própria correção. Corrigir uma ligação quebrada e acidentalmente quebrar a hierarquia de cabeçalhos na mesma página é exatamente o tipo de coisa que uma verificação única não deteta e uma reverificação capta. O custo real desse ciclo é a ocasional construção que demora um minuto extra no final sem razão visível. As pessoas notam esse minuto. Não notam os seis agentes que acabaram de discutir sobre o site delas. É uma crítica justa à experiência — só não me parece um bom argumento para publicar sem que essa discussão tenha acontecido.
