Como uso o Codex para revisar 15 projetos sem abrir mão do controle manual

Há alguns anos, a ideia de revisar seriamente 15 projetos de software ao mesmo tempo teria parecido pouco realista para mim. Não estou falando de abrir 15 repositórios e dar uma olhada. Estou falando de revisar projetos reais repetidamente em busca de bugs, suposições frágeis, problemas de SEO, erros de tradução, inconsistências de localização, testes ausentes, regressões e código antigo que já não combina com o resto do sistema.

O gargalo nunca foi velocidade para digitar. Foi atenção. Cada projeto tem sua própria história, convenções, edge cases e trechos que parecem errados, mas existem de propósito. Uma revisão cuidadosa exige ler, pesquisar, comparar, executar checks e só então decidir o que realmente deve mudar.

O Codex mudou para mim a economia desse trabalho repetitivo. Ele pode fazer uma primeira passagem pelo repositório, seguir referências, inspecionar arquivos relacionados, destacar padrões suspeitos, sugerir testes e ajudar a investigar áreas que antes eu abriria manualmente uma por uma. Isso não torna a decisão final automática. Torna muito mais rápida a parte cara que vem antes dela.

A regra mais importante que aprendi é simples: não uso o Codex para me retirar do loop de review. Uso para ampliar esse loop.

O verdadeiro gargalo é repetição, não escrever código

Quando você mantém um único projeto, consegue lembrar uma quantidade surpreendente de contexto. Com muitos projetos isso deixa de escalar. As mesmas classes de trabalho aparecem de novo e de novo:

• procurar bugs parecidos em componentes diferentes;
• verificar se um refactor deixou algum call site antigo;
• revisar testes após mudanças de comportamento;
• encontrar inconsistências em metadata, regras de idioma, headings ou links internos;
• comparar localization keys e conteúdo traduzido;
• procurar error handling ausente e edge cases;
• verificar se uma mudança “pequena” tocou mais arquivos do que deveria;
• ler diffs que são simples individualmente, mas caros em conjunto.

Nada disso é glamouroso. Tudo importa. E quando o mesmo tipo de revisão precisa ser repetido em várias codebases, o custo cresce muito.

É exatamente aí que um AI coding agent é mais útil para mim. Ele consome a parte repetitiva do espaço de busca e deixa minha atenção disponível para julgamento.

Começo pela inspeção, não dando permissão para reescrever tudo

Uma das maneiras mais fáceis de obter um resultado ruim é pedir “revise o projeto inteiro e corrija tudo”. Parece eficiente, mas mistura discovery, priorização, arquitetura, implementação e validação em uma tarefa sem controle.

Tenho resultados muito melhores quando separo as etapas.

inspect → explain findings → prioritize → change → validate → review diff

Primeiro quero que o agente entenda a área relevante e explique o que encontrou. Quero caminhos concretos de arquivos, o código afetado, por que algo parece suspeito e qual pode ser o impacto. Só depois quero mudanças.

Isso importa porque a IA pode estar errada com muita confiança. Um código pode parecer redundante e existir por causa de um navegador antigo, um edge case de pagamento, uma migração ou uma regra de negócio que não aparece em um único arquivo. Inspecionar primeiro me dá a chance de parar uma suposição ruim antes que ela vire um diff enorme.

Trato findings como pistas, não como vereditos

Uma boa review do Codex não termina em “encontrei 17 problemas”. O número sozinho vale quase nada. Eu quero evidência.

Para um finding realmente acionável, quero saber:

• onde está o problema;
• por que é um problema;
• qual comportamento pode falhar;
• quanta confiança a conclusão merece;
• qual check pode confirmar ou rejeitar a hipótese;
• qual é o menor fix seguro.

Isso é especialmente importante em security, SEO e lógica de negócio. O agente pode apontar algo que merece investigação, mas uma explicação com linguagem de segurança não é automaticamente uma vulnerabilidade. Um alerta SEO não é automaticamente um problema de ranking. Uma condição estranha não é automaticamente dead code.

A IA reduz o custo de encontrar candidatos. A verificação continua decidindo o que é real.

O validation loop torna o workflow confiável

Geração de código é a parte mais visível do desenvolvimento assistido por IA, mas validação é o que torna isso útil em produção.

Depois de uma mudança, quero que a própria codebase responda. Dependendo do projeto, isso pode incluir:

• TypeScript ou outro compiler/type checker;
• lint;
• testes unitários e de integração;
• build checks;
• buscas direcionadas por nomes antigos ou call sites;
• review manual do diff final;
• verificação manual do comportamento visível ao usuário.

Os comandos específicos importam menos que o loop. O agente faz uma hipótese, o repositório devolve evidência e a próxima decisão usa essa evidência.

Por isso gosto especialmente de projetos com tipagem forte para trabalho assistido por IA. Escrevi separadamente por que TypeScript funciona tão bem com Codex em software real: os tipos transformam muitas suposições erradas em feedback imediato e legível pela máquina.

Algumas categorias de review combinam especialmente bem com IA

Bugs e regressões

Um agente pode seguir um valor entre arquivos, inspecionar callers, comparar implementações parecidas e procurar branches inconsistentes. Isso ajuda a restringir a origem de um sintoma. Mesmo assim, reproduzo ou verifico o comportamento antes de aceitar a conclusão.

Testes

A IA é útil para encontrar comportamento que mudou sem cobertura de testes equivalente, sugerir edge cases e explicar o que um teste existente realmente protege. Também pode mostrar testes que verificam detalhes de implementação em vez do comportamento real.

SEO

