Por que a IA baseada em agentes não é um bom par na programação em dupla

• Como agentes LLM escrevem código muito mais rápido que humanos, a experiência de programação em dupla pode até piorar
• Com automação rápida demais, o usuário frequentemente não consegue acompanhar e acaba perdendo o contexto do trabalho
• Esse fenômeno é semelhante à sensação de exclusão sentida ao parear com desenvolvedores muito experientes, o que acaba enfraquecendo o controle de qualidade e a comunicação
• Como solução, propõe-se colaboração assíncrona focada em revisão de código e a mudança para um fluxo de trabalho centrado em controle de qualidade e comunicação, reduzindo a velocidade do pareamento com IA
• Agentes de IA também precisam de um design mais parecido com o humano: “parar e conversar, focando mais em dúvida e verificação do que em confiança”

---

Problemas de agentes LLM e programação em dupla

• Agentes de IA (ex.: Copilot Agent) escrevem código muito mais rápido do que a velocidade de raciocínio humano
• Por isso, o código começa a surgir em volume antes mesmo que o usuário consiga acompanhar, causando perda de contexto e queda no nível de imersão no trabalho
• Quando o agente pede ajuda em uma situação problemática, o usuário muitas vezes acaba assumindo o papel de “arrumar a bagunça” sem sequer entender bem o que aconteceu, o que aumenta a carga de organizar código que já seguiu na direção errada
• No fim, fica mais difícil manter controle de qualidade, boa comunicação e a direção correta do trabalho

• A experiência de parear com os melhores agentes de IA traz de volta memórias negativas de pareamentos passados com programadores humanos excepcionais
  • O parceiro de dupla digita no teclado em velocidade excessiva, sem dizer nada, tornando impossível acompanhar o código
  • Depois de consumir toda a energia mental, a outra pessoa vai aos poucos se desconectando do trabalho
  • Quando a dupla trava, o parceiro pede ajuda, mas isso gera uma experiência constrangedora porque é difícil entender a situação
  • Durante o processo, surgem implementações em direção diferente do objetivo, e o peso de corrigir isso dentro do prazo acaba sendo repassado

The path forward: soluções práticas

• 1. Colaboração assíncrona

  • Assim como em programação em dupla com humanos quando uma pessoa conduz o trabalho, é mais eficaz que a IA escreva código de forma independente e isso seja revisado via Pull Request
  • Com fluxos de trabalho assíncronos como o GitHub Coding Agent, o usuário pode se concentrar em revisão e controle de qualidade

• 2. Pareamento “por turnos”, com velocidade reduzida

  • Em vez do “Agent Mode” da IA, usar um modo de progressão etapa por etapa, como Edit/Ask Mode
  • Como no ping-pong pairing (um lado propõe, o outro aprova), o usuário controla o ritmo aceitando/revisando diretamente as mudanças propostas pela IA
  • É desejável não usar IA apenas para resolução de problemas/debug, mas sim como parte de um fluxo de trabalho consistente

Ideias para tornar o pareamento com agentes mais humano

• Permitir que o usuário ajuste diretamente a velocidade de saída de código do agente (linhas/minuto, palavras/minuto)
• Recurso para pausar temporariamente o agente, para que o usuário possa fazer perguntas ou contestar a direção adotada
• Ir além da UI tradicional de chatbot, oferecendo primitivos de UI integrados ao andamento do trabalho (ex.: fixar a sessão atual a uma issue específica do GitHub, lista de tarefas embutida etc.)
• Projetar o agente para parar e conversar com mais frequência: confirmar “por que isso está sendo feito”, pedir conselhos, revisar a direção etc., criando um clima de colaboração humana
• Introduzir suporte avançado a chat por voz, para que o usuário mantenha os olhos no código e se comunique com a IA por voz

• Se esses recursos forem aplicados, em vez do pareamento atual com agentes, rápido e unilateral, será possível chegar a uma verdadeira experiência de colaboração conjunta entre humano e agente

