Tratar contexto como código: essa é a tese central apresentada por Patrick Debois na QCon London, em 30 de setembro. O pioneiro do DevOps e líder de Product DevRel na Tessl propôs aplicar ao contexto de agentes de IA as práticas consagradas da engenharia de software: testes, CI/CD, gerenciadores de pacotes e varredura de segurança.
Debois, organizador do AI Native DevCon, definiu o que chamou de Ciclo de Vida de Desenvolvimento de Contexto, em paralelo direto ao SDLC tradicional. O loop tem quatro fases: gerar, avaliar, distribuir e observar. Cada uma ganhou equivalente técnico no mundo dos agentes.
Info: Debois não falou de engenharia de contexto dentro do agente (o que entra na janela do LLM), mas de contexto como artefato versionável e distribuível para toda a organização.
Como gerar e avaliar contexto de agentes de IA?
A geração de contexto começa no famoso arquivo AGENTS.md, que virou padrão de fato da indústria, segundo Debois. O curioso: o Claude segue usando CLAUDE.md, com um PR aberto sobre o tema. Ferramentas como Context7 e Ref puxam automaticamente documentação das bibliotecas usadas no projeto, na versão correta.
Além de regras e docs, surgiram as especificações soltas: Kiro trata isso como task specification, o SpecKit como features permanentes do projeto, e a proposta de intent integrity de Baruch permite verificar specs durante a execução. Conectores via MCP, protocolo que recentemente ficou stateless na AWS, permitem aos agentes buscar contexto em fontes como Slack.
# publicidade
Testes e evals substituem o TDD
Na avaliação, o equivalente aos testes são os evals inspirados no SWE-bench, mas adaptados para quem não treina modelos, apenas constrói contexto. Debois escalou quatro níveis: linting de metadados YAML das skills, feedback de estilo via LLM-as-a-judge (um "Grammarly para contexto"), testes funcionais do objetivo da skill e testes end-to-end no repositório real, a partir de um commit e um prompt.
A Vercel já testa quais informações cada modelo novo precisa para acertar com sua biblioteca. O problema: resultados são não determinísticos. A solução proposta, análoga a error budgets de SRE, é rodar o teste cinco vezes, definir evals críticos que precisam passar e aceitar erraticidade em outros, com o product owner decidindo o go-live.
# fluxo típico de teste de contexto em CI
run_evals --skill./skills/onboarding.md \
--baseline sem-contexto \
--comparar versao-antiga versao-nova \
--runs 5 --threshold Dica: quando o Claude Code errar algo na sua sessão, transforme o erro em test case: escreva o eval sem contexto, depois com o contexto melhorado, e confirme a correção antes de distribuir.
Distribuir contexto como pacote: registries, scanning e proveniência
copiar contexto no Slack não é compartilhamento, é gambiarra. Debois defendeu registries de contexto com gerenciadores de pacotes: instala-se a versão exata da skill, com versionamento, como um pacote npm. As skills, segundo ele, caminham para virar o "JAR" do contexto, formato suportado pelos principais fornecedores de agentes: a mesma padronização que o setor busca com o AGENTS.md se repete aqui, tema que o portal já explorou ao mostrar por que a engenharia de contexto é o futuro da IA.
Distribuição exige confiança. Skills contêm código, e o caso OpenClaw expôs o risco de skills maliciosas. A Snyk já lançou um scanner de contexto. Debois defendeu ainda um AI Bill of Materials: quem criou o contexto, quando e por quê, com proveniência capturada via anotações no Git, distinguindo linhas escritas por humanos e por IA.
Context flywheel é o ciclo em que melhorias de contexto geradas na prática voltam ao registry e beneficiam todos os agentes da organização.
Observabilidade, dark factories e o novo papel do desenvolvedor
A fase de observar inclui agentes que reescrevem o próprio contexto com base em falhas registradas nos logs, abordagem que a Hugging Face chama de retrospectiva, um post-mortem do agente. Padrões de logs abertos, análogos ao OpenTelemetry, começam a surgir, com a Devin construindo loops de autorreflexão.
Ferramenta citada como destaque: a Hud instrumenta código em produção e alimenta o agente com lições aprendidas de incidentes reais. Debois demonstrou ainda um "firewall de contexto" via interceptação de leituras de disco, inspirado em eBPF, para auditar o que o agente carrega, incluindo vetores como exfiltração por DNS.
Sobre as chamadas dark factories, onde specs entram e software sai sem humanos, Debois foi cético: autonomia não é o objetivo, e os praticantes dessas fábricas usam gêmeos digitais de Google, Okta e Jira para simular observabilidade. Ele listou quatro estilos de gestão de agentes, do microgerenciamento ao on-call por conflito, e defendeu que o gestor deve escolher o estilo conforme o risco, como já ocorre com o gerenciamento de agentes de IA com contexto e memória que redefinem o papel do prompt engineering.
Atenção: context drift é um problema ainda sem solução, alertou Debois. Modelos mudam e contexto de um ano atrás pode perder eficácia; versões antigas e novas convivendo em times diferentes seguem sem resposta da indústria.
Na visão de Debois, o desenvolvedor migra de papel: vira operations dos agentes, arquiteto de QA ao escrever especificações, product owner ao decidir o que construir e, ao final, gestor de dados que transforma contexto em conhecimento organizacional. O diferencial competitivo das empresas, concluiu, pode deixar de ser o código e passar a ser o contexto certo: os agentes são o motor, e o contexto é o combustível.
Fonte: Infoq
