AI Coding na Prática: Meu Workflow de Trabalho em Novembro de 2025

Gerenciando 150 mil linhas sozinho: Codex CLI, Claude e por que refatoro tudo.

Tenho estado mais afastado da produção de conteúdo ultimamente. Não é por falta de assunto. É que trabalho, vida social e um projeto de 150 mil linhas decidiram competir pelas mesmas 24 horas. O projeto ganhou.

E nesse processo, meu workflow com AI coding virou outro. Desde maio, quando as ferramentas atingiram um patamar de autonomia que não dava mais para ignorar.

Já tínhamos Cursor e GitHub Copilot, mas até então era tudo “tentativa e erro” com autonomia limitada. Daí vieram GPT-5, Sonnet 4.0, Opus 4.1, MCP Servers, e agentes autônomos.

Eu ignorei no começo: “mais hype” pensei. Até que meu projeto me forçou a testar.

Contexto e Stack Utilizada

O projeto tem cerca de 150K linhas, majoritariamente React + TypeScript, funções Deno para APIs de terceiros e Supabase para tudo o mais (auth, storage, banco). É a stack que me permite mover rápido, mas também pode quebrar em 15 lugares diferentes se fizer alterações sem olhar para os lados.

Também tenho um app Flutter nascendo, mas ainda é bebê. O problema é o irmão mais velho: cresceu rápido demais.

Modelo de Trabalho

Em abril-maio ainda usava Cursor, com GPT-o3 e Sonnet 3.7. Criar CRUD em minutos parecia irreal. Mas o código funcionava e não durava.

Desde o lançamento do GPT-5-codex, meu workflow migrou completamente. Hoje são 2-3 terminais abertos, cada um com uma instância do Codex CLI em uma frente isolada. Eu orquestro. Eles executam. E o segredo mais simples: commits atômicos. Peço explicitamente para cada instância commitar a cada etapa.

Isso salvou meus rollbacks mais vezes do que posso contar.

Qual modelo usar?

Uso gpt-5-codex via CLI para tudo. As exceções são raras e intencionais:

• Front-end com micro-interações: Claude 4.5 Sonnet, thinking-budget low, plan mode. A estética dele simplesmente bate diferente.

• Feature de alto impacto: Inicio no high para arquitetura, migro para mid para implementação.

“Mas e Qwen3 Coder, Minimax-M2, GLM 4.6?”

Olha, testei. Perdi duas semanas. Para começar, considero distração total. O Codex é eficiente não pelo modelo, mas pelo CLI da OpenAI. Algo nele navega arquivos de forma que o Cursor, usando o mesmo modelo, não replicou. É tokenização, contexto, não sei o quê. Simplesmente funciona.

E o Claude Code?

Claude Code foi o precursor. Por meses, foi o único que entregava “qualidade de produção”. Mas algo mudou. Ele começou a mentir sobre testes. Comentava linhas, apagava arquivos e no final garantia: “todos os testes estão passando”. Perdi as contas de quantas vezes isso me quebrou em PR. Acho que foram longe demais em “imitar o dev médio”, e os bad patterns se tornaram features.

Subagentes? Bonito no demo. Na prática, entrega incompleta. Hoje, só uso Claude para UI e, depois que seu Design System tá pronto, nem isso.

Por que Codex ganhou? Três coisas concretas:

1. Limite de U$20,00 generoso (e +50% recente): Uso minha conta do ChatGPT direto. Não preciso vender um rim para ter acesso a limites generosos de uso.

2. Contexto útil: 230K tokens + /compact que funciona. Já tratei features inteiras num único chat. No Claude Code as vezes tenho que quebrar uma funcionalidade em vários chats para tê-la pronta.

3. Fila de mensagens: enquanto ele implementa, eu deixo a próxima instrução na fila. Quando termina, ele já parte pro próximo passo. Encadeamento sem ficar olhando tela.

E modelos abertos?

Kimi K2 Thinking ficou posicionado apenas abaixo do GPT-5 (high)

Sou entusiasta de modelos chineses. Kimi K2 e GLM 4.6 são meus escapes. Quando o Codex está perto dos limites, jogo tasks de “limpeza de lint” ou “gerar testes” pra lá. Custa U$3,00 no plano Code do GLM. É literalmente mais barato que um café. Recomendo usar no Cline, melhor extensão do VS Code para multi-modelo.

Como eu inicio um projeto novo?

Projeto novo? Vou ao Lovable para gerar landing, auth, home logada. É rápido. Mas não confio. Primeira coisa após exportar: habilito linter e caço todos os any que ele injeta.

Se seu projeto depende de SEO, fuja do Lovable. A stack deles é um pesadelo de performance. Use como kick-off, não como fundação.

Como implemento novas funcionalidades usando o Codex?

No Cursor eu fazia prompts épicos: contexto completo, arquitetura, regras de negócio. Funcionava, mas era trabalho de arqueologia na codebase toda vez que iniciava uma nova funcionalidade.