Conclusão

• Neste momento, estamos vendo ao mesmo tempo os limites e o potencial da programação em dupla baseada em agentes de IA
• A programação em dupla com agentes de IA pode gerar mais resultado quando é desenhada em torno de comunicação, qualidade e verificação — e não apenas velocidade, como acontece na colaboração humana
• Uma abordagem de “ir devagar, conversar, verificar e compartilhar o contexto” melhora a qualidade do pareamento com IA

[panarch]

> 1. Colaboração assíncrona
> Assim como no pair programming com humanos, quando uma pessoa conduz o trabalho de forma mais ativa, é mais eficaz quando a IA escreve o código de forma independente e faz a revisão por meio de um Pull Request

Estou usando o Codex há alguns dias e, mais do que no formato de agente, concordo com isso. Agora que consigo tocar o trabalho de vários projetos ao mesmo tempo, realmente parece que estou trabalhando com vários desenvolvedores juniores.
Como passei a poder usar a IA de forma assíncrona, consigo delegar várias tarefas ao mesmo tempo em vários projetos e até em um mesmo projeto, e dá realmente para sentir na prática um ganho de produtividade de 3 a 10 vezes ou mais.

[GN⁺]

Opiniões do Hacker News

• Parece que este texto explica exatamente por que eu parei rápido de usar IA desse jeito. Quando quero construir alguma coisa, normalmente já tenho uma ideia aproximada de <i>como</i> fazer, mas a forma como a IA realmente faz isso muitas vezes é diferente do que eu quero. E quando a IA gera 2.000 linhas de código de uma vez, o trabalho acaba aumentando. Você precisa dizer coisas como: "primeiro apaga todos esses comentários, a explicação desnecessária em código simples está em dobro. Não abstraia X desse jeito, eu quero isto aqui..."; e quando dá feedback, de repente aquelas 2.000 linhas viram 700, mudando tudo de forma brusca e ficando difícil demais acompanhar. Também odeio quando a base de código vira um monte de scripts que eu mal conheço e que seguem estilos totalmente diferentes. Eu preciso de uma IA que se pareça mais com meu estilo e minha forma de pensar, mas isso é difícil demais. Trabalhar com IA parece um pouco como trabalhar com alguém sem experiência no primeiro dia. Pessoalmente, acho menos um problema de excesso de confiança da ferramenta e mais uma questão de ela ter tornado o processo de design mais visível. Idealmente, eu precisaria primeiro ver um documento de design dizendo algo como "estou pensando nesta abordagem, vou gerenciar estas funções, classes e estado desta maneira" e, se estiver bom, só então passar para a implementação.

  • Assim como com engenheiros humanos, vale reforçar que uma sessão de planejamento antes é realmente importante. Discutir e negociar os detalhes antes de escrever código. Eu costumo fazer de propósito a primeira pergunta o mais vaga possível para ver se surgem recomendações inesperadas, e vou ficando mais específico aos poucos. Quando fico satisfeito, peço ao LLM para criar dois documentos: initialprompt.txt e TODO.md. Em initialprompt.txt, ele inclui um resumo do projeto, a instrução para ler TODO.md e a ordem para marcar cada etapa conforme for concluída. Desse jeito, o LLM entende tanto o objetivo geral quanto as tarefas detalhadas, e depois, quando a conversa é interrompida por limite de contexto e precisa recomeçar, ele consegue retomar o trabalho rapidamente.

  • Senti que isso resume exatamente minha experiência também. Só consegui concluir com sucesso código escrito por IA quando o que importava era apenas o resultado final e eu quase não tinha conhecimento de domínio sobre a área. Quando eu tinha opiniões fortes sobre o que era um resultado “bom”, acabava frustrado e frequentemente abandonava o projeto. Com o recurso architect do roo code, primeiro organizei a abordagem e depois usei o modo code para implementar de fato; foi meio a meio entre alegria e frustração. A lição importante foi sempre começar tarefas novas, sem prolongar conversas longas. Eu já tenho o hábito de quebrar problemas em partes pequenas e verificar os resultados, mas com LLMs eu tendi a jogar todo o espaço do problema de uma vez e fracassar. Tentei várias vezes para encontrar meu próprio método e, ainda hoje, adicionei uma funcionalidade a um app em 30 minutos. Se eu implementasse sozinho, isso realmente levaria dias. E só registrei 30 minutos no diário porque eu sabia exatamente o que queria e não me importava com o processo. Essas experiências me levaram à conclusão de que pedir à IA para escrever código que outra pessoa vai ter de usar algum dia é impossível, por todos esses motivos.

  • No fim, a experiência só me deixou exausto e insatisfeito com os resultados. Digo isso para quem tem essa mesma preocupação. Para mim, as únicas vezes em que fiquei satisfeito com agentic coding foram em scripts de curto prazo onde eu não ligo para a qualidade do código ou em funções realmente isoladas, sem impacto em lugar nenhum.

  • O fluxo de trabalho recomendado no guia de uso do Claude Code da Anthropic vale a recomendação. A ideia principal é: “faça a IA ler o código primeiro, depois planejar a mudança, e só no final executar”. Você pode revisar e ajustar o plano antes que a IA escreva uma única linha. Se, ao usar um agente, ele estiver agindo de um jeito diferente do que você quer — por exemplo, começando a codar direto sem um plano — basta pedir: "faça de outro jeito".

  • Esse papo de gerar 2.000 linhas de código de uma vez me faz pensar se a pessoa não está digitando um prompt tipo “coloque Skyrim inteiro no SNES”. Aí vai almoçar, volta e fica brava porque a IA fez um Fallout em estilo PS1 com combate só corpo a corpo.

