DEV Community: Alex Pimenta

O engenheiro não precisa escrever cada linha — mas precisa decidir o que vale herdar de volta

Alex Pimenta — Sat, 19 Sep 2026 13:52:12 +0000

Código escrito por agente já deixou de ser novidade. No Barômetro de Desenvolvedores da BairesDev (Q3 2026), 42% dos profissionais afirmaram que a IA escreve pelo menos metade do código deles. Um ano antes, o índice era 12%. Em outra leitura de mercado, cerca de 47% do código do mês anterior já vinha sendo gerado por agentes. O volume mudou. A responsabilidade, no entanto, não sumiu — só trocou de lugar.

Um agente pega a especificação, navega o repositório e devolve implementação. Às vezes antes de o humano digitar muito. O tempo de produção cai. O tempo de decisão permanece — e em muitos times aumenta, porque agora é preciso filtrar o que volta.

Liad Elidan, CEO da Milestone, descreveu o deslocamento de forma direta: código gerado por IA ainda exige alguém que revise, corrija e mantenha. O engenheiro passa a calibrar quanto trabalho entregar e quanto herdar de volta. Não se trata de “saber mais prompt”. Trata-se de delimitar fronteira.

Quando o volume sobe, a tentação é tratar o retorno do agente como quase pronto. “Quase pronto” sem critério vira fila de revisão, retrabalho e surpresa em produção. Os mesmos dados mostram outra face: 41% dos desenvolvedores dizem que praticamente nenhum código de IA chega à produção sem olhar humano específico. E 58% relatam maior accountability pessoal pelo código que não escreveram por completo.

Se o engenheiro não consegue explicar o que o trecho faz e por que funciona daquela forma, a organização tende a bloquear o merge. Em um cenário ainda sem explicabilidade automática confiável, sobra a explicabilidade humana.

Na prática, isso exige decisões concretas. O que o agente pode alterar sem revisão. O que precisa de evidência antes do merge. Quais partes do sistema são sensíveis demais para delegação ampla. Qual o critério mínimo de “bom o suficiente para embarcar”. Quem não define isso herda tudo de volta — só que em volume maior e com menos contexto de origem.

A autonomia do agente não elimina responsabilidade. Ela concentra a responsabilidade no momento em que a decisão de aceitar acontece. Escrever sintaxe ficou mais barato. Definir o que deve existir, sob quais restrições, e o que pode ser aceito sem reabrir o problema continua sendo o trabalho caro — e continua sendo humano.

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).

Quem quiser aprofundar o tema de forma estruturada — do contexto à governança de agentes — pode consultar a série:

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

Fontes

•Liad Elidan, “The software engineer’s role is moving beyond code”, Ctech, 19/09/2026
•BairesDev Q3 2026 Dev Barometer
•Dados complementares de adoção e accountability em análises de mercado 2026 (leituras alinhadas a JetBrains Research)

Tags:

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #DesenvolvimentoDeSoftware #AgentesDeCodigo #DelegacaoTecnica #CodeReview #EngenhariaDeSoftwareAssistidaPorIA

Se a IA não precisa de legibilidade, por que parar em C?

Alex Pimenta — Thu, 17 Sep 2026 15:01:40 +0000

Um post no X defendeu que uma das linguagens mais importantes do futuro pode ser C. Não C++. Não Python. Não Rust.

A lógica é direta: as abstrações de alto nível existem porque humanos erram com gerenciamento de memória, ponteiros e concorrência. Se a IA escreve a maior parte do código, esse custo de legibilidade vira overhead. C volta a ser eficiente, pequeno e perto do hardware.

A tese tem força. O problema é o que vem depois do "gera".

Estudos recentes sobre C e C++ gerados por LLM mostram um padrão inconveniente:

Compila e muitas vezes passa no teste superficial.
Em runtime, vazamento de heap, hangs e violações aparecem com frequência maior do que no código humano.
Em um benchmark de C++, a chance de violação confirmada em runtime ficou cerca do dobro no código de IA, mesmo controlando tamanho e taxa de testes.
Em análises multi-linguagem, C e C++ concentraram mais problemas de memory safety, secrets e uso ruim de criptografia do que Python e Java.

A IA não comete os mesmos erros que o programador humano. Ainda assim, comete erros. Em C, esses erros são baratos de introduzir e caros de encontrar.

Aí entra o reductio. Se a premissa é "não precisa de review humano porque a IA não esquece bounds check", o destino lógico não é C. É código de máquina — binário direto para a arquitetura. Por que parar no meio do caminho?

