DEV Community: Alex Pimenta

Mais código, menos software: o que 700 empresas mostram sobre o gargalo que a IA não removeu

Alex Pimenta — Sun, 11 Oct 2026 14:34:33 +0000

Adotar agentes de código em escala aumenta volume. Linhas geradas sobem cerca de 30%. Commits sobem cerca de 20%. Pull requests sobem cerca de 23%. A resolução de issues e épicos - o que de fato sai como software entregue - não acompanha esse salto de forma estatisticamente relevante. O estudo de Fiona Chen e James Stratton (Harvard), com dados agregados da Jellyfish sobre mais de 300 milhões de eventos de trabalho em mais de 700 empresas e cerca de 700 mil pessoas entre 2021 e março de 2026, deixa o descompasso visível: a eficiência na geração é absorvida pelo gargalo de revisão humana.

O tempo médio entre abrir o PR e mergear sobe cerca de 49%. A parcela de PRs com pedido de alteração quase dobra. Comentários por PR sobem cerca de 35%. As empresas respondem deslocando cerca de 14% a mais do time para revisar. Ferramentas de revisão assistida por IA já estão em cerca de 80% das firmas medidas; mesmo assim, agentes respondem só cerca de 23% dos comentários de review e cerca de 11% dos PRs. O grosso do trabalho de inspeção continua com pessoas.

Gerar código mais rápido não encurta sozinho o ciclo de entrega. O que entra em produção ainda passa por quem confere intenção, risco e efeito colateral - e esse passo não escalou na mesma proporção do volume gerado. Medir só commits ou linhas cria a impressão de progresso enquanto a fila de revisão engorda e o throughput de issues resolvidas fica parado. O indicador que importa para o negócio continua sendo o que sai validado, não o que o agente produziu na branch.

Na prática, times que tratam agente como multiplicador de escrita sem redesenhar quem revisa, o que precisa de olho humano e o que pode ser triado por política acabam pagando a conta em atraso de merge e em pressão sobre os mesmos revisores. O dado de firmas reais não diz que agente não ajuda. Diz que o ganho de geração se perde quando a revisão e a decisão de merge permanecem no mesmo desenho de antes - só que com mais volume passando pela mesma porta.

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

Chen, F. & Stratton, J. (Harvard) com dados Jellyfish, cobertura Ars Technica, 9-10 out 2026: +30% linhas, +20% commits, +23% PRs; resolução de issues sem ganho claro; tempo PR merge +49%; agentes com ~23% dos comentários de review e ~11% dos PRs

Tags

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #CodeReview #Produtividade #EngenhariaDeSoftwareAssistidaPorIA

O próximo ataque não vem no código. Vem no skill do agente

Alex Pimenta — Thu, 08 Oct 2026 12:32:15 +0000

Skills de agentes de código parecem documentação útil: pastas com Markdown, instruções em linguagem natural e, às vezes, scripts de setup. O time instala para o agente aprender a configurar ambiente, publicar pacote, rodar teste ou revisar segurança. O paper Towards a Risk Assessment of Malicious Skill Files in Coding Agents (arXiv:2608.05223) mostra o outro lado dessa interface. Comandos de shell reais foram transformados em skills de aparência benigna — 2.826 habilidades mapeadas a 11 táticas MITRE ATT&CK e testados em agentes de grau empresarial. Em milhares de execuções, Gemini CLI foi explorado em cerca de 95-96% das corridas; Qwen Code em cerca de 72-74%. Reconhecimento explícito de risco de segurança apareceu em menos de 2% das runs.

A mistura é o problema. Linguagem natural parece legítima; scripts e instruções embutidas podem alterar ambiente, ler arquivos, chamar serviços externos ou exfiltrar dados. O agente carrega o skill com a mesma autoridade que já tem sobre o workspace — muitas vezes com permissão de executar comandos. Investigações posteriores (Mitiga Labs e outros) documentaram skills e arquivos de instrução capazes de copiar repositório local, empurrar conteúdo para remoto controlado pelo atacante e deixar o log de auditoria do agente vazio. Em alguns casos bastam poucas interações do usuário para o fluxo completar.

Isso não é o mesmo risco de um pacote npm malicioso clássico. O skill entra no contexto do agente, influencia o raciocínio e pode orientar ações sem parecer malware no disco. Pinagem de versão ajuda pouco se o mecanismo de instalação ainda permitir troca silenciosa do conteúdo executado, ou se o skill vier embutido no próprio repositório clonado (pastas de projeto que o agente carrega automaticamente). A superfície se parece com cadeia de suprimentos, mas o payload fala a língua do assistente.

