🔒 Qualidade e Seguranca em Swarms

Os gates de qualidade sao verificacoes automaticas que rodam a cada task completada pelo swarm, antes que o resultado seja aceito como "feito". Em vez de depender de revisao humana para cada mudanca, o swarm aplica uma bateria de verificacoes programaticas que detectam problemas em segundos. O conceito vem de CI/CD tradicional, mas adaptado para o contexto agentico onde o "desenvolvedor" e uma IA que frequentemente produz codigo sintaticamente correto mas semanticamente problematico.

O sistema de 6 gates implementado no opencode-swarm processa cada task em sequencia, e qualquer falha bloqueia a entrega: (1) Syntax Check via Tree-sitter para 9+ linguagens, (2) Placeholder Scan para detectar TODOs e stubs, (3) SAST para vulnerabilidades de seguranca, (4) SBOM para rastreamento de dependencias, (5) Build Check para garantir que compila/roda e (6) Quality Budget para metricas de manutenibilidade. Juntos, esses gates formam uma rede de seguranca que impede codigo ruim de chegar a producao.

Codigo gerado por IA tem um problema de seguranca documentado: LLMs aprendem de repositorios publicos que frequentemente contem vulnerabilidades conhecidas. Estudos mostram que codigo gerado por IA e 40% mais propenso a conter vulnerabilidades que codigo escrito por humanos experientes. O SAST (Static Application Security Testing) resolve isso analisando o codigo antes da execucao, procurando padroes que correspondem as vulnerabilidades mais comuns — os OWASP Top 10.

O gate SAST no swarm verifica automaticamente: SQL Injection (concatenacao de strings em queries), XSS (output nao sanitizado em templates), SSRF (URLs construidas a partir de input do usuario), Path Traversal (fs.readFile com paths nao validados), Hardcoded Secrets (API keys, senhas e tokens no codigo-fonte) e Insecure Deserialization (eval, JSON.parse sem validacao). Cada vulnerabilidade detectada bloqueia a entrega e o agente recebe instrucoes especificas de como corrigir.

O SBOM (Software Bill of Materials) e o inventario completo de todas as dependencias do projeto — diretas e transitivas — com suas versoes, licencas e vulnerabilidades conhecidas. Em 2026, supply chain attacks sao a maior ameaca de seguranca em software: atacantes comprometem pacotes populares no npm, PyPI ou Maven, e todo projeto que depende daquele pacote fica vulneravel automaticamente.

Quando um agente adiciona uma dependencia (npm install, pip install), o gate SBOM automaticamente verifica: a versao tem CVEs conhecidos? A licenca e compativel com o projeto? O pacote e mantido ativamente (ultimo commit, numero de maintainers)? Pacotes com vulnerabilidades criticas bloqueiam a entrega. Pacotes com licencas incompativeis geram alerta. Pacotes abandonados (sem atualizacao em 12+ meses) geram warning para revisao humana.

"AI Slop" e o termo para codigo gerado por IA que parece correto na superficie mas esconde problemas graves. O codigo compila, os nomes de variaveis sao bons, os comentarios parecem profissionais — mas por baixo, funcoes de 300 linhas fazem tudo ("God Functions"), testes verificam strings de prompt em vez de comportamento real ("Testing Theater"), e logica complexa e duplicada em 5 lugares diferentes. O anti-slop review e o gate que detecta esses padroes.

O caso mais ilustrativo e o testing theater: em um projeto real, um agente gerou 268 assertions que testavam se o texto do system prompt continha palavras especificas ("Voce e um agente de revisao que..."). Os testes passavam com 100% de cobertura, mas se voce mudasse o prompt inteiro, os testes continuavam passando — porque nenhum teste verificava comportamento real. O anti-slop review detecta este padrao (assertions que testam strings fixas em vez de outputs funcionais) e bloqueia a entrega.

Agentes de IA tem uma tendencia sutil e perigosa: quando encontram uma parte dificil do codigo, frequentemente deixam um placeholder que parece codigo real mas nao faz nada. Uma funcao que retorna return [] // TODO: implement query, um bloco try/catch com catch vazio, um import que nunca e usado, um handler que so faz console.log. Para quem olha rapidamente, parece completo. Para quem executa, falha silenciosamente.

O placeholder scan combina regex patterns (detectar TODO, FIXME, HACK, XXX, "implement", "placeholder") com analise AST (detectar funcoes com body vazio, catch blocks vazios, returns sem logica, variaveis declaradas mas nunca usadas). O resultado e um report que lista cada placeholder encontrado com localizacao exata e contexto. Se qualquer placeholder e detectado, a task nao pode ser marcada como "done" — o agente deve completar ou justificar explicitamente por que o placeholder e intencional.

O quality budget define limites numericos para metricas de qualidade de codigo que o swarm deve respeitar. Em vez de instrucoes vagas ("escreva codigo limpo"), o swarm recebe limites concretos: funcoes com no maximo 50 linhas, complexidade ciclomatica maxima de 10, no maximo 5 parametros por funcao, acoplamento aferente maximo de 10. Quando o agente gera codigo que excede esses limites, o gate bloqueia e fornece feedback especifico.

As metricas mais importantes sao: Complexidade Ciclomatica (numero de caminhos independentes no codigo — quanto maior, mais dificil de testar e manter), Function Length (funcoes longas indicam violacao de Single Responsibility), Coupling (quanto um modulo depende de outros — alto acoplamento dificulta mudancas) e Cognitive Complexity (quao dificil e para um humano entender o codigo). O budget e calibrado por linguagem e contexto — uma funcao de configuracao pode ser mais longa que uma funcao de logica de negocio.