Estamos num ponto de viragem no desenvolvimento de software. A discussão gira frequentemente em torno de qual qual IA escreve o melhor código (Claude vs. ChatGPT) ou onde onde essa IA deve residir (IDE ou CLI). Mas essa não é a questão correta.
Se adotarmos a IA como "Vibe Coders" – onde indicamos a intenção e a IA realiza a execução – criamos um fluxo enorme de novo software. Um enxame de agentes de IA pode gerar mais código num minuto do que um programador sénior consegue rever numa semana. O ser humano tornou-se o estrangulamento.
A solução não é mais mais pessoas. A solução é uma Autoridade de Design de IA.
Tradicionalmente, a "Autoridade de Design" é um 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 ultrapassado. É demasiado lento e reativo.
Se passarmos para o "Código Descartável" – software que não refatorizamos infinitamente, mas que descartamos e geramos novamente quando os requisitos mudam – então o nosso papel muda fundamentalmente. Já não somos pedreiros que assentam pedra sobre pedra. Somos os arquitetos da fábrica que imprime as paredes.
Mas quem verifica se essas paredes estão direitas?
Uma Autoridade de Design de IA não é uma pessoa, mas um pipeline. Uma "luva" (gauntlet) pela 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 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. Deixamos o Gemini 3, o GPT-5 e um modelo de código aberto (como o Llama) trabalharem em paralelo no mesmo problema. Isto evita a visão em túnel e quebra a "preguiça" de que os LLMs por vezes sofrem. Esta abordagem também é cientificamente comprovada e demonstra que é possível evitar alucinações de IA e construir cadeias muito longas sem erros
2. O Filtro Rígido (A Lei)
Aqui não há discussão possível. O código tem de compilar. Os linters não podem apresentar erros. E, crucialmente, os Testes de Caixa Preta têm de ser bem-sucedidos. Não testamos se a função funciona internamente (a IA pode manipular isso), testamos se o sistema, do ponto de vista externo, faz o que deve fazer. O teste falha? Vai diretamente para o lixo.
3. O Filtro Suave (O Júri de 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 lê código. Foi treinado nos nossos princípios de arquitetura, requisitos de segurança (OWASP, ISO) e regras de conformidade (Lei da IA da UE).
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.
Este modelo impõe uma separação de poderes que falta em muitas equipas.
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 porquê.Liberta-nos da tirania dos erros de sintaxe e permite-nos focar naquilo em que somos bons: Pensamento sistémico. Descoberta da verdade. Estrutura e tomada de decisão.
A questão não é 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 deixar de controlar o código para, assim, recuperar o controlo sobre a qualidade recuperar?
diz-me o que pensas