O papel da capacidade dos desenvolvedores na codificação agêntica

• À medida que os assistentes de codificação agênticos se tornam mais capazes, as reações têm sido muito variadas, e alguns chegam a afirmar que "dentro de um ano os desenvolvedores não serão mais necessários"
• Outros levantam preocupações sobre a qualidade do código gerado por IA e sobre como preparar desenvolvedores juniores para esse ambiente em transformação
• Nos últimos meses, usei assistentes de codificação agênticos como Cursor, Windsurf e Cline, e eles foram muito eficazes para alterar codebases existentes
• Fiquei muito impressionado com a integração com a IDE, que inclui execução de testes e correção automática de erros, detecção e correção de erros de lint/compilação, busca na web e até recursos de pré-visualização no navegador
• A experiência de colaboração entre desenvolvedor e IA foi muito impressionante e contribuiu para resolver problemas e implementar funcionalidades com rapidez

• No entanto, ainda foi necessária a intervenção contínua do desenvolvedor, com correções e definição de direção
• Em muitos casos, isso nem chegou a resultar em commits reais, e a IA ainda é insuficiente para escrever de forma autônoma código para tarefas não triviais
• Portanto, as habilidades e a experiência dos desenvolvedores continuam sendo importantes e devem seguir sendo treinadas no futuro

Momentos em que o desenvolvedor precisou intervir diretamente

• As ferramentas de IA apresentaram desempenho consistentemente fraco em certas áreas, algo confirmado repetidamente
• Parte disso pode ser parcialmente mitigada com prompts adicionais ou regras personalizadas, mas controle total é impossível
  • LLMs frequentemente não seguem com precisão as instruções do prompt
  • Quanto mais longa a sessão de codificação, menor a consistência dos resultados
• Portanto, os casos apresentados abaixo são problemas que podem ocorrer com frequência suficiente independentemente de prompt ou configuração
• Os erros da IA foram classificados em 3 categorias de acordo com o raio de impacto
  • a. Redução da velocidade de desenvolvimento e aumento do tempo até o commit
    • A IA acaba desacelerando em vez de ajudar
    • Em alguns casos, é menos eficiente do que programar sem assistência
  • b. Geração de atrito no fluxo de trabalho da equipe
    • Surgem conflitos ou problemas de colaboração dentro de uma iteration
  • c. Piora da manutenibilidade do código no longo prazo
    • No início, parece não haver problema, mas depois surgem dificuldades em mudanças ou expansões futuras
• Quanto maior o raio de impacto, mais longo é o loop de feedback até que a equipe perceba e corrija o problema

Raio de impacto: atraso no tempo até o commit

• Esta categoria reúne casos em que a IA atrapalhou em vez de ajudar
• Como é a forma mais evidente de falha, não tende a ser um grande problema
  • Na maioria das vezes, o desenvolvedor consegue perceber e impedir o problema antes da etapa de commit

• Código que não funciona

  • O código gerado pela IA simplesmente não funciona
  • O desenvolvedor precisa corrigir manualmente ou encerrar a sessão com a IA e resolver o problema manualmente
  • Um desenvolvedor experiente consegue identificar rapidamente onde deu errado e agir

• Diagnóstico incorreto do problema

  • A IA identifica erroneamente a causa do problema e tenta uma solução na direção errada
  • Com base em experiência anterior, o desenvolvedor conseguiu trazer a IA de volta do caminho equivocado

    Exemplo: um erro de build no Docker foi interpretado como um problema de configuração de arquitetura, e a configuração foi alterada
    A causa real era a cópia de node_modules compilado em uma arquitetura incorreta
    Como era um problema frequente no passado, foi possível reconhecê-lo e corrigi-lo rapidamente

Raio de impacto: fluxo de trabalho da equipe dentro da iteration

• Esta categoria trata de casos em que surge atrito dentro da equipe durante a iteration por falta de revisão ou de intervenção do desenvolvedor
• O autor conseguiu perceber e ajustar preventivamente esses problemas antes do commit graças à experiência acumulada em diferentes equipes
• Desenvolvedores iniciantes também podem aprender essas lições ao passar por tentativa e erro com IA
• Mas, se a IA acelerar a codificação, a equipe pode não conseguir absorver esses problemas

