Engenharia com IA

Padrão que a máquina consome

ligações 9

Padrão de código escrito para humano tem um problema conhecido: ninguém lê na hora que importa. Padrão escrito para agente tem outro, mais silencioso: ele continua parecendo correto depois de ficar errado. Um documento que ensina um método cuja assinatura mudou não quebra nada. Ele só ensina errado, para todo mundo, indefinidamente.

Foi resolvendo esses dois problemas que o padrão da casa virou infraestrutura em vez de documento.

Uma fonte, vários consumidores

A regra vive escrita uma vez, em formato neutro, sem saber qual ferramenta vai consumi-la. Cada ferramenta de IA tem um adaptador fino que traduz aquilo para o formato que ela entende. Acrescentar uma ferramenta nova amanhã é escrever um adaptador, não reescrever os padrões.

Isso resolve um problema real de mercado: as ferramentas de IA não convergiram num formato de instrução, e provavelmente não vão tão cedo. Amarrar o padrão da casa ao formato de um fornecedor é comprar uma migração futura.

Há também duas audiências com necessidades opostas, e tratá-las igual estraga as duas. Agente precisa de regra imperativa, exemplo compilável e a consequência de errar. Humano precisa de narrativa, do porquê da decisão e do contexto histórico. São arquivos diferentes, com o mesmo assunto.

O que impede o padrão de apodrecer

Esta é a parte de que eu mais gosto, e a ideia é simples: existe um projeto que consome cada API citada pelos padrões, e compilar é a asserção. Se o padrão descreve um método que não existe mais, não é um documento que fica desatualizado em silêncio — é um build que fica vermelho.

Combinado com atualização automática de dependência e uma execução periódica, “o padrão apodreceu” deixa de ser uma descoberta constrangedora em revisão de código e vira um PR vermelho. O drift não nasce de commit no repositório de padrões: nasce de um pacote mudar lá fora, e por isso a verificação precisa rodar mesmo quando ninguém mexeu em nada.

O mecanismo não cobre tudo, e vale dizer: prosa e justificativa não são verificáveis assim, e política — “não usamos tal biblioteca” — não é uma afirmação sobre o mundo. Ele cobre a categoria mais perigosa, que é a afirmação técnica concreta que envelhece sem avisar.

Skills apontando para as minhas ferramentas

Padrão que descreve o que fazer é metade. A outra metade é a skill que executa o caminho certo, usando os CLIs de Ferramenta como CLI.

São 11 habilidades e 20 regras de padrão distribuídas, em duas camadas:

  • No nível do usuário, o que vale para qualquer projeto: o ritual de merge request, como abrir sessão de banco, como ler log de serviço, o mapa do parque como base consultável
  • No nível do projeto, o que só vale ali: a arquitetura daquele repositório, a armadilha conhecida daquele domínio, o que não fazer

Mais 5 ganchos, que são a camada que age sem eu pedir: verificação mecânica antes do commit, recusa de dado pessoal, e a captura do atrito que alimenta O ciclo que se alimenta. Cada gancho existe em par, porque o time trabalha em dois sistemas operacionais — e um gancho que só roda em metade das máquinas é pior que gancho nenhum: cria a expectativa de proteção sem entregá-la.

O contexto da máquina também é dividido assim: há uma parte comum a todo mundo e uma parte por sistema operacional, porque o que o agente precisa saber sobre onde ficam as coisas muda entre eles — e escrever “depende do seu sistema” dentro de um arquivo só é jogar a decisão para o agente na hora errada.

A divisão entre o que é sempre carregado e o que é lido sob demanda importa mais do que parece. Contexto sempre carregado entra em toda requisição, então ele fica curto e contém só o que vale para qualquer edição. Enfiar tudo ali gastaria contexto em toda conversa para entregar regra de API a quem está editando teste.

O que isso substituiu

Antes, o padrão da casa era um conjunto de regras escritas e versionadas, citáveis em revisão. Isso já era melhor do que padrão combinado, pelo motivo descrito em Revisão de código e padrão: com regra escrita o apontamento é “isto contraria a regra X”, e sem ela é “eu faria diferente”.

O que mudou é que a regra deixou de depender de alguém lembrar de aplicá-la. Ela chega junto com o código, no momento em que o código está sendo escrito.

Ver também

Engenharia com IA · O ciclo que se alimenta · Revisão de código e padrão · Qualidade e engenharia de contexto · Suíte PMQ

Pablo Mickael Quevedo Senior Software Engineer · autor principal de 32 sistemas · Novo Hamburgo, RS

9 notas ligadas a esta

A vizinhança desta estrela no céu do portfólio.

Explorar a galáxia →