Padrões de Equipe Como Infraestrutura, Não Como Tradição Oral

Rahul Garg, engenheiro principal na Thoughtworks, publicou na semana passada o quarto padrão da série “Reducing Friction in AI-Assisted Development” no site de Martin Fowler. O título: Encoding Team Standards. A tese central: padrões de equipe devem ser codificados em arquivos de instrução versionados nos repositórios, não deixados como conhecimento tácito na cabeça de engenheiros seniores.

É uma ideia correta. E chega dois anos atrasada para quem já opera dessa forma.

O problema real que Garg identifica

O ponto de partida é um diagnóstico preciso. Dois desenvolvedores na mesma equipe, usando a mesma ferramenta de IA, produzem código materialmente diferente. O sênior embute padrões instintivamente nos seus prompts. O júnior não sabe quais padrões existem.

Pesquisa confirma a magnitude do problema. Mu et al. demonstraram que o output de modelos de linguagem varia até 76 pontos de acurácia dependendo apenas da formatação do prompt. Não do conteúdo. Da formatação. Outro estudo (arXiv 2508.03678) documenta que programadores novatos omitem detalhes que experts incluem por reflexo. O conhecimento que faz a diferença é precisamente o conhecimento que não está documentado em lugar nenhum.

Garg propõe uma solução em quatro elementos: definição de papel para o agente, requisitos de contexto, padrões categorizados (críticos versus consultivos) e formato de output. O processo começa com entrevistas com engenheiros seniores para extrair o conhecimento tácito. O resultado vai para arquivos de instrução que vivem no repositório da equipe, versionados pelo git.

A frase-chave do artigo: “Um prompt na máquina individual é um hack de produtividade. O mesmo prompt no repositório da equipe é infraestrutura.”

Concordo com a distinção. O enquadramento que vem depois é que fica aquém.

O que está certo

Três contribuições do artigo merecem atenção.

Primeiro, o processo de extração. Garg descreve como entrevistar seniores para transformar intuição em instruções explícitas. O valor aparece antes mesmo das instruções existirem. Em um caso que ele relata, o processo de entrevista revelou que dois engenheiros seniores da mesma equipe tinham limiares diferentes de severidade de segurança. Nenhum dos dois sabia. Ambos achavam que a equipe estava alinhada.

Dívida organizacional tornada visível. Isso tem valor independente de qualquer ferramenta de IA.

Segundo, a categorização. Separar padrões em “críticos” (devem ser seguidos sempre) e “consultivos” (recomendados, não obrigatórios) reconhece que nem toda regra tem o mesmo peso. Como exploramos em Especificações para Agentes de IA São Artefatos de Governança, esse modelo de dois níveis espelha o padrão Sempre/Pergunte/Nunca que emerge em todo sistema de controle para agentes.

Terceiro, o posicionamento no repositório. Instruções versionadas no git são diffáveis, auditáveis e sujeitas a revisão de código. São infraestrutura. É a mesma tese que defendemos em Seu Guia de Estilo É uma Camada de Governança: o momento em que um padrão sai de um documento de referência e entra em um arquivo executável por máquina, ele muda de natureza. Deixa de ser sugestão e passa a ser controle.

O que está ausente

O artigo tem lacunas significativas. Vale examiná-las porque iluminam a distância entre tratar o tema como tooling de desenvolvedor e tratá-lo como governança organizacional.

Zero evidência quantitativa. O artigo é inteiramente baseado em asserções. “Equipes que fizeram X relataram Y.” Sem números, sem métricas, sem estudos de caso detalhados. Para uma publicação no ecossistema Fowler, que historicamente preza por rigor, a ausência é notável.

Sobreclaim de novidade. Linters, CI pipelines e pre-commit hooks codificam padrões de equipe há décadas. A extensão para instruções de IA é uma evolução natural, não uma mudança de paradigma. Garg menciona brevemente as ferramentas existentes mas não as posiciona na mesma categoria conceitual. Quem já usa CLAUDE.md, como descrevemos em CLAUDE.md: O Manual de Instruções do Seu Assistente de Código, reconhece o padrão de imediato.

Feedback loop inexistente. O fluxo proposto é unidirecional: extrair conhecimento, codificar em instruções, aplicar. Sem mecanismo para detectar quando instruções produzem resultados ruins. Sem métrica de conformidade. Sem evolução baseada em dados. É governança sem observabilidade.

