De Debugar Código para Debugar Produtos
Uma vez passei três dias construindo uma feature. O código funcionava perfeitamente. Testes passando. Zero bugs.
Aí os usuários começaram a reclamar.
A feature estava errada. Não quebrada. Errada. Resolvia um problema que ninguém tinha.
O Debug Antigo
Antes de assistentes de IA, debugar significava encontrar por que o código não funcionava como esperado. Null pointer exceptions, race conditions, erros de off-by-one. Problemas técnicos com soluções técnicas.
O ciclo de feedback era lento. Você passava uma semana implementando algo, outra semana corrigindo bugs, e só então entregava pros usuários. Quando você descobria que a feature estava errada, já tinha investido tanto tempo que pivotar parecia caro demais.
Essa lentidão era dolorosa, mas tinha um benefício escondido: forçava você a pensar com cuidado antes de codar. Você não podia se dar ao luxo de construir a coisa errada porque construir qualquer coisa levava uma eternidade.
O Debug Novo
Com a IA escrevendo código, consigo prototipar uma feature em horas ao invés de dias. A implementação técnica é rápida. Rápida demais, às vezes.
Agora descubro que uma feature está errada no dia um, não na semana três. O bug não é um null check faltando. O bug é que eu entendi errado o que os usuários realmente precisam.
Esse é um tipo diferente de debugging. Ao invés de perguntar “por que isso não funciona?”, estou perguntando “por que isso não importa?”
O Que Mudou
O gargalo se moveu.
Quando código era lento de escrever, a parte difícil era traduzir requisitos em software. Agora essa tradução é quase instantânea. A parte difícil é garantir que os requisitos estavam certos desde o início.
Me pego gastando mais tempo em:
- Conversar com usuários antes de construir, não depois
- Prototipar versões descartáveis pra testar suposições
- Questionar requisitos que parecem óbvios demais
- Matar features cedo quando o sinal é fraco
Menos tempo escrevendo código. Mais tempo garantindo que o código vale a pena ser escrito.
A Mudança de Habilidade
Debug tradicional requer profundidade técnica. Você precisa entender memória, concorrência, internals do sistema. Essas habilidades ainda importam, mas agora são o básico.
Debug de produto requer músculos diferentes:
- Empatia. Entender o que usuários realmente precisam, não o que dizem que querem.
- Ceticismo. Questionar suas próprias suposições antes de investir tempo.
- Velocidade até o sinal. Colocar algo na frente dos usuários o mais rápido possível.
- Disposição pra deletar. Jogar fora código que funciona mas não importa.
Os melhores engenheiros que conheço não são mais os que codam mais rápido. São os que desperdiçam menos tempo construindo a coisa errada.
Um Exemplo Prático
Uma vez trabalhei num algoritmo de recomendação. A implementação técnica era elegante. Vector embeddings, busca semântica, a stack completa.
Os usuários não ficaram felizes.
Não porque estava quebrado. Porque mostrava resultados que batiam com critérios explícitos mas não com a intenção real. Alguém querendo mudar de direção não queria mais do mesmo. Queria algo diferente.
O bug não estava no algoritmo. Estava na suposição de que match de preferências declaradas equivale a match de necessidades reais.
Debug tradicional nunca teria encontrado isso. O código estava correto. O produto estava errado.
O Que Isso Significa para Engenheiros
Se você só sabe debugar código, vai sofrer. A parte fácil agora é fácil. A parte difícil é todo o resto.
Comece a praticar debug de produto:
- Entregue algo pequeno antes de construir algo grande
- Observe usuários usando ao invés de perguntar o que acham
- Meça comportamento não só funcionalidade
- Delete mais rápido quando algo não está funcionando
O código se escreve sozinho. Descobrir o que escrever ainda precisa de um humano.