Passei a maior parte da última década como product manager. Antes disso eu escrevia código, liderei time de engenharia, cofundei coisa que não deu certo e coisa que deu. Em algum ponto virei a pessoa que escreve documento e conduz reunião, e aceitei isso como uma sequência natural de carreira.
No último ano voltei a construir. Não como hobby de fim de semana — construindo o que a operação usa.
Não foi um plano. Foi consequência de o custo de tentar ter caído tanto que a decisão realmente cara passou a ser não tentar.
Anotei o que aprendi, incluindo o que aprendi errando.
1. O gargalo mudou de lugar e demorei pra ver
Durante anos, a fila era: ideia → especificação → priorização → engenharia → entrega. O passo caro era o último e todo o processo existia pra protegê-lo. Priorização é isso: um jeito de decidir o que merece um recurso escasso.
Quando o recurso deixa de ser escasso, o processo continua funcionando por inércia — e passa a ser o gargalo. Eu segurei ideias por três meses num backlog porque "não tem capacidade de dev", num período em que dava pra ter feito o protótipo em duas tardes e descoberto que duas delas eram ruins.
O aprendizado não é "agora tudo é rápido". É que a pergunta mudou. Antes era "vale o custo de construir?". Agora é "vale o custo de manter?". São perguntas bem diferentes e a segunda é mais difícil, porque o custo de manutenção aparece devagar.
2. Especificar ficou mais importante, não menos
Com agente escrevendo código, achei que a especificação viraria menos relevante. É o oposto.
Quando eu chego vago, o agente entrega algo plausível e errado, rápido. Aí eu reviso o errado, corrijo, ele entrega outro errado. Duas horas depois eu tenho código funcionando que resolve o problema que eu não tinha.
Quando eu chego com o problema bem definido — o que entra, o que sai, o que não pode acontecer, como sei que funcionou — a coisa flui.
Ou seja: os anos de PM não viraram passado, viraram ferramenta. A habilidade de transformar uma queixa vaga em um requisito verificável é exatamente o insumo que falta na maior parte do trabalho com agentes. Quem só sabe escrever código está tão limitado quanto quem só sabe escrever documento.
3. Revisão é o trabalho, não o adendo
Meu erro mais caro do ano foi aceitar código que eu não entendia porque os testes passavam.
Era um pipeline de processamento com um tratamento de erro sutilmente errado. Passou em tudo. Rodou em produção por três semanas engolindo silenciosamente um caso de borda que era, claro, o caso que mais importava pro cliente.
Ninguém tinha mentido. Eu é que tinha delegado a compreensão junto com a escrita, e essas duas coisas não se delegam juntas.
Desde então trabalho com uma regra simples: se eu não consigo explicar o que o código faz sem abrir o arquivo, ele não entra. Isso me deixa mais lento e já me poupou de duas versões do mesmo erro.
4. Sistema de conhecimento é infraestrutura
Foi disso que nasceu o Credence. O padrão que se repetia era sempre o mesmo: o agente sabia muita coisa e não sabia dizer de onde, e por isso não dava pra confiar no que ele sabia nem corrigir direito quando errava.
A generalização que ficou: em sistema com agente, procedência não é feature, é fundação. Se você não sabe de onde veio a informação, você não tem sistema — tem um oráculo simpático. Oráculo é ótimo em demo e péssimo em auditoria.
5. Infra por uso mudou meu comportamento, não só minha conta
Escrevi sobre isso no post do Modal, mas o ponto vale repetir fora do contexto técnico.
Quando o recurso é caro e fixo, você trata com cerimônia. Quando é sob demanda, você experimenta. A economia de dinheiro foi boa; a mudança de comportamento foi melhor. Trocamos de modelo duas vezes em dois meses porque comparar ficou barato — não porque ficamos mais espertos.
Custo fixo alto é conservadorismo disfarçado de disciplina. Isso vale pra GPU e vale pra várias outras decisões.
6. Consertar prompt não conserta processo
Um dos agentes internos vivia errando classificação de um tipo de documento. Passei duas semanas melhorando prompt, exemplo, few-shot, reranking. Ganhei alguns pontos e um cansaço razoável.
O problema real era que dois times preenchiam o mesmo campo com convenções diferentes havia dois anos. Não tinha prompt que resolvesse. Alinhamos a convenção numa conversa de quarenta minutos e o erro sumiu.
Boa parte do que parece problema de IA é problema de processo que ficou visível. A IA não criou a bagunça, só parou de tolerá-la em silêncio — que é, sinceramente, o serviço mais útil que ela prestou aqui.
7. Correr longo ensinou algo que reunião nenhuma ensinou
Estou treinando pra uma ultra e a parte que se transferiu pro trabalho não foi disciplina. Foi ritmo.
Em prova longa, quem sai rápido não termina. O corpo cobra depois, sempre, e o preço é maior que o ganho. A tentação de acelerar é mais forte exatamente quando você está se sentindo bem.
Projeto de software é igual e eu sabia disso na teoria havia anos. Correr me fez sentir na prática, que é diferente. Semana de sprint heroico produz duas semanas de dívida. O ganho é visível e imediato; a conta chega depois, discreta, e ninguém liga uma coisa à outra.
O que eu levo pro próximo ano
Três coisas, curtas:
Construir cedo, decidir depois. Protótipo virou instrumento de investigação, não compromisso. Jogar fora ficou barato o suficiente pra ser estratégia.
Registrar tudo que o sistema afirma. Se um agente diz algo, precisa dar pra saber de onde veio. Isso paga em depuração, em auditoria e em sono.
Desconfiar do que funciona rápido demais. Nem toda velocidade é progresso. Às vezes é só a parte fácil sendo feita antes da parte que importa.
Voltar a construir foi a melhor decisão profissional que tomei em anos. Não porque o código me fazia falta — porque a distância entre entender um problema e mexer nele diminuiu, e essa distância era onde as boas ideias morriam.