Quando um agente aponta um comportamento estranho no código, a tentação é tratar isso como tarefa pronta para merge. Na prática o caminho entre a suspeita e a alteração em produção ainda passa por confirmação, escopo, teste e alguém que aceite o risco residual e essa parte continua sendo onde o processo mais falha ou mais demora.
O Active-SWE, com 1.663 tarefas em seis categorias de bugs e oito linguagens, mede a capacidade de agentes descobrirem e corrigirem problemas sem um issue detalhado na mão. Os resultados mostram dificuldade real: localizar o defeito, lidar com mais de um problema no mesmo repositório e distinguir o que é bug do que é comportamento intencional ainda são pontos fracos da maioria dos sistemas avaliados. Corrigir a partir de um ticket bem escrito e investigar o sistema do zero são habilidades diferentes; o mercado costuma falar das duas como se fossem a mesma coisa.
Em ambientes de segurança a distinção aparece de forma mais explícita. A OpenAl descreve a Defense Factory como uma operação contínua em que agentes mapeiam sistemas, encontram vulnerabilidades, validam explorações, preparam correções, testam os patches e registram evidências para revisão humana. O Google publicou o Mantis, um harness de código aberto que automatiza descoberta, triagem, reprodução e correção, incluindo o passo de atacar de novo a correção para medir risco residual. Nos dois casos o fluxo não termina no diagnóstico. Termina num pacote que precisa ser aceito ou rejeitado por quem tem autoridade para autorizar mudança em produção.
Uma forma útil de organizar isso é separar quatro níveis de trabalho. Suspeitar: marcar um comportamento anômalo. Confirmar: reproduzir em ambiente isolado. Corrigir: propor alteração mínima e testável. Autorizar: decidir se aquela mudança pode ir adiante. A IA pode atuar nos quatro. A autorização, no entanto, permanece ligada a política, evidência e responsabilidade de alguém que responde pelo sistema depois do merge. Quando o time pula essa separação, o alerta do agente vira ordem de deploy - e o residual (falso positivo, patch incompleto, regressão lateral) fica para o próximo incidente.
Há um efeito colateral interessante do lado de requisitos. Muitos defeitos encontrados sem ticket não batem com um requisito já escrito. O agente acaba inferindo invariantes, contratos implícitos, limites de segurança ou divergências entre documentação e implementação. Isso ajuda a revelar o que faltava na especificação, mas só vira valor se alguém transformar a evidência em critério de aceite e em decisão de escopo. Sem esse passo, o time só acumula diffs "interessantes" e pouca clareza sobre o que o sistema deveria garantir.
Times que levam o assunto a sério pedem ao agente um envelope mínimo: como reproduzir, qual o impacto provável, qual o escopo afetado, qual a hipótese causal, qual o patch, quais testes rodaram e o que restou de risco depois da correção. Quem recebe só a frase "aqui está o fix" continua no modo reativo, agora com mais volume e menos rastreabilidade.
O ponto prático é simples de enunciar e difícil de operar: achar ficou mais fácil; decidir o que o repositório pode herdar ainda exige o mesmo rigor de sempre - só que agora sobre um volume maior de suspeitas geradas por máquina.
Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa.
Autor da série de livros "Engenharia de Software Assistida por IA" (disponível na Amazon). Aprofunde-se no tema de forma estruturada — do contexto à governança de agentes — pode consultar a série "Engenharia de Software Assistida por IA" clicando na imagem abaixo:
- Cupom de 30% OFF:
LEIA30. - Disponível também no Kindle Unlimited.
Referências
- arXiv:2608.04682 - Active-SWE: Benchmarking Coding Agents for Proactive Bug Fixing without Issue Reports
- OpenAl Defense Factory
- Google - Mantis (harness de descoberta, triagem, reprodução e correção)
Tags
#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #Al #BugDetection #Security #CodeReview #EngenhariaDeSoftwareAssistidaPorIA
Top comments (0)