Porque, na prática, ainda precisamos de alguém que entenda o que foi gerado. Alguém que revise, corrija e delegue o próximo ajuste. Linguagem legível não é luxo de humano lento — é requisito de supervisão. Quanto mais opaca a saída, mais caro fica o code review e mais frágil fica a correção pontual.

Onde C ainda faz sentido:

Kernel e sistemas operacionais
Sistemas embarcados
Caminho quente (hot path) de alta performance
Legado crítico que não pode ser reescrito

Nesses casos, o domínio exige C — e quem delega precisa dominar C. Fora deles, empurrar a geração para C "porque a IA não precisa de abstração" troca um custo de runtime por um custo de manutenção e de confiança.

Rust aparece no debate como meio-termo: performance com o compilador como aliado de segurança. Funciona em parte, mas o ponto central não muda: enquanto o humano continuar responsável pelo que entra em produção, a linguagem precisa ser legível para esse humano.

C não morreu. Também não virou automaticamente a linguagem do futuro só porque a IA escreve rápido. O que falta na tese é o verificador final: quem confere, quem corrige, quem decide o que sobe.

E você: em que cenário ainda pediria C para um agente?

Fontes:

The Reliability Gap: A Multi-Dimensional Technical Audit of Memory Safety and Logical Integrity in LLM-Generated C Code (Jarrin et al., 2026)
The Illusion of Safety: Multi-Tier Verification of AI vs. Human C++ Code (arXiv:2607.00107)
Security and Quality in LLM-Generated Code: a Multi-Language, Multi-Model Analysis
Discussões públicas sobre o papel de C na era de código gerado por IA

Leia o artigo mais aprofundado.

Publiquei o artigo aprofundado no meu blog:👇

📚 Autor da série "Engenharia de Software Assistida por IA" (disponível na Amazon).

Quem quiser aprofundar supervisão, auditoria e delegação técnica de código gerado por IA encontra o tema tratado de forma estruturada na série Engenharia de Software Assistida por IA.
🎟️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível também no Kindle Unlimited

#EngenhariaDeSoftware #IA #LinguagemC #Seguranca #MemorySafety #Rust #CodeReview #Verificacao #GovernancaIA #FuturoDaEngenharia

Nem todo agente é igual: o que 37 mil PRs revelam sobre qualidade depois do merge

Alex Pimenta — Thu, 17 Sep 2026 12:45:58 +0000

O agente abre o pull request. O time aprova. O que acontece depois?

Um estudo recente analisou 37.623 PRs com proveniência marcada de cinco agentes comerciais — OpenAI Codex, Devin, GitHub Copilot, Cursor e Claude Code —, além de um baseline humano. Os dados cobrem 2.807 repositórios no GitHub entre dezembro de 2024 e julho de 2025.

Três resultados principais se destacam:

1. Taxa de Revert (Diferenças por Fornecedor)

OpenAI Codex: Apresentou a menor taxa de reversão, sendo revertido cerca de metade das vezes em comparação ao código humano (6,1% contra 11,5%).
Devin: Ficou no outro extremo, registrando uma taxa de revert superior à humana, com 14,5%.

2. Security Smells (Débito de Segurança)

No agregado, o código gerado por agentes apresentou menos security smells do que o código escrito por humanos (odds ratio de 0,63).
A melhoria foi puxada principalmente por um menor índice de credenciais hardcoded e menos construtos inseguros no estilo eval.

3. Esforço e Tempo de Code Review

O esforço de revisão humana não é distribuído de forma uniforme entre as ferramentas.
GitHub Copilot: Atraiu mais revisões e pedidos de mudança.
Claude Code: Enfrentou maior tempo de espera até o primeiro review humano, com uma mediana de 12,6 horas.

O Que Importa de Verdade

O estudo não conclui que os agentes são simplesmente "melhores" ou "piores". Ele demonstra que o comportamento pós-merge muda drasticamente conforme a ferramenta utilizada — impactando taxa de reversão, segurança e carga de revisão de código.

Quem trata "agente de IA" como uma categoria única perde o detalhe operacional mais importante: qual ferramenta usar, em qual tipo de mudança e com qual custo de manutenção posterior.

Qualidade depois do merge continua sendo o verificador real que nenhum benchmark consegue isolar sozinho.

📚 Fonte e Leitura Aprofundada

Paper de referência: Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild (arXiv:2609.17598).

Leia o artigo mais aprofundado, com exemplos e a análise completa clicando na imagem abaixo:

Para quem deseja se aprofundar na supervisão e auditoria de código gerado por IA, o tema é tratado de forma estruturada na série Engenharia de Software Assistida por IA (disponível na Amazon).

💡 Destaques:

🏷️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível também no Kindle Unlimited!

#EngenhariaDeSoftware #InteligenciaArtificial #IA #SoftwareEngineering #AIAgents #CodeReview