Na operação diária, a pergunta deixa de ser só "quem revisa o diff gerado". Passa a incluir: de onde veio esse skill, quem autorizou a instalação, o que ele pode executar sem novo consentimento e se o time tem trilha quando o agente segue uma instrução embutida. Tratar skill como documentação inofensiva é o atalho. Tratar como código com permissão implícita — e auditar como tal — é o mínimo para não importar um atacante dentro do loop de desenvolvimento.

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.05223 - Towards a Risk Assessment of Malicious Skill Files in Coding Agents (Yang et al., ago/2026); benchmark de 2.826 skills; taxas de exploração ~95% (Gemini CLI) e ~72-74% (Qwen Code)
Mitiga Labs e análises correlatas sobre exfiltração via skills/instruções de agentes (2026)
arXiv:2609.36879 — SKILLLITE (detecção de skills maliciosos)

Tags

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #CodingAgents #SupplyChain #Segurança #EngenhariaDeSoftwareAssistidaPorIA

Quem audita o auditor? O problema de confiar em agentes para revisar agentes

Alex Pimenta — Wed, 07 Oct 2026 14:04:59 +0000

Quando o volume de código gerado ultrapassa o que qualquer pessoa consegue inspecionar linha a linha, a resposta automática é empilhar mais automação: agente que escreve, agente que revisa, testes que validam, monitores que alertam. O estudo de caso aceito no workshop Meta-Agents da NeurIPS 2026 (A Case Study in Assuring AI-Written Software, arXiv:2610.08651) acompanha seis meses de uma plataforma de saúde em produção construída assim e operada por alguém sem formação formal em engenharia de software. O fluxo virou um meta-sistema: um agente codificava, outros supervisionavam e revisavam, regras do projeto carregavam lições, e uma pessoa dava a decisão final.

As camadas de supervisão também falharam. Alguns monitores mediam métricas substitutas em vez do resultado que importava. Auditorias caíram em silêncio. Verificações exigidas sumiram dos relatórios. Em um episódio, um reparo automatizado causou interrupção operacional. O ponto não é que agentes de revisão sejam inúteis. É que tratá-los como prova suficiente cria uma cadeia em que o erro do revisor fica invisível até o impacto chegar ao usuário.

Código gerado por agente não se comporta como saída de compilador. O modelo infere intenção incompleta, age em ambiente com estado e, em alguns fluxos, pode alterar os próprios testes. Revisão exaustiva por humano já era frágil quando o volume era menor; com agentes produzindo mais do que dá para ler com atenção, a revisão humana deixa de ser o único controle confiável e a revisão por agente não herda automaticamente a autoridade que o time gostaria de atribuir a ela.

No caso descrito, o controle humano só se sustentou quando quatro coisas permaneceram amarradas ao mesmo objetivo: o resultado pretendido, a evidência usada para julgar esse resultado, as permissões dos agentes e a decisão final de uma pessoa. Quando o monitor olha para um proxy, quando o agente revisor compartilha o mesmo viés do agente autor, ou quando a auditoria falha sem alarme, a cadeia de confiança se desfaz sem que ninguém perceba na hora.

Na prática isso pede desenho de supervisão, não só mais agentes na fila. Separar quem gera de quem verifica; exigir evidência reproduzível (não só "aprovado pelo revisor"); tratar silêncio de monitor como falha; e reservar autorização humana para o que altera permissão, dinheiro, dados sensíveis ou comportamento em produção. Empilhar agentes de revisão sem auditar o auditor só desloca o ponto cego.

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:2610.08651 A Case Study in Assuring AI-Written Software (Ferris & Bonilla; aceito no NeurIPS 2026 Meta-Agents Workshop)

Tags

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #CodeReview #MetaAgents #Supervisão #EngenhariaDeSoftwareAssistidaPorIA

O agente vai bem no benchmark. Por que falha no seu repositório?

Alex Pimenta — Tue, 06 Oct 2026 11:41:31 +0000

