Se você usa Spec Kit, provavelmente já tem um constitution.md dentro de .specify/memory. A pergunta desconfortável não é se o arquivo existe. É se ele está protegendo alguma coisa, ou se é um punhado de boas intenções que o agente lê, acha bonito e ignora na primeira decisão que importa. Boa parte dos constitution.md que aparecem por aí está no segundo grupo: cheios de princípio genérico ("escreva código limpo", "siga boas práticas") e vazios das regras que realmente doem quando são violadas.
O problema aparece no dia em que a geração de código deixa de ser exclusivamente humana. Um agente de IA não herda cultura por osmose. Ele lê o que está escrito, gera o que foi pedido e preenche o resto com o palpite estatisticamente mais provável. No vão entre "o que foi pedido" e "o que o negócio nunca pode violar", ele não pergunta, ele inventa. O desconto que não podia. O dado que não podia trafegar. A chamada síncrona que derruba o checkout na Black Friday. Rápido, plausível e errado. Escrever o constitution.md corretamente é fechar esse vão: transformar as regras inegociáveis do negócio, que hoje moram na cabeça do sócio, do dev sênior e do arquiteto, num artefato versionado que o agente recebe como restrição antes de gerar código, e cuja aderência precisa ser verificada antes do merge.
Principais pontos
- A constituição fica acima da spec de feature. A spec muda toda semana; a constituição codifica os princípios que não mudam: arquitetura, segurança, compliance, invariantes de domínio, padrões de teste, limites de custo.
- O risco não é a IA errar a feature, é ela violar uma regra que ninguém escreveu. Código gerado rápido preenche silêncios com suposição, e o passivo só aparece em produção.
- Constituição é artefato versionado, não wiki esquecida. Vive no repositório, evolui com decisão explícita e é injetada como contexto persistente em toda tarefa, humana ou de agente.
- O gate humano é parte do desenho, não um extra. Alguém aprova mudanças na constituição e valida aderência antes do merge; sem isso, a regra vira sugestão.
- Constituição não substitui discovery nem decisão estratégica. Ela não decide o que construir; codifica o que já foi decidido pra que não seja violado por acidente.
Pra empresas que passaram a usar IA na engenharia, a pergunta deixou de ser "a IA escreve código bom?" e virou "quem garante que o código que ela escreve não viola as regras do meu negócio?". É o tipo de governança que separa velocidade sustentável de dívida silenciosa, e onde parceiros como a Vertis Tech, que opera os próprios agentes de IA sob regras versionadas, entram na conversa com prática, não teoria.
O que é uma constituição de projeto
Se você já leu sobre spec-driven development, conhece a spec: o documento que descreve uma funcionalidade específica, o que ela faz, quais entradas aceita, qual comportamento esperado. A constituição está uma camada acima. Ela não descreve uma feature; descreve as regras que toda feature precisa respeitar.
A analogia com a constituição de um país é deliberada. Leis ordinárias mudam com frequência; a constituição estabelece os princípios que qualquer lei nova precisa obedecer, e mudá-la exige um processo mais pesado. No software, a spec é a lei ordinária, muda a cada sprint. A constituição é o texto de referência que toda geração de código, humana ou de IA, precisa herdar como restrição.
Toolkits de spec-driven development tornaram isso concreto em 2026. O GitHub Spec Kit, um dos toolkits mais populares do movimento, cria o .specify/memory/constitution.md como memória de princípios do projeto: um documento de diretrizes não-negociáveis que o agente referencia durante especificação, planejamento e implementação. No fluxo, a constituição é a etapa inicial, estabelecida antes de qualquer spec. Um trabalho acadêmico recente sobre "Constitutional Spec-Driven Development" (arXiv, 2026) vai além e propõe embutir restrições de segurança derivadas de catálogos como o CWE/MITRE Top 25 diretamente na camada de especificação: a ideia de buscar conformidade por construção, não por inspeção depois que o código já existe.
O ponto de negócio por trás do detalhe técnico: quando a regra está escrita num artefato que a máquina lê antes de gerar qualquer linha, o dev júnior que entrou ontem, o fornecedor novo que você contratou semana passada e o agente de IA que roda de madrugada partem todos da mesma restrição. A regra deixa de depender de quem está na sala.
O que entra na constituição (e o que não entra)
O erro mais comum é transformar a constituição num depósito de tudo. Ela perde força quando vira detalhe de feature. A régua é simples: entra o que é inegociável e transversal; fica de fora o que é específico de uma funcionalidade.
O que entra
- Princípios de arquitetura. "Comunicação entre serviços críticos é assíncrona por padrão." "Nenhum acesso a banco fora da camada de repositório." São decisões que, violadas, comprometem o sistema inteiro, não uma tela.
- Restrições de segurança e compliance. "Transferência internacional de dados pessoais só pode ocorrer por fluxo previamente mapeado, com mecanismo válido previsto na LGPD e no Regulamento da ANPD." "Toda credencial trafega criptografada, nunca em log." Aqui mora boa parte da sua exposição a LGPD, e é exatamente onde a IA improvisa se você não escrever.
- Invariantes de domínio. As regras que definem o que é um estado válido do negócio. "Um pedido não pode ser faturado sem estoque reservado." "Desconto acima de determinado limite exige aprovação registrada." Essas são as regras que moram na cabeça das pessoas e que a IA não tem como adivinhar.
- Padrões de teste. "Fluxo que movimenta dinheiro tem teste de integração antes do merge." Define a barra de qualidade que nenhuma pressa justifica furar.
- Limites de custo e performance. "Nenhuma operação síncrona pode bloquear a resposta ao usuário por mais que um teto definido." "Chamada a modelo de IA em loop precisa de teto de orçamento." Restrições que protegem a conta no fim do mês e a experiência sob carga.
O que não entra
Detalhe de feature. Como a tela de cadastro se comporta, qual o texto do e-mail de boas-vindas, quais campos o formulário tem: isso é spec, muda toda semana e não pertence à constituição. Se você se pega escrevendo "o botão deve ser azul" na constituição, é sinal de que a fronteira se perdeu. A pergunta de teste: isso é verdade pra todo o projeto, ou só pra esta funcionalidade? Se for só pra uma, é spec.
Sinais de que o seu constitution.md está incompleto
A pergunta do título tem uma régua prática por trás. Um constitution.md que existe mas não protege quase sempre dá pelo menos um destes sinais:
- Está cheio de princípio genérico e vazio de invariante de domínio. Se ele diz "código limpo" mas não diz "pedido não fatura sem estoque reservado", ele não protege nada que seja específico do seu negócio.
- Não tem uma linha sequer de fronteira de dado pessoal. Se a IA precisa adivinhar onde o dado do cliente pode trafegar, ela vai adivinhar, e a conta aparece em auditoria de LGPD.
- Ninguém sabe dizer quando foi a última vez que ele mudou. Constituição sem histórico de revisão virou wiki esquecida, não contrato vivo.
- Existe no repositório, mas não entra no contexto do agente. Se o arquivo não é injetado no início de cada sessão, ele é decoração: o agente nunca leu a regra que você achou que estava valendo.
- Qualquer um reescreve sem revisão. Se um PR muda a regra sem passar por quem responde pelo negócio, a regra não vale nada.
Se você marcou dois ou mais, o arquivo está lá, mas o vão entre "o que foi pedido" e "o que não pode ser violado" continua aberto para a IA preencher no palpite.
Como fazer a IA herdar a constituição e como versionar
Uma constituição em Markdown não é governança. Governança começa quando o fluxo consegue carregar a regra, detectar desvios e impedir que código incompatível seja promovido. Escrever o arquivo é apenas metade do trabalho; a outra metade é garantir que ela seja obedecida de fato, por gente e por máquina.
Injeção em toda tarefa. A constituição precisa entrar como contexto persistente no início de cada sessão de geração de código, não como um documento que alguém deveria ter lido. Nos fluxos de spec-driven maduros, o arquivo é carregado automaticamente antes de qualquer prompt de implementação. O agente não começa a tarefa sem a restrição na frente.
Versionamento com processo. A constituição vive no repositório, ao lado do código, sob controle de versão. Mudá-la não é editar um Google Docs, é abrir uma alteração revisada, com histórico de quem mudou o quê e por quê. Isso importa porque as regras do negócio evoluem: quando a política de desconto muda, a mudança precisa ser rastreável, não improvisada num canto.
O gate humano. Nenhuma constituição se sustenta sem um ponto de aprovação humana. Duas frentes: aprovar mudanças na constituição (uma regra nova ou relaxada passa por revisão de quem responde pelo negócio) e validar aderência à constituição antes do merge (código gerado é conferido contra as regras, seja por revisor, seja por verificação automatizada). Sem esse gate, a constituição é decoração.
Como a constituição é consumida pelo agente como instrução privilegiada, ela também se torna uma superfície potencial de ataque. Uma alteração maliciosa ou não autorizada nesse artefato pode contaminar specs, planos e código gerado. Por isso, ela precisa da mesma proteção de integridade aplicada a artefatos críticos: controle de acesso, revisão obrigatória e rastreabilidade.
O limite honesto
A constituição não pensa por você. Ela não decide se vale a pena entrar num mercado, se o produto deve priorizar velocidade ou robustez, se aquela integração é estratégica. Isso é discovery, é decisão de negócio, e continua sendo trabalho humano de arquitetura e produto.
O que a constituição faz é mais modesto e mais valioso do que parece: ela codifica o que já foi decidido pra que não seja violado por acidente. É a diferença entre "nós decidimos que dado pessoal não sai do país" dito numa reunião de seis meses atrás e essa mesma decisão escrita num artefato que a próxima geração de código (feita por um agente que não estava na reunião) é obrigada a respeitar. Ela não substitui o pensamento; ela impede que o pensamento seja esquecido sob pressão de prazo.
Como a Vertis Tech ajuda em governança de código com IA
Essa não é uma prática que a Vertis Tech recomenda de fora. Na própria operação interna, a Vertis Tech já trabalha com agentes de IA apoiados em Know-How e Playbooks versionados, que funcionam na prática como a constituição que esses agentes precisam obedecer, com aprovação humana em pontos críticos e auditoria append-only. A regra que separa o que a IA pode afirmar do que ela não pode inventar mora num artefato, não na cabeça de ninguém.
Cada projeto é dimensionado conforme a complexidade do domínio, a sensibilidade dos dados, a maturidade da engenharia do cliente e o grau de autonomia que a IA vai ter na geração de código. A depender do escopo, a implantação pode contemplar:
- Definição da constituição de projeto junto com o time, mapeando invariantes de domínio, restrições de arquitetura e limites que hoje vivem só no conhecimento tribal.
- Governança LGPD desenhada como regra verificável, com fluxos de dado pessoal, transferências internacionais, acessos e retenção codificados como restrições do projeto, não enterrados num PDF de compliance.
- Fluxo de aprovação humana em pontos críticos, pra que mudança de regra e geração de código sensível passem por gate antes do merge.
- Auditoria append-only das ações de IA, com rastro de quem gerou o quê sob qual regra, o mesmo padrão que a Vertis Tech aplica aos próprios agentes.
- Stack moderno e versionável (TypeScript, Postgres, Claude Agent SDK, MCP tools), desenhado pra que a constituição viva no repositório e evolua com processo, não improviso.
Perguntas frequentes
Constituição de projeto é a mesma coisa que documentação?
Não. Documentação descreve como o sistema funciona; a constituição prescreve o que nenhuma implementação deveria violar e cria a referência contra a qual essa aderência será validada antes do merge. Ela é lida ativamente pela IA antes de gerar código, enquanto a documentação é passiva e frequentemente desatualizada. A constituição é um artefato vivo, versionado e injetado como restrição em toda tarefa.
Preciso adotar uma ferramenta de spec-driven development pra ter uma constituição?
Ajuda, mas não é obrigatório. Toolkits como o Spec Kit padronizam o fluxo: um arquivo lido pelo agente no início de cada sessão. Mas o conceito é independente da ferramenta: qualquer projeto pode manter um artefato versionado de regras inegociáveis e garantir, por processo, que ele seja herdado em toda geração de código. A disciplina importa mais que a ferramenta.
E se as regras do meu negócio mudam com frequência?
A constituição não é o lugar do que muda toda semana, isso é spec. Ela guarda o que é estável e transversal: princípios de arquitetura, fronteiras de compliance, invariantes de domínio. Quando algo desse nível muda de fato, a mudança passa por revisão explícita e fica versionada, com histórico. É lento de propósito.
Isso vale mesmo pra quem ainda gera pouco código com IA?
Vale, e o momento de escrever é antes de a IA acelerar, não depois. Enquanto a geração é lenta e humana, o custo de uma regra não escrita é baixo, alguém percebe na revisão. Quando a IA passa a gerar rápido, o mesmo silêncio vira passivo em escala. Codificar o inegociável é o pré-requisito pra usar IA na engenharia sem herdar dívida invisível.
As regras do seu negócio já existem. A pergunta não é se você tem regras inegociáveis, é se elas estão num artefato que a próxima linha de código, gerada por quem não estava na reunião, é obrigada a respeitar. Enquanto viverem só na cabeça das pessoas, cada aceleração da IA é uma aposta silenciosa de que ela vai adivinhar certo. Codificar a constituição é trocar a aposta por um contrato.