• Trabalho inicial excessivo

  • A IA tende a tentar implementar a funcionalidade inteira de uma vez, em vez de avançar de forma incremental
  • Se, por causa disso, a escolha técnica for inadequada ou os requisitos forem mal compreendidos, muito trabalho pode ser desperdiçado

    Exemplo: em uma migração de stack frontend, houve tentativa de converter todos os componentes de UI de uma só vez
    O ideal teria sido aplicar a mudança gradualmente, começando por um único componente integrado ao backend

• Resolver sem analisar a causa

  • Sem analisar a causa raiz do problema, a IA tenta apenas corrigir o erro visível na superfície
  • Depois, outro membro da equipe que assumir o problema passa a ter o ônus de reanalisar a situação sem contexto

    Exemplo: diante de um erro de memória durante o build no Docker, em vez de procurar a causa, a IA apenas aumentou a configuração de memória

• Complexificação do workflow do desenvolvedor

  • A forma de build/execução gerada pela IA piora a experiência do desenvolvedor
  • Se isso for commitado imediatamente, o workflow dos outros membros da equipe também será prejudicado

    Exemplo: os comandos para executar frontend e backend são fornecidos separadamente
    Exemplo: ausência de hot reload
    Exemplo: uma configuração de build complexa deixa tanto desenvolvedores quanto a IA confusos
    Exemplo: a IA não detecta previamente um erro de Docker e tenta tratá-lo apenas no fim do build

• Requisitos mal compreendidos ou incompletos

  • Se os requisitos da funcionalidade não forem apresentados com clareza, a IA pode entendê-los mal e implementar a funcionalidade na direção errada
  • O ideal é corrigir isso logo no começo, mas tanto com uma IA autônoma quanto com um desenvolvedor desatento, o custo de correção posterior aumenta
  • Essas implementações incorretas acabam sendo descobertas mais tarde durante o andamento da story, gerando muito retrabalho e custo de comunicação

Raio de impacto: piora da manutenibilidade no longo prazo

• É o raio de impacto mais sorrateiro e perigoso
  • No início, o código funciona sem problemas, mas depois fica difícil alterá-lo e expandi-lo
• Muitas vezes, esses problemas só são descobertos semanas ou meses depois
• Especialmente nessa área, foi onde mais pesaram os mais de 20 anos de experiência em desenvolvimento do autor

• Código de teste verboso e redundante

  • A IA é boa em gerar testes, mas frequentemente surgem problemas como:
    • criar novas funções de teste em vez de integrar aos testes existentes
    • adicionar assertions demais até mesmo em partes já cobertas
  • Um ponto que desenvolvedores iniciantes podem interpretar mal: mais testes ≠ testes melhores
  • Quanto maior a redundância, mais difícil a manutenção, e maior a chance de falhas em massa nos testes quando o código mudar
  • Tentou-se mitigar isso com comandos personalizados, mas ainda assim acontece com frequência

• Baixa reutilização

  • O código escrito pela IA frequentemente tem pouca modularização, o que dificulta a reutilização

    Exemplo: não reconhecer um componente de UI já existente e implementar outro duplicado
    Exemplo: abusar de estilos inline em vez de usar classes CSS

• Código excessivamente complexo ou verboso

  • A IA frequentemente gera mais código do que o necessário, obrigando a remoção manual de partes desnecessárias
  • Isso aumenta o custo de manutenção e eleva a possibilidade de erro ao fazer mudanças

    Exemplo: ao alterar CSS, é preciso apagar manualmente muitos estilos duplicados
    Exemplo: criar um web component desnecessariamente complexo para exibir dados JSON
    Exemplo: durante um refactoring, a IA não percebe a cadeia existente de injeção de dependência,
    e torna o design mais complexo ao passar novamente como outro parâmetro um valor que já havia sido injetado

    • no formato value = service_a.get_value(); ServiceB(service_a, value=value)

Conclusão: a IA poderá escrever todo o código no lugar de todos?

• Com base na experiência até aqui, é irrealista que, dentro de um ano, a IA escreva de forma autônoma 90% de todo o código
• Ainda assim, como assistente para escrita de código, há equipes e codebases em que um nível de apoio de 90% é possível
• Na prática, o autor afirma estar recebendo cerca de 80% de ajuda da IA em um projeto de complexidade média com 15K LOC

Como evitar os erros da IA

• O que pode ser feito no nível do desenvolvedor individual

  • Sempre revisar cuidadosamente o código gerado pela IA
    • Quase nunca acontece de não haver nada para corrigir
  • Interromper imediatamente a sessão com a IA se ela ficar confusa
    • Ajustar o prompt ou simplesmente mudar para o trabalho manual (também chamado de "codificação artesanal")
  • Desconfiar de soluções "plausíveis" que parecem milagrosamente prontas em pouco tempo
    • Pode haver um custo oculto de manutenção de longo prazo
  • Praticar pair programming
    • 4 olhos e 2 cérebros oferecem julgamentos melhores