Leaderboards públicos de agentes de código costumam pintar um cenário generoso. Tarefas derivadas de issues abertos, repositórios conhecidos, enunciados relativamente formais. O Real-SWE, publicado pela Specific Labs em setembro de 2026, corta esse atalho: as tarefas vêm de bases de produção privadas licenciadas por empresas reais cobrança, impostos, migração de dados de clientes, lógica espalhada entre serviços. O melhor arranjo avaliado (Fable 5.1 com Claude Code) resolveu 38,8% das tentativas. GPT-6 Astra ficou em 33,8%; Gemini 3.8 Flash em 31,2%. Seis das dez tarefas públicas do conjunto ficaram abaixo de 15% para todos os modelos. Uma tarefa de reescrita de stream analítico não foi resolvida em nenhuma das 64 execuções.

A mediana do fix de referência toca 11 arquivos. Em benchmarks mais "limpos", esse número costuma ser perto de 6. Trabalho real raramente cabe num único módulo. O enunciado médio do Real-SWE tem cerca de 1.700 caracteres e carrega contexto de negócio - não só "corrija o bug no arquivo X". A avaliação mede modelo e harness juntos, com a suíte de testes da própria empresa como oráculo. Não é o modelo isolado num playground.

A falha recorrente não é só sintaxe. Relatos do próprio benchmark apontam "requisito perdido" como bucket frequente: o agente entrega um patch que passa em parte dos testes e ignora uma regra de negócio que estava implícita no sistema, não no issue. Código privado concentra convenções internas, acoplamentos legados, serviços externos e intenções que nunca entraram no pré-treino. Reconstruir essa intenção a partir do repositório e do pouco que o ticket diz é o trabalho difícil. Programar a alteração, uma vez que a intenção está clara, é a parte em que os modelos já se saem melhor.

Isso desloca a conversa de "qual modelo está no topo do SWE-bench" para "quanto do nosso contexto de negócio o agente consegue recuperar antes de editar". Requisitos incompletos, arquitetura distribuída e regras que só existem no código ou na cabeça de quem manteve o sistema por anos não somem porque o harness melhorou. Continuam sendo o teste que separa demonstração de engenharia no repositório de verdade.

Quem usa agente em produção e só olha o leaderboard público subestima o custo de revisão, de contexto e de correção quando o patch "quase certo" viola uma invariante que ninguém escreveu no ticket. O número de 38,8% no melhor caso do Real-SWE não é um ataque aos modelos. É um lembrete de onde ainda está o trabalho: na reconstrução do que o sistema deveria fazer, não só na geração do diff.

Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa.

Cupom de 30% OFF: LEIA30.
Disponível também no Kindle Unlimited.

Referências

Specific Labs — Real-SWE: Benchmarking AI Coding Models on Real Enterprise Codebases (setembro 2026); melhor resultado 38,8% (Fable 5.1 + Claude Code), 640 rollouts, bases privadas licenciadas
Cobertura e tabelas de custo/resolução (análises públicas de set/2026)

Tags

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #CodingAgents #Benchmarks #EngenhariaDeSoftwareAssistidaPorIA

O contexto também envelhece: por que agentes de código precisam esquecer para continuar corretos

Alex Pimenta — Mon, 05 Oct 2026 14:34:59 +0000

Em tarefas longas de repositório, o agente inspeciona arquivos, busca referências, edita, roda testes e volta a inspecionar. Cada passo deixa rastros no contexto. Parte desse material ainda importa na etapa seguinte; outra parte já virou lixo — hipótese descartada, saída de ferramenta que não se aplicou, tentativa que falhou. Quando o sistema trata todo o histórico como sagrado, o modelo continua raciocinando em cima de coisas que deixaram de ser verdadeiras.

O paper AutoCompact (arXiv:2610.02163, 1º de outubro de 2026) parte dessa observação e muda a pergunta. Em vez de comprimir só quando a janela estoura, o agente aprende a decidir quando compactar, o que preservar como estado de trabalho e como seguir a partir desse resumo. Nos experimentos em SWE-bench Verified e SWE-PolyBench Verified, o ganho absoluto de taxa de sucesso chegou a 9,2 e 5,0 pontos percentuais sobre o modelo base — inclusive com janela de 256K que nunca estoura e com janela curta de 16K em que a compactação de fallback entra quando necessário.

A diferença prática é sutil e cara. Compactação por limite de tokens é reação a estouro. Compactação por estado de tarefa é reconhecimento de que uma fase acabou: a causa raiz foi localizada, certos caminhos foram eliminados, o próximo passo é editar e verificar. O resumo útil guarda conclusões confirmadas, trechos de código relevantes, status do workspace e a lista do que ainda falta. O que sobra de exploração barulhenta some. Se o resumo for ruim, o agente perde o fio — goal loss, regressão de raciocínio, correção aplicada no lugar errado.

