A Autoridade de Design de IA
Estamos num ponto de viragem no desenvolvimento de software. A discussão é frequentemente sobre qual se a 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 correcta.
O problema não é o gerar do código. É o validação dele.
Se adoptarmos a IA como “Vibe Coders” – em que indicamos a intenção e a IA executa – criamos um fluxo enorme de novo software. um enxame de agentes de IA pode gerar, num minuto, mais código do que um developer sénior consegue rever numa semana. O humano tornou-se o estrangulamento.
A solução não é mais os humanos. A solução é uma Autoridade de Design de IA.
Do Artesão ao Diretor de Fábrica
Tradicionalmente, a "Design Authority" é um pequeno grupo de arquitetos que se reúne semanalmente ou mensalmente para aprovar ou rejeitar um design. Num mundo de desenvolvimento de IA de alta velocidade esse modelo está irremediavelmente desatualizado. É demasiado lento e reativo.
Se migrarmos para "Disposable Code" — software que não refatoramos indefinidamente, mas descartamos e geramos novamente quando os requisitos mudam — então o nosso papel muda fundamentalmente. Já não somos pedreiros a colocar um tijolo de cada vez. Somos os arquitetos da fábrica que imprime as paredes.
Mas quem verifica se essas paredes estão direitas?
A "Gauntlet": Uma prova de fogo automatizada
Uma AI Design Authority não é uma pessoa, mas uma pipeline. Uma "Gauntlet" pela qual cada linha de código gerado deve passar 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 só IA por uma solução, pedimos três. Fazemos Gemini 3, GPT-5 e um modelo de código aberto (como Llama) trabalharem em paralelo no mesmo problema. Isso evita visão de túnel e quebra a "preguiça" que às vezes afeta os LLMs. Esta abordagem também é investigado cientificamente e demonstra que se podem prevenir alucinações de IA e construir cadeias muito longas sem erros
2. O Filtro Rigoroso (A Lei)
Aqui não há discussão possível. O código deve compilar. Os linters não podem reclamar. E crucial: os Testes de Caixa Negra têm de passar. Não testamos se a função funciona internamente (isso pode ser manipulado pela IA), testamos se o sistema faz externamente o que deve fazer. Falha no teste? Directamente para o lixo.
3. O Filtro Suave (O Júri de IA)
Esta é a verdadeira inovação. As soluções remanescentes são submetidas a uma “IA de Votação” especializada. Este agente não escreve código, mas lê código. Está treinado nos nossos princípios de arquitetura, requisitos de segurança (OWASP, ISO) e regras de conformidade (Regulamento de 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 microserviços.”
O vencedor vai para produção.
A Tríade Política 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 rígidos. O arquiteto determina o quê o que construímos, quem o constrói, como e porquê. - O Poder Executivo (Os Coding Agents): Eles executam. Rápido, barato e sob a supervisão de desenvolvedores humanos.
- O Poder Judiciário (A Design Authority): 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 focar no que fazemos melhor: pensamento sistémico. Verificação da verdade. Estrutura e tomada de decisão.
A questão não é se a IA pode escrever o nosso código. Esse assunto já está resolvido. O código tornar-se-á em grande parte um produto descartável.
A pergunta é: você ousa perder o controlo sobre o código deixar ir, recuperando assim o controle sobre o qualidade recuperar o controlo?
diz‑me