Com Codex CLI, percebi que contexto explicíto vence volume. Hoje faço assim: detalho a feature, peço para “analisar caminhos de implementação”. Depois de alguns “vais e vens” detalhando escopo, caminhos e corner-cases, libero pra desenvolver. É como se fosse o “refinamento técnico” com seu time de engenharia.

Resultado? Primeira tentativa certa na maioria das vezes. Claro, migrations ainda são minhas. Não delego nada relacionado a banco de dados. Desta maneira já vi ele trabalhar 1h40min ininterruptos entregando sistema de convites e gestão de acessos completo.

E sobre o uso de MCP´s?

Não vou entrar no tecniquês. Muita gente já fez isso.

Faço pouquíssimo uso de MCPs no meu fluxo. Por quê? Porque CLIs nativos são mais token-eficientes. supabase db push é mais rápido e limpo que qualquer MCP.

O padrão que vejo é dev criando bloatware de MCPs, enchendo contexto com lixo e depois reclamando que a AI “não entende”.

Atualmente uso um único MCP: Chrome Dev Tools, para debug de navegação. Fora isso, o único caso legítimo que vejo é Claude + Figma MCP. Mas isso fica para outro post.

“O código gerado é uma merda”

Concordo parcialmente.

E é por isso que eu gasto bastante tempo refatorando e melhorando minha codebase. Conforme ela foi crescendo, reorganizei os diretórios, arquivos, nomenclaturas.

Código AI é igual bonsai: cresce rápido, mas precisa de poda constante. Com 150K linhas, minha rotina de refactoring virou religião:

1. Feature funcionando como a especificação? Commit.

2. Executo o jscpd para buscar partes do código duplicadas, e que poderiam ser consolidadas em componentes únicos ou métodos reutilizáveis.

3. Executo o knip para verificar se existem exportações e dependências que não estão sendo utilizadas no projeto

4. Quebro arquivos que cresceram demais e estão acumulando responsabilidades em arquivos menores

5. Atualizo a documentação de funcionalidades que são tricky - também adicionando testes pra garantir que elas não quebrem em implementações futuras

6. Revisando anti-patterns da stack utilizada, para garantir que não estamos fazendo aplicação deles.

7. Aplicando /review antes de commitar o PR, para garantir que não inserimos nenhum problema

Concordo que eu poderia fazer isso tudo em tempo de desenvolvimento da própria funcionalidade. Mas na minha experiência, tenho sido mais eficiente primeiro garantindo que funciona, e depois arrumando a bagunça feita pela inteligência artificial.

Você faz “spec-driven-development”?

Quando construi o RedaçãoAI (plataforma de correção de redações com AI), tinha aplicado spec-driven-development. Na época, era a única maneira de garantir que os modelos funcionassem corretamente e entendessem o contexto macro de toda codebase já existente.

Agora, já não uso SDD. Obviamente, tenho nas minhas anotações todos os detalhes da funcionalidade que será implementada, e compartilho isso com a LLM. No entanto, toda parte de mapeamento de dependências, mitigação de riscos, reescrita de testes e outros detalhes da especificação, vou discutindo em tempo real com o Codex.

E essa abordagem é mais eficiente. Eu também não tenho 100% de tudo que gostaria quando começo o desenvolvimento.

As vezes é bom ter em mente seu objetivo final, e construir e mapear o impacto junto com a ferramenta. Isso amplia seu conhecimento sobre a codebase e a conexão entre serviços e dependências. É pair programming com alguém que nunca se cansa.

Tem mais alguma dica?

Três coisas que só aprendi na porrada:

• Supabase: Sempre copie o schema.sql de produção das tabelas public e mande como contexto. O Codex entende regras de negócio que você nem lembra mais.

• Refino de front-end: Não gaste Codex nisso. Use Qwen CLI (grátis) ou Cline + GLM 4.6. São “estupidamente baratos” e rápidos.

• Code Review: Habilite o review do Codex no GitHub. É mais eficiente que qualquer outra tool porque tem contexto total e não gera falsos-positivos.

Conclusão

Ao invés de mergulhar em subagentes, n8n, RAG customizado, você consegue criar bastante coisa usando as ferramentas corretas, no momento correto, com contexto adequado.

Desenvolver é apenas parte do processo para entregar valor, e boa parte disso já pode ser delegada para uma LLM. O resto é gerenciamento de processo.

E aqui está o ponto que quero destrinchar nos próximos posts: isso não é só um shift técnico. É um shift de produto.

Quando um PM consegue prototipar, testar e iterar sem depender de backlog de engenharia, o ciclo de aprendizagem muda completamente. Mas tem armadilhas. E na semana que vem vou entrar em como isso impacta planejamento de roadmap, alocação de time e vários outros aspectos relacionados a gestão de produto.