Isso mexe com o desenho do harness e com a governança de contexto. Quem só amplia a janela e nunca ensina o agente a descartar acaba pagando em tokens, em latência e em decisões tomadas sobre premissas mortas. Quem trata compactação como política — gatilho por estágio, critérios do que deve sobreviver, auditoria do resumo antes de continuar — reduz o risco de o modelo “lembrar” de um arquivo que já mudou ou de uma hipótese que o próprio agente já rejeitou três passos atrás.

Na operação diária, o sintoma aparece quando o agente insiste em um caminho que a própria trajetória já mostrou inviável, ou quando o patch final ignora uma restrição que estava no início da conversa e sumiu no meio do ruído. Nesses casos o problema não foi falta de contexto. Foi excesso de contexto que envelheceu e ninguém mandou esquecer.

Gerenciar contexto em agentes de código deixou de ser só “não estourar a janela”. Passou a ser decidir, no meio da tarefa, o que ainda é estado de trabalho e o que já é história que atrapalha.

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:2610.02163 - AutoCompact: Learning When to Compact Context in Long-Horizon Coding Agents (Zhang, Zheng, Du, An, Dong; 1 out 2026)
Discussões correlatas sobre compaction em harnesses de agentes de código (Claude Code, Codex, Deep Agents)

Tags

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #ContextEngineering #CodingAgents #EngenhariaDeSoftwareAssistidaPorIA

Descobrir não é autorizar: o que falta entre o agente achar o bug e o patch ir para produção

Alex Pimenta — Sat, 03 Oct 2026 14:32:12 +0000

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.

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

Quando a IA encontra o bug antes do usuário: a transição da engenharia reativa para a engenharia proativa de software

Alex Pimenta — Thu, 01 Oct 2026 17:29:09 +0000

O fluxo clássico ainda domina muita operação: o usuário reporta, o suporte classifica, o time reproduz, alguém corrige. Entre o primeiro sintoma em produção e o patch, entram coordenação, fila e custo. Parte desse atraso deixa de ser inevitável quando agentes passam a vasculhar o repositório ou a rodar testes derivados de intenção antes de existir ticket.

A literatura de 2025-2026 separa com clareza três modos de garantia de qualidade. Prevenção de regressão (não quebrar o que já funcionava). Reprodução reativa (a partir de issue ou stack trace). E descoberta proativa: achar defeito sem relatório, comparando implementação com intenção documentada ou explorando o código em busca de falhas ainda não disparadas. O benchmark TestExplora (arXiv:2602.10471) formaliza esse terceiro modo com 2.389 tarefas em 482 repositórios, ocultando sinais de defeito e usando documentação como oráculo. O teto dos modelos avaliados ficou em torno de 16% de taxa Fail-to-Pass; com exploração agentic, o SWE-Agent chegou perto de 17% (e ~30% em F2P@5). O número é baixo e já basta para mostrar que o problema deixou de ser só "gerar teste de regressão".

Active-SWE (arXiv:2608.04682) empurra a barra um passo adiante: o agente deve descobrir e corrigir bugs sem issue report, inclusive em cenários de múltiplos defeitos. A maioria dos agentes de ponta ainda se sai mal quando não há pista humana. Ou seja: a capacidade existe em embrião; a engenharia de processo que a torna rotina ainda é rara.

No mundo real, exemplos públicos apontam o mesmo deslocamento. Agentes de segurança (como os descritos em divulgações de OpenAl e trabalhos ligados ao Google DeepMind) já encontraram vulnerabilidades em projetos abertos que depois receberam CVE em alguns casos antes de sinais de exploração ativa. O valor não está só em "achar o bug". Está em achar, validar em sandbox, ranquear severidade e propor correção enquanto o defeito ainda não virou incidente.

Isso muda o desenho do time. Engenharia reativa dimensiona suporte, plantão e fila de hotfix. Engenharia proativa dimensiona quem define o que o agente pode explorar, com qual oráculo (documentação, contrato, propriedade), com qual critério de falso positivo e com quem herda o patch sugerido. Sem critério de aceite e sem supervisão, o agente que "encontra bug" vira ruído: alerta demais, corrige demais, ou corrige o sintoma errado.

