A IA gera código em velocidade de máquina, mas a compreensão, a intenção, o comportamento, o raciocínio arquitetural, não acompanha. A resposta é um context store versionado que humanos e agentes consultam, combinando especificação, testes e funções de aptidão em um único sistema de verificação.
A lacuna de contexto entre código gerado por IA e compreensão humana é um problema crítico para a evolução arquitetural.
Um context store, registro versionado de intenção, comportamento e conformidade, fecha essa lacuna.
Três disciplinas existentes (SDD, TDD, funções de aptidão) integradas como um sistema produzem o context store.
O context store não é pré-merge: serve antes da implantação (briefing de agentes, revisão) e depois (debug, planejamento).
Primeiros passos práticos: comprometer especificação, adotar testes primeiro, codificar três funções de aptidão no CI.
O Problema: A Lacuna de Contexto
Em 2023, um estudo da Microsoft Research mostrou que desenvolvedores usando GitHub Copilot completavam tarefas 55,8% mais rápido. Dois anos depois, o METR conduziu um ensaio controlado randomizado com desenvolvedores experientes em suas próprias bases de código grandes. O resultado: os desenvolvedores levaram 19% mais tempo. A percepção deles, porém, era de que a IA os tornara 20% mais rápidos, uma lacuna de percepção de 39 pontos percentuais.
Essa lacuna tem uma forma reconhecível. A IA faz os primeiros 80% de uma funcionalidade parecerem dramaticamente mais rápidos. Os últimos 20% é onde o trabalho retorna: integração com o sistema existente, casos de borda comportamentais, configurações de teste esquecidas, restrições de desempenho não documentadas. Os primeiros 80% são onde a IA é genuinamente rápida. Os últimos 20% são onde a arquitetura vive.
O custo aparece em duas altitudes. No nível de time, as interrupções da Amazon em março de 2026 foram atribuídas a mudanças assistidas por IA mescladas sem revisão adequada. No nível de liderança, o relatório DORA 2025 do Google encontrou correlação entre adoção de IA e aumento da instabilidade na entrega de software.
A Estrutura: Três Disciplinas de Verificação como um Único Sistema
O que as organizações realmente precisam é de um context store: um registro determinístico e versionado de intenção, comportamento e conformidade arquitetural que humanos e agentes de IA consultam. A fonte da verdade são os artefatos no repositório, não a memória de um LLM.
As três disciplinas, SDD ancorado em especificação, TDD e funções de aptidão arquitetural, alimentam e mantêm esse context store atualizado. Nenhuma é nova. O que é novo é a integração: três loops de verificação em uma cadência, três práticas sociais que os mantêm vivos e um context store como saída compartilhada.
SDD ancorado em especificação: estabelece a camada de intenção com uma especificação viva e legível por máquina no repositório.
TDD: estabelece a camada de comportamento com testes escritos antes do código de produção.
Funções de aptidão arquitetural: estabelecem a camada estrutural com verificações automatizadas de conformidade no CI.
O Context Store: Camadas e Projeções
As três disciplinas em um único fluxo de valor produzem o context store. Suas quatro camadas são: estrutura (anatomia do sistema), linhagem (raciocínio que o moldou), comportamento (pretendido e observado) e conformidade (status vivo de cada restrição).
Duas projeções saem dessas camadas: um grafo de conhecimento legível por máquina que os agentes e jobs de CI consultam, e uma especificação de sistema legível por humanos que o arquiteto lê.
Concretamente, isso vive no repositório como um diretório /specs/, um catálogo de funções de aptidão e um template de PR que requer referências a seções da especificação, um delta de funções de aptidão e uma nota de hand-off 80/20 para PRs liderados por agente.
A pergunta da produtividade não é mais a interessante. A IA gera código mais rápido; essa parte funciona. A pergunta premente é o que acontece com o contexto ao redor do código. O código agora é enviado em velocidade de máquina. O contexto não, e a arquitetura é onde a conta chega.
A arquitetura evolutiva já contém os instrumentos para fechar essa lacuna. Funções de aptidão, SDD ancorado em especificação e TDD existem há anos como práticas separadas. Executá-los juntos como um único sistema de verificação é a resposta operacional.
O context store não é um artefato pré-merge. Antes da implantação, ele dá aos agentes de IA o contexto para gerar código alinhado com intenção e conformidade. Depois da implantação, ele dá aos engenheiros o contexto para depurar, planejar e integrar.
Perguntas Frequentes
O que é um context store em arquitetura de software?
É um registro versionado de intenção, comportamento e conformidade arquitetural, mantido no repositório, que humanos e agentes de IA consultam para entender decisões de design.
Como o context store se relaciona com TDD e funções de aptidão?
TDD e funções de aptidão são duas das três disciplinas que alimentam o context store, junto com SDD. Elas produzem artefatos (testes, verificações) que são persistidos e consultados.
Qual o primeiro passo para implementar um context store?
Comprometer um arquivo de especificação para uma funcionalidade, adotar a norma de testes primeiro para mudanças lideradas por agente e codificar as três maiores dores arquiteturais como funções de aptidão no CI.
O context store substitui a revisão de código?
Não. Ele complementa a revisão, fornecendo contexto rastreável para que os revisores possam focar no 'porquê' em vez do 'o quê', reduzindo a carga cognitiva.
O context store é útil apenas antes do deploy?
Não. Ele serve tanto antes (briefing de agentes, revisão) quanto depois (debug, planejamento de refactor, integração entre sistemas).