Quando vale a pena um servidor on-premises só para IA de desenvolvimento? E quando ainda não é a hora?

Alex Pimenta — Wed, 16 Sep 2026 19:42:31 +0000

O gasto com agentes e modelos em nuvem não para de subir. Alguém no time sempre pergunta: e se a gente rodasse o modelo aqui dentro?

Para cinco desenvolvedores, a resposta costuma ser frustrante: se a motivação for só cortar custo, a conta quase nunca fecha.

Um servidor decente com GPU boa sai entre R$ 80 mil e R$ 200 mil (às vezes mais). Enquanto isso, Copilot, Claude Code, Cursor e similares ficam na casa de 20 a 100 dólares por pessoa por mês. O payback, no cenário otimista, passa de quatro anos. Em um ano e meio, dois no máximo, o hardware já começa a ficar apertado de VRAM — e alguém precisa manter driver, container, rede e segurança.

A nuvem troca o modelo sem avisar. O servidor local não.

Quando Ainda Não É a Hora

Para times pequenos, com uso moderado, código que pode circular via API e pouca paciência para virar operador de GPU, o modelo de assinatura + API continua sendo a opção mais simples e barata no horizonte de 2 a 3 anos. Caching bem-feito na nuvem derruba o custo efetivo por token de um jeito que a planilha de hardware local raramente consegue acompanhar.

Quando a Conversa Muda

Existem cenários específicos onde a infraestrutura própria deixa de ser capricho:

Conformidade e Regulação: O código não pode sair da rede devido a contratos, LGPD ou regras de clientes regulados. Nesses casos, a decisão deixa de ser financeira e vira requisito de compliance.
Volume Alto e Estável: Consumos na casa de dezenas de milhões de tokens por mês, com uso contínuo e pouca variação, tornam a amortização competitiva.
Alternativa Híbrida (Dev Workstation): Colocar memória alta nas máquinas dos próprios devs (Apple Silicon com 64/128 GB ou GPU local) rodando modelos de 8B a 32B via Ollama ou vLLM para autocomplete e tarefas leves. O modelo pesado continua na nuvem, reduzindo o drama operacional.
Servidor Compartilhado para Times Maiores: Utilizar vLLM + um proxy compatível com a API da OpenAI (como LiteLLM). Sob uso compartilhado de GPU, o custo total pode ficar cerca de 40% abaixo de APIs com cache. No entanto, modelos locais fracos aumentam o tempo gasto em debug — e economia de token não é o mesmo que economia de tempo de engenheiro.

O Que Importa de Verdade

Repatriar inferência é totalmente possível: há papers, stack madura e cases reais. Mas "funciona" não é o mesmo que "vale a pena agora".

A pergunta prática a se fazer é: qual parte do fluxo precisa ficar local (privacidade, latência, previsibilidade) e qual parte ainda depende da qualidade do modelo de ponta?

Quem compra servidor achando que vai zerar a fatura da nuvem frequentemente descobre custos escondidos de operação, obsolescência e perda de qualidade. Quem usa o ambiente local de forma estratégica (sigilo, volume estável ou arquitetura híbrida) extrai valor sem transformar a equipe em time de infraestrutura.

📚 Fontes da Pesquisa e Leitura Complementar

Análise de viabilidade técnica/financeira.
Inference Economics of Enterprise Coding Agents (arXiv:2607.13080).
Arquiteturas vLLM / PagedAttention e discussões de mercado sobre cloud repatriation.

Leia o artigo mais aprofundado com levantamento de valores.

Publiquei o artigo aprofundado no meu blog:👇

Clique aqui para ler o artigo completo.

📚 Autor da série "Engenharia de Software Assistida por IA" (disponível na Amazon).

Quem quiser aprofundar arquitetura, delegação e governança de ferramentas de IA no desenvolvimento encontra o tema tratado em detalhes na série Engenharia de Software Assistida por IA, com destaque para o Volume IV (Arquitetura e Design de Soluções na Era da IA) e o Volume VIII (Engenharia de Contexto e Governança de IA).

💡 Destaques:

🏷️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível também no Kindle Unlimited!

👉 Série eBook completa

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

#EngenhariaDeSoftware #InteligenciaArtificial #IA #OnPremise #LLM #SoftwareEngineering

Os agentes de código convergiram: por que o ranking do SWE-bench já não ordena os melhores?

Alex Pimenta — Wed, 16 Sep 2026 12:06:40 +0000

Pequenas diferenças no leaderboard viraram ranking. Não deveriam.

Um paper de 15 de setembro de 2026 auditou 254 submissões do SWE-bench — sem rodar modelo nenhum, apenas analisando o que já estava publicado.