Na prática, times que avançam nesse caminho costumam começar estreito: um módulo crítico, intenção documentada legível, agente que propõe teste ou patch e humano que decide merge. O custo de um bug em produção continua sendo ordem de magnitude maior do que o de um ciclo de detecção cedo. A diferença é que a detecção cedo deixou de depender só de alguém lembrar de escrever o teste e passou a depender de alguém desenhar o loop proativo com a mesma seriedade com que se desenha o pipeline de Cl.

A IA não elimina o usuário como fonte de verdade sobre o produto. Ela pode, se o processo permitir, reduzir quantas vezes o usuário é o primeiro a descobrir o defeito.

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:2602.10471 — TestExplora: Benchmarking LLMs for Proactive Bug Discovery via Repository-Level Test Generation
arXiv:2608.04682 — Active-SWE: Benchmarking Coding Agents for Proactive Bug Fixing without Issue Reports
arXiv:2510.08005 — Past, Present, and Future of Bug Tracking in the Generative AI Era
Divulgações públicas sobre agentes de caça a vulnerabilidades (OpenAI Aardvark; linhas de trabalho tipo Big Sleep / CodeMender)

Tags

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #BugDetection #QualityAssurance #AgentesDeCodigo #EngenhariaDeSoftwareAssistidaPorIA

O harness é o novo código: por que o desempenho do agente depende mais do ambiente de execução do que do modelo

Alex Pimenta — Wed, 30 Sep 2026 14:30:53 +0000

Trocar o modelo e manter o mesmo ambiente de execução raramente produz o salto que o marketing promete. O que muda o resultado, em muitos casos, é o conjunto que envolve o modelo: ferramentas disponíveis, regras de uso, memória de sessão, planejamento, subagentes, validações e o modo como o agente lê e escreve no repositório. Esse conjunto tem nome na literatura recente: harness.

Dois trabalhos de final de setembro de 2026 colocam o harness no centro da discussão. Beyond the Model: Demystifying Harness Effects in Software Engineering Agents (arXiv, 26 set 2026) compara harnesses, modelos e benchmarks (incluindo SWE-bench Pro e tarefas em nível de repositório). A conclusão prática é que a eficácia do harness depende ao mesmo tempo da capacidade do modelo e do tipo de tarefa. Uso estruturado de ferramentas e subagentes específicos da tarefa tende a gerar ganhos mais estáveis. Compressão agressiva de contexto e subagentes genéricos, em certos cenários de geração sobre repositório inteiro, chegaram a piorar o resultado.

Outro estudo, Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents, analisa o código-fonte de onze sistemas de agentes e descreve o harness como anatomia operacional: não é “prompt bonito”, é a camada que transforma um modelo de linguagem em algo capaz de trabalhar de forma repetível sobre um codebase — com permissões, loops de ferramenta, critérios de parada e mecanismos de verificação.

Isso desloca a conversa de “qual o melhor modelo” para “qual o ambiente em que esse modelo opera”. Times que só trocam o LLM e reutilizam o mesmo harness fraco repetem o mesmo padrão de falha com custo diferente. Times que investem em ferramentas certas para a tarefa, em contexto que o agente consegue usar de fato e em regras que limitam o que pode ser alterado sem revisão, obtêm comportamento mais previsível — inclusive com modelos menos badalados.

Na prática de engenharia, o harness vira objeto de desenho. Quais ferramentas o agente pode chamar. O que entra no contexto e o que fica de fora. Quando um subagente específico é acionado e quando não. Quais validações rodam antes do diff ser oferecido ao humano. Quem define isso está fazendo engenharia de software assistida por IA de verdade; quem só escolhe o modelo na interface está delegando o resultado ao acaso do ambiente padrão do fornecedor.

O modelo importa. O ambiente em que ele corre, muitas vezes, importa mais para o que chega ao repositório. Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa.

Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa.

✅ Cupom de 30% OFF: LEIA30.
✅ Disponível também no Kindle Unlimited.

Referências

Beyond the Model: Demystifying Harness Effects in Software Engineering Agents (arXiv, 26 set 2026)
Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents (análise de onze sistemas de agentes)

Tags

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #CodingAgents #Harness #ContextEngineering #EngenhariaDeSoftwareAssistidaPorIA

Quando editar ficou barato, o gargalo virou a revisão

Alex Pimenta — Tue, 29 Sep 2026 13:38:58 +0000

