O custo marginal da correção

O custo marginal da correção está a tender para zero. É preciso compreender bem o que isto significa para a forma como pratica a engenharia de software. É preciso ter uma obsessão por fazer as coisas corretamente.

Um panorama em mudança

Antigamente, um engenheiro conseguia destacar-se graças ao seu talento técnico puro: raciocínio algorítmico eficiente, sistemas distribuídos escaláveis, análise minuciosa manual dos pontos de paragem do depurador. Isto está a tornar-se cada vez menos verdade, a um ritmo acelerado. Os agentes estão a permitir que qualquer pessoa escreva código correto.

A competência mais importante que precisas de desenvolver para te destacares neste momento é um «far:» a capacidade de perceber o que não está bem e a força de vontade para corrigir a situação.

Detetar uma API lenta

Estamos a treinar um novo modelo na Pangram (não acho que esteja a revelar demasiado ao admitir isso) — será maior, mais inteligente e também *mais rápido* do que os nossos modelos anteriores. Esse último superlativo não teria sido possível sem uma obsessão por fazer as coisas corretamente, apenas pelo prazer de o fazer. Porque podemos. Porque nos orgulhamos do nosso ofício. Porque um dia eu estava a testar a nossa API e senti que «isto devia ser definitivamente mais rápido do que isto».

Na altura, não tinha como saber exatamente como é que mergulhar nessa aventura iria compensar. Estava apenas munido da convicção de que devíamos fazer as coisas como deve ser e da crença de que, com o Fable ao meu lado, tudo era possível.

Conseguimos superar o desafio apenas alguns dias depois, saindo vitoriosos contra a latência que tinha prejudicado o meu «dogfooding». Com o Fable, consegui criar um ambiente de testes totalmente local para o nosso complexo orquestrador de APIs distribuídas. Gerámos hipóteses para todos os pontos críticos do nosso código e testámos correções para cada um deles. Organizámos em pipeline operações complexas do Redis e validámos a preservação do comportamento. Executámos simulações de diferentes padrões de carga com base no tráfego de produção e estimámos a infraestrutura necessária.

Sem os agentes, este teria sido um projeto insustentável e inviável — que exigiria semanas ou meses de trabalho de engenharia. Em vez disso, foi um projeto paralelo enquanto o meu treino decorria em segundo plano.

Os nossos esforços foram recompensados com um aumento de cerca de 5 vezes na utilização da GPU — de 20% (ai!) para 98% — e um débito comparável ao dos nossos nós «bare metal». Isto custou-nos muito pouco. E valeu-nos tudo. Fez com que a hospedagem do nosso novo modelo passasse de um custo proibitivo para uma verdadeira pechincha.

Desenvolver o seu olfato

Infelizmente, não existe um «truque fácil» para desenvolver o teu olfato, mas é uma competência que podes desenvolver. Eis o que funcionou para mim (penso eu):

Ter pouca tolerância à dor

Tudo o que te frustra provavelmente também frustra os teus utilizadores — não te limites a aguentar em silêncio. Tens de estar em sintonia contigo mesmo: repara no que te causa uma agitação subtil ao longo do dia, nas partes do código que podes estar a evitar inconscientemente ou nas tarefas durante as quais te sentes um pouco inquieto. É aqui que há ganhos a alcançar. Foi isto que deu início à minha análise aprofundada da otimização da API.

Gosto de dizer que «as coisas fáceis devem ser fáceis». Isto aplica-se ao teu código (por exemplo, executar uma ablação de treino simples não deve exigir qualquer esforço mental) e ao teu produto (por exemplo, uma única chamada à API deve ser apenas ligeiramente mais lenta do que a própria passagem de avanço). Quando te apanhares a pensar «isto não devia ser assim tão difícil», resolve o problema! Agora já tens agentes! Cria uma worktree e lança o Codex /golo Vá lá, o que tens a perder?

Questionar tudo a partir dos princípios básicos

Os agentes facilitam imenso esta tarefa. «Quanto tempo deverá demorar esta tarefa, tendo em conta o tamanho do nosso lote, as especificações da GPU e o número de parâmetros?» «Quanto devemos gastar com este fornecedor, tendo em conta o nosso volume de dados e de consultas?» Quando sabemos como é que o resultado correto se apresenta, é muito mais fácil identificar o que está errado.

Faço isto para todas as topologias de modelo/nó/formato de pedido que suportamos — é assim que otimizo a nossa configuração do vLLM para garantir que estamos próximos do limite teórico. Foi assim que percebi que havia uma diferença entre o débito da nossa API e o que obtemos num nó bare metal.

Este princípio aplica-se também ao teu código. Se alguma abstração te parecer estranha, não aceites simplesmente «sempre foi assim» como resposta. Repensa o contrato a partir dos princípios básicos — como deveria ser, tendo em conta o que sabemos agora? A tua função é determinar para onde orientar o agente. O agente pode refatorar e validar a correção durante a noite.

Sê curioso, lê muito

Uma das minhas otimizações favoritas que implementei durante a minha primeira semana na Pangram foi inspirada no mecanismo híbrido de atenção esparsa do DeepSeek V4.

A minha otimização não teve nada a ver com a arquitetura neural, muito menos com a atenção, especificamente. Tratou-se de uma melhoria no algoritmo que utilizamos para detetar as fronteiras entre texto humano e texto gerado por IA, o qual antes exigia uma segunda passagem de inferência sem limites.

Absorve o máximo possível de conceitos interessantes de tantas pessoas inteligentes quanto conseguires. A tua tarefa agora é ser infinitamente curioso, estabelecer ligações e perguntar «e se...». Lembra-te de que o custo marginal de descobrir está a tender para zero.

Utiliza as tuas fichas

Tenho um ritual todos os domingos em que simplesmente coloco o Codex num local aleatório /golo para tentar usar os meus tokens semanais antes da reinicialização. Na maioria das vezes, acabo por deitar fora o código ou este fica esquecido num rascunho de PR. Às vezes compensa. Quase sempre aprendo alguma coisa com este exercício. Seja como for, não me custa nada. Há quem chame a isto «jogar nas slot machines», mas eu digo que não se pode ganhar se não se jogar