Os Dados da Convergência

Sobreposição alta: No split Verified, os dois primeiros resolvem 396 de 500 instâncias cada um. Os dez primeiros compartilham 285 sucessos e 51 falhas, sobrando apenas 164 instâncias que de fato os separam.
Comportamento idêntico: O median nesting é de 0,935 nos conjuntos de solução da fronteira — bem acima do que o score sozinho sugeriria (0,774). Em outras palavras: os líderes acertam quase as mesmas coisas.

O Peso do Scaffold vs. Modelo

O score depende diretamente do par modelo + scaffold.

Dentro do mesmo modelo, a variação de scaffold chega a 29,8 pontos percentuais, enquanto o spread dos trinta primeiros no ranking geral é de apenas 8,8 pontos. Trocar a estrutura de orquestração mexe mais no número do que a diferença "entre os melhores" exibida pelo leaderboard.

O que isso muda na prática?

Quem escolhe ferramenta só pelo lugar no ranking está olhando um indicador que já não ordena bem. O que importa medir passa a ser:

Estabilidade em instâncias difíceis;
Custo por resolução;
Comportamento sob scaffolds diferentes;
Capacidade de manter o que já funciona no repositório real.

O paper não invalida o SWE-bench, mas mostra seu limite atual quando os sistemas da ponta convergem. Times que tratam o número do leaderboard como verdade absoluta tendem a otimizar para o benchmark — e não para o seu repositório real.

📚 Fonte e Leitura Complementar

Paper original: Coding Agents Have Converged: Why the SWE-bench Leaderboard Can No Longer Order Its Top Entries, and What to Measure Instead (arXiv:2609.17394, setembro/2026).

Leia a análise completa e aprofundada com todos os exemplos de arquitetura clicando no link abaixo:

Artigo completo artigo no Hashnode.

Para quem deseja aprofundar a avaliação e governança de agentes, o tema é tratado de forma estruturada na série Engenharia de Software Assistida por IA, com foco nos Volumes VI (Supervisão e Auditoria de Código Gerado por IA) e VIII (Engenharia de Contexto e Governança de IA).

💡 Destaques:

🏷️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível também no Kindle Unlimited!

👉 Série eBook completa

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

#EngenhariaDeSoftware #SWEBench #AgentesDeIA #Benchmarks #Avaliacao #GovernancaIA #CodeReview #FuturoDaEngenharia

Técnicas de resiliência: o que realmente segura o sistema quando algo quebra

Alex Pimenta — Tue, 15 Sep 2026 21:11:49 +0000

Sistema distribuído falha. A pergunta útil não é se vai falhar. É o que acontece quando falha.

Os Blocos Fundamentais de Resiliência

Timeout: Corta espera infinita. Sem ele, uma chamada travada segura thread, conexão e, em cascata, o restante do fluxo.
Retry com Backoff e Jitter: Trata falha transitória (rede instável, serviço reiniciando). Sem jitter, vários clientes retentam juntos e pioram o problema.
Circuit Breaker: Para de martelar o que já está caindo. Depois de N falhas, abre. As próximas chamadas falham rápido, sem consumir recurso. Depois de um tempo, testa de novo.
Bulkhead: Isola pool de threads ou conexões por dependência. Uma integração lenta não engole o resto.
Rate Limiting e Load Shedding: Protegem o lado que recebe. Um corta excesso de chamadas; o outro descarta o que tem prioridade baixa quando a carga passa do limite.
Deadline Propagation: Carrega o tempo restante entre serviços. Evita trabalho zumbi (processar algo cujo cliente já desistiu).

Arquiteturas e Paradigmas

Microsserviços

Em microsserviços, muita coisa saiu do código e foi para a malha. Service mesh (Istio, Linkerd, Envoy) configura retry, timeout e circuit breaker em YAML. Sidecar cuida disso ao lado de cada serviço. Para transações distribuídas, Saga (orquestrada ou coreografada) evita two-phase commit. Outbox garante que o evento saia depois da escrita no banco. Idempotency keys tornam o retry seguro em pagamento e pedido.

Serverless

Serverless muda o desenho. Função pode ser reexecutada pelo provedor, tornando a idempotência obrigatória. Exige timeout curto por função e DLQ para isolar o que falha repetidamente. Step Functions (ou Durable Functions) orquestram etapas com retry nativo.

Frontend

No frontend, o mesmo raciocínio aparece em outra forma: retry no client, circuit breaker para não bombardear API já fora, cache com stale-while-revalidate, Optimistic UI com rollback, Error Boundary para isolar componente sem derrubar a tela inteira e estratégia offline-first com fila de ações.

Banco de Dados e Mensageria

