DEV Community: Alex Pimenta

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

A geração de código já superou o controle: o que a pesquisa da GitLab mostra sobre governança de IA

Alex Pimenta — Mon, 07 Sep 2026 11:33:50 +0000

A velocidade de geração de código aumentou. A capacidade de controlar o que entra em produção, na maior parte das organizações, não acompanhou no mesmo ritmo.

Essa é a conclusão central do 2026 AI Accountability Report da GitLab, pesquisa conduzida pela The Harris Poll com 1.528 profissionais de DevSecOps e compradores de tecnologia em seis países.

Os números são diretos e pouco ambíguos.

📊 O que a pesquisa encontrou

Adoção à frente da governança

80% das organizações afirmam ter adotado ferramentas de IA mais rápido do que desenvolveram políticas para governá-las.
92% relatam algum tipo de desafio de governança com código gerado por IA.
91% usam duas ou mais ferramentas de codificação com IA (sendo que 54% usam três ou mais).

O gargalo mudou de lugar

85% concordam que a IA deslocou o gargalo de "escrever código" para "revisar e validar".
84% apontam que o maior desafio não é gerar o código, e sim governar o que acontece depois que ele é criado.

Lacunas de rastreabilidade

87% se dizem confiantes de que conseguiriam determinar, em até 24 horas, se código gerado por IA contribuiu para um incidente em produção.
Na prática, 34% das organizações que tiveram incidente no último ano não conseguiram fazer essa determinação.
43% não conseguem distinguir de forma confiável, no próprio código-base, o que foi gerado por IA e o que foi escrito por humanos.

Percepção de risco

83% identificam o acúmulo de código gerado por IA como um risco a ser gerenciado agora.
44% o classificam como um dos principais riscos tecnológicos.

Em resumo: a geração acelerou. O controle, a rastreabilidade e a responsabilidade ainda estão em construção na maioria dos ambientes.

👔 Por que isso importa para quem lidera

Para CTOs, CISO, VPs e líderes de engenharia, o relatório descreve um descompasso estrutural, não um problema pontual de ferramenta.

Quando o volume de código sobe e a origem, a intenção e a responsabilidade de cada mudança não estão claras, três efeitos tendem a aparecer:

Revisão mais lenta e mais cara: Desenvolvedores passam a validar código que não escreveram e, em muitos casos, não entendem por completo. O ganho de velocidade na geração é parcialmente consumido no tempo de revisão.
Risco operacional difuso: Em incidentes, a dificuldade de responder "este trecho veio de agente?", "com qual contexto?" e "quem responde por ele?" aumenta o tempo de diagnóstico e o custo de correção.
Acúmulo silencioso de dívida: Código que "passa" na revisão, mas carrega decisões implícitas, padrões inconsistentes ou dependências pouco visíveis, tende a se acumular. O relatório chama atenção exatamente para esse acúmulo como risco atual, não futuro.

A frase que resume a posição da GitLab é direta: **velocidade sem controle deixa de ser vantagem e passa a ser passivo.**

❓ Três perguntas que a maioria ainda não responde bem

O relatório define accountability, neste contexto, como a capacidade de responder de forma confiável a três perguntas sobre qualquer trecho de código gerado por IA:

De onde este código veio?
O que ele deveria fazer?
Quem é responsável por ele depois que entra em produção?

A maior parte das organizações ainda não consegue responder a essas três perguntas de forma consistente. Isso não é um detalhe de processo — é o núcleo do problema de governança.

🛠️ O que muda na prática

O relatório não sugere frear o uso de agentes, mas sim realinhar o investimento. Enquanto a conversa de mercado ainda enfatiza "qual ferramenta gera mais rápido", os dados apontam para outra prioridade:

Tornar a origem do código rastreável.
Explicitar contexto e intenção por trás das mudanças.
Definir claramente responsabilidade e critérios de aceite.
Integrar políticas de governança ao fluxo real de desenvolvimento, e não apenas a documentos separados.

Organizações que já tratam governança como parte do ciclo (e não como camada posterior) tendem a converter melhor o ganho de geração em entrega estável. As que tratam governança como tema "para depois" acumulam risco e retrabalho.

📌 Conclusão

A pesquisa da GitLab descreve um momento de transição: a capacidade de gerar código já é amplamente disponível, mas a capacidade de controlar, rastrear e responsabilizar o que é gerado ainda é desigual e insuficiente.

Para quem lidera engenharia e produto, as perguntas fundamentais passam a ser:

Como sabemos a origem do que entra no sistema?
Como garantimos que o contexto e a intenção estão explícitos?
Como distribuímos responsabilidade de forma clara quando o volume sobe?

Velocidade continua importante. Porém, sem controle proporcional, ela deixa de ser diferencial e passa a ser fonte de risco operacional e de dívida técnica.

📌 Fonte principal:

GitLab - 2026 AI Accountability Report (pesquisa com 1.528 profissionais de DevSecOps e compradores de tecnologia, conduzida pela The Harris Poll).

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

📚 Quer aprofundar o tema de forma estruturada?

Do contexto à governança de agentes, você pode consultar a série Engenharia de Software Assistida por IA, em especial 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:

Acessar Série de eBooks na Amazon (Cupom 30% off: LEIA30)

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

💬 Na sua empresa, como vocês rastreiam se um código veio de IA ou foi escrito por humanos? Já possuem políticas claras para governança desse código? Compartilhe nos comentários!

Escrever código não é entregar software: a produtividade real dos agentes de IA

Alex Pimenta — Fri, 04 Sep 2026 19:23:56 +0000

A narrativa dominante sobre agentes de código é simples: eles aumentam a produtividade.

Os dados mais recentes e amplos disponíveis mostram que essa afirmação é verdadeira e incompleta.

Um estudo de 2026 (NBER Working Paper 35275), baseado em mais de 100 mil desenvolvedores do GitHub e em telemetria real de uso de ferramentas de IA, mediu o efeito de três gerações sucessivas de ferramentas:

Autocomplete
Agentes interativos (síncronos)
Agentes autônomos (assíncronos)

O resultado central é claro: os ganhos são grandes na escrita de código e diminuem de forma acentuada à medida que se aproxima da entrega.

📊 O que os números mostram

No nível de atividade de código (commits), a adoção cumulativa das três gerações eleva a produção em cerca de 180%. Esse efeito, porém, se atenua ao longo da cadeia de produção:

📈 Volume de linhas de código: sobe de forma muito mais acentuada.
🗂️ Número de projetos ativos: sobe cerca de 50%.
🚀 Número de releases: sobe apenas cerca de 30%.

Em outras palavras: triplicar a atividade de commits não se traduz em triplicar o software entregue.

Para agentes síncronos isoladamente, o padrão é ainda mais marcado: aumento de mais de 7 vezes no volume de linhas de código e de cerca de 65% em pull requests, com alta de apenas cerca de 20% em releases.

🔗 A hipótese do elo fraco (weak-link hypothesis)

Os autores interpretam o padrão como evidência da hipótese do elo fraco. A produção de software não é uma sequência de etapas independentes, mas uma cadeia de atividades complementares.

Quando uma etapa (escrever código) acelera muito e as demais (revisão, integração, testes, decisão de release e operação) não acompanham na mesma proporção, o ganho total fica limitado pelo elo mais lento.

A elasticidade de substituição estimada entre esforço de IA e esforço humano é baixa (cerca de 0,25). Isso indica complementaridade forte: a IA amplifica o que o time já consegue processar e decidir, mas não substitui os pontos em que ainda é necessário julgamento, coordenação e validação humana.

💡 O que isso significa na prática

O estudo ajuda a explicar um fenômeno que muitos times já observam no dia a dia:

🟢 Mais código sendo gerado
🟢 Mais pull requests abertos
🟢 Mais atividade visível no repositório
🔴 Entrega e estabilidade que não crescem na mesma proporção

Há também evidências complementares em outras fontes: código frequentemente bem avaliado na revisão surge associado a um aumento de incidentes e retrabalho após o deploy. A velocidade de geração sobe, mas a capacidade de absorver, verificar e estabilizar essa geração nem sempre acompanha.

Isso não invalida o uso de agentes. Mostra onde o retorno se concentra e onde ele se perde.

👔 Implicações para quem lidera engenharia

Medir o lugar certo: Commits e linhas de código são métricas de atividade, não de entrega. A métrica relevante precisa incluir o que de fato chega ao usuário e com que estabilidade.
Tratar a cadeia, não só a geração: Acelerar apenas a escrita de código sem reforçar revisão, testes, integração e critérios de release tende a acumular trabalho incompleto.
Investir nos elos humanos e de processo: Contexto claro, critérios de aceite, supervisão em camadas e governança deixam de ser "boas práticas" e passam a ser condições para converter velocidade de geração em entrega.
Separar produtividade de tarefa de produtividade de sistema: Um agente pode ser altamente produtivo em uma tarefa local e, ainda assim, gerar pouco ganho no sistema como um todo se o restante da cadeia não absorver o volume.

📌 Conclusão

Os dados disponíveis em 2026 mostram que os agentes aumentam de forma significativa a capacidade de escrever código. Mostram também que esse aumento se comprime à medida que o trabalho se aproxima da entrega.

Escrever mais código não é o mesmo que entregar mais software.

O gargalo de produtividade está se deslocando: de "quanto código conseguimos gerar?" para "quanto desse código conseguimos validar, integrar, estabilizar e colocar em uso de forma confiável?"

Times que tratam agentes apenas como aceleradores de digitação tendem a ver o funil se estreitar no meio do caminho.
Times que tratam a cadeia completa — do contexto à supervisão e governança — têm mais chance de converter o aumento de geração em resultado real.

📌 Fonte principal:

Demirer, M.; Musolff, L.; Yang, L. – Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools (NBER Working Paper 35275, 2026). Divulgado via CEPR/VoxEU.

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

📚 Quer aprofundar o tema de forma estruturada?

Do contexto à governança de agentes, você pode consultar a série Engenharia de Software Assistida por IA, em especial 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:

Acessar Série de eBooks na Amazon (Cupom 30% off: LEIA30)

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

💬 Na sua equipe, como o aumento na velocidade de geração de código tem impactado o tempo até a entrega (release)? Onde está o gargalo atual? Compartilhe sua experiência nos comentários!

A escolha de linguagem de programação: o que realmente importa para quem lidera engenharia

Alex Pimenta — Fri, 04 Sep 2026 13:05:13 +0000

A escolha de uma linguagem de programação raramente é uma decisão apenas técnica. Ela afeta custo de manutenção, capacidade de contratação, velocidade de entrega, risco operacional e a facilidade com que o time consegue sustentar o sistema ao longo dos anos.

Em 2026, com agentes de IA gerando uma parcela crescente do código, esse cálculo ganhou uma camada adicional: a linguagem também influencia o quanto o código gerado é verificável, revisável e alinhado às restrições do projeto.

A premissa continua a mesma: a escolha não deve ser pautada por modismo ou por sintaxe aparente. Deve ser pautada pelo alinhamento entre características técnicas, domínio do problema e capacidade da equipe de sustentá-la.

⚖️ Critérios que pesam na decisão

Líderes de engenharia costumam equilibrar três grupos de fatores:

Custo de construir e evoluir: Facilidade de aprendizado, produtividade do time, qualidade do ecossistema de bibliotecas e ferramentas, e tempo de onboarding de novos engenheiros.
Custo de operar: Desempenho, consumo de recursos, previsibilidade de latência, facilidade de deploy e comportamento sob carga.
Externalidades de longo prazo: Disponibilidade de profissionais no mercado, risco de lock-in, maturidade do suporte, e o quanto a linguagem favorece (ou dificulta) verificação automatizada e revisão.

Frameworks recentes de decisão tratam a escolha de linguagem como uma decisão econômica: o que importa não é só o tempo até o primeiro deploy, e sim o custo total por mudança aceita ao longo do ciclo de vida.

📊 O que os dados de uso mostram (2021–2025)

Antes de olhar para adequação técnica, vale observar como a participação das linguagens evoluiu nos últimos anos:

JavaScript manteve a liderança.
TypeScript, SQL e Python registraram os maiores ganhos de participação.
Go e Rust avançaram de forma consistente.
Java e PHP recuaram.
C# permaneceu estável.

Esses números não indicam qual linguagem "é melhor", mas sim movimentos de adoção. A decisão de engenharia continua dependendo do domínio, do custo de sustentação e da capacidade do time — não apenas da popularidade.

Fonte: Análise de Dados Agregados. Variação calculada entre 2021 e 2025 (ponto percentual).

🗺️ Mapeamento prático das linguagens mais relevantes

