Fitness functions agênticas: quando a IA passa a julgar arquitetura

Um artigo publicado na InfoQ em agosto de 2026, escrito por participantes do programa Certified Architect (Hemant Kumar Mahato, Łukasz Sieczkowski e Vijayasenthilkumar Kuppusamy, com revisão de Luca Mezzalira), propõe um conceito novo para quem trabalha com arquitetura evolutiva: as fitness functions agênticas. A ideia é estender o modelo clássico de arquitetura evolutiva para concerns que são baseados em evidência mas não podem ser reduzidos a uma regra, um limiar ou um schema.

Para entender o que muda, vale relembrar o ponto de partida. Arquitetura evolutiva parte da premissa de que arquitetura não é um estado-alvo fixo, e sim um sistema de decisões que precisa evoluir com segurança conforme o negócio, a tecnologia e os times mudam. As fitness functions são o mecanismo que torna isso possível: elas transformam intenção arquitetural em feedback executável. Uma regra de dependência protege limites entre pacotes, um contract test protege compatibilidade de integração, um orçamento de latência protege performance, um scan de segurança protege conformidade de política.

O teto das regras determinísticas

O argumento central do artigo é que essas checagens determinísticas são indispensáveis, mas só protegem o que pode ser expresso como regra, limiar, schema ou experimento executável. Acima dessa linha fica uma classe grande de erosão arquitetural.

Os autores dão exemplos concretos. Uma regra de dependência mostra que o pacote A importou o pacote B, mas não diz se aquilo é um shared-kernel intencional, um atalho acidental ou o primeiro sinal de um limite sendo esvaziado. Um diff de schema prova que a API ainda faz parse, mas não julga se o novo campo preserva o modelo de domínio ou vaza uma preocupação de UI para dentro de um evento de domínio.

Segundo o texto, esses não são casos exóticos: é assim que arquitetura decai de verdade, através de mudanças individualmente razoáveis que passam em toda regra escrita enquanto afastam lentamente a implementação da intenção original. A resposta histórica foi revisão manual, e o problema é que revisão manual não escala para cada pull request, cada mudança de contrato, cada trace de workflow ou cada patch gerado por agente de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI →.

O que é uma fitness function agêntica

A definição proposta é precisa: uma fitness function agêntica é uma checagem de governança de arquitetura cujo avaliador é um agente de IA calibrado, cujos critérios são expressos como uma rubrica analítica, e cuja saída é um veredito estruturado com evidência, confiança e justificativa.

Os autores insistem num ponto que separa a proposta de hype genérico de IA: não é um oráculo e não substitui checagens determinísticas nem arquitetos. O agente calibra-se contra Architecture Decision Records (ADRs), metadados de ownership, limites de serviço, rubricas e exemplos históricos, e avalia evidência delimitada. Compilador, linter, validador de schema ou checagem de SLO devem continuar bloqueando deploy quando detectam violação clara. A fitness function agêntica normalmente começa como sinal consultivo e só ganha peso depois de calibração que demonstre precisão, recall e variância aceitáveis. Mesmo assim, baixa confiança, discordância entre juízes, alto raio de impacto ou trade-offs ambíguos devem escalar para um humano.

O princípio de design é resumido assim: use gates determinísticos para invariantes objetivas e juízes agênticos para interpretação baseada em evidência. O agente recebe um pacote de evidência pequeno, não a empresa inteira; avalia um concern nomeado, não "boa arquitetura" em geral; retorna resultado legível por máquina, não um ensaio conversacional. E a própria rubrica é versionada e revisada como código.

Como fica na prática: o veredito estruturado

O artigo apresenta uma implementação de referência baseada em ADK (o repositório agentic-fitness-functions), que modela a fitness function como um pipeline. Um evento de mudança (um pull request, um diff de contrato) vira um pacote de evidência com escopo. As checagens determinísticas rodam primeiro e seguem responsáveis pelas restrições objetivas. Só então o juiz de arquitetura em ADK avalia os concerns que exigem julgamento, aplicando a rubrica e produzindo um veredito estruturado.

