Decidi começar um diário de desenvolvimento. A ideia é simples: toda semana, olhar pro que eu fiz, escolher o que vale contar, e escrever. Sem fórmula, sem tutorial, só o que aconteceu de verdade.
Este primeiro é diferente. Estou começando no meio do mês, então vai cobrir os últimos 30 dias. Os próximos serão semanais. Vamos ver se consigo manter o ritmo.
O mês foi movimentado, mas o que mais me marcou não foi o que eu construí. Foi o que eu decidi jogar fora.
O processo de trabalho também precisa de refatoração
No trabalho, foi um mês de coisas que ficam invisíveis mas mudam como o produto evolui.
A entrega mais concreta foi a integração do PostHog num facade de analytics. Antes, as chamadas pra ferramenta estavam espalhadas pelo código em vários lugares. O problema com isso não é técnico agora, é daqui a seis meses: quando você precisar entender o que está sendo rastreado, ou trocar de ferramenta, ou só auditar o que acontece, você vai ter que caçar chamada por chamada por todo o repositório. Centralizar num facade não resolve nada hoje. Resolve um problema que você vai agradecer no futuro.
Junto com isso, isolei um módulo que tinha crescido além do que devia. Ele estava pegando dependências de várias partes do sistema e exportando acoplamento pra todo lado. Ficou com fronteira bem definida: o que entra, o que sai. Essas coisas são mais difíceis de fazer do que parecem quando você está dentro do código há meses e já perdeu a noção do que deveria pertencer a quem.
Mas o que tomou mais tempo foi um problema que eu estava adiando: as instruções que guiam os agentes de IA no nosso processo de desenvolvimento tinham virado um nó. Um arquivo de contexto aqui, uma regra ali, uma instrução que contradiz outra que ninguém mais lembra de onde veio. O resultado não era catastrófico, mas era inconsistente. O mesmo tipo de tarefa produzia resultados com qualidade variável dependendo de como você perguntava e em que ordem.
Parei e fui desmontar isso. Defini o que cada tipo de agente pode decidir sozinho, o que precisa confirmar antes de avançar, como reporta o que fez. Eliminei o que estava duplicado. A qualidade das entregas ficou mais previsível logo depois.
Processo precisa de refatoração com a mesma frequência que código. Só que código quebra em prod e te avisa. Processo vai deteriorando devagar e você só percebe quando já tá feio demais pra ignorar.
O projeto que nasceu e já quis crescer além do que devia
RPGTeller é um projeto pessoal meu, um engine de livros-jogos narrativos. Comecei do zero há pouco mais de um mês, usando Claude Code e Cursor pesado no desenvolvimento, com agentes rodando em paralelo pra cada parte do trabalho.
O problema apareceu cedo. Quando você tem vários agentes rodando ao mesmo tempo, precisa de alguma forma de coordenar o trabalho. Qual agente tá fazendo o quê? Qual terminou? O que pode começar agora?
Minha solução foi construir um orquestrador próprio. Levei dias nisso, servidor, banco de dados pra persistir o estado de cada tarefa, interface pra monitorar tudo em tempo real. Funcionava. Era até satisfatório de usar.
Aí no fim de abril, o Cursor lançou o /multitask.
Faz exatamente o que eu tinha construído. Identifica as partes independentes do trabalho, cria agentes em paralelo, coordena a execução. Nativamente, em um clique.
Passei alguns dias tentando justificar por que o meu era melhor. "Mas tem mais controle." "Posso customizar." Até que parei e perguntei honestamente: o que esse orquestrador tem a ver com RPGTeller? Nada. Era infraestrutura pela infraestrutura, e eu estava gastando energia mantendo ela.
Deletei tudo. Centenas de linhas foram embora num commit só. No lugar ficou uma configuração mínima pro Cursor entender como coordenar os agentes no contexto do projeto.
Com a coordenação funcionando de verdade, o trabalho no design system acelerou bastante. Mais de quinze componentes auditados e alinhados ao padrão visual nas semanas seguintes, cada um em paralelo, sem conflito, sem overhead de gerenciamento.
Pode ser que no seu caso não faça sentido jogar fora. Às vezes o que você construiu tem nuances que a ferramenta nativa não cobre, e vale manter. Mas se fizer sentido deletar, não precisa ter dor no coração com isso.
Testes que só passam às vezes
Num projeto pessoal de estudos, os testes automatizados tinham um problema que eu ficava adiando resolver: o resultado dependia de quando você rodava.
Com vários workers em paralelo, os testes brigavam por estado compartilhado. Um criava dados que o outro não esperava encontrar. O resultado era aquele flake clássico, passa agora, falha amanhã, passa de novo. Impossível confiar.
A correção foi consolidar o ambiente num servidor único compartilhado e criar um estado base comum pra todos os testes partirem do mesmo ponto. A ordem de execução parou de importar. CI voltou a ser confiável.
Testes flaky são piores do que não ter testes. Pelo menos sem testes você sabe que não tem cobertura.
Da semana que vem em diante, o diário vai ser semanal. O que você acha da ideia?
Top comments (0)