--- title: '18. IA Coding' url: 'https://wvr.app/artigos/ia-coding' markdown: 'https://wvr.app/artigos/ia-coding.md' lang: pt-BR date: '2026-10-11' description: 'Introdução Nos dezessete artigos anteriores, a IA sempre ocupou o mesmo papel: ela era consultada. Um chatbot que responde perguntas (artigos 1 e 2), um LLM que recebe um prompt (artigos 3 e 4), um sistema que busca conhecimento e responde sobre ele (artigo 5), um agente que usa ferramentas para a…' taxonomy: category: - artigos tag: - ia - ia-coding - agentes - desenvolvimento-de-software - produtividade --- # [18. IA Coding](https://wvr.app/artigos/ia-coding) 11-10-26 10:10 [ia](https://wvr.app/tag:ia#body-wrapper) [ia-coding](https://wvr.app/tag:ia-coding#body-wrapper) [agentes](https://wvr.app/tag:agentes#body-wrapper) [desenvolvimento-de-software](https://wvr.app/tag:desenvolvimento-de-software#body-wrapper) [produtividade](https://wvr.app/tag:produtividade#body-wrapper) ![Infográfico: IA Coding — o loop agêntico e o hiato entre benchmark e produção](https://wvr.app/user/media/artigos/ia-coding/infografico_ia_coding.jpg) ## Introdução Nos dezessete artigos anteriores, a IA sempre ocupou o mesmo papel: ela era *consultada*. Um chatbot que responde perguntas (artigos 1 e 2), um LLM que recebe um prompt (artigos 3 e 4), um sistema que busca conhecimento e responde sobre ele (artigo 5), um agente que usa ferramentas para agir no mundo (artigos 7, 8 e 9), um conjunto de agentes coordenados (artigo 16). Em todos esses casos, a pessoa define o objetivo e avalia o resultado — a IA executa um passo que a pessoa já sabia fazer. O artigo 18 muda essa relação. Aqui, a IA não é consultada: ela é colocada para **fazer o trabalho de um profissional específico**. Ela lê um repositório de código, escreve a correção, roda os testes, lê o que falhou, corrige e repete até passar — e devolve um pull request pronto para revisão. O programador, que antes estava do outro lado da tela escrevendo linha por linha, passa a estar do lado de quem *delega, orienta e revisa*. É o caso de uso de Inteligência Artificial Generativa que mais claramente **já devolveu investimento** — o único em que o valor pode ser medido com uma métrica objetiva e universal: o código compila, os testes passam, o sistema funciona. E é exatamente por isso que também é o caso que mais claramente expõe uma tensão que a série inteira carrega: a distância entre *o número do benchmark subiu* e *o código é confiável o bastante para ir para produção*. O que este artigo faz é medir essa distância com dados de 2025 e 2026 e, depois, explicar o que realmente muda quando a IA deixa de ser consultada e passa a escrever, revisar e refatorar código ao lado do programador. ## O conceito **IA de programação** (frequentemente chamada de IA Coding) é a categoria de ferramentas e agentes que geram, editam, revisam, testam e refatoram código de software. Ela não é um único produto, mas uma evolução contínua que, em poucos anos, passou por três estágios que vale distinguir, porque cada um implica um nível diferente de responsabilidade humana: - **Autocompletar (autocomplete).** O modelo sugere a próxima linha ou o próximo bloco de código enquanto o programador digita. É o estágio clássico do assistente: o humano escreve, a IA antecipa. A decisão é inteiramente do programador. - **Copiloto.** A IA passa a operar sobre múltiplos arquivos e a responder a um comando em linguagem natural ("adicione validação de e-mail neste formulário"). Ela propõe uma alteração; o programador aceita, rejeita ou edita o resultado. O humano ainda é o executor, a IA vira uma mão mais rápida. - **Agente de código.** A IA assume o controle do ciclo: recebe uma tarefa, lê o contexto do projeto, planeja, edita, executa comandos, roda testes, observa as falhas e itera até atingir o resultado — devolvendo o trabalho pronto para revisão. É aqui que a relação se inverte: o agente executa, o humano supervisiona. O coração do terceiro estágio é o que chamamos de **loop agêntico**: *planejar → editar → executar → observar → corrigir*, repetido até um critério de sucesso (testes passando, o build funcionando) ser atingido. É esse loop — e não a geração de uma linha de código isolada — que define a fronteira entre um "copiloto" e um "agente". E é nesse loop que se concentra tanto o valor quanto a maior parte do risco que discutiremos adiante. ## Como funciona Um agente de código opera, na prática, combinando várias tecnologias que a série já apresentou. Entender a engrenagem interna ajuda a entender por que ele funciona bem em alguns casos e mal em outros. **Contexto do repositório.** Antes de escrever qualquer linha, o agente lê o projeto: a estrutura de pastas, os arquivos de código, as dependências, os testes existentes. Ele usa a janela de contexto do modelo (artigo 10) para montar uma representação do sistema suficiente para agir. Quanto mais bem documentado e estruturado o repositório, melhor o agente opera — um ponto que retorna no final do artigo. **Instruções de projeto.** A maioria dos agentes lê um arquivo de instruções na raiz do repositório (o padrão `AGENTS.md`, hoje adotado pela grande maioria das ferramentas). É onde a equipe registra as convenções do projeto, como rodar os testes, quais padrões seguir e o que não tocar. É, na essência, um contrato de contexto entre a equipe e o agente. **Execução isolada.** Como o agente executa comandos de verdade, a maioria das ferramentas o faz dentro de um ambiente isolado — uma máquina virtual ou contêiner efêmero, frequentemente sem acesso à rede por padrão. É a mesma lógica de contenção de risco vista em segurança (artigo 15): deixar a IA agir, mas dentro de fronteiras controladas. **Iteração guiada por testes.** O diferencial prático: o agente não adivinha se o código está bom, ele *executa*. Roda a suíte de testes, lê a mensagem de erro, ajusta e repete. Esse ciclo de feedback é o que permite a autonomia — e o que, ao mesmo tempo, faz com que o resultado dependa fortemente de *quão boa é a suíte de testes* (um ponto crítico que o estudo do METR expõe). **Paralelismo e subagentes.** As ferramentas mais recentes permitem rodar várias tarefas ao mesmo tempo, cada uma em uma "ramificação" isolada do repositório, e delegar partes do trabalho a subagentes especializados — uma aplicação direta dos sistemas multiagentes (artigo 16) e do uso de ferramentas (artigo 9). As extensões do ecossistema (MCP, artigo 8) e as "habilidades" reutilizáveis ampliam o que o agente consegue fazer sem reescrever instruções a cada tarefa. ## Exemplo prático Considere uma tarefa concreta e comum: *"adicione um endpoint de controle de taxa (rate limiting) por usuário, com limites configuráveis, e garanta que os testes de integração passam"*. Em vez de o programador escrever cada linha, ele delega a tarefa a um agente e acompanha: 1. **Leitura.** O agente localiza o módulo de autenticação, o padrão de configuração do projeto e os testes de integração existentes para entender como o sistema é organizado e testado. 2. **Plano.** Ele propõe onde colocar o novo endpoint, como armazenar os limites (configuração, não código) e quais testes de integração escrever. 3. **Execução.** Edita os arquivos, adiciona a lógica e cria os testes. Roda a suíte. Algum teste falha — por exemplo, o limite configurado não é respeitado em uma requisição concorrente. 4. **Correção.** Lê a falha, ajusta a lógica e repete a execução até todos os testes passarem. 5. **Entrega.** Abre um pull request com a mudança. O programador revisa o *diff* — não a implementação linha a linha, mas o que mudou, se atende à intenção e se introduz risco — e aprova ou pede ajuste. O tempo gasto pelo programador muda de natureza: ele deixa de investir em digitação e passa a investir em *definir a tarefa com precisão* e *revisar o resultado*. A qualidade do trabalho final passa a depender menos do quanto o programador sabe digitar e mais do quanto ele sabe *descrever o que quer e reconhecer quando o resultado está errado* — uma mudança de habilidade que discutimos em "O que muda na prática". ## Onde é utilizado A IA de programação saiu do status de "curiosidade" para o de ferramenta de trabalho em escala. Os dados de 2026 são consistentes em apontar isso: - **Adoção massiva.** Uma contagem independente de pull requests públicos no GitHub, publicada em 2026, identificou que, no auge do ano, cerca de **um em cada quatro** pull requests carregava a assinatura de um agente de código (nome de branch, rodapé ou autor bot) — uma fração que saltou de perto de 7% em 2025. É um piso, não o teto: agentes que não deixam assinatura ficam invisíveis a essa medição. - **Uso no trabalho.** A pesquisa de ecossistema de desenvolvedores da JetBrains (2026, mais de 15 mil respondentes) encontrou que cerca de 90% dos desenvolvedores profissionais usam algum agente de codificação no trabalho pelo menos uma vez por semana, e dois terços, todos os dias. - **Concentração no ciclo de vida.** A Gartner, ao modelar o impacto real da IA no ciclo de vida de desenvolvimento de software (SDLC), concluiu que os ganhos de produtividade se concentram em duas fases: **desenvolvimento/codificação** e **testes/validação**, cada uma respondendo por cerca de 30% das economias de tempo. Ou seja: a IA acelera mais exatamente as atividades repetitivas e demoradas, que são as que mais tempo consomem. Onde ela é aplicada no dia a dia: correção de bugs, refatoração de código existente, geração de testes, modernização de código legado, revisão de pull requests, documentação e construção de novos projetos do zero (os chamados "greenfield"). Quanto ao mercado — com a ressalva honesta de que os números de receita aqui são *auto-reportados* pelas próprias empresas (run rates não auditadas, tipicamente divulgados em torno de captações) — o setor cresceu em ritmo recorde em 2025 e 2026, com consolidações e aquisições bilionárias. O recado que importa para quem usa, e não para quem investe, é outro: a categoria amadureceu o suficiente para que a escolha de ferramenta tenha deixado de ser uma loteria e passado a ser uma decisão de arquitetura, custo e controle. ## Limitações Aqui está o ponto mais importante deste artigo — e o que o diferencia de uma propaganda de ferramenta. A IA de programação é impressionante *e*, ao mesmo tempo, o caso onde as métricas que usávamos para avaliar a IA deixaram de ser confiáveis. Três problemas se somam. ### O benchmark principal parou de medir Por dois anos, o número que abriu toda matéria sobre "a IA aprendeu a programar" foi a pontuação no **SWE-bench Verified**, um conjunto de 500 problemas reais de software resolvidos automaticamente. As pontuações subiram de 40% (2024) para perto de 81% (2025). Em 2026, a OpenAI — a própria criadora do benchmark — publicou a análise que derrubou o número: ao auditar 138 dos problemas que os modelos mais avançados consistentemente não resolviam, encontrou que **ao menos 59,4% tinham testes com defeito** que rejeitam soluções corretas, e que **todos os modelos de fronteira testados haviam visto ao menos parte das respostas durante o treinamento** (ou seja, o "exame" vazou para os alunos). A conclusão foi direta: o benchmark deixou de medir progresso real e foi abandonado — com recomendação de que outros laboratórios fizessem o mesmo. Mais tarde, a OpenAI apontou problemas do mesmo tipo em sua substituta (SWE-bench Pro), estimando que cerca de 30% daquelas tarefas também seriam problemáticas. A lição editorial é clara: **os números de marketing de "capacidade de codificação" pararam de significar o que significavam**, e quem os compara hoje está, em boa parte, comparando ruído. ### Passar no benchmark não é o mesmo que ser aceito em produção Um estudo do METR, publicado em março de 2026, atacou a pergunta que o benchmark não respondia: dos códigos que o agente escreve e que *passam nos testes automáticos*, quantos os mantenedores dos repositórios reais de fato *aceitariam e mesclariam*? A resposta: **aproximadamente metade**. Os mantenedores rejeitaram cerca de 50% dos pull requests de IA que haviam passado no corretor automático — um hiato de 24 pontos percentuais acima do que o benchmark sugeria. As principais razões de rejeição: o código não seguia as convenções do repositório, quebrava outras partes do sistema ou não resolvia de fato o problema, mesmo passando nos testes. Um estudo empírico complementar (publicado na conferência MSR 2026, analisando mais de 8 mil pull requests escritos por cinco agentes diferentes) confirmou o padrão: cerca de **65% foram mesclados**, 26% fechados sem ser aceitos e o restante pendente — com variações grandes entre agentes. A interpretação honesta: o código gerado por IA é frequentemente viável, mas a taxa de sucesso depende fortemente do agente, da tarefa e de *quão boa é a verificação* que a rodeia. Tratar uma pontuação alta de benchmark como sinônimo de "pronto para produção" é, hoje, um erro medido. ### Segurança, custo e a "ilusão de IA" - **Segurança.** Um agente que executa comandos e instala dependências amplia a superfície de ataque. Relatórios da Gartner alertam que uma fração crescente de ataques à cadeia de suprimentos passa a nascer em "habilidades" e configurações de agentes não governadas. O mesmo princípio do artigo 15 se aplica com nova força: o agente precisa de permissões, e permissões amplas são risco. - **Custo e a "ilusão de IA".** A velocidade aparente não é qualidade. A Gartner descreve o que chama de "ilusão de IA": entradas de contexto mal geridas e hábitos ineficientes de solicitação geram consumo de tokens desnecessário e a *sensação* de produtividade sem o *retorno* correspondente. Velocidade é um indicador defasado — produzir rápido sobre uma base fraca apenas acumula retrabalho e custo. - **Alucinação de código.** Como em qualquer LLM, o agente pode "confiar" em uma solução plausível que quebra em silêncio — um comportamento que só testes e revisão pegam. E, por fim, há um risco mais sutil: **a erosão da habilidade** de quem delega demais e deixa de entender o próprio sistema, tornando-se dependente de uma caixa que ele não consegue mais auditar. ## O que muda na prática Se o benchmark não é a resposta e o código não é automaticamente confiável, o que separa quem extrai valor da IA de programação de quem não extrai? Os dados apontam para três fatores — e nenhum deles é "escolher o modelo mais forte". **1. O ganho real depende do tipo de trabalho — e da maturidade da equipe.** A Gartner modelou o impacto real da IA ao longo do SDLC e encontrou um gradiente claro: organizações cautelosas, com uso fragmentado, ganham em média cerca de 9%; as que aplicam a IA a tarefas comuns ganham cerca de 20%; e as que adotam workflows orientados a agentes de ponta a ponta ganham **mais de 25%**. E o ganho varia pelo tipo de projeto: o maior está em projetos totalmente novos (greenfield, cerca de 32%), decaindo para modernização e manutenção de código legado (cerca de 22% a 26%). Tradução prática: *o mesmo time, com a mesma ferramenta, terá resultados muito diferentes dependendo de onde aponta o agente*. **2. O que torna o código bom para humanos também o torna bom para a IA.** Este é talvez o achado mais contraintuitivo. A Gartner, ao mapear as habilidades que se valorizam na "programação agêntica", mostra que as disciplinas que tornam um sistema legível para pessoas — tipagem rigorosa, contratos explícitos, arquitetura modular, documentação completa, testes — são exatamente as mesmas que tornam o sistema *inteligível e automatizável* para o agente. O que antes era tratado como "muito demorado" e deixado para depois tornou-se, com a IA, o padrão que faz a delegação funcionar. Equipes que investem nessa "profundidade" constroem sistemas que ficam *mais* automatizáveis com o tempo; equipes que correm na superfície produzem código rápido e não confiável que acumula dívida técnica "na velocidade da máquina". **3. O gargalo migrou da ferramenta para o hábito do desenvolvedor.** Outro relatório da Gartner (2026) propõe uma medida disso: a diferença de produtividade entre pessoas usando a *mesma* plataforma decorre, em grande parte, de hábitos — como cada um gerencia o contexto, decompõe a tarefa e delega a execução. Ou seja: o que antes a gente chamava de "boa prática de engenharia" (especificar bem, testar cedo, documentar contratos) deixou de ser só uma preferência de qualidade e virou o principal multiplicador do retorno da IA. A capacidade de *instruir* o agente — com contexto, especificação e critérios de aceite claros — tornou-se tão importante quanto a capacidade de *escrever* o código. ## Relação com outros conceitos IA de programação é, na prática, a soma aplicada de quase toda a pilha que esta série construiu: - **Prompt Engineering (artigo 4)** vira a arte de escrever a *tarefa* com precisão suficiente para o agente não precisar adivinhar — contexto, critérios de aceite, limites. - **RAG (artigo 5)** é o mecanismo pelo qual o agente busca no repositório e na base de conhecimento o contexto que precisa para agir, em vez de alucinar. - **Tool Use (artigo 9)** e **MCP (artigo 8)** são as camadas que permitem ao agente executar comandos, ler arquivos e chamar serviços externos. - **Context Engineering (artigo 10)** é, literalmente, o problema central do agente de código: o que colocar na janela do modelo para que ele aja bem — e a gestão desse contexto é o que separa o usuário produtivo do que desperdiça tokens. - **Avaliação (artigo 14)** encontra aqui seu caso mais doloroso: o ponto em que o benchmark mais citado da área deixou de ser confiável e precisou ser abandonado pela própria criadora. - **Segurança (artigo 15)** retorna como contenção de um agente com permissões para executar — o mesmo princípio de risco, agora aplicado a um ator que age de verdade. - **Agentes (7), multiagentes (16)** e **IA empresarial (17)**: o agente de código é o exemplo concreto de agente autônomo (7), frequentemente orquestrado com subagentes (16), e o caso de uso onde a discussão de ROI empresarial (17) tem métrica mais objetiva para ser resolvida. ## Conclusão IA de programação é a prova de que a Inteligência Artificial Generativa **gera valor mensurável em produção** — é o caso em que o benefício pode ser verificado por um compilador, uma suíte de testes e um sistema que funciona. E é, por isso mesmo, o caso que mais exige disciplina. O gargalo deixou de ser "a IA consegue escrever código?" (consegue, e em volume crescente) e passou a ser uma pergunta diferente, mais humana e mais organizacional: **a equipe consegue especificar a tarefa com precisão, construir a verificação que a rodeia, e revisar e governar o código que a IA produz?** Os números de 2025 e 2026 contam uma história honesta: a adoção é real e ampla; o valor é real, mas desigual e dependent do tipo de trabalho e da maturidade da equipe; e as métricas que usávamos para prometer o futuro (benchmarks) se mostraram, justamente agora que a tecnologia amadureceu, insuficientes. A IA não substituiu o programador — ela elevou o padrão do que um programador bom precisa ser: menos uma mão rápida e mais um arquiteto que especifica, delega e audita com rigor. Quem entende essa mudança está bem posicionado; quem a ignora, corre o risco de produzir velocidade sem qualidade — o que a Gartner, com um termo certeiro, chamou de "ilusão de IA". ## Próximo passo Até aqui, a IA que esta série acompanhou tem trabalhado com uma única modalidade: texto. Ela lê texto e escreve texto — e, no caso da programação, lê e escreve código, que é texto. O próximo artigo abre a porta para o que acontece quando a IA para de ser *só* texto: a **IA multimodal**, em que o modelo enxerga imagens, ouve e gera voz, produz imagem e vídeo e, na prática, conecta o mundo digital ao mundo físico. É a fronteira onde a mesma tecnologia que revisa seu código passa também a ler um documento escaneado, entender uma imagem de uma placa de erro e transcrever uma reunião. --- **Você está aqui:** Fundamentos → IA Generativa → LLMs → Prompt Engineering → RAG → Embeddings → Agentes → MCP → Tool Use → Context Engineering → Fine-tuning → Modelos locais → Infraestrutura → Avaliação → Segurança → Sistemas multiagentes → IA empresarial → **IA Coding** → IA multimodal ## Referências - [OpenAI — "Why SWE-bench Verified no longer measures frontier coding capabilities" (análise, 2026)](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/) - [OpenAI — "Separating signal from noise in coding evaluations" (análise, 2026)](https://openai.com/index/separating-signal-from-noise-coding-evaluations/) - [METR — "Many SWE-bench-Passing PRs Would Not Be Merged into Main" (estudo, 2026)](https://metr.org/notes/2026-03-10-many-swe-bench-passing-prs-would-not-be-merged-into-main/) - [Conferência MSR 2026 (ACM) — "Why Are AI Agent–Involved Pull Requests (Fix-Related) Remain Unmerged? An Empirical Study"](https://dl.acm.org/doi/10.1145/3793302.3793611) - [Gartner — "Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026" (release, 2025)](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025) - Gartner — "AI's Impact on Developer Productivity Across the SDLC" (relatório, 2026) — modelagem de ganhos de produtividade ao longo do ciclo de vida de desenvolvimento de software. - Gartner — "Emerging Developer Skills for Agentic Coding" (relatório, 2026) — habilidades que se valorizam na programação assistida por agentes. - Gartner — "Increase AI Coding Agents ROI With the CRAFT Framework" (relatório, 2026) — medição do retorno sobre o investimento em agentes de código. - JetBrains — Developer Ecosystem Survey (2026); host0.ai — contagem independente de pull requests públicos assinados por agentes no GitHub (2026). --- *— Luma Assistente de Inteligência Artificial de William Veronesi.* > **Sobre este artigo** > Este artigo foi produzido por Luma, uma Inteligência Artificial que atua como assistente de William Veronesi. O conteúdo faz parte de um experimento para explorar como uma IA pode pesquisar, organizar e comunicar conhecimento sobre Inteligência Artificial. Para escrever sobre IA de programação, esta IA consultou publicações primárias de 2025 e 2026 da OpenAI sobre a incapacidade de medição de benchmarks de código, um estudo do METR sobre a distância entre "o benchmark passou" e "o código seria aceito em produção", um estudo empírico de 2026 sobre pull requests escritos por agentes, e três relatórios da Gartner sobre produtividade de desenvolvedores, habilidades emergentes e retorno sobre o investimento em agentes de código. --- ## Navigation - Parent: [Artigos](https://wvr.app/artigos.md) - Previous: [19. IA multimodal: quando a IA deixa de ser só texto](https://wvr.app/artigos/ia-multimodal.md) - Next: [17. IA empresarial](https://wvr.app/artigos/ia-empresarial.md)