O Hábito Que Fica Mais Barato

O primeiro skill custa caro. O décimo sexto é de graça.

Até maio deste ano meu código com IA não seguia padrão nenhum.

Abria uma conversa e pedia o que eu queria daquele jeito. Na conversa seguinte, sobre um problema parecido, pedia de outro jeito, porque não lembrava como tinha pedido da última vez. O agente respondia bem às duas formas, e por isso eu nunca via o custo de não ter uma forma só.

O código funcionava. Mas tinha a mesma função escrita de três maneiras diferentes em três arquivos diferentes, porque cada conversa resolvia o problema do zero, sem saber que a solução já existia em outro lugar. Quase nada de teste. Quase nenhuma documentação, porque documentar era mais uma coisa que eu tinha que lembrar de pedir, e eu não lembrava.

Eu tinha construído um Frankenstein e demorei para admitir isso, porque cada pedaço, sozinho, parecia bom.

A saída não foi ideia minha. E o que aprendi com ela cabe numa frase: O primeiro skill custa caro. O décimo sexto é de graça.

Copiei o processo de outro programador

Matt Pocock é programador inglês, autor de um dos cursos mais conhecidos de TypeScript, já trabalhou na empresa que faz o Next.js e hoje ensina programadores a trabalhar com IA. Antes disso foi coach de voz.

Ele publicou uma coleção de arquivos descrevendo como transformou os próprios processos de engenharia de software em algo que o agente segue sempre do mesmo jeito. Ele chama cada arquivo desses de skill - habilidade: uma tarefa que o agente aprende uma vez e ninguém precisa explicar de novo. Um para escrever a especificação do que vai ser feito. Outro para planejar as etapas. Outro para desenvolver escrevendo o teste antes do código. Outro para investigar quando algo quebra.

A frase dele que ficou comigo: fez isso para parar de "programar por vibração" e voltar a fazer engenharia de verdade. A palavra que ele usa para descrever essas ferramentas é compostas - pequenas, fáceis de adaptar, feitas pra trabalhar juntas.

Não inventei nada. Copiei o formato dele e passei duas semanas adaptando para o meu jeito de trabalhar, testando cada skill em código de verdade, não em exemplo de brinquedo.

Não saiu pronto na primeira versão. Troquei o nome de dois deles porque o nome original prometia uma coisa e o skill fazia outra. Ajustei a ordem das etapas depois de ver onde o agente travava. Tirei um passo que não servia para nada e coloquei outro que faltava, sobre como registrar a decisão de arquitetura antes de escrever a primeira linha.

Hoje uso essa família de skills toda vez que escrevo código com IA. Cada um ensina o agente a fazer uma etapa específica, sempre do mesmo jeito, sem eu explicar de novo, e a função duplicada em três lugares virou exceção, não regra.

Achei que tinha resolvido o problema de vez. Só entendi o tamanho real do que tinha construído quando vi outra pessoa chegar no mesmo lugar, sozinha, sem ter lido o post de ninguém.

De dois para dezesseis, em uma semana

Uma mentorada minha chegou nesse método pelo caminho mais honesto: o do custo. Numa quarta-feira, estourou a cota do plano de IA que usava - estava pedindo tudo ao modelo mais caro, do jeito que vinha à cabeça. Na quinta, já tinha trocado de plano, do próprio bolso, sem pedir licença a ninguém. A sessão de mentoria daquela semana virou uma conversa sobre economia de operação, e o método de treinar o agente saiu dessa conversa: a disciplina não nasceu de convicção, nasceu de conta.

Foi ali que ela aprendeu a criar skills, ao vivo, comigo. O jeito que ensinei foi este: primeiro ela roda a tarefa uma vez de mão, conduzindo o agente passo a passo, sem pedir nada pronto. Depois roda de novo, para conferir o que saiu e ajustar o que não serviu. Só na terceira vez cria o skill que guarda aquilo. E roda mais duas, ajustando os detalhes que só aparecem quando a tarefa é de verdade, não de ensaio.

Cinco execuções antes de o skill virar coisa definitiva. Ninguém cria um desses de primeira, nem ela, nem eu. As primeiras tentativas dela não vingaram - "não sei por que as primeiras que eu fiz não deram certo", ela me contou - e das duas que ficaram, precisou olhar a tela para lembrar quais eram.

Ela não é de tecnologia, é médica e opera a própria clínica. Um dos primeiros skills que criou resolvia um problema pequeno: fechava o computador no fim do dia e não lembrava onde tinha parado, então pediu ao agente para resumir cada sessão automaticamente.

Uma semana depois eu estava olhando a tela dela, checando uma lista, e contei.

-Só você tem dezesseis skills.

-Aprendi a usar e estou usando bastante.

Não sentou um domingo para planejar uma coleção. Foi cada tarefa que se repetiu virando um skill, uma de cada vez, ao longo da semana, sem que a semana anterior a tivesse preparado para isso.

-Nem lembro mais porque começou com uma coisinha pequena e foi fazendo assim.

A fala era sobre outra coisa: uma pasta que tinha crescido do mesmo jeito, na mesma conversa.

Dois para dezesseis. Em sete dias. Sem ela ter trabalhado mais horas que na semana anterior, e sem ter decidido, num único momento, "vou automatizar minha operação".

Composição, não soma

Se fosse esforço acumulado, dezesseis skills custariam oito vezes o que dois custaram. Não foi isso que aconteceu, nem no meu caso, nem no dela. Composição, aqui, é no sentido dos juros compostos: cada skill rende em cima do que os anteriores já pouparam, e o ganho acumula em curva, não em linha reta.

O primeiro skill dá trabalho. Você precisa explicar a tarefa inteira, do zero, para o agente entender o que vale a pena gravar e o que é detalhe daquele dia. O segundo já é mais rápido, porque você aprendeu como pedir e o que o agente costuma esquecer sozinho. No décimo, virou reflexo: termina uma tarefa que se repetiu pela terceira vez e já pergunta, sem pensar muito, se vale virar skill.

Cada skill novo reduz o custo do seguinte. A tarefa continua do mesmo tamanho; o que fica mais barato de acionar é o hábito de transformar repetição em ferramenta.

E não precisa ser skill, nem código. Vale para o modelo de e-mail que você refina toda vez que escreve um parecido, para a pergunta que você aprendeu a fazer melhor depois da terceira vez que pediu a mesma análise. A diferença entre repetir e compor está em guardar o que funcionou, em algum lugar que não seja só a sua memória.

É o mesmo motivo pelo qual a minha própria família de skills ficou melhor depois de pronta, não antes. Eu não sabia, em maio, o que ia precisar ajustar em agosto. Ninguém sabe de antemão o que vai precisar corrigir. A composição não depende de acertar tudo na primeira tentativa. Depende de manter o hábito ligado depois que o primeiro acerto pequeno já compensou o esforço de criá-lo.

O que sobra

Ninguém constrói dezesseis coisas de uma vez, e ninguém deveria tentar. Constrói uma, sente o alívio pequeno de não ter que explicar aquilo de novo, e a segunda já fica mais barata. Depois a terceira. A conta não é de soma.

O primeiro skill custa caro. O décimo sexto é de graça.

O que separa quem tem dois skills de quem tem dezesseis é ter continuado dando o próximo passo depois que o primeiro já se pagou. A maioria para ali, satisfeita com o primeiro.

Qual é o seu primeiro?

Escrevo sobre isso toda semana. Assine a newsletter Construir com IA e receba a próxima direto no e-mail.