Esse veredito é o coração da proposta. Um exemplo do artigo:

{
  "fitness_function": "checkout-boundary-fidelity",
  "rubric_version": "2026.07.01",
  "score": 0.68,
  "confidence": 0.74,
  "decision": "advisory_warn",
  "violated_criteria": [ "semantic coupling"],
  "evidence": ["ADR-014", "OrderEvent.diff", "PaymentSession DTO"],
  "recommended_action": "Move PaymentSession behind a checkout-owned adapter or create an explicit shared-kernel ADR.",
  "deterministic_rule_candidate": "Disallow public events from exporting internal payment-state DTOs."
}

Repare no campo deterministic_rule_candidate: quando um padrão se repete, o veredito agêntico vira insumo para escrever uma regra determinística nova. Essa, segundo os autores, é a promessa de longo prazo: tornar o julgamento arquitetural mais observável, calibrável e auditável, e mais fácil de converter em guardrails automáticos quando os padrões se repetem.

Calibração e controles contra os vieses

A parte que separa a proposta de "joga o PR no ChatGPT e pede opinião" é o rigor de calibração. O artigo recomenda um conjunto de calibração com 20 a 50 mudanças anteriores que a comunidade de arquitetura já classificou como aceitáveis, arriscadas ou inaceitáveis. Roda-se o juiz contra esses exemplos e ajusta-se a rubrica até entender falsos positivos, falsos negativos e variância. O conjunto é reexecutado sempre que o modelo, o prompt, a rubrica, a toolchain ou o contrato de evidência mudam.

Uma regra vale destaque: não esconda a incerteza. Discordância entre dois juízes, variância grande entre execuções repetidas ou evidência faltante devem escalar para uma pessoa. Segundo os autores, tirar a média da discordância é perigoso porque a discordância costuma ser o próprio sinal de que o trade-off arquitetural é real.

O texto ainda mapeia modos de falha e controles, incluindo:

• Position bias: o juiz favorece o primeiro design que lê. Controle: avaliar as duas ordens em mudanças de alto impacto.
• Verbosity bias: uma descrição de PR mais longa parece mais convincente que o código. Controle: pontuar contra evidência, não contra tamanho do texto.
• Self-enhancement bias: o modelo favorece padrões parecidos com os que ele mesmo gerou. Controle: usar modelo juiz separado do que gerou o código.
• Não-determinismo: mesma evidência gera scores diferentes. Controle: repetir execuções e tratar variância como baixa confiança.
• Prompt injection: um comentário no diff instrui o juiz a ignorar um critério. Controle: tratar conteúdo do repositório como evidência, nunca como instrução.

Três aplicações e o que fica em aberto para o dev brasileiro

O artigo detalha três exemplos: um Boundary-Fidelity Reviewer (avalia se uma mudança enfraquece o ownership de uma capacidade de negócio sem quebrar regra de dependência explícita), um Semantic Contract Evaluator (checa se um contrato ainda expressa o domínio, mesmo mantendo compatibilidade estrutural) e um ADR Drift Monitor (monitora quando premissas de decisões arquiteturais deixam de valer).

Para quem toca arquitetura no Brasil, o valor prático não está em adotar o framework de referência, e sim no padrão de pensamento. Times que já geram código com agentes de IA convivem com o dilema de revisar volume crescente de PRs pequenos onde decisões arquiteturais aparecem escondidas em diffs de contrato e traces. A proposta oferece um caminho para escalar julgamento sem abrir mão de auditabilidade, mantendo o humano no loop justamente onde há ambiguidade.

Ficam pontos em aberto que o próprio artigo não fecha: qual o custo real de manter conjuntos de calibração atualizados, como medir o retorno frente a revisão humana tradicional, e quanto tempo de operação é preciso antes que os deterministic_rule_candidate gerados realmente compensem. É uma prática emergente, apresentada como capstone de um programa de certificação, não como padrão consolidado de produção. Vale acompanhar, testar em escopo pequeno e desconfiar de qualquer adoção que pule a etapa de calibração.

Fonte: InfoQ