Com base em características técnicas consolidadas e no uso observado em produção:

C/C++ permanece onde o controle de recursos e a latência são requisitos duros.
Rust ganha espaço onde segurança de memória e determinismo importam, mesmo com curva de aprendizado elevada.
Go se consolidou em backend e infraestrutura pela simplicidade operacional e deploy previsível.
Java continua sendo a base de grande parte dos sistemas empresariais de longa duração.
C# oferece produtividade alta e confiabilidade sólida, especialmente em ambientes investidos no ecossistema .NET.

🤖 O que muda com o uso de agentes de IA?

Quando parte relevante do código passa a ser gerada por agentes, alguns critérios ganham peso:

Verificabilidade mecânica: Linguagens que permitem provar mais propriedades sem executar a aplicação inteira (tipos estritos, análise estática forte, testes rápidos) reduzem o custo de supervisionar o código gerado.
Tamanho e complexidade da toolchain: Quanto mais camadas existem entre o código e o artefato executável, mais pontos existem para o agente errar com confiança.
Defaults que falham de forma fechada: Sistemas com comportamento padrão restritivo ajudam a conter erros quando o volume de mudanças sobe.

A combinação linguagem + toolchain + processo de verificação altera o custo de manter a qualidade quando a geração de código acelera.

👔 Implicações para CTOs e líderes técnicos

Trate a escolha como portfólio, não como religião: Sistemas maduros costumam ser poliglotas por necessidade, mas o risco está em multiplicar linguagens sem critério de sustentação.
Meça o custo de contratação e onboarding: Uma linguagem excelente no papel torna-se cara se o time não consegue contratar ou treinar em tempo razoável.
Avalie o custo por mudança aceita: Geração rápida só reduz custo se a verificação, revisão e operação acompanharem o ritmo.
Externalize as restrições: Padrões, arquiteturas e limites precisam estar explícitos para humanos e agentes.
Revise periodicamente: A linguagem certa em 2022 pode não ser a mais adequada em 2026 se o domínio, a escala ou o time mudaram.

📌 Conclusão

O erro mais comum não é escolher uma linguagem "errada" em abstrato, mas escolher sem considerar o domínio, a capacidade de sustentação e o custo real de evoluir o sistema ao longo do tempo.

Em um cenário onde o código se torna abundante, a pergunta deixa de ser apenas "qual linguagem gera mais rápido?" e passa a ser "qual combinação de linguagem, toolchain e processo nos permite confiar no que está sendo produzido?"

📌 Referências e bases utilizadas:

Mapeamento técnico consolidado de propósitos e cenários de C/C++, Rust, Go, Java e C#
Discussões de líderes técnicos sobre fatores de custo de ciclo de vida na escolha de linguagem
Análises de adoção empresarial e trade-offs de contratação e produtividade
Observações recentes sobre como toolchains e verificabilidade afetam o trabalho com agentes de código

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

📚 Quer aprofundar o tema de forma estruturada?

Do contexto à governança de agentes, você pode consultar a série Engenharia de Software Assistida por IA, em especial o Volume VIII — Engenharia de Contexto e Governança de IA.

💡 Informações úteis:

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

👉 Série eBook completa:

Acessar Série de eBooks na Amazon (Cupom: LEIA30)

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

💬 Qual linguagem tem sido a principal escolha no seu stack atual? O uso de assistentes de IA mudou a forma como vocês avaliam novas linguagens? Deixe sua opinião nos comentários!

Quando a revisão deixa de escalar: supervisão em camadas no desenvolvimento assistido por IA

Alex Pimenta — Thu, 03 Sep 2026 15:24:54 +0000

A velocidade de geração de código aumentou. O volume de mudanças também. Os mecanismos que as equipes usavam para manter qualidade e coordenação — revisão de código, lint, testes e pipelines — continuam os mesmos, mas passam a operar sob uma pressão sem precedentes.

Um estudo publicado em agosto de 2026, aceito no ESEM (Software Engineering in Practice), investigou exatamente como organizações estão reagindo a essa pressão. A partir de entrevistas com praticantes e de um survey mais amplo, os autores descrevem uma transição: de um modelo centrado na revisão humana para um modelo de supervisão em camadas.

A conclusão central é direta: nenhuma camada sozinha consegue carregar o peso da supervisão quando o volume de código gerado por agentes sobe de forma sustentada.

📈 O que muda quando o volume aumenta?

Durante anos, a revisão de código funcionou como o principal ponto de controle: combinava verificação técnica, alinhamento de estilo, transferência de conhecimento e detecção de riscos.

Com agentes produzindo implementações em ritmo acelerado, esse ponto único começa a saturar. A inspeção linha a linha torna-se inviável em escala, e o risco de aprovar código que "parece correto" na superfície, mas carrega problemas estruturais, aumenta significativamente.

Dados recentes reforçam esse descompasso:

⚠️ Aumento de incidentes: Uma parcela significativa de líderes de tecnologia relata aumento de incidentes em produção associados a código gerado por IA, mesmo quando bem avaliado na revisão.
⌛ Dívida técnica persistente: Estudos em repositórios reais mostram que uma fração relevante dos problemas introduzidos por assistentes permanece no código ao longo do tempo.
🛡️ Falhas de segurança em PRs: Análises de pull requests gerados por agentes identificam proporções elevadas de problemas de segurança e configuração com baixa taxa de detecção prévia.

O padrão que emerge não é de falha isolada de uma ferramenta, mas de descompasso entre capacidade de geração e capacidade de supervisão.

🛡️ As três camadas que as organizações estão combinando

O estudo de Stolze e Strässle organiza a resposta prática em três camadas de guardrails:

1. Guardrails Preventivos

A primeira camada consiste em externalizar intenções de arquitetura, convenções e restrições em formato legível por máquina. Em vez de depender apenas do julgamento do revisor no momento da mudança, o time torna essas regras disponíveis antes da geração.

Artefatos: Arquivos de instrução de projeto (AGENTS.md, CLAUDE.md), regras de arquitetura versionadas, restrições de escopo e critérios de aceite estruturados.
Resultado: Repositórios que versionam esses artefatos tendem a apresentar menor aumento de complexidade cognitiva e de avisos de análise estática após a adoção de agentes.

2. Guardrails Executáveis

A segunda camada reutiliza mecanismos existentes — lint, testes, análise estática e pipelines de CI/CD — como infraestrutura de supervisão em escala.