• Quando um texto meu vai para a primeira página do HN, eu sempre fico com medo de ler os comentários e descobrir o quão burro eu sou, ou de ver gente fazendo comentários agressivos para me humilhar. Mas, às vezes, se eu acerto muito bem no título, ninguém lê meu texto e cada um só fala de si mesmo, então eu escapo dessas críticas.

  • Acho uma observação divertida e realista. Vejo esse mesmo padrão com frequência em outros textos. De qualquer forma, gosto dessas discussões, então acabo achando divertido.

  • Gostei do texto. Ficou meio como um “como aproveitar pair programming com IA”. Foi útil, então agradeço.

• Quando usei agentes LLM pela primeira vez, eu esperava comunicação de mão dupla, um pair programming realmente colaborativo. Mas, na prática, encontrei um parceiro que quer resolver tudo inteiramente do jeito dele. Quando tentei ajustar um pouquinho, o contexto do código escrito pela IA se quebrou e a experiência ficou ainda pior. O que eu quero é colaboração de verdade: eu faço um pouco, a IA faz um pouco, e vamos nos alternando.

  • Pergunta se você tentou de novo recentemente. Minha experiência é diferente. Eu modifico o código gerado pela IA e depois mando ela reler o arquivo. Normalmente ela reage com algo como “vejo que houve mudanças no arquivo”. Quando a IA altera o código, eu rodo os testes e dou feedback, e ela vai melhorando de forma iterativa. Isso funciona bem para mim no Zed e com Claude Sonnet.

  • O jeito que eu geralmente uso é receber primeiro a sugestão da IA e depois refatorar ou, se necessário, pedir de novo por prompt. Essa abordagem acaba inflando artificialmente a taxa de aceitação (accept rate), e no fim essa estatística pode servir para empresas de IA sustentarem a tese de que “a IA escreve código muito bom”. Na prática, houve muitas vezes em que eu só pensei “ah, deixa, eu mesmo conserto isso”.

  • Eu normalmente consigo a conversa do jeito que quero acrescentando algo como “vamos apenas discutir primeiro. Não modifique o código”. Depois de bastante ida e volta, no final eu mando “aplique”.

  • Se você quer um certo tipo de colaboração, o conselho é pedir isso explicitamente ao LLM. Vale a pena deixar preparados alguns documentos de prompt para reutilizar em todas as conversas.

  • Hoje em dia manter o contexto já não é tão difícil, então editar código também não virou um problema para mim. Eu uso só o modo Ask (mais consulta e resposta do que comando), com Opus no Claude Code e o3 max no Cursor. Evito de propósito o modo agente porque, como no texto original, sinto que com o tempo o ganho para mim vai diminuindo. Uso conclusão por tab raramente, e 80% a 90% do código sugerido eu altero e digito com as próprias mãos. Por isso ainda consigo manter 170 wpm. A velocidade de saída do Opus e do o3 max é limitada, então também não fica difícil acompanhar a leitura; no começo foi rápido demais, mas me adaptei logo. Minha opinião pessoal é que, se GitHub Copilot é toda a sua experiência com LLM, isso não passa de uma experiência de nível motel.