Possuem seu próprio conjunto: connection pool com limite (bulkhead de fato), read replica com failover, DLQ, schema registry e consumer com backoff.

Observabilidade

Observabilidade não é detalhe. Tracing distribuído mostra onde a falha começou. SLO e error budget dizem quanto de confiabilidade o time pode "gastar" em troca de velocidade. Sem isso, as técnicas acima viram configuração no escuro.

Resumo Prático por Camada

Frontend sozinho: Retry, cache local, error boundary, offline-first.
Vários clientes + API instável: BFF/Gateway centralizando circuit breaker, retry e cache.
Microsserviços: Mesh + Saga + Outbox + Bulkhead + DLQ.
Serverless: Idempotência + DLQ + timeout curto.
Banco de dados: Pool, replica, failover.

O Ponto Central

Resiliência não é lista de libs. É decidir, por camada, o que falha isolado e o que propaga.

Quanto mais o código é gerado por agentes, mais essa decisão precisa estar explícita no contexto e na arquitetura — senão o sistema ganha velocidade e perde capacidade de sobreviver à falha.

📚 Artigo Completo e Leituras Recomendadas

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

Quem quiser aprofundar arquitetura e design de soluções na era da IA encontra o tema tratado de forma estruturada no Volume IV da série Engenharia de Software Assistida por IA.

💡 Destaques:

🏷️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível também no Kindle Unlimited!

👉 Série eBook completa

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

#SoftwareEngineer #Resilience #SoftwareArchitecture #Microservices #AI #Csharp #Typescript #DotNet #Java #Javascript #DevOps

Code review com agentes na prática: o que a Ericsson testou

Alex Pimenta — Tue, 15 Sep 2026 12:55:40 +0000

O volume de código gerado por agentes cresceu. A revisão humana não acompanhou no mesmo ritmo.

Um estudo recente da Ericsson, publicado no arXiv em setembro de 2026 (Using Agentic AI for contextualized and multifaceted code review at Ericsson), testou uma saída diferente: usar agentes especializados para fazer code review com contexto real do projeto.

A equipe seguiu Design Science Research e avaliou a solução em commits reais da empresa. O sistema combina skills de agentes com conhecimento específico do ambiente e analisa mudanças em quatro eixos:

Legibilidade
Manutenibilidade
Confiabilidade
Performance

Os Resultados

+200 issues identificadas
96% de acurácia na detecção correta (validada pelos próprios desenvolvedores)
69% das issues consideradas importantes
33% classificadas como severas (precisam ser corrigidas)
36% classificadas como importantes (deveriam ser corrigidas)

Não foi um benchmark genérico. Foi avaliação industrial.

O ponto que interessa

O agente de review não funcionou bem só porque o modelo é forte. Funcionou porque recebeu contexto do projeto e skills orientadas a antipadrões reais daquele código. Sem isso, a tendência é gerar comentários genéricos — ou pior, comentários que parecem úteis e não são.

Times que só aumentam a geração sem ajustar a revisão tendem a acumular fila. Times que tratam a revisão como parte do processo — com critérios, contexto e algum grau de automação assistida — conseguem absorver mais volume sem perder o filtro.

O estudo não afirma que o review humano acabou. Mostra que, com o contexto certo, agentes conseguem fazer a primeira triagem com precisão útil. O resto continua com quem decide o que entra em produção.

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

Publiquei o artigo aprofundado no meu blog:👇

Clique aqui para ler o artigo completo.

📚 Autor da série "Engenharia de Software Assistida por IA" (disponível na Amazon).

Quem quiser aprofundar supervisão e auditoria de código gerado por IA encontra o tema tratado de forma estruturada no Volume VI da série Engenharia de Software Assistida por IA.

💡 Destaques:

🏷️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível também no Kindle Unlimited!

👉 Série eBook completa

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

Fonte:

Using Agentic AI for contextualized and multifaceted code review at Ericsson (arXiv:2609.15877, setembro/2026)

EngenhariaDeSoftware #InteligenciaArtificial #IA #SoftwareEngineering #AIAgents #CodeReview

A realidade continua sendo o verificador final: os dois gaps da Engenharia de Software com agentes

Alex Pimenta — Mon, 14 Sep 2026 15:39:21 +0000

Agentes de código operam em um ciclo de implementação e verificação.

Eles geram uma mudança, rodam testes ou outras checagens e, se o avaliador aceita, a tarefa é considerada concluída.

O problema é que esse avaliador quase nunca é a realidade de produção.

Ele é um proxy.

Um paper recente no arXiv (Reality Is the Final Verifier: On Two Key Gaps in Agentic Software Engineering, setembro/2026) organiza essa limitação em dois gaps principais:

1. Requirement Gap

O conjunto de requisitos (explícitos ou implícitos) que o agente recebeu não cobre tudo o que realmente importa.

Restrições de arquitetura, padrões do time, efeitos colaterais e critérios de aceite muitas vezes ficam de fora.

Quando isso acontece, o agente pode "resolver" o problema formal e ainda assim produzir uma mudança inadequada.

2. Model Gap

O ambiente de avaliação (testes, sandbox, simulação) não representa fielmente o ambiente real.

O agente otimiza para o que o modelo de avaliação consegue medir.

O que não está coberto por esse modelo tende a passar despercebido.

Esses dois gaps explicam boa parte dos comportamentos problemáticos observados com agentes: patches que passam nos testes e falham depois, soluções que exploram brechas da especificação e alucinações que preenchem lacunas com premissas incorretas.

O ponto central

Tudo o que usamos antes da produção — testes, benchmarks, revisões automatizadas — são aproximações.

A realidade continua sendo o verificador final.

Isso não significa abandonar agentes.

Significa tratar requisitos, contexto e critérios de verificação como parte estrutural do processo, e não como detalhes opcionais.

Quanto mais o volume de código gerado aumenta, mais caro fica descobrir tarde que a mudança só era válida dentro do modelo de avaliação — e não no sistema real.

📚 Artigo Completo e Leituras Recomendadas

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

📚 Autor da série "Engenharia de Software Assistida por IA" (disponível na Amazon).

Fonte:

Reality Is the Final Verifier: On Two Key Gaps in Agentic Software Engineering (arXiv:2609.12039, setembro/2026)

Quem quiser aprofundar o tema de forma estruturada pode consultar a série Engenharia de Software Assistida por IA, em especial os volumes sobre Requisitos, Supervisão e Governança.

💡 Destaques:

🏷️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível também no Kindle Unlimited!

👉 Série eBook completa

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

#EngenhariaDeSoftware #InteligenciaArtificial #IA #SoftwareEngineering #AIAgents

AI Code Slop: como o excesso de código gerado por agentes está mudando a revisão de código

Alex Pimenta — Fri, 11 Sep 2026 16:40:43 +0000

Agentes de código passaram a gerar volume alto de mudanças em pouco tempo.

O efeito colateral mais visível não é só na velocidade de implementação, mas na forma como arquitetos e revisores lidam com o que chega.

Um artigo publicado pela IEEE Spectrum em 8 de setembro de 2026 (AI Slop Is Changing How Engineers Review Code) descreve bem este movimento. A expressão "AI Code Slop" vem sendo usada para se referir ao excesso de código gerado por agentes que, embora funcional, ainda exige revisão humana.

O que os dados nos mostram

Segundo o texto da Spectrum, a maior parte dos desenvolvedores ainda não confia plenamente no código produzido pelos agentes de IA. Em uma das pesquisas citadas, 96% afirmaram que não consideram o resultado confiável o suficiente sem verificação adicional.

O volume de código aumentou, mas a confiança não está no mesmo patamar.

Isso tem consequências diretas no processo de revisão. O que antes era uma etapa relativamente previsível passa a lidar com mais pull requests, mais trechos gerados automaticamente e mais necessidade de julgar se a mudança respeita o contexto do projeto, os padrões internos e as decisões arquiteturais já existentes.

Como as empresas estão reagindo

O artigo descreve algumas práticas que já estão sendo testadas:

Revisar o plano antes de deixar o agente gerar código
Usar agentes especializados para uma primeira triagem (testes, segurança, aderência ao plano etc.)
Exigir que o desenvolvedor consiga explicar e defender o código que o agente produziu

A lógica por trás dessas mudanças é a seguinte: se o volume de código aumenta e a confiança não, a revisão precisa ser obrigatória, reorganizada e contínua em várias etapas de desenvolvimento. Deixar tudo para o final tende a criar filas e retrabalho com volume alto de reimplementação.

O ponto que importa

O problema não é apenas a qualidade individual em cada patch, mas o acúmulo de mudanças que passam em testes e que ainda exigem intervenção humana para se tornarem aceitáveis no repositório e na esteira de implementação e deploy em produção.

Nesse cenário, a supervisão deixa de ser um detalhe operacional e passa a ser parte estrutural do processo. Quem trata a revisão como uma etapa que "dá conta" do volume extra, costuma sentir o custo mais cedo.

Conclusão

A geração de código aumentou muito; portanto, a revisão está sendo forçada a se adaptar.

Em equipes de desenvolvimento de software que conseguem combinar velocidade de geração com critérios claros de aceite, seguindo checklists homologados e rígidos de controle de qualidade, limites (boundaries) de contexto e supervisão tendem a ter resultados melhores.