Lógica: O que puder ser verificado de forma automática e repetível deve ser verificado assim, liberando a atenção humana para o que não se reduz a regras locais.
Contratos de Delegação: Inclui verificações de escopo (o agente alterou apenas o que deveria?), testes de regressão e contratos explícitos (Software Delegation Contracts). Tornar o contrato explícito melhora a revisabilidade, trazendo mais evidência estruturada e limitações conhecidas.

3. Supervisão Humana

A terceira camada não desaparece, mas muda seu foco de atuação.
Em vez de inspecionar linha por linha, o papel humano se desloca para:

🏗️ Raciocínio arquitetural
🧠 Avaliação de explicabilidade das decisões do agente
🔮 Julgamento sobre manutenibilidade de longo prazo
🚦 Decisão sobre quando escalar ou bloquear

❓ Por que a revisão isolada deixa de bastar?

Há três razões práticas:

O Volume: O custo de revisar tudo no mesmo nível tradicional se torna economicamente e operacionalmente inviável.
A Natureza dos Erros: Problemas de arquitetura, acoplamento e dívida estrutural raramente aparecem como falhas locais óbvias. Eles se acumulam e só se manifestam sob carga ou mudanças futuras.
O Risco da Falsa Confiança: Código gerado por agentes frequentemente apresenta uma "boa forma superficial". Revisores podem superestimar a qualidade e subestimar a necessidade de verificação estrutural profunda.

👔 Implicações para quem lidera engenharia

Para CTOs e líderes técnicos, a mensagem operacional é clara:

1️⃣ Tratar a supervisão como sistema, e não como uma etapa única.
2️⃣ Investir em tornar intenções e restrições legíveis por máquina (camada preventiva).
3️⃣ Fortalecer o que é automatizável (testes, lint, análise de escopo) como infraestrutura de controle.
4️⃣ Redefinir o papel da revisão humana: menos inspeção sintática, mais julgamento sobre coerência e evolução do sistema.
5️⃣ Medir não só a velocidade de geração, mas a capacidade de detectar e conter problemas antes que cheguem à produção.

Organizações que continuam dependendo quase exclusivamente da revisão humana tendem a acumular a chamada "dívida de agente": problemas que passam despercebidos na superfície e se manifestam depois.

📌 Conclusão

A revisão de código continua necessária, mas deixa de ser suficiente como mecanismo isolado.

Quem trata a supervisão apenas como "mais revisão" tenta resolver um problema de volume com as mesmas ferramentas do passado. Quem redistribui o controle entre camadas aumenta a chance de manter qualidade e coerência sem abrir mão da velocidade que os agentes oferecem.

📌 Principais referências:

Stolze, M.; Strässle, M. – When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering (arXiv:2608.26316, ESEM 2026)
Estudos sobre dívida técnica e smells em código gerado por IA em repositórios reais
Análises de segurança em pull requests de agentes (security smells, supply chain, credenciais)
Trabalhos sobre contratos de delegação e revisabilidade
Relatórios de líderes de tecnologia sobre incidentes pós-deploy associados a código gerado por IA

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

📚 Quer aprofundar o tema de forma estruturada?

Do contexto à governança de agentes, você pode consultar a série Engenharia de Software Assistida por IA, em especial o Volume VIII — Engenharia de Contexto e Governança de IA.

💡 Duas boas notícias:

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

👉 Série eBook completa:

Acessar Série de eBooks na Amazon (Cupom 30% off: LEIA30)

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

💬 Como a sua equipe tem lidado com o aumento do volume de código para revisar? Vocês já adotam algum tipo de guardrail preventivo? Compartilhe nos comentários!

Context Engineering: o ativo que a maioria ainda trata como prompt

Alex Pimenta — Thu, 03 Sep 2026 10:01:50 +0000

Em 2026, a maior parte das discussões sobre agentes de código ainda gira em torno do modelo: qual é o melhor, qual tem a janela de contexto maior, qual gera código mais rápido.

Há, no entanto, um consenso crescente na literatura e na prática de engenharia: o gargalo principal deixou de ser a capacidade de geração. Passou a ser o contexto.

Context Engineering é a disciplina de decidir, de forma deliberada, o que o agente vê em cada momento e o que ele não vê. Não se trata apenas de escrever um prompt melhor. Trata-se de projetar a informação que entra na janela de contexto, o que permanece entre sessões e o que é recuperado sob demanda.

🔍 Por que contexto se tornou o ponto crítico?

Agentes de código operam com uma janela de contexto finita. Nela entram, ao mesmo tempo:

⚙️ Instruções de sistema e regras do projeto
📄 Arquivos lidos
💬 Histórico da conversa
🛠️ Saídas de ferramentas
🧪 Resultados de testes e logs

Quando esse conjunto fica desorganizado ou excessivo, o desempenho cai. Estudos recentes descrevem efeitos conhecidos: degradação de atenção em contextos longos, dificuldade de recuperar informação do meio da janela e tendência a repetir padrões anteriores mesmo quando eles já não se aplicam.

Em repositórios grandes, o problema se agrava. O agente precisa de informação estrutural (dependências, convenções, decisões históricas), e não apenas de trechos de código semelhantes ao pedido atual. Sem essa camada, ele tende a produzir soluções localmente corretas e globalmente inconsistentes.

📄 O que as equipes estão colocando nos arquivos de contexto?

Uma prática que se consolidou é o uso de arquivos persistentes de instrução — AGENTS.md, CLAUDE.md e equivalentes. Um estudo empírico de 2026 analisou mais de 2.300 desses arquivos em quase 2.000 repositórios.

Os resultados mostram priorização clara:

🧪 Procedimentos de teste
💻 Detalhes de implementação
🏗️ Arquitetura e estrutura do projeto

Em contraste, requisitos não funcionais como segurança e desempenho aparecem com bem menos frequência. Isso indica que muitas equipes ainda tratam o arquivo de contexto como documentação operacional, e não como instrumento de governança.

Outro ponto observado: esses arquivos evoluem como código de configuração, com alterações frequentes e incrementais, e não como documentação estática.

🧩 Camadas práticas de Context Engineering

A literatura e a prática de 2026 apontam algumas camadas recorrentes:

Instruções persistentes do projeto: Arquivos lidos no início de cada sessão. Devem ser concisos e orientados a decisões ("use TypeScript strict", "não altere contratos públicos sem revisão"), e não a listas exaustivas de práticas.
Contexto recuperado sob demanda: Em vez de carregar o repositório inteiro, o agente busca trechos relevantes. Abordagens baseadas em análise estática (dependências estruturais) tendem a ser mais estáveis em tarefas de nível de função. Abordagens de navegação dinâmica ganham valor em tarefas mais complexas, mas dependem de modelos mais capazes e consomem mais recursos.
Skills e módulos carregáveis: Instruções e recursos que o agente só carrega quando julga necessários. Isso reduz o ruído na janela de contexto.
Memória e estado entre sessões: Mecanismos para preservar decisões, convenções e erros já conhecidos, evitando que cada sessão recomece do zero.
O próprio ciclo de desenvolvimento (SDLC) como contexto: Alguns times argumentam que o SDLC — como o trabalho é especificado, revisado, testado e liberado — é a camada de contexto mais importante. Arquivos de instrução ajudam, mas não substituem regras operacionais claras sobre quando escalar para um humano, que tipo de teste se aplica a cada tipo de mudança e o que constitui evidência de aceite.

⚠️ Problemas recorrentes quando o contexto é mal gerido

Vários trabalhos recentes descrevem padrões de falha comuns:

💥 Explosão de contexto: a janela se enche com histórico e saídas de ferramentas, degradando a qualidade.
📉 Deriva silenciosa entre especificação e código: o código evolui, a especificação não, e a divergência só aparece tarde.
☣️ Contexto contaminado: erros anteriores permanecem na janela e influenciam decisões seguintes.
📢 Excesso de informação irrelevante: o agente se distrai com material que não contribui para a tarefa atual.

A resposta comum a esses problemas não é "aumentar a janela". É curadoria: o que deve estar sempre presente, o que deve ser recuperado sob demanda e o que deve ser descartado.

👔 Implicações para CTOs e líderes técnicos

Para quem lidera times de engenharia, Context Engineering deixa de ser detalhe de ferramenta e passa a ser decisão de processo.

Algumas perguntas práticas para autoavaliação:

[ ] Existe um conjunto mínimo e versionado de instruções de projeto que todos os agentes leem?
[ ] Requisitos não funcionais (segurança, desempenho, observabilidade) estão explícitos nesse conjunto?
[ ] Há distinção clara entre o que o agente pode decidir sozinho e o que exige revisão humana?
[ ] O time trata arquivos de contexto como artefatos vivos, ou como documentação esquecida?
[ ] A estrutura de trabalho (especificações, revisão, testes, critérios de aceite) está legível o suficiente para um agente operar com menos ambiguidade?

💡 Times que investem apenas em escolher o "melhor" agente e negligenciam o contexto tendem a acelerar a geração de código e, ao mesmo tempo, aumentar o retrabalho.

📌 Conclusão

Context Engineering não é uma técnica de prompt. É a prática de tratar a informação que o agente recebe como um ativo de engenharia: versionado, curado, mensurável e alinhado aos objetivos do sistema.

Em 2026, a capacidade de gerar código deixou de ser o diferencial principal. O diferencial passou a ser a capacidade de controlar o que o agente sabe, o que ele assume e sob quais restrições ele opera.

Quem continua tratando contexto como "mais um prompt" está, na prática, deixando um dos principais fatores de qualidade e risco fora do processo formal de engenharia.

📌 Principais referências utilizadas:

Estudos empíricos sobre arquivos de contexto de agentes (AGENTS.md / CLAUDE.md)
Trabalhos sobre paradigmas de recuperação de contexto em nível de repositório
Análises de falhas de contexto em agentes de código (explosão, deriva, contaminação)
Práticas documentadas por times e plataformas (incluindo Sourcegraph, Claude Code e frameworks de memória de agentes)
Papers recentes sobre gestão de working memory e infraestrutura de contexto codificado em repositórios complexos

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

📚 Quer aprofundar o tema de forma estruturada?

Do contexto à governança de agentes, você pode consultar a série Engenharia de Software Assistida por IA, em especial o Volume VIII - Engenharia de Contexto e Governança de IA.

💡 Duas boas notícias:

🏷️ 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

🔗 Ou eBook completo

💬 Sua equipe já utiliza arquivos como AGENTS.md ou CLAUDE.md nos repositórios? Como vocês fazem a curadoria do contexto dos agentes? Compartilhe sua experiência nos comentários!

Agentic IDEs ainda não substituem o desenvolvedor, mas mudam o papel dele

Alex Pimenta — Wed, 02 Sep 2026 18:35:15 +0000

Ferramentas como GitHub Copilot, Cursor e Windsurf passaram a oferecer modos cada vez mais autônomos de geração de código. A pergunta natural é: até que ponto elas conseguem construir uma aplicação completa?

Um estudo empírico publicado em agosto de 2026 avaliou exatamente isso. Os pesquisadores pediram a essas três agentic IDEs que gerassem cinco aplicações web full-stack a partir do zero.

O resultado ajuda a colocar o debate em bases muito mais realistas.

📊 O que o estudo observou

As ferramentas mostraram bom desempenho em padrões conhecidos e bem estabelecidos, tais como:

🟢 Operações CRUD
🔐 Funcionalidades de autenticação

Nesses casos, a geração foi, em geral, bastante consistente.

Já em arquiteturas menos comuns — por exemplo, uma aplicação utilizando fila de tarefas (task queue) —, o número de erros aumentou de forma significativa.

💡 Em resumo: quanto mais o problema se afasta de padrões recorrentes, maior a necessidade de intervenção humana.

🔄 O que muda no papel do desenvolvedor?

O estudo conclui que as agentic IDEs não substituem o desenvolvedor; elas alteram o tipo de trabalho que ele realiza.

O papel do profissional se desloca para:

🎯 Definir o que precisa ser construído por meio de instruções em linguagem natural.
🔄 Refinar iterativamente o que o agente produz.
🎼 Orquestrar o processo de construção.

Em vez de escrever a maior parte do código linha por linha, o desenvolvedor passa a conduzir, avaliar e corrigir o trabalho do agente.

As diferenças entre as três ferramentas existiram, mas foram relativamente pequenas. O padrão geral se manteve: bom desempenho em tarefas conhecidas e dificuldades maiores em cenários menos convencionais.

🛠️ O que isso significa na prática?

Para quem desenvolve software no dia a dia, a mensagem é direta:

🚀 Agentic IDEs aceleram a implementação de partes previsíveis do sistema.
🧠 Elas dependem fortemente de direção humana quando a solução exige decisões de arquitetura ou padrões menos comuns.
🎯 A qualidade do resultado continua ligada à clareza das instruções e à capacidade do desenvolvedor de revisar e ajustar o que foi gerado.

Isso reforça um ponto fundamental: a ferramenta muda a velocidade de certas etapas, mas não elimina a necessidade de entendimento do problema, de definição de requisitos e de julgamento técnico.

📌 Conclusão

As agentic IDEs já são capazes de gerar partes relevantes de uma aplicação. No entanto, ainda não são capazes de substituir o raciocínio de engenharia necessário para construir software de forma consistente.

O desenvolvedor continua no centro do processo — agora com uma responsabilidade maior de orientar, avaliar e integrar o que os agentes produzem.

📌 Fonte:

Marceca, M.; Rossi, M. T.; Mariani, L. - Generation of Web Apps with Agentic IDEs: An Empirical Assessment (arXiv:2608.20903, 21 de agosto de 2026).

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

📚 Quer aprofundar nessa jornada?

Se você quer dominar as competências que a IA não substitui, conheça a série Engenharia de Software Assistida por IA (8 volumes).

💡 Duas boas notícias:

🏷️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível de graça no Kindle Unlimited!

👉 Série eBook completa:

Acessar Série de eBooks na Amazon

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

💬 Você já testou alguma Agentic IDE para criar uma aplicação completa do zero? Qual foi a sua experiência? Deixe seu comentário abaixo!

Um fluxo em fases para operar agentes de código: o que um time de pesquisa está fazendo na prática

Alex Pimenta — Wed, 02 Sep 2026 11:09:41 +0000

À medida que agentes de IA passam a escrever uma parcela cada vez maior do código, uma pergunta prática ganha força:

Como estruturar o trabalho com esses agentes para obter resultados confiáveis?

Um paper recente (31 de agosto de 2026) do time de pesquisa de IA da Infobip traz uma resposta concreta, baseada em experiência real de uso.

O trabalho se chama A Phased Workflow for Operating LLM-Based Coding Agents e descreve um fluxo em fases desenvolvido internamente para operar agentes de código de forma mais controlada.

💡 A ideia central

O fluxo organiza o desenvolvimento assistido por agentes em quatro fases, com uma lógica clara:

🧠 O esforço humano é concentrado no início (front-loaded).
🤖 A delegação para o agente aumenta conforme os artefatos amadurecem.

Em outras palavras: quanto mais maduro e bem definido estiver o contexto, mais seguro é delegar.

⚠️ Por que isso importa?

Os autores observam dois problemas recorrentes na prática:

Erros nas fases iniciais se propagam: Falhas de entendimento ou de planejamento no começo tendem a se agravar nas fases seguintes.
Corrigir código gerado pode piorar o resultado: Intervenções tardias para "consertar" o que o agente produziu frequentemente introduzem complexidade desnecessária e fragilidade.

Por isso a recomendação é clara: a revisão humana precisa ser *front-loaded* — feita com mais intensidade no início do processo, e não apenas no final.

🧠 O papel central do contexto

O paper destaca que a gestão de contexto é o ponto crítico do trabalho com agentes.

Não basta entregar um prompt. É necessário gerenciar o que o agente sabe, o que ele pode assumir e quais restrições valem em cada fase. Os autores descrevem estratégias aplicadas em cada etapa justamente para reduzir modos de falha conhecidos.

🎯 O que isso muda na prática?

O modelo tradicional de "abrir a ferramenta e pedir para criar o sistema" mostra seus limites quando a tarefa deixa de ser trivial.

O fluxo em fases proposto pela Infobip reforça uma tese que tem se consolidado em 2026:

A qualidade do resultado depende menos da capacidade bruta do modelo e mais da forma como o trabalho é estruturado ao redor dele.

Isso inclui:

🎯 Definir bem o problema antes de delegar
🧩 Construir contexto de forma progressiva e controlada
🔍 Revisar com critério nas fases certas
🚀 Aumentar a autonomia do agente apenas quando os artefatos já estão maduros

📌 Conclusão

Agentes de código aumentaram a velocidade de implementação. Mas a responsabilidade de estruturar o processo continua sendo humana.

❌ Times que tratam o agente como um "gerador de código sob demanda" tendem a acumular retrabalho.
✅ Times que organizam o trabalho em fases, com contexto e revisão no momento certo, conseguem extrair mais valor com menos risco.

O paper da Infobip é um excelente exemplo de como a indústria está começando a formalizar esses fluxos.

📌 Fonte:

Kapetanovic, A. et al. - A Phased Workflow for Operating LLM-Based Coding Agents (arXiv:2608.30701, 31 de agosto de 2026). Time de pesquisa de IA da Infobip.

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

📚 Quer aprofundar nessa jornada?

Se você quer dominar a governança, delegação e engenharia de contexto por trás dos agentes de IA, conheça a série Engenharia de Software Assistida por IA (8 volumes).

💡 Duas boas notícias:

🏷️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível de graça no Kindle Unlimited!

👉 Série eBook completa:

Acessar Série de eBooks na Amazon

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

💬 Sua equipe já utiliza algum fluxo estruturado em fases ou costuma interagir via prompts diretos? Deixe sua opinião nos comentários!

Claude Code virou o líder absoluto: o que a pesquisa JetBrains de 15 mil desenvolvedores revela

Alex Pimenta — Tue, 01 Sep 2026 10:31:57 +0000

Em 2026, a pergunta "você usa IA para programar?" deixou de fazer sentido.

A pergunta certa agora é: qual agente você está usando e quanto do seu código ele está realmente escrevendo?

A JetBrains publicou, em agosto de 2026, os resultados do Developer Ecosystem Survey 2026, uma pesquisa global com mais de 15 mil desenvolvedores profissionais. Os números são claros e mudam o mapa do mercado.

📊 Os números que importam

⚡ 90% dos desenvolvedores profissionais usam agentes de IA no trabalho pelo menos uma vez por semana.
📅 68% usam todos os dias.
🚀 Claude Code alcançou 39% de adoção no trabalho (subiu de 18% em janeiro de 2026).
🇺🇸 Nos Estados Unidos, a adoção do Claude Code chega a 47%.
🏆 Claude Code é a ferramenta mais usada por 31% dos desenvolvedores (taxa de conversão extremamente alta).
📉 GitHub Copilot caiu para 21%.
📈 Codex (OpenAI) cresceu de 3% para 16% no mesmo período.

