Andas a Correr Atrás de Ferramentas. A Competência Está Por Baixo.

Na maior parte dos dias escrevo código com dois modelos diferentes, e alterno entre eles sem grande cerimónia. Um é rápido, e recorro a ele quando o trabalho é mecânico e quero que o loop pareça uma extensão das minhas próprias mãos. O outro é mais lento e chega mais longe, e chamo-o quando o problema precisa mesmo de raciocínio. Esta é a parte que demorei a admitir. A troca não muda quase nada no trabalho. A especificação que escrevo é a mesma. A forma como parto o problema é a mesma. A revisão no fim é a mesma. Mudo o motor e fico com tudo o que construí à volta dele.

A pergunta é uma sondagem

A pergunta que me fazem, e a que vejo por todo o lado, é qual é a melhor ferramenta. Qual o modelo, qual o agente, qual o editor. Parece técnica. Na prática é uma sondagem. Melhor em quê, para quem, com que restrições, em que codebase? Tira isso e não sobra resposta nenhuma, só gosto, e gosto não é conhecimento. E qualquer resposta a que chegasses ficava desatualizada na release seguinte. Terias gasto esforço a sério a produzir um facto com prazo de validade de semanas.

Estás a otimizar a parte do sistema que mais muda e que menos importa. Há três camadas em jogo. O modelo, que é aquilo sobre que se discute, e que trocas num dia. O harness à volta dele, o produto que compras de facto: como gere o contexto, se consegue ler a tua codebase, correr os teus testes e recuperar quando parte. E o loop que corres através dele, as specs e a revisão, que é teu e vai contigo para todo o lado. Para o trabalho do dia a dia, os modelos de fronteira estão suficientemente próximos para que escolher entre eles seja atirar uma moeda ao ar; o que resta é rápido contra profundo, e essa é uma escolha que fazes tarefa a tarefa, não um ranking. A pergunta da ferramenta obceca com a primeira camada e mal menciona as outras duas, e são as outras duas que decidem o resultado.

A mesma ferramenta, duas mãos

Dá a mesma ferramenta a dois programadores e obténs dois resultados diferentes. Um especifica o problema, lê o que sai, apanha o sítio onde correu mal e corrige. O outro aceita o que quer que apareça. Fixa a ferramenta e os resultados divergem. Fixa a pessoa, faço-o de cada vez que troco de modelo, e quase nada mexe. Essa assimetria diz-te onde pôr a tua atenção.

Andar a saltar de ferramenta em ferramenta também tem um custo, e paga-se exatamente nessa atenção. Cada troca põe alguma coisa a zeros. Voltas a aprender as manias e reescreves as tuas instruções, e o ganho é pequeno e não dura. Entretanto, aquilo que compõe juros fica intocado, porque andavas entretido às compras. O programador que escolhe uma ferramenta suficientemente boa e vai fundo no loop ultrapassa o que anda sempre a migrar.

Onde a ferramenta importa mesmo

Nada disto quer dizer que a ferramenta não é nada, e a versão preguiçosa deste argumento finge que é. A categoria importa muito. Um autocomplete que termina a tua linha, um agente de terminal que edita um repo inteiro e abre um pull request, e um runner que apontas a uma tarefa e deixas a trabalhar sozinho são instrumentos diferentes, e tratá-los como substitutos é a forma como as pessoas acabam desiludidas.

Nos problemas mais difíceis, os que não cabem bem num benchmark, a diferença entre um setup forte e um fraco é entregares ou não entregares, e a maior parte dessa diferença é o harness e o loop, não o nome no modelo. Se o teu trabalho vive numa plataforma, a ferramenta nativa dela pode ganhar só pela integração. Até a velocidade que referi é uma diferença real, não um gosto; parte da competência é saber quando uma tarefa precisa do modelo rápido e quando precisa do lento.

"Aprende os fundamentos e pronto" é uma resposta igualmente vazia quando quer dizer ignora as ferramentas. As ferramentas amplificam os fundamentos. É por isso que os fundamentos compensam, e isso não é licença para ignorares aquilo com que estás a amplificar.

E depois há a fatura

O sítio onde a ferramenta mais importa não tem nada a ver com qual modelo é mais inteligente. É o preçário. Durante muito tempo vivi numa ferramenta que cobrava um preço fixo, e usei-a com força, o dia todo, todos os dias, e a fatura nunca mexeu. Sabia exatamente quanto custava um mês. Depois o preçário mudou debaixo de mim, de fixo para ao consumo, e o mesmo trabalho de sempre começou a somar mais de mil euros numa única semana. Nada na minha competência ou no meu loop tinha mudado, só o contador.