Equipes que apenas aumentam o volume sem ajustar o processo de revisão acumulam retrabalho.

📚 Artigo Completo e Leituras Recomendadas

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

Quem quiser se aprofundar no tema de forma estruturada pode consultar a série Engenharia de Software Assistida por IA, em especial o Volume VI – Supervisão e Auditoria de Código Gerado por IA.

💡 Destaques:

🏷️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível também no Kindle Unlimited!

👉 Série eBook completa

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

Fonte:

Aaron Mok - AI Slop Is Changing How Engineers Review Code (IEEE Spectrum, 8 de setembro de 2026)

EngenhariaDeSoftware #InteligenciaArtificial #IA #SoftwareEngineering #AIAgents #CodeReview

Passar nos testes não é suficiente: o que o benchmark SWE-Gate revelou sobre agentes de código

Alex Pimenta — Thu, 10 Sep 2026 13:06:40 +0000

Agentes de código têm avançado rápido na capacidade de gerar patches que passam em testes funcionais.

Mas passar nos testes não significa, automaticamente, que a mudança está pronta para ser aceita em um repositório real.

É o que mostra o benchmark SWE-Gate, apresentado em setembro de 2026 no arXiv (SWE-Gate: Passing Functional Tests Is Not Enough for Software Engineering Agents).

Os pesquisadores construíram 303 instâncias de reparo em nível de repositório, baseadas em 75 projetos open-source em Python. Além dos testes funcionais, eles incluíram restrições de revisão extraídas de comentários reais de pull requests.

O resultado foi claro:

Entre 644 reparos que passaram nos testes funcionais
221 falharam nas restrições de revisão

Ou seja: o agente resolveu o problema do ponto de vista dos testes, mas ainda violou critérios que revisores humanos normalmente exigem — padrões do projeto, limites arquiteturais, estilo, restrições implícitas ou decisões de design.

O que isso muda na prática

Avaliar agentes apenas por "passou no teste" cria uma falsa sensação de prontidão.

Em ambientes reais, a aceitação de uma mudança depende também de:

Conformidade com o estilo e as convenções do repositório
Respeito a decisões arquiteturais já existentes
Ausência de efeitos colaterais não cobertos pelos testes
Alinhamento com restrições que nem sempre estão escritas de forma explícita

O gap entre "funciona" e "é aceitável" continua sendo um dos principais pontos de atenção para quem usa agentes em produção.

Conclusão

A capacidade de gerar código que passa em testes aumentou.

A capacidade de gerar mudanças que sobrevivem à revisão humana e às restrições do projeto ainda é desigual.

Para times que usam agentes no dia a dia, o critério de sucesso precisa ir além do verde no pipeline.

📚 Artigo Completo e Leituras Recomendadas

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

Quem quiser aprofundar o tema de forma estruturada — supervisão, auditoria e governança de código gerado por IA — pode consultar a série Engenharia de Software Assistida por IA.

💡 Destaques:

🏷️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível também no Kindle Unlimited!

👉 Série eBook completa:

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon:

Fonte:

Xin He et al. - SWE-Gate: Passing Functional Tests Is Not Enough for Software Engineering Agents (arXiv:2609.04167, setembro/2026)

EngenhariaDeSoftware #InteligenciaArtificial #IA #SoftwareEngineering #AIAgents #CodeReview #DevTo

O risco escondido na configuração dos agentes: o que um estudo de 3.171 repositórios revelou

Alex Pimenta — Wed, 09 Sep 2026 15:20:54 +0000

Agentes de código como Claude Code, Cursor, GitHub Copilot e OpenAI Codex não funcionam só com o modelo. Eles dependem de uma camada de configuração que os desenvolvedores escrevem e compartilham: arquivos de instrução, skills, hooks, declarações de MCP servers e subagentes.

Essa camada é chamada de harness.

Ela é instalada a partir de marketplaces e repositórios públicos, roda com os privilégios do desenvolvedor, persiste entre sessões — e, até agora, quase não tinha sido tratada como uma dependência de verdade.

Um estudo recente no arXiv (Scanning the Harness: An Empirical Study of Supply-Chain Defects in AI Coding-Agent Configurations, setembro/2026) analisou exatamente essa superfície.

O que o estudo fez

Os pesquisadores examinaram 3.171 repositórios públicos no GitHub:

2.660 setups que combinam dois ou mais tipos de componentes
511 coleções de skills publicadas

Eles mediram apenas regras objetivas (decisíveis a partir dos arquivos) e validaram cada achado antes de contabilizar.

Os números principais

Três classes de risco de segurança sobreviveram à validação:

