Porque o QA é o Verdadeiro Gargalo no Desenvolvimento com IA

Hoje, o problema mais difícil por resolver no software feito com IA é a garantia de qualidade, não a geração. Construir funcionalidades com IA é barato e quase um problema resolvido. O que ainda é fronteira é confirmar que essas funcionalidades funcionam mesmo, à velocidade e à escala a que já as consegues gerar. Neste momento, o QA é o tecto da autonomia dos agentes, porque a verificação não paraleliza como a geração.

Já lançamos SaaS construído com IA há cerca de 18 meses, do Claude Opus 4.1 até ao Claude Fable 5. Ao longo desse tempo, o lado da construção ficou muito mais rápido e o lado da verificação quase não se mexeu. Essa diferença é a história toda.

---

---

Construir Deixou de Ser a Parte Difícil

O Build This Now é um sistema de construção de SaaS com IA: uma base de código de produção mais 18 agentes de IA especialistas que planeiam, constroem, testam e lançam funcionalidades em linguagem normal. Com uma boa estrutura de agentes e uma base de código de produção a sério por baixo, gerar deixou de ser o limite.

Um MVP que antes nos levava um mês agora leva um dia. Autenticação, pagamentos, segurança da base de dados, email, tarefas em segundo plano: quase tudo isso já vem ligado, e a IA constrói as funcionalidades à medida por cima. O custo de produzir uma funcionalidade que funciona caiu uma ordem de grandeza.

Então fizemos o óbvio. Tentámos correr mais delas em paralelo.

Foi aí que batemos no muro.

O Muro: Não Consegues Verificar Tudo o Que Consegues Construir

Pela nossa experiência, não conseguíamos correr de forma fiável mais do que umas quatro funcionalidades em paralelo antes de aquilo virar uma confusão. Os agentes de construção aguentavam bem. A verificação não.

Passadas mais ou menos quatro funcionalidades em simultâneo, três coisas corriam mal:

1. As execuções de testes começavam a chocar entre si. Estado partilhado, linhas de base de dados partilhadas, portos partilhados. A preparação dos testes de uma funcionalidade pisava a limpeza de outra.
2. O estado andava à deriva. O ambiente que os testes assumiam já não era o ambiente que existia, porque um agente vizinho o tinha alterado por baixo deles.
3. Os agentes de teste entravam em ciclos. Voltavam a correr e a verificar os mesmos fluxos sem chegar a lado nenhum, a gastar tempo e tokens, sem saber se uma falha era real ou apenas um choque.

Nenhum destes é um problema de geração. São problemas de verificação. E pioram, não melhoram, à medida que acrescentas trabalho em paralelo.

A Geração Escala. A Verificação Não.

É esta a assimetria central. Gerar uma funcionalidade é quase uma tarefa independente: dás a um agente uma especificação e uma base de código, e ele trabalha sozinho. Verificar uma funcionalidade é uma tarefa de mundo partilhado: o teste tem de observar comportamento real num ambiente real, e esse ambiente é exactamente aquilo em que todos os outros agentes também estão a mexer.

Podes pôr dez agentes em dez funcionalidades e sair com dez funcionalidades. Não podes pôr dez agentes em dez conjuntos de testes no mesmo ambiente e sair com dez veredictos limpos. Os verificadores disputam o mesmo mundo.

É por isso que o QA é o gargalo. Não é que testar seja difícil em abstracto. É que testar resiste exactamente àquilo que tornou a geração barata: correr muitas cópias ao mesmo tempo.

A Fiabilidade Cai à Medida que o Paralelismo Sobe

Aqui está a forma do que vimos, posto como funcionalidades em paralelo contra quão fiável se mantinha a verificação. São as faixas que observámos, não medições de referência.

A linha da construção manteve-se estável em todos estes casos. Conseguíamos gerar sete funcionalidades tão facilmente como duas. Só não conseguíamos acreditar nos resultados dos testes das sete.

Porque é que Modelos Melhores Ajudam, mas Não Resolvem

