A Autoridade de Design de IA

Estamos em um ponto de inflexão no desenvolvimento de software. A discussão costuma girar em torno de qual IA que escreve o melhor código (Claude vs. ChatGPT) ou onde onde a IA deve residir (IDE ou CLI). Mas isso não é a formulação correta da questão.

O problema não é o gerar do código. É o validação disso.

Se abraçarmos a IA como “Vibe Coders” – indicando a intenção e deixando a IA executar – criamos um enorme fluxo de novo software. Um enxame de agentes de IA pode gerar em um minuto mais código do que um desenvolvedor sênior pode revisar em uma semana. O ser humano se tornou o gargalo.

A solução não é mais pessoas. A solução é um Autoridade de Design de IA.

De artesão a diretor da fábrica

Tradicionalmente, a “Design Authority” é um pequeno grupo de arquitetos que se reúne semanal ou mensalmente para aprovar ou rejeitar um design. Num mundo de desenvolvimento de IA de alta velocidade esse modelo está desesperadamente desatualizado. É demasiado lento e reativo.

Se passarmos para “Disposable Code” – software que não refatoramos indefinidamente, mas descartamos e geramos novamente quando os requisitos mudam – então nosso papel muda fundamentalmente. Não somos mais pedreiros que colocam pedra sobre pedra. Somos os arquitetos da fábrica que imprimem as paredes.

Mas quem verifica se essas paredes estão retas?

O “Gauntlet”: Um teste de fogo automatizado

Uma AI Design Authority não é uma pessoa, mas sim um pipeline. Um “Gauntlet” onde cada linha de código gerado deve passar para alcançar a produção. Este processo não substitui a revisão humana de código com nada, mas com algo melhor.

Funciona em três camadas:

1. O Poder Executivo (A Geração)
Não pedimos a uma única IA uma solução, pedimos três. Fazemos o Gemini 3, o GPT-5 e um modelo de código aberto (como o Llama) trabalharem em paralelo no mesmo problema. Isso evita a visão em túnel e rompe a “preguiça” que os LLMs às vezes apresentam. Esta abordagem também é cientificamente investigado e demonstra que se pode prevenir alucinações de IA e construir cadeias muito longas sem erros

2. O Filtro Rigoroso (A Lei)
Aqui não há espaço para discussão. O código deve compilar. Os linters não podem reclamar. E crucial: o Testes de Caixa Preta devem ser bem-sucedidos. Não testamos se a função funciona internamente (isso pode manipular a IA), testamos se o sistema, externamente, faz o que deve fazer. Falha o teste? Direto para a lixeira.

3. De Zachte Filter (De AI Jury)
Esta é a verdadeira inovação. As soluções restantes são apresentadas a uma “IA de Votação” especializada. Este agente não escreve código, mas leest código. Ele é treinado nos nossos princípios de arquitetura, requisitos de segurança (OWASP, ISO) e regras de conformidade (EU AI Act).
Hij stemt: “Oplossing A is sneller, maar Oplossing B is veiliger en volgt onze microservices-architectuur beter.”

De winnaar gaat naar productie.

A Tríade Política do Software

Este modelo impõe uma separação de poderes que falta em muitas equipes.

• O Poder Legislativo (O Arquiteto): O Arquiteto escreve a “Constituição”. Os prompts, os documentos de arquitetura (project-description.md, rules.md, skills.md en principles.md), os requisitos rígidos. O arquiteto determina o quê o que construímos, quem o constrói, como e por quê.
• O Poder Executivo (Os Agentes de Codificação): Eles executam. Rápido, barato e sob a supervisão de desenvolvedores humanos.
• O Poder Judiciário (A Autoridade de Design): Uma camada de IA independente que verifica a conformidade com a lei.

Conclusão: O novo papel do Arquiteto

Ele nos liberta da tirania dos erros de sintaxe e nos permite focar no que fazemos bem: pensamento sistêmico. Busca da verdade. Estrutura e tomada de decisão.

A questão não é se a IA pode escrever nosso código. Esse assunto já está encerrado. O código torna‑se em grande parte um produto descartável.
A questão é: Você tem coragem de soltar o controle sobre o código deixá‑lo ir, para assim controlar o qualidade recuperar?

avise-me