- Resumo de 6 semanas de experiência em que o número de commits aumentou drasticamente ao melhorar a infraestrutura de desenvolvimento, com automação de tarefas repetitivas simples do agente de IA, eliminação do tempo de espera de build e construção de um sistema paralelo de worktrees
- Com a skill
/git-pr, o processo de criação de PR foi automatizado, eliminando o custo de troca de contexto, e o agente passou a escrever descrições de PR mais detalhadas por conta própria
- Ao migrar a ferramenta de build para SWC, o reinício do servidor caiu para menos de 1 segundo, garantindo um ambiente de desenvolvimento sem interrupções no fluxo
- Com o recurso de preview do Claude Code, o agente passou a validar a UI por conta própria, removendo o gargalo de o desenvolvedor precisar verificar manualmente todas as mudanças
- Ao remover cada ponto de atrito em sequência, revelou-se exatamente o padrão da Theory of Constraints, em que o próximo gargalo aparece logo em seguida
- Agora, o foco está menos na implementação de funcionalidades e mais em construir uma infraestrutura para o agente trabalhar com eficiência e aumentar a velocidade do loop
Automação de tarefas repetitivas simples
- No início, todo o processo era feito manualmente: stage das mudanças, escrita da mensagem de commit, descrição do PR, push e criação do PR no GitHub
- Reconhecer que isso era trabalho repetitivo (grunt work) foi o primeiro ponto de virada, e o papel mudou de implementador para gerente que administra agentes
- Foi criada a primeira skill do Claude Code,
/git-pr, para automatizar todo o processo de criação de PR
- Como o agente lê o diff completo e resume corretamente as mudanças, a descrição do PR fica mais detalhada do que quando era escrita manualmente
- O
CLAUDE.md do codebase especifica o uso de Graphite, mas pessoalmente a preferência é por plain git, então a operação é feita com /git-pr
- Mais importante do que a economia de tempo em si foi a eliminação da sobrecarga mental: desapareceu a pequena troca de contexto que acontecia ao mudar de “pensar no código” para “pensar em como explicar o código” a cada PR
Eliminação do tempo de espera
- Para fazer preview local, era preciso sair do trabalho atual, parar o servidor de desenvolvimento e reiniciá-lo em uma nova branch, algo que se repetia constantemente
- O build do servidor levava cerca de 1 minuto, tempo longo o bastante para quebrar a concentração, mas curto demais para fazer outra coisa útil
- Ao migrar o build para SWC, o reinício do servidor passou a levar menos de 1 segundo
- Assim que o arquivo é salvo, o servidor já está de pé, sem espaço para a atenção se dispersar
- A comparação feita é com a diferença entre “uma conversa com silêncios constrangedores” e “uma conversa que flui naturalmente”
Validação de UI pelo próprio agente
- Antes, era preciso conferir manualmente todas as mudanças de UI no preview local, o que transformava o desenvolvedor no gargalo de todas as funcionalidades
- Depois que a extensão do Chrome continuou travando, houve a migração para o recurso de preview do Claude Code
- O agente consegue configurar o preview e manter os dados da sessão, podendo ver diretamente como a UI realmente aparece
- Isso foi integrado ao fluxo de trabalho, e agora o agente só pode marcar algo como “concluído” depois de validar a UI diretamente
- Como a validação pode ser delegada, basta intervir apenas na revisão final, e o agente consegue operar de forma autônoma por muito mais tempo
- O fato de o agente detectar os próprios erros acabou sendo um efeito muito mais importante do que o esperado
Sistema paralelo de worktrees
- Depois de ter rebuild rápido e preview automatizado, surgiu o próximo ponto de atrito: só era confortável executar uma tarefa por vez
- Para revisar o PR de outro agente ou de um colega da equipe, era necessário sair da main, fazer checkout da branch do PR, rebuild e testes, mas isso entrava em conflito com mudanças ainda não commitadas
- stash → checkout → rebuild → test → switch back → pop stash, ou então criar worktrees manualmente e acabar enfrentando conflitos de porta
- O app precisava de portas separadas para frontend e backend, e todas as worktrees compartilhavam as mesmas variáveis de ambiente, tentando fazer bind na mesma porta
- Para resolver isso, foi construído um sistema que atribui automaticamente faixas de portas exclusivas para cada servidor ao criar uma worktree
- Com isso, é possível executar até 10 previews ao mesmo tempo
- O cenário mudou de ficar sobrecarregado até com 2 branches em paralelo para operar 5 worktrees simultaneamente
- Vários agentes são executados em worktrees separadas para construir funcionalidades diferentes, e seguem de forma autônoma até concluir a própria validação de UI
- A participação fica profunda na etapa de planejamento, mas sem intervir até o momento da revisão de código
- A revisão também ficou muito mais fluida: sem setup, sem rebuild e sem conflitos de porta, o fluxo vira simplesmente ler, conferir e fazer merge
O ponto central não é a IA, e sim a infraestrutura
- O papel mudou: em vez de gastar tempo resolvendo pessoalmente problemas complexos e fazendo a UI perfeita, ficou mais interessante construir infraestrutura para tornar os agentes eficazes
- É algo parecido com deixar de ser um desenvolvedor solo para se tornar gerente de uma equipe de 10 pessoas
- É um trabalho de plumbing nada glamouroso, mas é isso que determina se você permanece em estado de fluxo ou fica brigando com o ambiente
- Na Tano, o trabalho de maior alavancagem não foi desenvolver funcionalidades, e sim construir a infraestrutura que transformou o fluxo de commits em uma correnteza
O loop: aplicação da Theory of Constraints
- Cada etapa remove um tipo diferente de atrito:
/git-pr: remove o atrito de formatação para transformar mudanças de código em PR- SWC: remove o atrito de espera até ver o resultado após uma mudança
- recurso de preview: remove o atrito de validação ao conferir mudanças
- sistema de worktrees: remove o atrito de troca de contexto entre vários fluxos de trabalho
- Sempre que um gargalo é removido, o próximo aparece imediatamente, um padrão típico da Theory of Constraints
- A natureza do trabalho muda: deixa de ser “usar ferramentas para escrever código” e passa a ser um loop de feedback apertado de iniciar o trabalho → o agente escreve o código → conferir o preview → ler o diff → dar feedback ou fazer merge → próxima tarefa
- Quando o loop é rápido o suficiente, não há espaço para a atenção escapar, e a própria aceleração vira o jogo
- No fim, o objetivo do desenvolvimento deixa de ser implementar funcionalidades e passa a ser quanto mais é possível aumentar a velocidade do loop
- Chega-se ao estágio em que a velocidade em si vira o prazer da engenharia
2 comentários
Como revisor, quando vejo uma descrição de PR escrita por máquina, a experiência não costuma ser muito boa. Talvez dê para melhorar só ajustando bem o prompt...
Comentários no Hacker News
Dá a sensação de que a métrica de “linhas de código por semana” dos anos 90 voltou
“Fazer mais PRs” não é prova de que a IA está funcionando bem, apenas significa que estão fazendo mais merges
Julgar desempenho só por volume produzido, sem considerar qualidade do código, bugs e custo de manutenção, não é diferente das métricas ruins que gestores empurravam antigamente
No fim, parece que não éramos contra métricas ruins, e sim contra sermos medidos em si
O objetivo real é que o código seja simples e produza resultados impactantes
Estou experimentando rodar vários agentes ao mesmo tempo para tentar implementações diferentes e depois combinar as boas ideias
Também reúno documentos e requisitos, faço perguntas ao agente e generalizo o feedback de code review em forma de checklist para aplicar na revisão seguinte
Trabalhar até adoecer não é motivo de orgulho, é sinal de que há algo errado no sistema
Por exemplo, o modelo COCOMO é confiável a ponto de ser usado até em tribunal para estimar o valor de um sistema
A maioria dos desenvolvedores não quer quantificar a si mesma
Já os defensores de IA acham que, para provar melhoria, é preciso medir
Acho que LLM deve ser usada na direção de reduzir a carga cognitiva
Humanos não são bons em multitarefa, e LLM não resolve isso
Em vez de delegar a implementação para o Claude, eu uso num modelo em que sou guiado durante a implementação
Assim, consigo entender o processo inteiro e enxergar ao mesmo tempo os detalhes e o panorama geral
Só deixo com o Claude as partes repetitivas e mecânicas
Faço perguntas para a LLM entender o problema, escrevo eu mesmo o código central e depois deixo que ela monte o plano do restante da implementação
LLM é forte para ler código, explicar e fazer tarefas simples, e eu foco em escolher a direção de resolução do problema
Estou experimentando prompts como “faça uma lista de suposições” ou “liste as decisões que não estavam no plano” para rastrear o que a LLM decidiu por mim
Se você entende as características do Claude, a eficiência de validação também aumenta, e com mais experiência fica mais fácil controlar a qualidade
Se você roda vários agentes para criar funcionalidades grandes, acaba surgindo o problema de o tempo de review aumentar demais
Porque ler código de outra pessoa (ou de uma IA) é mais difícil do que escrever você mesmo
Dá para cobrir parte disso com automação de testes, mas é difícil confiar completamente
Deixo claros escopo, testes e plano de documentação, e aplico bots de code review (Sourcery, CodeRabbit, Codescene) com regras de lint bem fortes
Também uso BDD, property testing, testes e2e, auditoria de código e até testes de mutation/fuzzing
A vantagem do agent coding é justamente liberar tempo para investir nesse controle de qualidade
Estou tentando rollout gradual com abordagens como 100 PRs a day
Se você dividir o trabalho em partes menores e confiar nos testes, revisar código de IA também fica leve
Eu olho os casos de teste com mais cuidado e termino o code review rapidamente
Não rodo vários agentes em paralelo, mas mesmo assim minha produtividade certamente aumentou graças à IA
Se o processo de escrever PR for totalmente automatizado, você perde uma oportunidade de autoverificação
Muitas vezes eu percebia coisas estranhas no meu código justamente ao escrever a descrição do PR
Aquele momento de explicar em inglês era meu último sanity check
O sistema de worktree facilitou a troca de contexto, mas ao mesmo tempo aumentou o cansaço mental
Dividir em unidades pequenas e manter ciclos curtos de review facilita o controle de qualidade
O bom é poder voltar no dia seguinte sem quebrar meu fluxo e já encontrar progresso feito
Sou cético quanto à premissa de que o Claude escreve código com alto grau de completude
Na prática, são necessárias várias rodadas de feedback e correção, e gerenciar várias tarefas em paralelo ao mesmo tempo acaba sendo ineficiente
Claude Code é revolucionário como ferramenta de aprendizado, mas a qualidade de geração de código oscila bastante
Aprendi Flutter/Dart fazendo perguntas conceituais ao Claude, e consegui criar um app em uma semana sem usar livro
Parece uma enciclopédia interativa
Para perguntas como “qual é a forma idiomática de fazer X nessa linguagem?”, ele dá respostas úteis na hora
Mas, em vez de ser algo que muda o mundo, é apenas uma ferramenta muito boa
Só que o marketing exagerado está causando efeitos negativos na economia como um todo
Também preocupa a ideia ilusória de que a IA vai substituir empregos, levando jovens a desistirem de carreiras
Houve um comentário dizendo que “depois de migrar o build para SWC, o restart do servidor caiu para menos de 1 segundo”,
e SWC é o Speedy Web Compiler, uma ferramenta de transpile rápida sem type checking
A documentação do NestJS explica a mesma coisa
Usar LLM não é motivo para se gabar de que a produtividade explodiu
Se todo mundo usa a mesma ferramenta, a linha de base só sobe
Além disso, se grandes volumes de código gerados por IA não forem devidamente revisados, a qualidade no longo prazo continua incerta
LLM até aumenta a produtividade, mas medir isso por gráfico de número de commits não faz sentido
É tão tolo quanto julgar qualidade por LOC
Enquanto eu mesmo escrevia o código e entendia o que estava fazendo, o Claude ajudou muito como parceiro para decompor tarefas e revisar
A verdadeira produtividade está na capacidade de substituir código complexo por abstrações simples