O ciclo que se alimenta

As outras peças do sistema são estáticas: alguém precisa escrever o CLI, alguém precisa escrever a skill. Esta é a peça que produz as outras.

A pergunta que ela responde é: o que garante que o ferramental melhore sem eu ter que parar para melhorá-lo? Porque parar para isso é exatamente o que nunca acontece quando há entrega para fazer.

O ciclo

A barra de entrada é o que faz funcionar

Só entra no dicionário o que custou mais de uma tentativa e cujo sintoma apontava para a causa errada. Não entra erro de digitação, não entra o que o próximo descobriria de primeira.

Essa barra é a diferença entre um diário útil e uma lista de tudo que deu errado. Lista de tudo que deu errado ninguém relê, e o que ninguém relê não vira nada.

O cruzamento é onde está o valor

Registrar o problema não serve para lembrar do bug. Serve para que os padrões apareçam: lendo o acumulado dá para ver que uma classe inteira de problema tem origem comum, e aí o conserto certo é na origem, não no caso.

Esse cruzamento é automático. O sistema detecta a repetição, identifica que aquilo virou conhecimento recorrente em vez de acidente, e propõe a skill que resolve a classe inteira. Eu reviso e aprovo. É o único ponto do ciclo onde eu entro, e entro julgando, não executando.

Um caso real, ponta a ponta

O melhor exemplo do ciclo fechando não foi um problema. Foram três, que não pareciam o mesmo.

Primeiro sintoma. Uma instalação de pacote falhou dizendo que não resolvia o host. Logo depois, qualquer curl passou a responder HTTP 200 — com o HTML de uma página de login no corpo. Passei por “o gerenciador de pacotes quebrou” e por “problema de DNS” antes de chegar na causa: a sessão do appliance de borda da rede tinha expirado, e o portal cativo interceptava tudo respondendo 200. Umas oito tentativas. A hipótese errada era razoável — o primeiro erro era de resolução de nome.

Segundo sintoma, dias depois. Um build de aplicativo mobile não resolvia uma dependência, e curl no mesmo host funcionava. Isso não faz sentido até você descobrir que o mesmo appliance faz inspeção TLS seletiva — interceptava o repositório de artefatos de um fornecedor e não interceptava o repositório público da linguagem — e que cada ferramenta escolhe seu próprio truststore: o curl usa o do sistema operacional, onde a CA corporativa está instalada; o build usa o do JDK, onde não está. Três tentativas.

Terceiro sintoma. O aplicativo no emulador travava em “sem conexão”, e parecia bug do aplicativo. Derrubei duas hipóteses de framework antes de achar: o sistema operacional roda uma sonda HTTPS de validação de rede, a sonda falhava contra a CA corporativa, e o sistema marcava a rede como conectividade parcial. Sem a marca de rede validada, a biblioteca do aplicativo apenas repetia o que o sistema dizia. Umas dez tentativas.

O cruzamento. Três incidentes, três sintomas sem parentesco aparente — resolução de nome, build, conectividade de emulador. Nenhum deles, sozinho, revelava o padrão. Foi lendo o acumulado que apareceu: é o mesmo appliance, com três faces. Uma classe inteira de problema, não três acidentes.

O que virou. Uma skill de rede que o agente carrega sozinho quando um sintoma dessa família aparece. Ela descreve as três faces, explica por que curl funciona e o build não, e traz o procedimento de cada caso — inclusive onde fica a CA exportada, para instalar no truststore certo.

O custo antes e depois. Somando os três incidentes, mais de vinte tentativas e um dia perdido em diagnóstico que passou por gerenciador de pacotes, DNS, framework e bug de aplicativo — nenhum deles a causa. Hoje, o sintoma é reconhecido na primeira mensagem da conversa, e a resposta vem com o procedimento junto.

E um caso onde o ciclo não produziu skill

Vale mais que o anterior, porque mostra que a etapa de julgamento existe de verdade.

Havia um problema recorrente: comandos comuns falhando com “command not found”, incluindo utilitários básicos do sistema. Parecia pacote faltando. A causa real era o PATH do shell colapsando de vez em quando e perdendo até os diretórios padrão do sistema. Aconteceu doze vezes, em cinco projetos diferentes, ao longo de um mês antes de eu registrar.

Doze reincidências é exatamente o padrão que faz o sistema propor uma skill. Eu revisei e decidi que não vira skill. Skill entrega conhecimento a um agente; o problema aqui não é falta de conhecimento, é o ambiente quebrando. Uma skill dizendo “quando sumir o PATH, reexporte o PATH” seria automatizar a convivência com um defeito em vez de consertá-lo — e pior, faria o defeito parecer resolvido.

O registro continua no dicionário, marcado como revisado, e é isso que ele deve ser: um diagnóstico conhecido esperando conserto na origem. Nem todo atrito recorrente é oportunidade de ferramenta. Alguns são só dívida esperando alguém assumir, e a diferença entre os dois é a única coisa no ciclo que não dá para automatizar.

Por que isso é a peça que importa

Todo mundo que trabalha com agente acumula aprendizado sobre como fazer o agente funcionar. Na prática esse aprendizado fica na cabeça, ou num arquivo de anotação que envelhece, e cada pessoa da equipe reaprende do zero.

Transformar aprendizado em artefato executável é o mesmo princípio que produz biblioteca compartilhada em vez de código duplicado, e template de entrega em vez de pipeline copiado. O que se repete é extraído para um lugar só. A diferença é que aqui o que se extrai é conhecimento, e o lugar só é uma ferramenta que o agente carrega sozinho da próxima vez.

É também a razão de o sistema ficar melhor com uso em vez de piorar. Ferramental que só um humano mantém decai, porque manter não é urgente. Ferramental que se alimenta do próprio atrito melhora exatamente nos pontos onde ele está doendo.

O limite

O ciclo depende de eu continuar aprovando com critério. Skill gerada e aprovada no automático vira ruído acumulado, e ruído acumulado no contexto degrada o resultado de tudo. A aprovação é o portão, e ele só funciona enquanto eu levar a sério.

E ele só enxerga o atrito que aparece durante o trabalho com agente. Problema que eu resolvo de cabeça, sem passar pela ferramenta, não entra — e é justamente a classe de problema que eu já domino bem demais para notar que custou algo.

Ver também

Engenharia com IA · Padrão que a máquina consome · Ferramenta como CLI · Como eu depuro