Em repositórios grandes, a capacidade de gerar ou corrigir código com agentes deixou deser o limite operacional. O que trava o fluxo é o que vem depois: fila de CI, atenção de quem revisa e a forma como as mudanças são agrupadas e aprovadas.

Um estudo de campo de meados de setembro de 2026, em repositório industrial C++ com milhares de arquivos (Orchestrating AI-Assisted Code Remediation: Socio-Technical Bottlenecks in a Large Industrial Repository, arXiv:2609.29172), descreve o que acontece quando a edição mecânica fica barata. Commits feitos arquivo a arquivo saturaram a integração contínua e a capacidade de revisão. A equipe precisou passar a agrupar mudanças por diretório, limitar quantos arquivos entravam em cada change e negociar com o time qual granularidade de commit ainda era aceitável. A conclusão prática do trabalho é direta: remediação sustentável em escala exige tratar conjuntos semânticos de mudança — por exemplo, “corrigir todas as instâncias do warning X” — como unidade de trabalho de primeira classe, com controle deliberado de commit, revisão e lote de CI.

Isso desloca o problema. Enquanto o custo de editar cai, o custo de validar e absorver a mudança no processo humano e automatizado sobe ou, no mínimo, deixa de acompanhar a velocidade de geração. O revisor não escala na mesma proporção do agente. A pipeline de CI também não, se cada arquivo vira um commit isolado competindo por recurso e por olhar humano.

Em escala de produção, dados de uso de coding agents (incluindo caracterizações amplas do GitHub Copilot) mostram sessões em que o usuário inicia turnos esparsos e o agente desdobra loops autônomos com chamadas a modelo e ferramentas. O volume de artefato que chega à revisão cresce sem que a capacidade de quem aprova tenha crescido na mesma medida. O risco não é só qualidade pontual do diff; é fila, fadiga de revisão e merges que passam com menos contexto do que o time gostaria de admitir.

Na prática, times que sustentam o uso de agentes em repositórios grandes passam a desenhar a unidade de mudança com o mesmo rigor com que antes desenhavam a unidade de código. Batch por tema ou por diretório, limite explícito de escopo por PR, critério de aceite antes de liberar o agente e alguém responsável por herdar o conjunto — não só por clicar em approve — reduzem a saturação. Quem continua tratando cada sugestão do agente como um micro-commit independente descobre o gargalo na CI e na agenda dos revisores, não no modelo.

A edição barata não elimina engenharia de processo. Ela expõe onde o processo nunca foi dimensionado para o volume que a geração agora produz. 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:2609.29172 — Orchestrating AI-Assisted Code Remediation: Socio-Technical Bottlenecks in a Large Industrial Repository
Microsoft Research — Agentic Coding in the Wild (caracterização em escala de produção, GitHub Copilot)

Tags

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #CodeReview #CI #AgentesDeCodigo #EngenhariaDeSoftwareAssistidaPorIA

Dívida técnica induzida por prompt: o pedido vago que o agente transforma em custo de manutenção

Alex Pimenta — Mon, 28 Sep 2026 09:09:38 +0000

Quando o pedido chega solto e o agente devolve um diff que passa nos testes locais, a sensação imediata é de progresso. O trecho entra no repositório. Só mais adiante — às vezes semanas —, alguém precisa alterar aquele módulo e descobre que a lógica não está documentada na cabeça de ninguém, nem no desenho do sistema. A correção custa mais do que a geração original.

A literatura de 2026 começou a tratar esse padrão com nome próprio. O paper From Prompting to Engineering: A Research Agenda for Prompt Engineering in Software Engineering (arXiv:2609.02248) descreve a prompt-induced technical debt: dívida cuja introdução ou acúmulo depende da interação entre prompt, contexto incompleto, artefato gerado e revisão humana feita sob pressão de tempo. Não é só "o modelo errou". É o processo de delegar e aceitar sem critério suficiente que deixa residual estrutural para o ciclo seguinte.

Estudos em repositórios reais reforçam a escala do problema. Em Debt Behind the AI Boom (arXiv:2603.28592), a análise de centenas de milhares de commits atribuídos a assistentes de código encontrou uma quantidade elevada de issues; a maior parte code smells — débito de estrutura, não falha pontual de comportamento. Uma parcela relevante dessas issues ainda aparecia na revisão mais recente do repositório, o que indica que nunca foram de fato eliminadas. No front de segurança, o Veracode GenAI Code Security Report (2026) registrou que cerca de 44% das tarefas de geração produziram ao menos uma falha conhecida, com pouca variação em relação ao ano anterior. Acelerar a escrita de código não tem bastado, sozinho, para melhorar o perfil de risco.