Uma mudança de preço é uma razão a sério para trocar, e é o oposto de correr atrás de novidades. Mudei para uma ferramenta com um teto previsível, a correr os mesmos modelos que eu já preferia, e a minha fatura voltou a um número com que podia planear. Bato num limite de vez em quando. Não tenho saudades das semanas de mil euros. As ferramentas que deixei continuam a cobrar um prémio exatamente pelos modelos que eu quero, o que é um bom negócio para elas e um mau negócio para mim.

Quem já correu coisas na cloud já viu as duas metades disto. A fatura que passa a ser ao consumo e depois te surpreende. A capacidade com que não podes contar por inteiro: a instância que não arranca na tua região, o limite em que bates exatamente à hora errada. A cloud passou uma década a ensinar engenheiros a vigiar o contador, a pôr tetos onde conseguem e a nunca se amarrarem tanto a um fornecedor que sair signifique reescrever tudo. As ferramentas de IA estão no início da mesma história, e a lição transfere-se diretamente.

Por isso, quando alguém te diz que a ferramenta não importa, esta é a parte que está a deixar de fora. A inteligência converge e o harness importa, mas as condições do negócio podem importar mais do que qualquer um dos dois. Não só o preço e a capacidade, mas a licença que muda debaixo de ti, e a política de privacidade que começa a ler o teu código para o conjunto de treino do próximo modelo. São alavancas que um fornecedor pode puxar de um dia para o outro sem tocar numa linha tua, e todas elas já foram puxadas a alguém nos últimos anos. É esse o verdadeiro argumento para manteres o teu loop portátil. Não para correres atrás de um leaderboard, mas para que, no dia em que o negócio muda, possas ir-te embora.

A versão boa da pergunta

A versão boa da pergunta da ferramenta tem resposta, porque nomeia as suas restrições. Melhor para refactors grandes que têm de caber num só contexto. Melhor com um orçamento mensal fixo. Melhor para código que não pode sair das nossas máquinas. Melhor na linguagem em que trabalhamos de facto. Essas têm respostas. "Qual é a melhor ferramenta de IA para programar" não tem, porque nunca diz melhor em quê. Por isso decompõe-na, e troca de propósito em vez de por impulso: quando tiveres nomeado uma capacidade que te falta e feito uma comparação justa. Guarda também um bocado de tempo para reconhecimento, a ver o que as pessoas em quem confias adotam de facto, porque a troca que mais importa é às vezes para uma categoria que não sabias que existia.

Escolhi o meu setup desta forma e depois, no essencial, deixei de pensar nele. As instruções do projeto, as specs e os hábitos de revisão transitam todos; só o modelo por baixo muda com a tarefa. As ferramentas que construí inclinam-se para o mesmo lado: um pipeline que transforma uma frase num plano e abre os seus próprios pull requests, um control plane que governa frotas de agentes. Nenhuma delas quer saber que modelo está por trás. São andaimes à volta do mesmo loop.

E isto vai mais longe do que as minhas próprias ferramentas, porque a maior parte do que parece um produto de IA novo é construído sobre modelos de fronteira que qualquer um pode alugar. Ajudei a construir produtos que fazem trabalho a sério em direito, em saúde, em investigação científica e em auditoria, e nenhum deles corre num motor secreto. Lá dentro há um pipeline: vários passos com as suas próprias dependências, muitas vezes modelos diferentes em passos diferentes por razões diferentes, um rápido onde a restrição é a latência, um profundo onde é o raciocínio, a mesma divisão que faço na minha secretária. Mas todos os modelos na cadeia saem do mesmo menu curto de onde os concorrentes também pedem. O que faz com que valha a pena pagar por estes produtos é tudo o que está à volta dos modelos: o retrieval sobre fontes que importam de verdade, o grounding que mantém uma resposta presa a essas fontes, o fluxo de trabalho moldado à forma como a profissão funciona a sério. Os modelos não são vantagem defensável de ninguém. O valor acumula-se à volta deles, não dentro deles, e essa é a mesma lição a outra altitude.

O que fica mesmo contigo

Portanto corre atrás de uma ferramenta durante uma semana se quiseres, e depois torna-te bom. O modelo que usas vai ser substituído por um genuinamente melhor num calendário que não controlas, e mesmo assim não vai salvar o programador que nunca aprendeu a especificar nem a ler. A forma como pensas um problema até ao fim e o olho que apanha a linha errada continuam teus em todas as trocas. Um destes vale a pena construir. O outro merece uma semana da tua atenção, e uma porta de saída que manténs aberta.