Política organizacional ignorada. De quem é o conhecimento que está sendo codificado? Quando dois seniores discordam (como o próprio artigo ilustra), quem decide qual versão prevalece? Garg trata o conflito como algo positivo (torna o desacordo visível) mas não propõe como resolvê-lo. Em qualquer organização real, essa é a pergunta que define se a iniciativa funciona ou trava.

Realidade multi-ferramenta ausente. Equipes usam Claude, Copilot, Cursor, Gemini. Cada ferramenta tem formato próprio de instrução. Garg não aborda como manter consistência entre formatos diferentes. É como propor padronização de código sem mencionar que a equipe usa três linguagens.

O enquadramento que falta

O artigo permanece dentro do universo de “ferramentas de desenvolvedor.” Instruções para assistentes de IA. Produtividade de equipes de engenharia. O repositório como local de verdade.

É um enquadramento correto mas incompleto. O mesmo padrão se aplica a qualquer domínio onde agentes de IA operam: marketing, design, jurídico, operações. Quando uma equipe de conteúdo codifica suas regras de voz em instruções para um agente, como exploramos em Seu Guia de Estilo É uma Camada de Governança, está fazendo exatamente o que Garg descreve. Extrair conhecimento tácito de profissionais experientes, codificá-lo em formato executável, versionar no repositório da equipe.

A Thoughtworks publicou em 2026 o relatório Looking Glass, que advoga por “governança computacional.” O conceito é mais ambicioso que o artigo de Garg: governança que é executada por sistemas, não apenas documentada para humanos. As instruções de equipe são uma instância desse conceito. Mas o artigo não faz a conexão com o próprio framework da empresa.

Existe uma progressão natural que o artigo não percorre. Instruções versionadas são o primeiro passo. Skills modulares e versionadas são o segundo. Integração com sistemas de observabilidade é o terceiro. A camada de governança que já existe na disciplina de engenharia fornece o quarto. E enforcement em tempo de revisão é uma camada complementar, não alternativa.

Garg para no primeiro passo. É um bom primeiro passo. Mas quem já opera com agentes em produção sabe que versionamento sem observabilidade é como ter leis sem tribunal.

A validação que importa

Há algo valioso em ter o ecossistema Thoughtworks/Fowler chegando a essa conclusão. Martin Fowler é referência para uma geração de engenheiros de software. Quando a série “Reducing Friction in AI-Assisted Development” propõe que instruções para IA sejam tratadas como infraestrutura, isso legitima o que equipes menores vêm construindo sem a cobertura institucional.

Para equipes brasileiras, o sinal é especialmente relevante. A adoção de ferramentas de IA no Brasil é rápida. A formalização dos padrões de uso, nem tanto. O artigo de Garg fornece vocabulário e framework para uma conversa que muitas equipes precisam ter: quem define as regras que os agentes seguem? Onde essas regras ficam? Como elas evoluem?

Se sua equipe ainda opera com cada desenvolvedor usando instruções pessoais, o artigo é um ponto de partida válido. Se já versiona instruções no repositório, o próximo passo é observabilidade: medir se as instruções produzem os resultados esperados. Se já tem observabilidade, a pergunta é escala: as instruções funcionam para uma equipe de cinco. Funcionam para cinquenta?

O que fazer com isso

Três perguntas para equipes que querem avançar além do que o artigo propõe.

Onde vivem seus padrões hoje? Se estão na cabeça de engenheiros seniores, o processo de extração que Garg descreve é o primeiro passo. Se estão em wikis, o passo é torná-los executáveis. Se já são executáveis, o passo é medir conformidade.

Quem é dono? Não dos padrões. Da decisão sobre os padrões. Quando dois seniores discordam sobre tratamento de erros, quem decide? Sem essa resposta, o arquivo de instruções vira outro wiki que ninguém atualiza.

Como você sabe se funciona? Se não consegue medir a conformidade do output com as instruções, não tem governança. Tem documentação com um nome diferente.

A série de Garg no martinfowler.com vale a leitura completa. Os quatro padrões (Knowledge Priming, Design-First Collaboration, Context Anchoring, Encoding Team Standards) formam um framework coerente para equipes começando a formalizar o uso de IA. O limite é que param na formalização. Governança executável exige ir além.

Fontes

Garg, Rahul. “Encoding Team Standards.” Março 2026.
Mu, Jesse et al. “The Impact of Prompt Programming on Function-Level Code Generation.” Dezembro 2024.
Thoughtworks. “Looking Glass 2026.” 2026.

Victorino Group ajuda organizações a construir infraestrutura de governança que torna a consistência da IA uma propriedade do sistema, não uma dependência de pessoal: contato@victorino.com.br | www.victorino.com.br