• Pair programming também não serve para toda situação. Na verdade, em muitos casos talvez não sirva. Como mencionei em outro lugar, as sugestões de autocomplete do LLM quebram meu fluxo de concentração: preciso parar no meio, ler, revisar e aceitar ou rejeitar, e isso destrói completamente o estado de flow da programação. Foi realmente difícil tentar encaixar autocomplete de IA no meu fluxo de trabalho.

  • Penso o mesmo. A solução é usar tanto uma IDE dedicada sem IA quanto Cursor/VS Code, alternando entre as duas. Entrar em verdadeiro foco profundo enquanto conversa com um chatbot é impossível.

  • Recentemente comprei um notebook novo e reinstalei a IDE. Depois de algumas horas programando, senti que tinha algo “estranho”. Aí percebi que tinha esquecido de fazer login no GitHub Copilot e estava trabalhando sem IA. Senti que estava escrevendo código de forma muito mais ativa, sem esperar autocomplete. O Cursor em particular interrompe demais o fluxo, então até esses recursos de “prever a próxima posição do cursor” me parecem totalmente desnecessários. Daqui para frente, pretendo deixar o Copilot desligado e usar ferramentas estilo agente como o aider só para boilerplate ou tarefas repetitivas.

  • Autocomplete de IA ou sugestões de código ficam especialmente ruins quando você usa linguagens com tipagem forte. Na maioria das vezes a IA acerta uns 80%, enquanto o autocomplete da IDE chega perto de 100%. A abordagem de agente de IA é melhor porque 1) não interrompe seu fluxo de pensamento o tempo todo e 2) ela mesma compila e roda os testes, corrige o que está errado e devolve código funcional.

  • Eu, ao contrário, adoro autocomplete. Como preciso usar Go, há muito boilerplate, e isso não é algo que se resolva apenas adicionando bibliotecas, então muitas vezes digitar à mão é mais rápido. Para esse tipo de código chato, minha mão é mais rápida que a IA, então autocomplete ajuda de verdade. Sugestões de uma linha eu leio num instante, e sugestões longas, se parecem com o que eu já ia escrever, eu simplesmente deixo passar. Com o tempo você pega o jeito do que a IA tende a prever. Não é um ganho gigantesco de produtividade, mas acelera bastante coisas irritantes como mensagens de log ou loops for. Para mim, só ajuda quando ler é muito mais rápido do que digitar.

  • Pair programming não é a melhor opção em todos os casos, mas acho que na maioria das situações ele pode ser útil. Quando não funciona bem, normalmente é porque uma das pessoas — ou as duas — não está realmente engajada no processo, porque uma delas já chega dizendo “isso não funciona”, ou porque alguém tenta seguir os princípios de pair programming de forma rígida demais.