• Estratégias de resposta no nível de equipe e organização

  • Usar ativamente as ferramentas existentes de monitoramento da qualidade do código
    • Ex.: Sonarqube, Codescene
    • Ao usar ferramentas de IA, é preciso monitorar com mais atenção duplicação de código, code smells etc.
  • Configurar pre-commit hooks e revisão de código integrada à IDE
    • Reforçar estratégias de shift-left para detectar problemas logo no início do desenvolvimento
  • Restabelecer bons hábitos de qualidade de código
    • Compartilhar em retrospectivas semanais os casos de problemas causados por código de IA (o "log do que deu errado")
  • Usar ativamente regras personalizadas
    • A maioria das ferramentas de IA permite configurar um conjunto de regras enviado junto com o prompt
    • A equipe pode reduzir erros da IA melhorando o ruleset em conjunto
    • No entanto, quanto mais longa a sessão, maior a chance de as regras serem ignoradas
  • Construir uma cultura de equipe baseada em confiança e comunicação
    • A adoção de IA é uma mudança nova, e é preciso reconhecer que todos são iniciantes
    • Pressão do tipo "já que tem IA, faça mais rápido" aumenta o risco de qualidade
    • Equipes com segurança psicológica tendem a compartilhar problemas e aprender com mais intensidade

[bus710]

As pessoas que usam essa ferramenta, independentemente da capacidade, no fim das contas são todas desenvolvedoras.... Então parece meio estranho fazer propaganda como se no futuro não fosse mais precisar de desenvolvedores.

[prunusnira]

Não sei como isso vai evoluir no futuro, mas por enquanto ainda não me parece muito bom para uso mainstream... Recentemente usei o Cursor, e ele nem conseguia resolver direito algo básico como o caminho de import de arquivos. Ainda assim, foi meio impressionante como ele conseguia prever até certo ponto o que eu queria criar.

[daddy]

Quando ocorreu um erro de memória durante o build do Docker, em vez de perguntar desde o início por que tanta memória estava sendo usada, aumentaram a configuração de memória
-> Isso é... porque já fizemos assim em inúmeros casos no passado.
-> A IA de agora somos nós do passado

[GN⁺]

Comentários no Hacker News

• Hoje em dia uso o Cursor para a maior parte do desenvolvimento. Este texto é muito parecido com a minha experiência

  • Parece que os agentes de IA pararam por volta de 2021. Se você instala um pacote novo, o Claude volta para pacotes antigos ou implementações que eram populares há 4 anos. Corrigir isso é muito frustrante. Fornecer instruções claras pode amenizar o problema, mas não o resolve
  • A imprevisibilidade desses erros é especialmente desafiadora. Alguns meses atrás, usei o Claude para criar um web app útil em "one-shot". Era totalmente funcional e surpreendentemente sofisticado. Se eu tivesse feito sozinho, teria levado semanas ou vários fins de semana. Mas quando pedi para atualizar o favicon usando os arquivos fornecidos, ele ficou girando inutilmente por uma hora inteira (no fim, resolvi eu mesmo em poucos minutos). Alguns dias atrás, tentei criar de novo um web app de escopo parecido. Depois de umas 4 horas lidando com o agente, fiquei pronto para jogar todo o código fora
  • Essa abordagem me dá coragem para perseguir projetos que eu não teria tentado por falta de tempo, expertise ou motivação. Reduzir o atrito é empolgante, mas criar algo significativo ainda é difícil. Ainda é necessário um esforço considerável para construir um MVP sofisticado
  • Fico pensando o tempo todo na lebre e na tartaruga. Confiar em agentes de IA é tentador porque no começo parece que o progresso é muito mais rápido. Mas no fim fica a sensação de que eu teria avançado de forma mais sólida se tivesse ido devagar e com cuidado. Quando construo manualmente, quase nunca preciso voltar atrás ou abandonar a abordagem inteira. Em uma abordagem guiada por IA, dá para andar 10x mais rápido, mas talvez jogar fora uns 70% do trabalho no processo
  • Por causa dessas experiências, não consigo imaginar a IA escrevendo 90% do código de forma autônoma dentro de um ano. Ela pode ajudar a escrever 90% do código
  • O ambiente atual parece o ciclo de hype dos carros autônomos. Houve muitas promessas ousadas e progresso real, mas não vejo um mundo, nos próximos 5 anos, em que a IA escreva sozinha software útil

