Tenho trabalhado com muitos vibe coders no trabalho, e isso me fez pensar em manutenção. Software precisa de cuidado depois do lançamento, pacotes ficam desatualizados e vulnerabilidades são descobertas, e quando você está começando a construir com IA é fácil não pensar em nada disso.
Então percebi que devia aplicar o mesmo raciocínio aos meus próprios projetos, e fui olhar o histórico do git deles. Encontrei vários problemas, embora não do tipo que eu esperava, e um deles ainda estava aberto no dia em que olhei.
Por isso, este já não é um post sobre o que as outras pessoas esquecem. É sobre mim.
Um alerta, três apps
Em 14 de outubro, o Next.js publicou correções para duas vulnerabilidades críticas e uma de severidade alta. "Crítica" aqui significa execução remota de código, ou seja, em certas condições, um desconhecido na internet poderia rodar o próprio código no seu servidor sem fazer login. A correção veio na versão 16.4.1.
Tenho três apps em Next.js, todos construídos com ferramentas de programação com IA e todos com a mesma pessoa responsável, que sou eu. Foi isto que aconteceu:
| App | Quando o código passou para uma versão corrigida | Tempo após o alerta | Em produção |
|---|---|---|---|
| chandlernguyen.com | 18 de outubro | 4 dias | 18 de outubro |
| DIALØGUE | 29 de outubro | 15 dias | 29 de outubro |
| Prova | 3 de novembro | 20 dias | 3 de novembro |
Quando olhei em 3 de novembro, o Prova ainda estava travado no Next.js 16.2.6, a versão que usava desde maio, e era isso que rodava em produção. O pnpm audit --prod listou 5 alertas críticos, todos no Next.js.
Esse número parece pior do que o que encontrei, então quero ser justo. Quando analisei cada um com minhas ferramentas de IA, a maioria dos críticos não se aplicava ao Prova. Ele não tem funções use cache, não roda em Windows, e não encontrei nenhuma entrada controlada por um atacante chegando ao código do next/og. Os de otimização de imagem provavelmente também não se aplicam na Vercel, mas isso é uma inferência a partir de como a plataforma se comporta, pois não encontrei nenhuma declaração da Vercel dizendo isso. O que claramente se aplicava era um problema de negação de serviço de severidade alta em Server Actions, o que significa que alguém poderia ter atrapalhado o app, e isso ficou ativo até o patch.
Passei a produção para o Next.js 16.4.5 no mesmo dia. A auditoria foi de 5 críticos para 0, e a maioria dos de severidade alta também sumiu. O que resta está fora do Next.js e ainda preciso resolver, então está melhor, mas não limpo.
Não posso chamar nada disso de boa manutenção. Os piores alertas passaram longe do Prova principalmente por causa de como ele por acaso foi construído, não porque alguém verificou. Isso é sorte, e só sei disso porque finalmente olhei.
Também não posso levar muito crédito pela primeira linha da tabela. O commit do meu site em 18 de outubro foi uma atualização geral de ferramentas, a partir do Next.js 16.1.6, e a mensagem não menciona o alerta. Talvez tenha sido apenas uma boa coincidência.
Por que estar ocupado não ajudou
A explicação fácil seria que o Prova estava negligenciado, e há alguma verdade nisso. Houve um intervalo de 41 dias entre commits em agosto e setembro.
Mas essa explicação desmorona em outubro. O Prova teve 175 commits naquele mês. Entreguei correções para iOS, cobrança, e-mail e traduções, e a versão do Next.js não mudou. Em 30 de outubro, cheguei a escrever um plano de manutenção de dependências. A linha de status dele diz: "planejado; implementação não iniciada."
Então atividade não é manutenção, e acho que esta é a parte que mais importa para quem constrói com IA. Quando você cria um recurso, recebe retorno imediato. Você vê o botão, clica e vê funcionar. Quando uma vulnerabilidade é anunciada em um pacote que você instalou cinco meses atrás, você não recebe nada. O app continua servindo páginas, os testes continuam verdes e o build passa. Nada está quebrado, e é exatamente por isso que ninguém olha.
Seria como um detector de fumaça que só apita se você for lá perguntar. As ferramentas de IA deixam muito mais barato construir a casa. Elas não instalam o alarme.
Isso também já tinha acontecido comigo. O DIALØGUE não teve commits entre 6 de outubro de 2025 e 11 de janeiro de 2026. O React2Shell, uma vulnerabilidade crítica do Next.js e do React, se tornou público no início de dezembro. Meu commit com o patch é de 11 de janeiro, mais de cinco semanas depois, e o registro de deploy de produção mais antigo que ainda consigo ver é de 18 de janeiro, então não posso dizer exatamente o que estava rodando em dezembro. O que provavelmente mais me ajudou não teve nada a ver comigo: a Vercel diz que implantou regras de firewall para todos os clientes, ao mesmo tempo em que diz claramente para não confiar nelas no lugar do patch.
Quero deixar uma coisa clara, porque a expressão "vibe coder" pode soar como insulto. Aprendi a programar em cursos estruturados, incluindo um certificado de cibersegurança, esses repositórios têm testes e etapas de revisão, e mesmo assim aconteceu. Por isso não acho que seja um problema de iniciante. Acho que é o que acontece por padrão quando criar software fica barato e ninguém é designado para vigiá-lo.
Como é o alarme
A boa notícia é que uma verificação bem pequena muda muito isso.
Em 27 de outubro, adicionei pnpm audit --prod à CI do meu site, que é apenas o conjunto automático de verificações que roda quando o código é enviado. Em 28 de outubro ela falhou, por causa de um alerta em uma biblioteca de renderização de e-mail que meu site puxava mas nunca usava, e em 29 de outubro removi essa biblioteca. Levou dois dias e não precisei me lembrar de nada.
Não houve nada de esperto nisso. Alguém, ou alguma coisa, simplesmente precisa ter a tarefa de olhar.
Atualizar pacotes não teria me salvado
Se este post parasse aqui, daria a você um falso conforto, porque algumas das correções mais desconfortáveis que fiz em outubro não tinham nada a ver com pacotes desatualizados. Eram erros no meu próprio produto.
No DIALØGUE, por exemplo:
- Funções privilegiadas do banco de dados podiam ser chamadas só com a chave pública, e um usuário logado podia alcançar funções feitas apenas para o meu backend.
- Um podcast reembolsado podia voltar à vida e terminar sem ser cobrado de novo, e em um pequeno número de podcasts isso aconteceu.
No Prova, papéis públicos do banco de dados tinham herdado permissões que ninguém escolheu, como TRUNCATE, porque vinham de um padrão da plataforma. Nenhum caminho do app as usava, mas estavam lá.
Nenhuma atualização de versão corrige nada disso. Esses apps rodavam com esses problemas, e ali também nada quebrou. Eles só apareceram porque uma revisão de segurança foi procurá-los, e eu já tinha feito revisões de segurança anteriores nesses produtos que não pegaram todos.
Alguma coisa disso foi usada indevidamente? Não sei, e não consigo descobrir por completo. Meus logs de banco de dados só voltam cerca de 90 dias, e alguns desses problemas são mais antigos. No período que consigo ver, não encontrei chamadas externas a essas funções. Isso cobre uma janela limitada e não mostra que nada aconteceu. Também não sei dizer quem ou o que reiniciou aqueles podcasts reembolsados, embora uma nova tentativa no meu próprio código seja meu melhor palpite.
Esta também não é uma lista completa. Ainda estou trabalhando em outros problemas e não vou descrevê-los enquanto estiverem abertos.
A questão dos modelos não é a que eu pensava
Eu esperava escrever que modelos de IA antigos custam mais caro. Não consigo sustentar isso. Procurei e não tenho uma comparação de custos de antes e depois em nenhum desses repositórios, então seria só um palpite.
O que encontrei é mais estranho. Os modelos de rascunho de roteiro e de revisão do DIALØGUE estavam configurados como gemini-3.5-flash até 12 de outubro. A documentação do Google agora diz que esse endpoint não vai ser desligado e encaminha automaticamente as requisições para gemini-3.6-flash. Não sei quando esse encaminhamento começou, então não posso dizer qual modelo estava respondendo nem por quanto tempo. Um nome de modelo na sua configuração não congela o modelo.
Os preços também mudam. O Gemini 3.8 Flash, para o qual movi o Prova e o DIALØGUE em outubro, está listado a $0.75 por milhão de tokens de entrada e $3.75 por milhão de tokens de saída até 31 de dezembro. A partir de 1º de janeiro de 2027, isso dobra para $1.50 e $7.50. Só mudei para ele no mês passado, e ainda preciso calcular o que isso faz com os meus custos.
Atualizar também não é livre de risco, e não quero fingir que é:
- Pouco depois de mudar o Ask Sydney para o DeepSeek Flash, pelo menos uma pergunta falhou em produção porque o modelo queria mais rodadas de busca do que meu código permitia.
- Quando migrei os embeddings do Prova, as primeiras execuções falharam depois que a tabela da base de conhecimento já tinha sido esvaziada, então a recuperação ficou degradada até eu restaurá-la.
- Essa mesma migração revelou uma configuração de produção que teria enviado um nome de modelo Claude para a API do Google.
O que tornou a migração do Prova confiável foi algo sem graça. Eu tinha uma avaliação registrada de antes da mudança, 22 de 24 decisões de revisão de sprint corretas, e obtive a mesma pontuação depois. Sem isso, eu só estaria torcendo.
Você deveria mesmo manter isso?
A pergunta mais difícil é a que quase deixei de fora. Cada app que você lança é uma pequena assinatura que precisa continuar pagando com a sua atenção, e a IA deixou muito fácil assinar mais delas.
Com o STRAŦUM, fiz a outra escolha. Eu o aposentei e publiquei a v1 como implementação de referência. O repositório diz que ele não é mantido como serviço de produção, e o arquivo de segurança lista os alertas que conheço, incluindo problemas em dependências de build sem correção disponível, que ele avalia como de baixo risco prático. Acho que é um resultado perfeitamente honesto. A versão desonesta é um app que continua aceitando cadastros enquanto ninguém está cuidando dele.
O que eu faria na segunda-feira
Se você lançou algo com IA e há pessoas usando, esta é a lista por onde eu começaria. Nada disso precisa ser perfeito.
- Rode a auditoria uma vez, hoje.
npm audit --omit=devoupnpm audit --prod, em cada repositório que está no ar. Depois pergunte à sua ferramenta de IA quais resultados se aplicam a como seu app foi construído, porque nem todos vão se aplicar. - Torne essa verificação automática. Adicione à CI para que ela possa falhar sem você precisar lembrar. Para um app em que você mexe pouco, use também uma execução agendada, porque uma verificação que só roda em um push não ajuda em um mês tranquilo.
- Leia suas permissões, não só seus pacotes. Pergunte o que alguém consegue fazer só com sua chave pública e sem conta. Depois teste em uma cópia local em vez de presumir.
- Procure segredos no seu histórico. Se uma chave real já foi commitada, revogue. Apagar a linha não basta.
- Descubra até onde seus logs vão antes de precisar deles. Isso decide se você algum dia vai conseguir responder se algo foi usado indevidamente.
- Mantenha uma pequena avaliação para cada recurso de IA. Mesmo 20 exemplos reais com boas respostas conhecidas vão dizer se uma troca de modelo piorou as coisas.
- Verifique regularmente as páginas de descontinuação e de preços do seu provedor de IA. Coloque na agenda. Se você usa o Gemini 3.8 Flash, 1º de janeiro já é uma boa data para começar.
- Decida manter ou aposentar cada app. Se você não vai cuidar dele, tire do ar ou diga isso.
Ainda estou descobrindo quanto disso pode ser entregue a um agente de forma agendada. O que sei é que escrever o plano em 30 de outubro não corrigiu nada.
Se você está construindo com IA, quando foi a última vez que verificou algo que já tinha lançado, e o que encontrou? Eu gostaria muito de saber, principalmente se você tiver um alarme melhor que o meu.