• Minha posição é meio complicada. Há pelo menos um mês venho usando ativamente todas as ferramentas LLM da empresa para aprender a aproveitá-las da forma mais eficaz possível. Em quantidade de linhas de código, a produtividade sem dúvida aumentou. Mas não posso dizer que, no geral, fiquei mais produtivo. Em quase toda tarefa concluída, aparece algum comportamento estranho que eu não sei explicar, ou então a ferramenta mexe em partes sem relação e eu preciso reverter. Os testes gerados automaticamente pela IA parecem plausíveis à primeira vista, mas quando você olha para outros indicadores, como cobertura, as deficiências ficam claras. Para chegar ao resultado desejado, muitas vezes parece que eu preciso voltar várias etapas para trás. Dá uma sensação não de ganho ou aprendizado, mas de retrocesso total. Uma vez, a ferramenta adicionou escondido 50 mil linhas de imports desnecessários em um módulo que nem fazia parte do escopo da alteração. Em outra ocasião, mesmo depois de eu definir as regras claramente, ela destruiu toda a estrutura orientada a objetos e implementou tudo com um monte de if/else. O problema é que os resultados variam demais conforme a situação; até na mesma tarefa, às vezes sai perfeito e às vezes destrói tudo. Já tentei várias formas de orientar e distribuir o trabalho, mas mesmo em tarefas parecidas o comportamento muda demais, então a dor de revisar as mudanças é constante. Mesmo quando o código está quase certo, se eu peço para corrigir só um ponto específico, o trabalho inteiro muitas vezes desanda. Pela minha experiência, isso funciona para escrever ferramentas pequenas, mas é difícil esperar resultados consistentes em codebases médias ou grandes.

• Agentes LLM parecem falar demais e sempre achar que o jeito deles é o certo. Não são concisos e explicam longamente coisas que caberiam em uma linha. Colocam comentários enormes até em mudanças triviais. Tentam me ensinar, vêm com excesso em tudo.

  • Alguns comportamentos que as pessoas odeiam ("saída longa demais, comentários em excesso etc.") podem ser efeitos colaterais de o LLM ter sido projetado para melhorar eficiência em outros aspectos. Saídas longas tendem a se associar com código menos preguiçoso e notas melhores em benchmarks de desempenho. O excesso de comentários também pode reforçar o contexto local, melhorando a qualidade do código seguinte e reduzindo erros.

  • Ontem usei o sonnet 4, e ele passou 15 minutos testando e refatorando sem parar só para mudar um único valor de configuração. No fim, alterou 40 arquivos sem necessidade. Também ficava tentando executar um depurador que nem existia e abrir repetidamente páginas web que exigiam autenticação. Fiquei com a sensação de que está muito longe de ser algo perfeito.

• Na minha experiência, o problema não é ser rápido, mas sim ser lento demais. A velocidade é ambígua na medida errada, então fica pior. Se fosse mais rápido, eu conseguiria acompanhar o código em tempo real enquanto trabalho. Se fosse mais lento, eu poderia ir fazer outra coisa e voltar depois. Mas, na prática, a tarefa termina entre 50 segundos e alguns minutos, e isso não deixa eu me concentrar em outra coisa. Acho que seria melhor iterar mais rápido em unidades menores. No fim das contas, o ideal seria uma autonomia no nível de revisão humana, algo como trabalho independente do tipo revisar um merge request (PR). O loop atual — passar a tarefa, esperar 1 a 3 minutos, ver o resultado, dar feedback e repetir — para mim é o pior cenário possível.

  • Isso me lembra a tirinha do The Oatmeal sobre “internet lenta versus nenhuma internet”.

  • Quando a concentração se dispersar, a dica é colocar um aquário de 30L na mesa. Ótimo para ficar olhando para o nada.

