cloud / sistemas
Em Como este site foi construído com prompts, contei como a IA ajudou a transformar um antigo WordPress num site estático na AWS, com S3 e CloudFront. O que subestimei foi a velocidade com que um site pessoal simples se tornaria um projeto complexo de software.
Como a complexidade foi crescendo
Começamos com poucas páginas. Depois vieram previsão do tempo, dados de treinos, jogos, verificações de segurança, deploys automatizados e nove idiomas. Adicionamos alemão, espanhol, chinês, francês, português brasileiro, japonês, hindi e holandês ao inglês. Mais idiomas ampliaram o público, mas também aumentaram a quantidade de páginas HTML, navegação, feeds, metadados e oportunidades de falha.
Nossa hipótese ingênua era: se o site é estático, reconstruir tudo sempre será barato. Na realidade, até uma pequena alteração em inglês podia esperar instalação de fontes, geração de imagens, navegação de nove idiomas, sitemap e testes de segurança. Transformamos os nove idiomas em uma única dependência para publicar qualquer coisa.
Todos os idiomas tinham de ficar prontos
A culpa não era das traduções, mas do desenho das dependências.
Quando os mecanismos de segurança atrapalham
O histórico do GitHub mostra dificuldades com verificação de segredos, diferenças de compilação reproduzível, instalações de fontes travadas, erros nos workflows e permissões IAM da AWS insuficientes. Durante uma recuperação, verificamos 534 objetos públicos: 501 estavam corretos, 24 tinham diferenças e nove novas páginas não podiam ser lidas.
Cada proteção tinha sua justificativa. Juntas, porém, tornaram pequenas mudanças difíceis. Mais automação não é automaticamente melhor automação. Quando um teste falha, devemos investigar a causa, não desabilitar a proteção.
A nova arquitetura: inglês primeiro
Decidimos separar a publicação do conteúdo principal das oito traduções revisadas.
menor é melhor
O desenho representa a ordem de publicação desejada, não uma prova de que ela já ocorreu assim em produção. A revisão de cada tradução fica vinculada ao SHA-256 exato da fonte inglesa. Uma alteração da fonte invalida as aprovações anteriores. Nunca devemos publicar texto inglês fingindo ser uma tradução.
Mantemos builds reproduzíveis, OIDC, permissões mínimas na AWS, limites de custo e nenhuma invalidação no CloudFront.
O que foi realmente comprovado
Os PRs #119–#122 implementaram um compilador de artigos em inglês, outro para oito traduções revisadas e a sequência de testes inglês → idiomas → verificação integrada. O workflow de teste não possui permissão de escrita na AWS. A publicação por etapas ainda exige variáveis de aprovação; o workflow OIDC tradicional continua executando a verificação completa do site antes do upload.
Por isso, CI verde não comprova que inglês já estava publicado enquanto as traduções eram processadas. Os logs de simulação diziam sourceToHtmlBuildComplete=false, productionDeploymentApproved=false e zero gravações em S3.
Tempos de melhoria que conseguimos medir
Comparamos duas atualizações semelhantes do changelog em nove idiomas, realizadas em 7 de novembro de 2026. São tempos da pipeline global, não uma comparação de dois deploys reais por etapas.
| Métrica | Antes | Depois | Mudança |
|---|---|---|---|
| CI offline | 3min38s (218 s) | 3min18s (198 s) | 9,2% mais rápido |
| Verificação completa do site | 2min55s (175 s) | 2min27s (147 s) | 16,0% mais rápido |
| Gitleaks | 56 s | 67 s | 11 s mais lento |
| Semgrep | 10 s | 11 s | quase igual |
| pip-audit | 13 s | 12 s | quase igual |
| Abertura do PR até merge | 41min50s | 34min29s | 7min21s a menos |
menor é melhor
A verificação de qualidade está incluída no tempo de CI: não se somam esses números. Os jobs de segurança rodam em paralelo. Semgrep e pip-audit não executaram suas análises mais pesadas nesses exemplos de alterações documentais. Dois runs ainda não comprovam tendência permanente.
Também eliminamos verificações repetidas de assets, reutilizamos hashes SHA-256 e índices de navegação, adotamos cache para Python e Sharp, passamos a medir os geradores e criamos um caminho rápido para mudanças apenas na documentação.
A via rápida para inglês
Um benchmark de simulação levou 0,562 segundo para validar o HTML inglês (60 páginas, 96 assets e 514 links locais). A sequência simulada de verificações de merge levou 15 segundos; 501 arquivos de outros idiomas permaneceram intactos.
Esses números são tempos de componentes e testes, não o tempo entre merge e publicação real no S3. Não seria correto comparar diretamente os 15 segundos com os 198 segundos da CI inteira.
Do pull request ao site publicado
Um PR não é um deploy. Depois de revisão, testes e merge, o processo verifica os arquivos exatos, manifestos SHA-256, permissões da AWS e orçamento. Somente então envia arquivos ao S3. O CloudFront atualiza seu cache pela TTL normal, sem invalidações pagas.
Para medir a publicação escalonada, registraremos T0 merge da versão inglesa, T1 fim de seus testes, T2 confirmação do upload inglês, T3 processamento das traduções e T4 confirmação do upload dos oito idiomas. Só assim poderemos demonstrar quanto antes os leitores recebem o inglês.
Depuração com IA
ChatGPT pode analisar logs de um PR com falha, propor uma correção pequena e verificar outra execução de CI. Isso ajuda muito à noite, mas não significa que uma conversa continuará trabalhando indefinidamente sem supervisão. A sessão precisa estar ativa, e a decisão final de merge continua sendo revisada.
A principal lição
O ganho mais importante não é apenas economizar segundos. É parar de fazer o primeiro resultado útil depender de todos os resultados opcionais seguintes. O inglês deve poder chegar cedo; as oito traduções seguem depois, com a mesma qualidade. Os próximos deploys reais mostrarão a vantagem de tempo.