O Claude Code não apenas lidera. Ele se tornou, em poucos meses, o padrão de fato para uma parcela significativa do mercado.

💡 O que esses números realmente significam?

Não se trata apenas de "qual ferramenta está na moda". A pesquisa mostra uma mudança estrutural:

A era do autocomplete acabou: O mercado migrou de assistentes de código para agentes que planejam, editam múltiplos arquivos, executam comandos e abrem pull requests.
A lealdade mudou de lado: Quem experimenta o Claude Code tem alta probabilidade de transformá-lo na ferramenta principal. Isso é raro em um mercado tão competitivo.
O volume de código gerado por agentes já é alto: Em pesquisa complementar da própria JetBrains, desenvolvedores relatam que, em média, cerca de 47% do código que produzem já é gerado integralmente por agentes.

🎯 O ponto que a maioria ainda está ignorando

Quando quase metade do código passa a ser gerado por agentes, o gargalo muda de lugar.

O problema deixa de ser "como gerar código mais rápido" e passa a ser:

❓ Como garantir que o agente entendeu o problema certo?
🏗️ Como manter arquitetura e padrões sob controle?
🔍 Como auditar o que foi gerado?
🛡️ Como governar contexto, permissões e comportamento dos agentes?

Em outras palavras: quanto maior a autonomia da ferramenta, maior a necessidade de Engenharia de Software de verdade.

Claude Code, Cursor, Codex e similares aceleram a implementação. Mas não eliminam a necessidade de requisitos claros, arquitetura consciente, delegação controlada e governança.

🛠️ O que isso exige do profissional em 2026

O desenvolvedor mais valioso não será necessariamente quem digita mais rápido ou quem conhece o maior número de atalhos da ferramenta.

Será quem consegue:

📌 Definir bem o problema e o contexto
🎯 Delegar com precisão
🔍 Revisar e auditar com critério
🛡️ Governar o que os agentes estão fazendo em escala

A ferramenta mudou. O jogo também.

📌 Fonte principal:

JetBrains - AI Coding Agents: Adoption Trends (Developer Ecosystem Survey 2026, maio-julho 2026) e pesquisa complementar How Much Code Do Developers Really Let Agents Write?

📚 Quer se aprofundar no assunto?

Se você quer dominar a governança, delegação e engenharia por trás dos agentes de IA, conheça a série Engenharia de Software Assistida por IA (8 volumes).

💡 Duas boas notícias:

🏷️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível de graça no Kindle Unlimited!

👉 Série eBook completa:

Acessar Série de eBooks na Amazon

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

💬 Qual agente de IA você mais tem utilizado no seu dia a dia? O Claude Code já faz parte do seu workflow? Comente abaixo!

Quando o código fica abundante, o que se torna escasso?

Alex Pimenta — Mon, 31 Aug 2026 12:27:44 +0000

Em 2026, agentes de IA já geram uma parcela significativa do código que chega em produção. Ferramentas como Claude Code, Cursor e Codex tornaram a implementação rápida e, em muitos casos, abundante.

Mas um paper recente publicado no arXiv (25 de agosto de 2026) coloca o dedo na ferida com precisão:

Quando a capacidade de implementação sobe drasticamente, o que se torna escasso?

O trabalho se chama Model-Based Agentic Software Engineering (MAGE), de James C. Davis e coautores.

A tese central é clara e poderosa:

"Coding agents increase implementation capacity without automatically making project intent, system structure, or acceptance evidence explicit."

Em português direto: Agentes aumentam a capacidade de implementar. Mas não tornam automático o intent do projeto, a estrutura do sistema nem a evidência de aceite.

💎 O que realmente se torna escasso

Segundo os autores, quando o código deixa de ser o gargalo, o trabalho caro e crítico se desloca para três frentes principais:

Escolher boas abstrações: Decidir o que modelar, o que deixar de fora e qual a estrutura correta do sistema.
Produzir evidência: Gerar provas de que o que foi built realmente atende aos objetivos e restrições.
Definir as obrigações que governam a aceitação: Estabelecer o que é considerado "pronto", quem valida e sob quais critérios.

Em outras palavras: o problema deixa de ser "gerar código" e passa a ser representação + autoridade + governança.

⚠️ Por que isso importa agora?

A maioria dos times ainda trata agentes como "geradores de código mais rápidos". O paper MAGE mostra que essa visão é incompleta.

Quando a implementação fica barata e abundante, o risco não diminui — ele muda de lugar.

O risco se concentra em:

🔴 Construir a coisa errada com velocidade alta
🔴 Aceitar código sem evidência suficiente
🔴 Perder o controle sobre o que os agentes estão realmente fazendo

É exatamente por isso que requisitos claros, arquitetura consciente, delegação controlada e auditoria deixam de ser "boas práticas" e se tornam o diferencial competitivo.

🚀 A conexão com a Engenharia de Software real

O paper MAGE reforça algo que muitos profissionais da área já estão sentindo na pele:

A Inteligência Artificial acelerou a implementação. A Engenharia de Software continua sendo o diferencial.

Quanto maior a autonomia dos agentes, maior a necessidade de:

📋 Entender e documentar o problema (BRD, FRD, NFR)
🏗️ Definir arquitetura com responsabilidade
🎯 Delegar com contexto completo
🔍 Auditar o que é gerado
🛡️ Governar agentes e contextos como ativos organizacionais

Sem isso, temos apenas velocidade. Com isso, temos engenharia.

📌 Fonte:

Davis, J. C. et al. - Model-Based Agentic Software Engineering (arXiv:2608.25174, 25 de agosto de 2026)

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

📚 Quer aprofundar nessa jornada?

Para quem tiver interesse na série Engenharia de Software Assistida por IA (8 volumes), ela foi escrita especificamente para cobrir essas lacunas de contexto, arquitetura e governança.

💡 Duas boas notícias:

🏷️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível de graça no Kindle Unlimited!

👉 Série eBook completa:

Acessar Série de eBooks na Amazon

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

A IA já gera o código rápido. O problema agora é outro.

Alex Pimenta — Sat, 29 Aug 2026 22:01:18 +0000

Um time mediu o ciclo completo de desenvolvimento de uma feature real com apoio de ferramentas de IA. O resultado foi revelador:

⚡ Geração assistida por IA: apenas 7% do tempo total
🔍 Revisão de engenheiro: 16%
🔄 Retrabalho: 14%
🧪 Testes: 24%
🛡️ Checagens de segurança: 12%
🚀 Validação de deploy: 11%
✅ Aprovação de release: 16%

Ou seja: mesmo que a IA escrevesse o código na metade do tempo, o impacto no ciclo total seria mínimo.

O gargalo simplesmente se moveu para baixo.

📉 O gargalo da entrega de software na era da IA

Esse dado aparece em um artigo recente de Dhruv Joshi (Quokka Labs, publicado em 27 de agosto de 2026) intitulado "AI Coding Tools in Production: We Timed an AI-Assisted Feature and Coding Wasn't the Slow Part".

A conclusão é clara:

Otimizar a geração de código não resolve o sistema de entrega.

O que realmente está consumindo tempo:

Revisão: O código "quase certo" exige mais análise de arquitetura, permissões, casos de borda e manutenibilidade.
Retrabalho: O famoso "está quase bom, mas não está".
Testes: A superfície de código gerada cresce mais rápido do que a capacidade de verificação.
Segurança e governança: A criação de software está acelerando mais rápido do que os controles.

No mesmo período, outro artigo do mesmo autor listou 23 testes de falha que todo agente de IA deveria passar antes de ir para produção (timeouts, injeção de prompt, escalação de permissão, ações alucinadas, rollback, etc.).

A mensagem é a mesma: demo não é evidência de produção.

🎯 O que isso muda na prática?

Em 2026, a pergunta errada é:

❌ "Qual ferramenta gera código mais rápido?"

A pergunta certa é:

✅ "Como estamos controlando o que a IA gera, revisa, testa e libera?"

Quanto mais autonomia o agente recebe, maior precisa ser a engenharia prévia e a supervisão posterior. Isso inclui:

📋 Requisitos claros (BRD, FRD e NFR)
🧠 Contexto completo e persistente
🎯 Delegação técnica com limites
🔍 Auditoria rigorosa do código e do comportamento do agente
🛡️ Governança de agentes e contextos como ativos organizacionais

Sem isso, a velocidade da IA só acelera o caminho até o problema em produção.

📌 Fontes:

Dhruv Joshi / Quokka Labs - "AI Coding Tools in Production: We Timed an AI-Assisted Feature and Coding Wasn't the Slow Part" (27/08/2026)
Dhruv Joshi / Quokka Labs - "AI Agent Testing: 23 Failure Tests Every Agent Should Pass Before Production" (25/08/2026)

📚 Quer aprofundar nessa jornada?

Para quem tiver interesse em dominar esse processo do início ao fim, a série Engenharia de Software Assistida por IA (8 volumes) traz a fundamentação teórica e prática necessária.

💡 Duas boas notícias:

🏷️ Cupom de 30% OFF nos eBooks: LEIA30
📖 Disponível de graça no Kindle Unlimited!

👉 Série eBook completa:

Acessar Série de eBooks na Amazon

📖 Livros Físicos (capa comum):

🔗 Página do autor na Amazon

10 regras para obter melhores resultados com agentes de IA de código (o que o mercado está aprendendo em 2026)

Alex Pimenta — Sat, 29 Aug 2026 19:19:26 +0000

Todo mundo está usando agentes de IA para programar.

Claude Code, Cursor, Codex, Copilot Agent, Gemini CLI... as ferramentas evoluíram rápido. Mas melhores ferramentas não significam automaticamente melhor código.

Um artigo publicado recentemente no KDnuggets (26-29 de agosto de 2026) trouxe exatamente essa provocação e listou 10 regras práticas para quem quer resultados reais com agentes de código.

O texto reforça algo que muitos ainda resistem a aceitar:

A qualidade do resultado depende muito mais do processo e do contexto que você entrega do que da ferramenta em si.

💡 Algumas das regras mais importantes destacadas no artigo:

1. Comece com uma especificação, não com um prompt vago

Em vez de digitar "crie o dashboard", descreva o objetivo, as métricas, o público e as restrições. Agentes performam muito melhor quando recebem uma especificação clara do que quando recebem um pedido genérico.

2. Use arquivos de contexto persistentes

Não repita as mesmas instruções em todo prompt.

Crie um AGENTS.md, CLAUDE.md ou arquivo de instruções do Copilot no repositório. Esse arquivo funciona como um "README para o agente": comandos de setup, padrões de código, regras de teste e convenções do projeto.

3. Trate o agente como um membro do time (com limites)

Defina claramente o que ele pode e não pode fazer. Dê autonomia controlada, não autonomia cega.

4. Valide sempre

Código gerado por agente precisa passar por revisão, testes e auditoria. A velocidade que a IA entrega só tem valor se a qualidade for garantida depois.

5. Contexto é ativo estratégico

Quanto mais contexto de qualidade você fornecer (requisitos, arquitetura, restrições, histórico), melhor o agente performa.

Contexto descartável gera resultado descartável.

🛠️ O que isso significa para a Engenharia de Software em 2026?

O artigo completo do KDnuggets vale a leitura para quem está usando agentes no dia a dia. Ele mostra, na prática, que a diferença entre "gerar código rápido" e "entregar software de qualidade" continua sendo engenharia.

E é exatamente aqui que a conversa fica interessante:

Em 2026, a implementação ficou barata e rápida.

O que continua caro (e cada vez mais crítico) é:

📋 Entender e documentar o problema (BRD, FRD, NFR)
🏗️ Definir arquitetura com responsabilidade
🎯 Delegar tecnicamente com contexto completo
🔍 Auditar o que a IA gera
🛡️ Governar agentes e contextos em escala

Sem isso, o agente só acelera o caminho até o problema em produção.

📌 Fonte: "10 Rules for Getting Better Results from AI Coding Agents" - KDnuggets (agosto de 2026)

📚 Quer aprofundar nessa jornada do problema até a governança de IA?

Se você quer se aprofundar exatamente nesse caminho — do entendimento do problema até a governança de agentes — a série Engenharia de Software Assistida por IA (8 volumes) foi escrita para isso.

🏷️ Série completa (eBook) com 30% de desconto no cupom LEIA30:
👉 Garantir série em eBook na Amazon

📖 Livros Físicos:

🔗 Página do Autor na Amazon

💬 E você? Qual dessas regras já aplica no seu fluxo de trabalho com agentes de IA? Deixe seu comentário abaixo!