Modelos mais fortes mexem mesmo o ponteiro. Mais contexto significa que um agente consegue manter mais do sistema na cabeça e comete menos erros, o que deixa menos para apanhar mais à frente. Menos bugs gerados são menos bugs para verificar.

O Claude Fable 5, o modelo mais recente da Anthropic para trabalho complexo e de longa duração (a $10 por milhão de tokens de entrada e $50 por milhão de tokens de saída), absorve parte do problema de outra maneira. Corre cadeias mais longas sem andar à deriva, por isso um agente de verificação consegue manter-se coerente ao longo de um ciclo demorado de testar e corrigir, em vez de perder o fio a meio e começar a girar em vão. Isto ataca directamente o modo de falha em ciclo em que andávamos a bater.

Mas isto sobe o tecto. Não o tira. A assimetria é estrutural. Enquanto a verificação tiver de observar comportamento num ambiente partilhado, juntar verificadores em paralelo junta disputa de recursos. Um modelo melhor converge mais depressa e anda menos à deriva, o que te compra mais funcionalidades em simultâneo antes do muro. Não empurra o muro para o infinito.

O QA à escala continua a ser a fronteira, e é o próximo grande passo. A equipa que descobrir como paralelizar a verificação como já paralelizamos a geração vai dar o próximo salto de ordem de grandeza na autonomia dos agentes. Já escrevemos sobre porque é que construir não é o gargalo a partir dos princípios, e vês o mesmo limite a aparecer na prática na forma como corremos um enxame de IA autónomo e em porque nos apoiamos em avaliadores adversariais para manter os verificadores honestos.

FAQ

Porque é que os agentes de IA não conseguem testar código à escala?

Os agentes de IA não conseguem testar código à escala porque a verificação depende de um ambiente partilhado, e a geração não. Cada teste tem de observar comportamento real num sistema real, e quando muitos agentes testam em paralelo disputam a mesma base de dados, o mesmo estado e os mesmos recursos. A geração é isolada e paraleliza bem. A verificação choca. Pela nossa experiência, as execuções de testes começam a interferir umas com as outras passadas cerca de quatro funcionalidades em simultâneo.

Quantos agentes de IA podem correr em paralelo antes de a qualidade ruir?

Pela nossa experiência a construir SaaS com IA durante cerca de 18 meses, não conseguíamos correr de forma fiável mais do que umas quatro funcionalidades em paralelo antes de a verificação ficar pouco fiável. Os agentes de construção escalavam bem para lá disso, mas os agentes de teste começavam a chocar, a andar à deriva e a entrar em ciclos sem chegar a lado nenhum. O número exacto depende do isolamento do ambiente, mas a assimetria entre geração e verificação é constante: construir escala, verificar não.

Qual é o verdadeiro gargalo no desenvolvimento de software com IA?

O verdadeiro gargalo no desenvolvimento de software com IA é a garantia de qualidade, não a geração. Produzir uma funcionalidade que funciona com uma boa estrutura de agentes leva agora um dia em vez de um mês. Verificar essas funcionalidades à velocidade a que as consegues gerar continua por resolver, porque a verificação não paraleliza como a geração. Hoje, o QA é o verdadeiro tecto da autonomia dos agentes.

Modelos melhores resolvem o gargalo do QA?

Modelos melhores ajudam, mas não resolvem. Mais contexto e menos erros significam menos bugs para apanhar, e modelos como o Claude Fable 5 correm cadeias de verificação mais longas sem andar à deriva, o que reduz o modo de falha em ciclo. Mas o gargalo é estrutural: a verificação observa um ambiente partilhado, por isso juntar verificadores em paralelo junta disputa de recursos. Modelos mais fortes sobem o tecto; não o tiram.

Para Onde Isto Vai a Seguir

A geração já está resolvida ao ponto de deixar de ser interessante. O problema em aberto é uma verificação que escale como a geração. Quem decifrar o QA em paralelo desbloqueia o próximo nível de autonomia, e é nesse trabalho que estamos de olho, e a construir nessa direcção, com o Claude Fable 5 e a estrutura à volta dele.