O mecanismo do problema

O mecanismo é conhecido de quem trabalha com agentes no dia a dia. Pedidos do tipo "melhora a performance dessa API" ou "refatora esse serviço" empurram o modelo a preencher lacunas que o time não explicitou. Ele escolhe trade-off, nome de abstração, fronteira de módulo. O comportamento visível pode estar correto, mas o acoplamento, a duplicação e os caminhos de erro incompletos ficam para quem herdar o código.

Prompt mais detalhado reduz parte do problema, mas não o elimina. Trabalhos recentes sobre smells em código gerado por modelos mais capazes observam que volume e acoplamento tendem a crescer com a capacidade do modelo, e que acertar o comportamento funcional ou enriquecer o prompt não impede de forma confiável a degradação arquitetural.

Como conter a dívida

Na prática, times que conseguem conter esse tipo de dívida tratam o prompt como o que ele é: uma especificação improvisada, barata na primeira rodada e cara na terceira.

Para mudar o perfil do residual que sobra, são adotadas práticas como:

Critério de aceite antes de gerar.
Restrições claras do que não pode mudar.
Revisão que olha o desenho e não apenas se "passou no teste".
Alguém de fato responsável por herdar o trecho — e não apenas por aprovar o PR.

A velocidade de geração pode continuar, mas o que não se sustenta é assumir que pedido vago mais diff verde equivale a custo de manutenção zero.

Artigo Completo no Blog

Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa no meu blog:

Aprofunde-se no Tema

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 —, consultando a série:

🎟️ Cupom de 30% OFF: LEIA30

📖 Disponível também no Kindle Unlimited

Série Engenharia de Software Assistida por IA completa:

Referências

arXiv:2609.02248 – From Prompting to Engineering: A Research Agenda for Prompt Engineering in Software Engineering
arXiv:2603.28592 – Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild
Veracode GenAI Code Security Report (2026)

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #DebitoTecnico #PromptEngineering #AgentesDeCodigo #EngenhariaDeSoftwareAssistidaPorIA

Spec antes do código: por que a especificação virou artefato de engenharia e não documento de arquivo

Alex Pimenta — Fri, 25 Sep 2026 12:34:58 +0000

Gerar código ficou barato, mas entender o que gerar continua caro. Foi sempre esse o gargalo — só que agora ele aparece mais rápido, porque o agente preenche qualquer lacuna deixada em aberto. Sem intenção explícita, ele inventa comportamento, assume edge case e escolhe trade-off que ninguém pediu. O PR passa no teste genérico, mas semanas depois alguém descobre que o requisito de negócio era outro.

A resposta que ganhou tração em 2026 não é nova em essência: "especifique antes de construir" é uma máxima velha na engenharia de software. O que mudou é quem executa a spec. Não é mais o programador lendo um documento Word na segunda-feira; é o agente, em tempo real, tratando aquele texto como fonte de verdade operacional.

O nome disso é Spec-Driven Development, e o projeto que deu ao termo sua forma mais conhecida é o GitHub Spec Kit, liberado em código aberto em setembro de 2025 e construído sobre a pesquisa de John Lam para tornar o desenvolvimento guiado por LLM mais determinístico. A formulação usada pelo próprio kit resume o giro conceitual: especificações não servem ao código — o código serve às especificações. Não é retórica vazia, mas uma inversão de hierarquia onde o código deixa de ser a verdade e vira derivação, como binário compilado a partir de fonte.

O Kiro, da Amazon, chegou a uma arquitetura parecida por caminho próprio com três estágios (requisitos, design e criação de tarefas), funcionando cada um como checkpoint antes do próximo. Diferentes empresas e definições parecidas geram uma difusão semântica que, somada ao ritmo da mudança tecnológica, torna difícil nomear práticas adjacentes à IA. Isso, no entanto, não desqualifica a prática, mas sim o hype em torno dela.

Os custos e limites do modelo

A abordagem possui custos que raramente aparecem em posts de redes sociais:

Manutenção: Specs precisam ser mantidas; se o projeto muda e a spec não acompanha, cria-se documentação desatualizada na qual o agente confia cegamente.
Escala mínima: O overhead de escrever, revisar e versionar uma spec só compensa quando a funcionalidade justifica, sendo recomendado pular a abordagem em funcionalidades pequenas ou em trabalhos espalhados por múltiplos serviços.
Risco de longo prazo: Encher a IA de regras detalhadas escritas à mão pode ser mais uma repetição de padrões que a engenharia de software já tentou no passado sem grande sucesso de escala.

A orientação prática é tratar a spec como interface de contrato entre você e o agente, escrevendo o mínimo que elimina a ambiguidade (intenção, critério de aceite e escopo externo) sem exagerar no tamanho. O ganho real está em mover o ponto onde o erro custa uma frase de correção, em vez de um merge inteiro para desfazer.

Artigo Completo no Blog

Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa no meu blog:

Aprofunde-se no Tema

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 — consultando a série:

Cupom de 30% OFF: LEIA30

Disponível também no Kindle Unlimited

Fontes

Codemyspec – Spec-Driven Development in 2026: The Complete Guide and Tool Comparison
Thoughtworks Radar (zh-cn) – Spec-driven development (nov/2025)
Thoughtworks Technology Podcast (AWS) – What is spec-driven development?, com Laura Tacho
Augment – 6 Best Spec-Driven Development Tools for AI Coding in 2026

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #SpecDrivenDevelopment #EngenhariaDeRequisitos #AgentesDeCodigo #EngenhariaDeSoftwareAssistidaPorIA

AGENTS.md: O arquivo que o agente lê antes de tocar no seu código

Alex Pimenta — Thu, 24 Sep 2026 17:09:23 +0000

Em 2026, a maior parte das ferramentas sérias de coding agent procura um arquivo Markdown na raiz do repositório antes de começar a trabalhar. O nome que se consolidou como padrão aberto é AGENTS.md: um “README para agentes” — o que o projeto é, como buildar, como testar, quais convenções valem e o que não deve ser tocado.

Sem esse arquivo, cada sessão recomeça do zero. O agente infere stack, estrutura e limites a partir do que encontra no caminho. Com ele, o contexto chega antes da primeira linha gerada.

O que o arquivo resolve

A diferença não é mágica. É sinal certo no lugar certo.

Times que mantêm context files bem escritos reportam menos erro e tarefas concluídas mais rápido — mesmo modelo, mesmo tipo de pedido, contexto diferente. Análise de projetos open source mostra o padrão que funciona: descrever o que o projeto é, onde as coisas moram, comandos exatos de build e teste, e fronteiras explícitas (o que não editar manualmente, o que não commitar, o que exige aprovação).

O formato é deliberadamente simples. Markdown puro. Sem schema rígido. O que importa é alta densidade de informação que o agente erraria se não lesse: versão do runtime, pasta de migrações, estilo de PR, política de dependências, caminhos que são só leitura.

AGENTS.md e skills se complementam. O primeiro diz “aqui é o projeto e assim se trabalha nele”. O segundo diz “assim se faz este tipo de tarefa”. Um não substitui o outro.

O que evitar

Arquivo longo demais: Passado de cerca de 200 linhas, a adesão cai. Procedimentos multi-etapas cabem melhor em skills ou sub-agentes.
Regras genéricas: “Escreva código limpo” não ajuda; comando concreto e limite concreto ajudam.
Fragmentação: Manter um arquivo por ferramenta (CLAUDE.md, .cursor/rules, copilot-instructions...) e deixá-los divergir. A tendência de 2026 é um AGENTS.md canônico e, se necessário, um arquivo específico da ferramenta apontando para ele. O Claude Code passou a ler AGENTS.md nativamente.

O que muda na engenharia

Contexto deixa de ser conversa repetida em cada sessão. Vira artefato versionado, revisável, compartilhado pelo time. Quem entra no projeto — humano ou agente — encontra a mesma base.

Isso não elimina supervisão. Reduz o volume de chute e de retrabalho que nasce de contexto incompleto. Delegar com AGENTS.md bem feito é delegar com menos surpresa.

Quem ainda não tem o arquivo está pagando o custo de reexplicar o repositório a cada agente, a cada ferramenta, a cada sessão.

Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa.

📚 Aprofunde-se no Tema

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:

🎟️ Cupom de 30% OFF: LEIA30

📖 Disponível também no Kindle Unlimited

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #AGENTS.md #EngenhariaDeContexto #AgentesDeCodigo #EngenhariaDeSoftwareAssistidaPorIA