• Eu uso IA assim: como uma ferramenta de apoio à escrita dentro da IDE, que me responde como um pato de borracha muito legal e sofisticado

  • Frequentemente repito discussões sobre trechos específicos de código. Normalmente eles são fornecidos quase sem contexto, e eu vou refinando até que a funcionalidade opere corretamente, depois apresento isso no contexto mais amplo (ou eu mesmo cuido dessa parte)
  • Não uso assim: como um agente que deve alcançar objetivos amplos por conta própria
  • Motivo: o tempo e o esforço que preciso investir para garantir que a saída do sistema de agentes esteja alinhada com o que realmente quero alcançar são grandes demais. Por todos os motivos explicados neste ótimo texto
  • Paradoxalmente, usar IA como uma ferramenta de apoio à escrita muito competente acelera bastante meu fluxo de trabalho. Então, até certo ponto, uma IA menos agentic me torna mais crítico, inclusive em relação ao tempo extra que eu teria de investir para me adaptar às peculiaridades da IA agentic

• Eu realmente não entendo

  • Não entendo por que desenvolvedores experientes ficam tão empolgados em se prender a uma experiência tão obviamente ruim e insatisfatória
  • Eu gosto de escrever código e resolver problemas. Foi por isso que escolhi desenvolvimento de software como profissão

• Exemplo: quando ocorreu um erro de memória durante um build do Docker, em vez de perguntar por que tanta memória estava sendo usada desde o começo, ele aumentou a configuração de memória

  • A IA realmente é igual a nós

• As habilidades de desenvolvedor continuam essenciais — se você não sabe dirigir, não consegue pilotar. Mas e a energia do desenvolvedor? Antes da IA, eu só conseguia codar cerca de 2 horas por dia (tempo real escrevendo código). Mas com o Claude Code, consigo codar facilmente por 5 horas seguidas sem parar. É como andar de bicicleta elétrica em vez de bicicleta comum. A IA parece a metáfora da bicicleta para a mente do Steve Jobs — ela não me substitui, mas agora consigo ir muito mais longe e mais rápido

• Este diagrama é absurdamente identificável — nossa equipe marca todos os itens daqui. Mesmo sem usar IA ainda! Imagine quando finalmente passarmos a usar...

  • "Requisitos mal compreendidos" e "implementação complexa demais" são praticamente nossos mascotes. Estamos desenrolando esse caos aos poucos com conversas iniciais melhores e revisões iterativas. Mas hábitos não desaparecem facilmente. Será que existe alguém navegando por essas armadilhas sem a ajuda da IA?

• Para mim, o óbvio não aparece: usar IA ao redor

  • Muitas vezes é preciso construir e manter ferramentas como tooling de desenvolvimento, introspecção, logging, transformação etc. Tive muita sorte usando agentes para criar e modificar isso. Por exemplo, ferramentas para coletar dados e reunir logs em um sistema de planejamento customizado
  • Há muito boilerplate gerado fora do caminho crítico para construir essas ferramentas. Na maioria dos dias, eu não quero fazer isso

• Eu preciso pilotar bastante a IA, mas continuo otimista de que prompts melhores levarão a agentes melhores

  • Vamos pegar o exemplo do artigo: reutilização de código. Quando escrevo código, tenho inconscientemente um inventário mental do código que já existe. Inconscientemente me pergunto: "essa nova tarefa é muito parecida com um código já existente, funcional e testado?". Não examinei os detalhes do prompt inicial que os agentes de código recebem, mas meu instinto diz que seria bom adicionar ao agente um prompt instruindo-o a manter um inventário do que existe na codebase e, ao planejar um novo conjunto de código, contrastar os requisitos da nova tarefa com o que já existe
  • Sim, isso adiciona muitos ciclos de computação ao processo de planejamento. Mas, honestamente, é preciso dizer: "esse é o preço de fazer o agente escrever código". Planejamento melhor > maior capacidade de resolver problemas

• Quero prefaciar dizendo que as ferramentas de IA são sempre ruins nas coisas que listei

  • Acho que faltou um "não" aí. Por que alguém prefaciaria dizendo que elas são sempre ruins? O contrário faria mais sentido
  • Também há um erro gramatical: usaram "effected" em vez de "affected"

• O Martin Fowler agora está alugando espaço no site dele?