A Autoridade de Design de IA

Estamos num ponto de viragem no desenvolvimento de software. A discussão centra-se frequentemente em saber se qual a IA escreve o melhor código (Claude ou ChatGPT) ou onde onde essa IA deve estar (IDE ou CLI). Mas essa não é a questão certa.

Se abraçarmos a IA como “Vibe Coders” — indicando a intenção e deixando a execução a cargo da IA — criaremos um fluxo enorme de novo software. Um enxame de agentes de IA pode gerar, num minuto, mais código do que um programador sénior consegue rever numa semana. O ser humano tornou-se o estrangulamento.

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

De Artesão a Diretor de Fábrica

Tradicionalmente, a “Autoridade de Design” é um pequeno grupo de arquitetos que se reúne uma vez por semana ou por mês para aprovar ou rejeitar um projeto. Num mundo de desenvolvimento de IA a alta velocidade este modelo está irremediavelmente ultrapassado. É demasiado lento e reativo.

Se passarmos para o “Código Descartável” — software que não refatoramos indefinidamente, mas que eliminamos e voltamos a gerar quando os requisitos mudam — o nosso papel altera-se fundamentalmente. Já não somos pedreiros que assentam pedra a pedra. Somos os arquitetos da fábrica que imprime as paredes.

Mas quem verifica se essas paredes estão direitas?

O «Gauntlet»: uma prova de fogo automatizada

Uma Autoridade de Design de IA não é uma pessoa, mas um pipeline. Um «Gauntlet» pelo qual cada linha de código gerada tem de lutar para chegar à produção. Este processo não substitui a revisão humana de código por nada, mas por 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 a três. Fazemos com que o Gemini 3, o GPT-5 e um modelo de código aberto (como o Llama) trabalhem em paralelo no mesmo problema. Isto evita uma visão limitada e quebra a «preguiça» de que os LLM sofrem por vezes. Esta abordagem também é estudada cientificamente e demonstra que é possível evitar alucinações da IA e construir cadeias muito longas sem erros

2. O Filtro Rigoroso (A Lei)
Aqui não há lugar para discussão. O código tem de compilar. Os linters não podem apresentar erros. E, crucialmente, os Testes de Caixa Preta têm de passar. Não testamos se a função funciona internamente (a IA pode manipular isso); testamos se o sistema faz, externamente, aquilo que deve fazer. O teste falhou? Vai diretamente para o lixo.

3. O Filtro Suave (O Júri de IA)
Esta é a verdadeira inovação. As soluções que restam são apresentadas a uma «IA de Votação» especializada. Este agente não escreve código, mas lê código. Foi treinado com base nos nossos princípios de arquitetura, requisitos de segurança (OWASP, ISO) e regras de conformidade (Lei da IA da UE).
Ele afirma: “A Solução A é mais rápida, mas a Solução B é mais segura e segue melhor a nossa arquitetura de microsserviços.”

O vencedor entra em produção.

A Separação de Poderes do Software

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

• 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 rigorosos. O arquiteto determina o quê o que construímos, quem o constrói, como e porquê.
• O Poder Executivo (os Agentes de Codificação): Eles executam. De forma rápida, económica e sob a supervisão de programadores 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

Liberta-nos da tirania dos erros de sintaxe e permite-nos concentrar no que fazemos bem: pensar em sistemas. Encontrar a verdade. Estrutura e tomada de decisões.

A questão não é saber se a IA consegue escrever o nosso código. Esse assunto já está encerrado. O código tornar-se-á, em grande parte, um produto descartável.
A questão é: Tens coragem de abdicar do controlo sobre o código para, assim, recuperares o controlo sobre a qualidade ?

diz-me