SEO técnico tem muito trabalho de consistência: metadata, alternates de idioma, indexability, links internos, templates, sitemap generation, redirects e convenções por página. Um agente consegue comparar essas regras em uma codebase grande muito mais rápido do que eu abrindo cada route. Mas sempre separo correção técnica da questão mais difícil: o conteúdo merece rankear?

Localização e traduções

É uma das áreas mais repetitivas em um produto multilíngue. A IA pode comparar keys, encontrar valores ausentes, detectar idioma incorreto, revisar placeholders e destacar onde um locale se desviou estruturalmente de outro. É muito mais rápido que revisar grandes objetos de tradução manualmente, embora copy importante ainda precise de julgamento humano.

Consistência após refactoring

Refactors grandes costumam falhar de maneiras chatas: fica um import antigo, uma route ainda usa o nome anterior do campo, um test fixture mantém a shape antiga. Busca em todo o repositório junto com um agente que entende a intenção da mudança é muito útil aqui.

Trabalho paralelo só ajuda quando as tarefas são independentes

É tentador iniciar muitos agentes e deixar todos alterarem coisas ao mesmo tempo. Isso pode aumentar throughput, mas também multiplicar conflitos e suposições incompatíveis.

Penso em paralelismo como um problema de coordenação. Auditorias independentes são bons candidatos: um projeto pode ser verificado por localização enquanto outro é revisado por testes, ou repositórios diferentes podem ser inspecionados ao mesmo tempo. Dois agentes reescrevendo a mesma arquitetura sem um plano compartilhado são outra história.

Quanto mais paralela a execução, mais importantes os limites: um projeto claro, uma tarefa clara, definition of done clara e um resultado que possa ser revisado separadamente.

O objetivo não é maximizar o número de agentes ativos. É maximizar progresso útil e verificável.

O que não delego cegamente

• Decisões de arquitetura: o modelo pode sugerir opções, mas trade-offs de longo prazo dependem de contexto que talvez não exista no repo.
• Conclusões de segurança: findings precisam de verificação, threat context e muitas vezes ferramentas específicas.
• Regras de negócio: o código pode ser internamente consistente e ainda implementar o comportamento errado.
• Refactors destrutivos grandes: um diff enorme é mais difícil de entender e mais fácil de aprovar sem cuidado.
• Deploy em produção: testes passando não removem o risco operacional.
• Review final: quero entender o que mudou antes de colocar meu nome.

Não porque a IA seja inútil nessas áreas, mas porque uma resposta plausível e errada pode custar muito caro.

Review com IA não substitui análise estática

Também não vejo Codex como substituto de compilers, linters, testes, scanners ou monitoring. Essas ferramentas têm uma vantagem que a IA não tem: são estreitas, determinísticas e repetíveis.

O workflow mais forte combina tudo. Codex raciocina sobre contexto e sugere onde olhar. Ferramentas estáticas aplicam regras exatas. Testes verificam comportamento. Logs e monitoring mostram o que acontece na realidade. Review humana liga todos esses sinais à intenção do produto.

Sem esses feedback systems eu confiaria menos na IA, não mais.

O maior ganho de produtividade é uma melhor alocação de atenção

É fácil dizer “Codex economiza tempo”, mas isso descreve pouco do que mudou para mim.

O recurso escasso em desenvolvimento não são keystrokes. É atenção de alta qualidade. Antes dos AI coding agents, boa parte dela era consumida por discovery repetitivo: procurar os mesmos patterns, ler arquivos parecidos, seguir referências, verificar se uma mudança propagou para todos os lugares e repetir a mesma auditoria em outro repositório.

Agora consigo delegar mais dessa primeira passagem e guardar minha atenção para decisões difíceis de automatizar: esse finding importa? O fix combina com a arquitetura? A experiência do usuário melhora? O risco é aceitável? Eu realmente quero shippar isso?

É por isso que manter e revisar muitos projetos parece diferente hoje. Não reviso menos. Em muitos casos consigo revisar mais porque a parte mecânica não consome todo o orçamento.

O workflow em que confio

1. Definir um objetivo de review estreito. Bugs, testes, SEO, localização, refactor ou outro tema específico.
2. Deixar o agente inspecionar antes de editar. Primeiro quero evidência e locais afetados.
3. Priorizar findings. Nem todo problema teórico merece mudança.
4. Manter mudanças delimitadas. Diffs pequenos e coerentes são mais fáceis de validar.
5. Executar checks automáticos. Typecheck, lint, testes, build, buscas ou validação específica do projeto.
6. Ler o diff manualmente. Procuro rewrites desnecessários, suposições erradas, edge cases ausentes e mudanças fora do scope.
7. Verificar comportamento importante. Especialmente usuários, dinheiro, security, SEO e infraestrutura de produção.
8. Só então ir para o próximo projeto. Paralelismo ajuda, mas incerteza não resolvida não deve se espalhar.

Quinze projetos já não parecem quinze vezes o trabalho de review

Codex não tornou 15 projetos simples e não removeu minha responsabilidade. Ele mudou a relação entre escala e esforço repetitivo.

Posso pedir first passes mais profundos, checks de consistência mais amplos, mais ideias de testes e auditorias mais sistemáticas sem gastar pessoalmente cada minuto procurando em cada arquivo. Depois uso a atenção economizada nas decisões que ainda precisam de um desenvolvedor.

Esse é o tipo de AI-assisted development que considero valioso: não autopilot, não confiança cega e não “gere código até alguma coisa passar”. É um loop mais curto entre inspeção em escala de máquina e julgamento em escala humana.

Para mim, esse é o verdadeiro leverage do Codex. Ele não elimina review. Torna possível uma review séria em uma escala que antes era muito mais difícil manter.