DEV Community: Daniel Porto

Diário de dev #3: o bug que só aparece quando alguém usa

Daniel Porto — Mon, 08 Jun 2026 21:35:21 +0000

No trabalho, nenhum código mudou. O que mudou foi a forma como os clientes inserem os dados. E isso quebrou coisas que nenhum teste existente pegou.

O bug que só aparece quando alguém usa

A motivação pra montar E2E do zero veio de um problema específico.

Você precisava acessar a aplicação pra quebrar. Não era um erro de lógica isolado que um teste unitário pegaria. Era uma combinação de dados reais num fluxo real produzindo um resultado errado que só aparecia na tela. Os clientes chegavam lá antes da gente.

É uma categoria de problema que teste de código não resolve, porque o problema não está no código. Está na interação entre o código, os dados e o ambiente. A forma mais rápida de pegar antes é rodar o fluxo completo do jeito que o usuário roda.

Ficou com smoke tests cobrindo os principais fluxos do produto, configuração pra rodar contra múltiplos ambientes, e notificação no Slack quando o nightly quebra.

A parte mais útil não são os testes em si. É saber antes do cliente reportar.

Autocrop: quando nenhuma ferramenta resolve tudo

Num projeto paralelo que mantenho, passei o fim de semana montando autocrop automático pra imagens.

A ideia inicial era usar o imgproxy Pro, que tem detecção de objeto embutida. Não ficou preciso o suficiente pra variedade de imagens que eu tinha. Fui pro Rekognition, que retorna bounding boxes. Mais controle, mas bounding box tem um limite: é um retângulo. Objetos não são retângulos.

Aí descobri o rembg, que faz algo diferente. Em vez de delimitar uma área, ele cria uma máscara pixel por pixel usando uma rede chamada U2Net, treinada pra segmentação de primeiro plano. O resultado foi bem superior — ele recorta o objeto, não uma caixa em torno dele.

Colocar isso em Lambda foi onde a semana ficou mais lenta. O modelo precisava estar acessível pro processo do Lambda, coloquei em /root, Lambda não lê de lá. Movi pro /opt, chmod 755. O NUMBA tentou escrever cache em diretório read-only, defini NUMBA_CACHE_DIR=/tmp. Depois OOM em imagens maiores, aumentei pra 2048 MB. Cada um levou um ciclo de deploy pra aparecer.

A pipeline final ficou com critérios de aceite diferentes por camada: rembg com padrão rigoroso primeiro. Se não atingir, Rekognition em paralelo com rembg em critérios mais flexíveis. Se nenhum passar, review manual. Nenhuma abordagem de ML funciona pra 100% dos casos — a arquitetura respeita isso.

A review UI que construí em cima foi consequência: se o fallback é humano, precisa de interface decente. O fallback virou feature.

Se quiser o contexto dos anteriores, o #0 e o #1 estão no dev.to. O #2 foi uma semana mais calma e ficou só no LinkedIn.

Diário de dev #1: o que 15 minutos desbloqueou

Daniel Porto — Sun, 24 May 2026 03:41:54 +0000

Segunda semana do diário. Se a anterior foi sobre um mês inteiro de construir e jogar fora, essa foi mais mundana. Infra que ninguém vê, um projeto pequeno que virou ferramenta pra outra pessoa, e uma noite explorando um problema que ainda não tem resposta.

A última milha que ninguém pensa

Alguém do time de marketing me mostrou uma página de evento que tinha construído com IA. Ficou boa. Sério, boa mesmo: cores certas, espaçamento certo, seguindo o design system. Aí veio a pergunta: "como eu coloco isso no ar?"

Esse gap me pegou de surpresa. O trabalho difícil estava feito. A parte que eu esperaria ser o obstáculo, criar a interface, tinha sido resolvida por alguém sem experiência técnica usando IA. O que travou foi publicar. Um detalhe de infraestrutura que pra qualquer dev é trivial, mas que pra quem nunca mexeu com git ou servidores é uma parede.

Montei um repo no GitHub Pages onde cada pasta vira automaticamente uma URL em nosso domínio. Faz upload, aparece em dominio.com/nome-do-evento. Quinze minutos de configuração.

O que me ficou foi pensar em quantas outras pessoas estão nessa situação agora. IA abaixou muito o piso pra criar interfaces, mas a infraestrutura ainda pressupõe conhecimento que a maioria das pessoas não tem e provavelmente não quer ter. O trabalho de dev vai mudando, mas não necessariamente diminuindo. Às vezes vira isso: resolver a última milha pra quem chegou até lá sozinho.

A semana que não aparece em nenhum demo

No trabalho foi uma semana de trabalho que ninguém vai mostrar numa apresentação. Infraestrutura, permissões, estado inconsistente.

Tem uma categoria de bug que eu acho particularmente frustrante: o que não grita. Sem exception, sem mensagem de erro, sem log óbvio. Só um usuário preso num fluxo de login que não avançava e não explicava por quê. Quando você finalmente entende o que estava acontecendo, a solução cabe em três linhas. O difícil foi chegar até lá.

Além disso, rodou um ciclo de QA mais pesado numa tela complexa do produto, aquele tipo de tela onde o estado vem de vários lugares ao mesmo tempo e as fontes se interferem de formas que só aparecem quando você junta tudo. Tínhamos testes. Não eram suficientes.

Não é que os testes fossem ruins. É que teste automatizado tende a verificar o que você imaginou que poderia dar errado. QA externo encontra o que você não imaginou. São dois tipos de cobertura diferentes, e essa semana ficou claro de novo que um não substitui o outro.

O resto foi infra. Esse tipo de trabalho tem um ritmo próprio: você acha que vai ser rápido, descobre que não é, ajusta, testa de novo. Cloud costuma ter pelo menos uma surpresa guardada em algum canto de permissão que você não esperava precisar configurar.

Uma noite tentando dar voz a personagens em português

RPGTeller é um engine de livros-jogos que estou construindo. Essa semana queria explorar narração por voz, dar vozes distintas pra cada personagem.

Comecei pelo Kokoro, uma opção de síntese de voz que roda offline. Tem apelo óbvio pra um projeto assim: sem dependência de API, sem custo por caractere, roda localmente. O problema é que dublagem em português brasileiro ficou robótica demais. Funcional, mas longe de imersiva.

Migrei pro ElevenLabs. Ficou melhor, suficiente pra eu conseguir atribuir vozes específicas por personagem: uma voz de narrador, outra pra Svetlana, outra pro guerreiro. Dá pra imaginar como vai soar no jogo.

Mas ElevenLabs é uma API paga por caractere. Antes de seguir por esse caminho, quero saber se consigo qualidade aceitável rodando algo local. Ainda não sei a resposta.

Não terminei essa exploração. Ainda quero testar mais opções, especialmente coisas que rodam localmente e têm qualidade aceitável em pt-BR. Por enquanto ficou Kokoro ruim, ElevenLabs bom mas online.

O diário #0 cobriu um mês. Esse cobriu uma semana normal. Se quiser acompanhar os próximos, segue lá.

Diário de dev #0: o mês em que eu deletei mais do que adicionei

Daniel Porto — Sat, 16 May 2026 16:00:08 +0000

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?