9,8% dos setups instalam um MCP server sem versão fixada
3,1% pré-aprovam execução arbitrária de comandos por trás de uma permissão que parece restrita (ex.: Bash(python:*))
3,8% carregam uma skill que pré-aprova o shell para quem instalar

No total:

16% dos setups carregam pelo menos um defeito de segurança
16,7% carregam algum defeito confirmado

Por que isso importa

A harness funciona como uma camada de dependência, mas sem as proteções que já existem em outras partes do ecossistema:

Não há lockfile
Não há verificação no momento da instalação
Não existe um vocabulário claro do que cada componente pode fazer

Na prática, o desenvolvedor (ou o time) pode estar importando permissões e comportamentos de terceiros sem perceber o alcance real dessas permissões.

O que muda na prática

Quem usa agentes no dia a dia precisa começar a tratar a configuração do agente com o mesmo cuidado que trata dependências de código:

Fixar versões sempre que possível
Revisar o que skills e MCP servers realmente autorizam
Evitar pré-aprovações amplas disfarçadas de permissões restritas
Tratar marketplaces e coleções públicas como fonte de risco, não só de produtividade

A velocidade de geração de código aumentou.

A superfície de configuração dos agentes também cresceu — e ainda está pouco governada.

📖 Leituras Recomendadas

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

Artigo completo.

Quem quiser aprofundar o tema de forma estruturada pode consultar a série Engenharia de Software Assistida por IA.

💡 Destaques:

🏷️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível também no Kindle Unlimited!

👉 Série eBook completa

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

softwareengineering, #artificialintelligence, #cybersecurity, #devops, #softwarearchitecture

Além da geração de código: o custo real da verificação na era dos agentes

Alex Pimenta — Tue, 08 Sep 2026 23:58:07 +0000

A capacidade de gerar código com agentes avançou rápido.

O que ainda não avançou na mesma proporção é a capacidade de transformar esse código em mudança confiável de produção.

Um paper recente no arXiv (Beyond Code Generation: Reliability, Verification, and Cost Economics in the Agentic Software Development Lifecycle, setembro/2026) sintetiza evidências de 2024 a 2026 e propõe um conceito útil: o Verification Tax — o custo adicional de revisar, testar, integrar e validar o que os agentes produzem em volume.

O que os dados mostram

Estudos de campo e telemetria indicam ganhos relevantes na atividade de escrita de código. Porém esses ganhos diminuem de forma acentuada quando se observa o que realmente chega em produção de forma estável.

O paper organiza o problema em quatro ideias:

Agentic SDLC Throughput Paradox: Mais código gerado não se traduz automaticamente em mais software entregue com qualidade.
Production-Qualified Change (PQC): Nem toda mudança que passa em testes locais está pronta para produção. Falta ainda o filtro de revisão, contexto, segurança e operação.
Verification Tax: Quanto mais volume os agentes geram, maior tende a ser o esforço (e o custo) de verificação humana e automatizada.
Control Plane: A necessidade de um mecanismo que decida quanto de autonomia conceder ao agente com base em custo, confiabilidade e atenção humana disponível.

Por que isso é importante agora

Enquanto o mercado ainda discute "qual agente gera melhor", o gargalo real está se deslocando para:

Revisão de mudanças em maior volume;
Rastreabilidade da origem do código;
Validação de contexto e intenção;
Custo variável de tokens, ferramentas e retrabalho.

"Gerar mais barato não elimina o custo de garantir que o que foi gerado é seguro, coerente e responsável."

O que muda na prática

Times que tratam agentes apenas como aceleradores de digitação tendem a acumular verificação e dívida.

Times que tratam agentes como participantes de um ciclo com critérios claros de aceite, supervisão e governança conseguem converter melhor o ganho de geração em entrega real.

A pergunta deixa de ser apenas "quanto código o agente consegue escrever?".

Passa a incluir: "quanto desse código conseguimos verificar, explicar e sustentar?".

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

Publiquei o artigo aprofundado no meu blog:👇

Clique aqui para ler o artigo completo.

📚 Autor da série "Engenharia de Software Assistida por IA" (disponível na Amazon).

📖 Leituras Recomendadas

Quem quiser aprofundar o tema de forma estruturada pode consultar a série Engenharia de Software Assistida por IA, em especial os volumes sobre supervisão, contexto e governança.

💡 Destaques:

🏷️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível também no Kindle Unlimited!

👉 Série eBook completa:

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon:

EngenhariaDeSoftware #InteligenciaArtificial #VerificationTax #AgenticSDLC #CodeReview #GovernancaIA #DORA #Produtividade #Qualidade #DebitoTecnico #DevOps #EngenhariaDeContexto