A Autoridade de Design de IA
Estamos num ponto de viragem no desenvolvimento de software. O debate centra-se frequentemente em qual se a IA escreve o melhor código (Claude vs. ChatGPT) ou onde onde essa IA deve residir (IDE ou CLI). Mas esse é o debate errado.
O verdadeiro problema não é a geração do código. O verdadeiro problema é a validação dela.
Se abraçarmos a IA como "Vibe Coders" – onde indicamos a intenção e a IA executa – criamos um enorme fluxo de novo software. Um enxame de agentes de IA pode gerar mais código em um minuto do que um desenvolvedor sênior consegue revisar em uma semana. O ser humano tornou-se o gargalo.
A solução não é mais pessoas. A solução é uma Autoridade de Design de IA.
Do Artesão ao 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 de alta velocidade esse modelo está irremediavelmente desatualizado. É muito lento e reativo.
Se mudarmos para o "Código Descartável" – software que não refatoramos infinitamente, mas sim descartamos e regeneramos quando os requisitos mudam – nosso papel muda fundamentalmente. Não somos mais pedreiros assentando pedra por pedra. Somos os arquitetos da fábrica que imprime as paredes.
Mas quem controla se essas paredes estão retas?
O "Gauntlet": Um teste de fogo automatizado
Uma Autoridade de Design de IA não é uma pessoa, mas sim um *pipeline*. Um "Gauntlet" (Desafio) pelo qual cada linha de código gerado deve lutar para chegar à produção. Este processo não substitui a revisão de código humana por nada, mas sim por algo melhor.
Funciona em três camadas:
1. O Poder Executivo (A Geração)
Não pedimos a uma única IA para uma solução, pedimos a 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 de túnel e quebra a "preguiça" que, por vezes, afeta os LLMs. Esta abordagem também cientificamente investigado e demonstra que é possível prevenir a alucinação da IA e construir cadeias muito longas sem erros
2. O Filtro Rígido (A Lei)
Aqui não há espaço para discussão. O código tem de compilar. Os linters não podem reclamar. E, crucialmente, os Testes de Caixa Preta têm de ser bem-sucedidos. Não testamos se a função funciona internamente (isso pode ser manipulado pela IA), testamos se o sistema faz o que deve fazer do lado de fora. O teste falha? Direto para o lixo.
3. O Filtro Suave (O Júri da IA)
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 sim lê código. Ele é treinado nos nossos princípios de arquitetura, requisitos de segurança (OWASP, ISO) e regras de conformidade (Lei Europeia da IA).
Ele vota: “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 vai para produção.
A Trias Politica 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 en principles.md), os requisitos rigorosos. O arquiteto determina o quê o que construímos e porquê. - O Poder Executivo (Os Agentes de Codificação): Eles executam. Rápido, barato e sob a égide 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
Liberta-nos da tirania dos erros de sintaxe e permite-nos concentrar no que fazemos bem: Pensamento sistémico. Descoberta da verdade. Estrutura e tomada de decisão.
A questão não é se a IA pode escrever o nosso código. Isso já está decidido. O código tornar-se-á, em grande parte, descartável.
A questão é: Ousa largar o controlo sobre a execução para, com isso, recuperar o controlo sobre a qualidade voltar a ter?
