Construir é metade do trabalho. Provar com número é a outra

Yuri se candidatou a uma vaga que lhe interessa de verdade. Antes da entrevista, pediu a uma IA uma avaliação fria: o que falta, tecnicamente, para essa vaga. Esperava ouvir o nome de alguma ferramenta que ele ainda não domina, algum método que precisasse estudar no fim de semana. Não foi isso que veio.

A resposta apontou para outro lugar. Em anos construindo sistemas com IA, ele nunca tinha montado uma avaliação capaz de provar, com número, que uma versão de um sistema era melhor que a anterior. Ele construía, entregava, o sistema funcionava, e ele seguia para o próximo. Nunca mediu.

É mais comum do que parece. Boa parte do trabalho com IA hoje se baseia numa espécie de olho clínico: alguém troca uma instrução, olha a resposta, acha que ficou melhor, e segue. É rápido, é humano, e é exatamente o ponto fraco que a avaliação fria de Yuri encontrou nele. Times inteiros vivem assim, decidindo se uma mudança valeu a pena pela impressão de quem testou, não por uma comparação sistemática entre a versão antiga e a nova.

Isso não é falta de disciplina, é um problema de natureza diferente. Testar código tradicional é relativamente simples porque, para uma entrada, existe uma saída certa e verificável: a função soma dois números, o resultado está certo ou está errado. Pedir a uma IA que redija um e-mail não tem uma resposta certa, tem milhares de respostas aceitáveis, cada uma boa de um jeito diferente. Sem um jeito estruturado de comparar, a única régua que resta é a impressão de quem está olhando. "Acho que ficou melhor" é o máximo que se consegue dizer, e achar não é prova de nada.

O que uma avaliação de verdade muda é justamente isso: transforma impressão em número. Em vez de "acho que melhorou", passa a ser possível dizer algo como "testamos duzentos casos, a taxa de acerto subiu cinco por cento e o tom da resposta não piorou". A diferença entre as duas frases é a diferença entre opinião e evidência.

O ganho não é só ter um número bonito para mostrar. É poder testar centenas de situações de uma vez, em vez de olhar cinco exemplos escolhidos a dedo. É conseguir ver quando melhorar uma coisa piora outra, porque quase sempre existe uma troca escondida ali. E é, sobretudo, ter como provar que a versão nova realmente supera a antiga, em vez de acreditar que sim porque parece melhor num teste rápido. Yuri construiu sistemas assim por anos sem nunca ter montado essa régua. Funcionavam. Ele só nunca soube dizer, com número, o quanto.

O segundo achado da avaliação doeu mais, segundo ele mesmo contou. Seu currículo conta o que ele desenhou: a arquitetura, a decisão, o desenho da solução. E esconde o que ele codificou, depurou e mediu para fazer aquele desenho funcionar de verdade. A primeira impressão que o currículo causa é a de alguém que só desenha soluções no quadro branco, não de alguém que também constrói, depura os erros e confere se o resultado bate.

Isso também não é um problema exclusivo dele. Um currículo pede prova compacta: uma linha, uma frase, um resultado. O trabalho de engenharia sênior, ao contrário, cria um contexto enorme, cheio de decisões pequenas que só fazem sentido juntas. Quanto mais profundo o trabalho, menos visível ele fica de fora. E o que importa, na maioria das vezes, não é a linha de código em si, é a decisão por trás dela: por que essa abordagem e não outra, o que foi testado e descartado, o que quebrou e como foi corrigido.

Um currículo que só lista tarefas descreve atividade. Um currículo que descreve decisões descreve julgamento, e é o julgamento que separa quem executou o que foi pedido de quem decidiu o que fazer. Yuri desenhava e decidia havia anos. O currículo só contava a parte do desenho.

As duas lacunas são, na verdade, a mesma lacuna vista de dois ângulos. Construir um sistema e nunca provar, com número, que ficou melhor é uma forma de contar a própria história pela metade. Escrever um currículo que só mostra o desenho e esconde a construção é outra forma da mesma metade que falta. Nos dois casos, o trabalho existiu, foi feito, funcionou. Só não foi provado.

É tentador achar que construir bem basta, que o resultado fala por si. Às vezes fala. Mas no trabalho com IA, onde não existe uma resposta certa única para comparar, e no mercado de trabalho, onde ninguém vê o que se passou por trás da decisão, o resultado raramente fala sozinho. Alguém precisa traduzi-lo em número, ou em frase que mostre o julgamento por trás dele. Construir é metade do trabalho. Provar, com número ou com a história certa, é a metade que falta para diferenciar.