O plano que você pula é a interrupção que você vai depurar depois
Todo framework de engenharia de software te diz para ir rápido, lançar cedo, iterar em produção. Para sites gerados por IA, isso é ao contrário. O builder aqui se recusa a transmitir código direto do seu prompt — ele para, escreve um plano e espera você olhar para ele — e essa recusa é a única decisão sobre a qual tudo o mais neste pipeline é construído. Mais lento no início, mais barato depois em tudo. Eu topo essa troca sempre, e acho que a maioria das pessoas que defende o oposto não viu de fato quanto um palpite errado custa lá na frente.
Aqui está o modo de falha que o plano existe para evitar. Você digita "um site de reservas para o meu estúdio" e aperta ir. O sistema tem que adivinhar o que "reserva" significa — um widget de calendário, um embed de terceiros, um sistema de reservas de verdade com checagem de conflitos — e tem que adivinhar antes de ter escrito qualquer coisa, porque não existe outra ordem para fazer isso. Errar o palpite dentro de um plano e o conserto é uma frase, cinco segundos, pronto. Errar o palpite dentro de código já gerado e você não está mais editando uma frase, está desfazendo dez arquivos que já dependem da suposição errada. Já vi as duas versões acontecerem. A correção na etapa de planejamento é uma troca de mensagens. A mudança de rumo pós-geração na mesma ambiguidade é descartar e reconstruir.
O plano também não é só uma lista de tarefas, e é essa parte que as pessoas deixam passar. É um contrato, e o sistema se cobra por ele: um verificador de conformidade, um dos agentes que precisa aprovar antes de um build ser lançado, compara o site finalizado com o plano que você aprovou. Toda página planejada foi construída? A lista de recursos bate com o que foi entregue? "Pronto" não é uma vibe aqui — é relativo a uma promessa escrita, verificável linha por linha. Essa é uma garantia mais forte do que "o código roda", e você só consegue isso porque existe um documento para conferir. Tire o plano e você tira o parâmetro de referência.
Onde isso realmente compensa
Sua influência como a pessoa que conduz o build vem carregada no início, quer você a exerça ou não. Se você se importa com arquitetura de informação, estrutura de páginas, quais recursos entram na v1 versus v2 — esse cuidado vale dez vezes mais na revisão do plano do que depois da primeira passagem de geração. Quatro minutos extras relendo um plano vale mais do que uma ida e volta consertando um build que já deu errado.
O exemplo mais claro é o tipo de produto — site estático simples, app instalável, build de framework, app com backend real com persistência de dados. Parece um menu suspenso. 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 a aparência do site.
| Tipo de produto | Pré-visualização | Publicar | Contas / banco de dados |
|---|---|---|---|
| Site estático simples | Instantâneo, já que são só arquivos estáticos | A saída estática é copiada sem complicações | Não é possível — pedir login é pedir algo que o tipo, por estrutura, não consegue fazer |
| Build de framework | Compila primeiro; um build quebrado aparece como "sem pré-visualização", não como "página quebrada" | O mesmo caminho limpo de cópia estática, depois de compilado | Não é possível |
| App com backend | — | Precisa de um lugar para de fato rodar um processo, o que falha de forma diferente — um processo que trava, não um arquivo faltando | O único tipo em que contas e bancos de dados existem |
E você não pode simplesmente trocar de tipo depois. Ir de site simples para app com backend não é um botão nas configurações — é quase um segundo build, porque metade das suposições do plano (como as páginas carregam, onde os dados ficam, o que "publicar" significa) foram feitas com base no tipo antigo. Então diga isso na hora do plano, mesmo que meio incerto: "há uma chance de eu precisar de contas". Planejar para um app com backend e usar só as partes estáticas não custa nada. Descobrir depois que você precisava de um custa uma reconstrução.
Onde os críticos têm razão
Nada disso é de graça, e não vou fingir que é. Workspaces isolados por execução significam que seus arquivos de conhecimento são copiados do zero, nada volta para a sua máquina — bom para você se o seu laptop travar no meio do build, ruim para a latência, porque provisionar um workspace e, para builds de framework, rodar uma instalação real de dependências dentro de um limite de contêiner leva tempo real. Esse limite de contêiner existe porque um build de framework roda `npm install` e scripts de build arbitrários — código que você não escreveu, executando com privilégios de tempo de build — e fazer isso num host compartilhado sem isolamento é um ataque de dependency confusion longe de tocar nos dados de outro cliente. A opção rápida e insegura existia. Só não valia a pena como troca.
Mesma história com a verificação. Um build finalizado não sai do pipeline quando a geração termina; sai quando um conjunto de verificadores independentes para de encontrar coisas que valham a pena bloquear:
- Revisão de código
- Segurança
- Links e SEO
- Acessibilidade
- Conformidade
- Uma execução real no navegador
Isso não é uma única passagem, é sinalizar-corrigir-reconferir, repetindo até ninguém ter mais nada a dizer, porque uma única passagem de linter pode não pegar uma regressão que sua própria correção introduz. Consertar um link quebrado e sem querer quebrar a hierarquia de títulos na mesma página é exatamente o tipo de coisa que uma checagem única deixa passar e uma reconferência pega. O custo real desse loop é o build ocasional que leva um minuto a mais bem no final sem motivo aparente. As pessoas notam esse minuto. Não notam os seis agentes que acabaram de discutir sobre o site delas. É uma reclamação justa sobre a experiência — só não acho que seja um bom argumento para lançar sem que a discussão tenha acontecido de verdade.