• Como desenvolvedor, quase não uso IA; no máximo, às vezes uso um chatbot para perguntas fora de projeto. Tenho curiosidade se vocês usam IA também em projetos de clientes ou só em projetos pessoais. E, se usam para clientes, colocam no contrato que o código será enviado para uma IA? A maioria dos clientes trabalha com NDA e cláusulas de confidencialidade, e alguns já incluíram proibição explícita de uso de IA. Fico curioso se alguém já encontrou cliente que aceite ferramentas de IA para programação como exceção.

  • Eu uso quase só internamente, e isso porque a empresa tem diretrizes claras sobre uso de IA. Na prática, não sinto que economize tanto tempo assim, então eu não pagaria para usar isso em projetos pessoais. Em projetos próprios, o mais importante para mim é o prazer de construir, não apenas o resultado, então é mais divertido fazer eu mesmo do que ficar trabalhando em prompt.

  • Também há casos em que o cliente pede ativamente o uso de IA. A expectativa é qualidade melhor e desenvolvimento mais rápido (no fim, redução de custo), mas muitas vezes a realidade não corresponde a essa expectativa (embora isso já seja outra discussão).

  • Eu só compartilho com OpenAI/Anthropic código que eu poderia colar tranquilamente em uma caixa de busca na web, ou seja, código que já é público.

  • Eu não compartilho. Isso inclui projetos internos, e qualquer compartilhamento externo de código só seria possível mediante pagamento. Como também lido com dados pessoais, o risco jurídico de expor código a empresas americanas é alto demais.

• Finalmente alguém apontou exatamente o problema. A IA mostra confiança excessiva no design e segue para a implementação detalhada por conta própria, sem combinar. Até APIs mockadas muitas vezes acabam quebrando a estrutura e exigindo retrabalho. Eu queria que o comportamento do LLM fosse mais colaborativo e que, quando faltassem detalhes, ele perguntasse imediatamente. Não dá para colocar todas as informações no prompt inicial, e prompts adicionais acabam quebrando o contexto e a linha de raciocínio do design original. Fico me perguntando se estou usando errado ou se existe um jeito melhor. Gostaria que o LLM melhorasse no sentido de receber feedback incremental e incorporá-lo. Talvez adicionar e atualizar contexto seja um problema difícil por si só, mas quero continuar aprendendo.

  • Hoje em dia a maioria das stacks suporta uma sessão de “design/planejamento”, então vale testar isso primeiro para ver se melhora. Um fluxo que funciona bem para mim, com modelo grande ou pequeno, é começar com algo como: “com base em @file, @docs e @examples, quero fazer _ em @path, consultando @module_requirements.md — vamos discutir tudo o que for necessário antes da implementação real”. Depois de bastante ida e volta até todo mundo concordar, você pode salvar isso em um arquivo .md ou simplesmente seguir com “agora pode prosseguir”. Também dá para registrar o fluxo em .rules, arquivos .md, snippets da IDE etc., e reutilizá-lo em novas tarefas. Só vale lembrar que os LLMs mais recentes exigem muito mais contexto, então é importante experimentar fluxos diferentes para cada codebase (cada projeto), porque os resultados também mudam.

  • Também tenho a sensação de que, quanto mais informação você dá, mais a IA se confunde. Talvez exista uma forma de superar isso. Ela é muito boa em extrair pedaços bem pequenos de informação, mas acho uma pena que a indústria inteira esteja tão focada apenas em modelos de chatbot. Fico imaginando como seria se nunca tivéssemos criado teclado, mouse, interface gráfica ou tela sensível ao toque.

• Acho que o estilo colaborativo, usando a IA como assistente, é justamente a forma correta de usar IA, e essa moda de focar em “IA escrevendo código diretamente” é um exemplo de o setor de software estar indo na direção errada. Eu nunca deixo a IA escrever código para mim. Uso para criticar código que eu escrevi ou para formular estratégias de design de estruturas grandes. É como usar um consultor estratégico: se você montar bem o contexto do LLM, consegue orientação excelente. O agente principal sou sempre eu, entendendo e executando; meu princípio é nunca dar à IA responsabilidade maior do que a de conselheira. Eu trato a IA como um “idiot savant” e acho que ela deve ser abordada com cautela.