O humano no loop está cansado

• A programação com LLM aumenta a produtividade, mas ao mesmo tempo amplia a fadiga de supervisão, já que o desenvolvedor precisa manter o controle constante sobre intenção e qualidade, abalando a satisfação e a sustentabilidade
• Os modelos geram código plausível rapidamente, mas podem perder a intenção consistente em mudanças complexas, fazendo do humano o gate de qualidade que revisa e corrige um volume maior de resultados
• Mesmo que a quantidade de tarefas que podem ser iniciadas dispare, o volume de trabalho que pode ser concluído com cuidado continua limitado pelo cérebro e pela atenção humanos, enquanto as pequenas recompensas da programação diminuem e a carga cognitiva da revisão aumenta
• Em áreas profundamente compreendidas, é possível orientar LLMs com eficiência, mas em áreas de especialização superficial eles tendem mais à plausibilidade do que à precisão, tornando gosto e julgamento arquitetural ainda mais importantes
• A engenharia de software tende menos a desaparecer e mais a encolher e se reorganizar; o recurso escasso não é escrever código em si, mas a atenção humana, o julgamento de engenharia e a capacidade de manter uma visão consistente do sistema

---

Programação com LLM: útil, mas instável

• A programação com LLM é praticamente útil e ao mesmo tempo instável; ignorar essa instabilidade pode levar desenvolvedores ao burnout
• A equipe do Pydantic também vive a mesma confusão enquanto cria validação de dados, agentes de IA e ferramentas de observabilidade para produção
• A questão central não é se a IA vai substituir programadores, mas como a experiência atual de desenvolvimento mudou e com o que ela pode ser melhorada

A sensação de construir com as próprias mãos

• Programar sempre ofereceu uma sensação de criação, permitindo construir algo só com lógica e lidar diretamente com camadas profundas de abstração
• Para quem aprendeu engenharia de software por tentativa e erro, em vez de por formação tradicional em ciência da computação, princípios de arquitetura e qualidade de código se parecem mais com cicatrizes acumuladas do que com regras de livro-texto
• Ferramentas low-code/no-code dos anos 2010 e produtos como Dreamweaver também prometiam criar coisas sem código, mas geravam código espaguete internamente e não cumpriam totalmente essa expectativa
• As ferramentas de IA atuais, ao contrário das anteriores, reduziram a distância entre promessa e realidade a um nível significativo, e é exatamente isso que as torna mais inquietantes

A experiência real de “o código se escreve sozinho”

• Até certo ponto, o código realmente se escreve sozinho, mas a experiência humana de revisar, orientar e corrigir o rumo disso pode piorar
• Douwe, mantenedor do Pydantic AI, precisava revisar todas as manhãs cerca de 30 PRs feitos durante a noite pela IA de outras pessoas, tomando decisões imediatas sobre cada um
  • A tentação de delegar também a revisão à IA é grande, mas isso deixa a dúvida sobre o que exatamente sobra para o humano fazer
• Mesmo depois de passar quase dois dias escrevendo e refinando repetidamente um plano para o LLM executar, o modelo ainda pode mover um hook do React para um arquivo de story do Storybook ou ler o plano errado e criar um componente que nem existe
• Essas falhas se parecem menos com mera falta de capacidade e mais com falta de consistência
  • O modelo é inteligente o bastante para gerar código plausível, mas pode não conseguir manter uma única intenção ao longo de uma mudança complexa inteira
• O humano precisa continuar avaliando grandes volumes de resultados “quase certos” enquanto preserva a intenção na cabeça, e nesse processo surge uma nova forma de fadiga de supervisão
• Também diminui a recompensa de construir funcionalidades com pessoas reais em open source e ajudá-las a evoluir
  • Quando o trabalho entra numa caixa-preta de IA, não há ninguém aprendendo do outro lado, então a satisfação da colaboração desaparece

A armadilha de intensificar o trabalho

• O estudo da Berkeley Haas, apresentado por Simon Willison, afirma que usar IA não reduz a carga de trabalho; em vez disso, aumenta a intensidade do trabalho
  • No fim do dia, continua existindo a pressão de mandar só mais um prompt ou concluir só mais uma funcionalidade
  • A sensação de estar quase terminando o plano pode levar alguém a continuar enviando prompts até perto das 2 da manhã
• Marcelo, da Pydantic, brinca que, se uma sessão do Claude Code travar, basta abrir cinco sessões
  • A ideia é que, se você estiver ocupado demais dando feedback às outras, talvez nem perceba que uma delas parou
• O trabalho em paralelo aumenta muito a quantidade de coisas que podem ser iniciadas, mas não muda a quantidade de coisas que podem ser concluídas com cuidado
  • Concluir exige o cérebro humano, um recurso que não pode ser paralelizado

Falha na função de recompensa humana

• Assim como a função de recompensa em machine learning define bons resultados para um agente, a programação manual também tinha pequenas recompensas como resolver problemas, entender lógica complexa, compilar com sucesso e sentir controle
• A programação assistida por LLM automatiza as tarefas que geravam essas recompensas de dopamina e preenche esse espaço com a carga cognitiva de revisar e supervisionar
  • O que era satisfatório diminui
  • O que era desgastante aumenta
  • Ainda não surgiu uma nova recompensa para preencher esse vazio
• O fato de a produtividade subir enquanto a satisfação cai não é defeito individual, mas uma falha no loop de feedback que precisa ser tratada como um problema de engenharia separado

Isolamento e recompensa variável

• Programar com LLM pode se tornar uma atividade muito solitária, em que humano e máquina repetem prompts, correções e revisões
• Momentos de perguntar algo a colegas, resolver problemas em voz alta juntos e compartilhar pequenas alegrias da solução acabam sendo substituídos por mais um prompt
• Em equipes com cultura colaborativa já fraca, a comunicação entre pessoas pode se retrair ainda mais, e fica mais difícil confirmar que os outros também estão passando por dificuldades
• O fato de o resultado às vezes ser excelente e às vezes um lixo, sem que isso possa ser previsto, cria uma estrutura de recompensa variável parecida com uma Skinner Box
• Ainda é possível escrever código manualmente quando necessário, mas o trabalho assistido por LLM e o trabalho manual exigem modos de pensar muito diferentes, tornando a troca desconfortável
  • Permitir a si mesmo alternar entre os dois exige maturidade e confiança

Semelhança com a transição para design responsivo

• Por volta de 2009, quando a web passou de layouts de largura fixa em pixels para design responsivo, os designers também sentiram perda de controle
• Para quem construiu identidade e especialização em layouts precisos e grids perfeitos, a ideia de o design fluir conforme larguras de tela e dispositivos arbitrários foi uma mudança fundamental
• Os designers que se adaptaram à transição não abandonaram suas habilidades anteriores; eles as reorganizaram
  • O senso de proporção e a compreensão de hierarquia continuaram importantes
  • A obsessão por controle em nível de pixel perdeu importância
  • Sistemas, adaptabilidade e projetar para a incerteza se tornaram mais importantes
• A transição atual com IA é muito mais rápida do que a do design responsivo e envolve interesses diferentes
  • A mudança do design responsivo levou anos, enquanto a atual avança em escala de meses
  • Na época, agências perdiam clientes e designers perdiam trabalho, mas isso não vinha acompanhado da mesma ansiedade existencial de hoje
• Ainda assim, o padrão de a técnica não desaparecer, mas evoluir, e de as competências centrais se tornarem mais importantes também se aplica ao código baseado em LLM
• Mesmo sem escrever pessoalmente todo o código, o valor do engenheiro não diminui; mas, como ele se tornou o gate de qualidade de um volume muito maior de resultados, cresce a necessidade de saber identificar o que é bom

Especialização que sobrevive e novas formas de trabalhar

• Num ambiente em que qualquer pessoa pode produzir uma UI plausível e código que compila, gosto e nuance, julgamento arquitetural maduro e decisões fora do consenso baseadas em especialização real viram diferenciais
• Quanto mais profundamente se entende uma área de código, decisões e trade-offs, melhor se consegue orientar um LLM com sucesso
• Quanto mais superficial é a especialização numa área, mais o resultado se afasta do nível pronto para produção e mais se aproxima de algo impressionante e plausível, mas não necessariamente correto
  • O modelo preenche lacunas com confiança sem saber o que não sabe, um tipo de falha que também aparece em humanos
• Em planos complexos, dá para usar um pre-mortem
  • Você pede a uma nova sessão de LLM que assuma que o plano fracassou miseravelmente e diagnostique as causas
  • Isso ajuda a encontrar lacunas de especificação que passaram despercebidas por quem olhou os detalhes por dois dias
• Um engenheiro da Pydantic criou uma ferramenta que extrai regras de milhares de comentários antigos de code review e as transforma em instruções iniciais num arquivo AGENTS.md
  • Isso equivale à destilação da especialização, transformando julgamento de engenharia acumulado implicitamente ao longo de anos em diretrizes que o LLM consegue seguir
• Quem está se adaptando à mudança tem critérios fortes formados na prática e consegue distinguir entre princípios que continuam válidos e hábitos que nasceram de limitações antigas de largura de banda
• Essas pessoas estão dispostas a mudar o fluxo de trabalho sem abandonar seus critérios

O recurso escasso revelado dentro do loop

• A onda atual de IA não encerra a profissão de engenharia de software, mas pode provocar uma contração severa e uma reorganização fundamental do setor
• O medo de obsolescência, de degradação de capacidade e de ficar para trás por não se mover rápido o suficiente é legítimo
  • A última preocupação às vezes é exagerada, mas não é totalmente sem fundamento
• O verdadeiro gargalo nunca foi o código, e sim a atenção humana, o julgamento de engenharia e a capacidade de manter uma visão consistente do sistema
• Isso não aparecia com tanta clareza antes porque escrever código parecia a parte difícil, mas, com a automação da escrita, fica evidente que a capacidade humana é o verdadeiro recurso escasso
• Desenvolvedores podem se tornar mais produtivos e ao mesmo tempo menos felizes e mais instáveis, e até as equipes que constroem essas ferramentas enfrentam o mesmo problema, ajustando a função de recompensa em tempo real
• O código e a forma de desenvolver estão mudando, mas o humano continua dentro do loop, e o estado central agora é a fadiga do participante humano

[GN⁺]

Comentários do Hacker News

• Na programação manual, quanto mais difícil era, maiores eram as pequenas recompensas como resolver o problema, entender a lógica, compilar com sucesso e sentir controle. Já a programação com agentes continua exigindo uma supervisão parecida independentemente do tamanho da funcionalidade, então no começo é empolgante, como pegar uma onda de produtividade, mas as partes gratificantes diminuem e a carga cognitiva da revisão aumenta, o que leva rapidamente ao esgotamento

  • Mais do que perder o emprego, existe o medo de em breve passar a odiar o próprio trabalho. Tarefas em que dar instruções ao LLM não economiza muito tempo ainda são feitas manualmente, e a estrutura da saída é retrabalhada para ficar mais fácil para humanos entenderem, preservando a sensação de controle
  • Minha motivação está menos em como o código foi feito e mais em quantas pessoas conseguem usar bem o produto criado. Sempre coloquei o usuário em primeiro lugar e, se necessário, escolhi atalhos, e o equilíbrio entre código de fácil manutenção e velocidade de entrega pode ser mantido mesmo usando LLM
  • O desenvolvimento pode virar algo mais parecido com trabalho fabril de baixa remuneração do que uma profissão baseada em conhecimento. Para orientar um LLM, é preciso muito menos conhecimento e experiência do que para escrever tudo diretamente, e no LinkedIn já há gente com quase nenhuma experiência ou só nível júnior sendo contratada como engenheiro de IA
  • Dá para sentir dopamina ao criar um loop em que a própria IA testa sua saída. Foi ainda mais satisfatório quando virou uma automação estilo Rube Goldberg, fazendo o Codex controlar remotamente um adaptador de teclado network-USB-C, um Fingerbot e até uma webcam para ativar a hibernação em um notebook específico e em um kernel Linux específico
  • Em projetos pessoais, fica mais fácil criar funcionalidades e, ao mesmo tempo, os resultados são mais refinados e consistentes, então a satisfação às vezes até aumenta. Ao focar um mês em um projeto, é possível obter um resultado muito bom, e como reescrever e reorganizar a estrutura ficou barato, dá para explorar de fato um espaço de design muito mais amplo. Ainda assim, muitas vezes é frustrante; metade é problema meu ao fornecer contexto, metade é limitação intrínseca do modelo

• Tenho usado o Claude com prazer no trabalho e em projetos pessoais, e o ponto central é evitar a tentação do agente e tratá-lo como um gerador de código. Abro apenas uma sessão, refino bastante o plano e depois acompanho a execução passo a passo; ao fim de cada etapa, reviso e ajusto a direção, o que permite continuar entendendo bem o estado do código até o final
  Para usar de forma quase one-shot, na etapa de planejamento é preciso detalhar não só a arquitetura, mas também o código real que determina as principais decisões. Como o custo de refatoração nunca foi tão baixo, qualquer parte difícil de entender deve ser corrigida imediatamente com o LLM, mas um único LLM deve fazer apenas uma coisa por vez, e você precisa continuar participando do processo

  • Depois de alguns meses trabalhando com Claude, aprendi um fluxo em que primeiro discutimos detalhes o suficiente e, se necessário, até montamos o esqueleto antes de executar, e organizei isso em https://github.com/ctomkow/claude/blob/main/README.md. Estou refatorando com sucesso um código legado que vinha adiando para uma nova arquitetura
    Dar controle total ao Claude inevitavelmente cria confusão e obstáculos que acabam esgotando a pessoa. Quando quero, programo eu mesmo; quando estou cansado, passo para o Claude, e assim também mantenho a sensação de controle da base de código
  • Colo apenas os trechos de código necessários em uma conversa totalmente separada do editor, discuto restrições e ideias e, quando fico satisfeito, levo para o editor para refinar melhor nomes e implementação. Faço diretamente o que é claro ou prazeroso, e também preciso participar das decisões de arquitetura para sentir conexão com o projeto e compreendê-lo em profundidade
  • O vibe coding, mesmo usando vários loops de agentes, tende a ser mais desgastante do que um modo de ferramenta auxiliar em que se observa a saída de perto
  • Mesmo trabalhando de forma incremental, quando outra pessoa vai revisar, ela precisa olhar o resultado inteiro de uma vez, com olhos de quem está vendo tudo pela primeira vez, então a carga da revisão não diminui
  • O fluxo de trabalho pode alternar entre no máximo duas coisas, mas acima disso a troca de contexto esgota completamente a cabeça

• Ao revisar código de colegas ou subordinados, a maior parte da energia mental vai para considerar não só a validade técnica do feedback, mas também ego, diferenças de visão de arquitetura, tom educado, carga extra de trabalho e dinâmica da equipe. Já com LLMs, não é preciso se preocupar com impacto emocional, então revisar e redirecionar é muito mais fácil

  • Sabendo que um colega vai repassar meu feedback para uma IA, acabo escrevendo para a IA, não para a pessoa, e entrego uma lista de correções bem mais curta e direta
  • Como tech lead, sempre enfrentei resistência do tipo “isso já está bom o suficiente” em cada PR, mas com um LLM dá para pedir sem resistência que refaça da maneira correta, o que é confortável

• No trabalho, começaram a chamar isso de Human on the hook em vez de human in the loop. A expressão descreve melhor a estrutura em que, se der certo, o humano não leva o crédito, mas se der errado, ele é o responsável — ou seja, o ser humano só importa quando surge um problema

• Escrever código em si nunca foi a parte difícil para mim. Digitação rápida, edição modal no Vim, comandos Unix, scripts e atalhos, Git, refatoração no IDE, aprender Java — quando eu sabia o que queria construir, eu trabalhava na velocidade do pensamento
  Os momentos em que eu parava não eram por digitação ou sintaxe, mas ao pensar na forma do código e na mudança correta; quando ficava difícil, eu criava abstrações melhores, ferramentas no IDE ou pipelines Unix com sed. Então o gargalo não era escrever código, mas pensar e julgar
  Talvez a programação com IA pareça um grande salto porque há mais desenvolvedores do que se imagina que nunca tiveram acesso a ótimas ferramentas ou não chegaram a dominá-las. Se eu tivesse 20 e poucos anos hoje, talvez gastasse menos tempo aprendendo essas técnicas, mas o momento em que a engenharia de software se tornou atraente para mim foi quando entendi que nada daquilo era mágica

  • A frase “a IA parece boa em coisas nas quais você mesmo não é bom” soa muito correta. Se você não é bom em programação, a saída da IA parece rápida e excelente; mas, para um desenvolvedor experiente, somando instruções, espera, convencimento, correções e refatoração, talvez não seja mais rápido do que fazer sozinho
    Assim como sou ruim em desenho e por isso imagens geradas por IA me parecem impressionantes, a programação com IA pode ser avaliada pelo mesmo princípio

• O cansaço que muita gente sente vem da combinação entre maior impulso e maior confusão, gerando uma perda de controle. O LLM fica em algum ponto entre um gênio e um bebê, e observar do banco de trás é ao mesmo tempo emocionante e assustador
  Depois de correr rápido por um tempo, talvez a gente perceba que andar também não era ruim — e que, na verdade, isso aumentava a chance de chegar ao destino desejado

• Programar com LLM parece repetir um ritual, como puxar a alavanca de um caça-níquel, torcendo para que desta vez dê certo. Erros na programação tradicional têm causas consistentes, e ela é projetada para que essas causas sejam compreendidas e, se possível, eliminadas de forma permanente. Um desenvolvedor experiente não tenta coisas aleatoriamente e, quando funciona, trata isso como algo cujo motivo ele não consegue explicar
  Se você já está exausto por lidar com várias partes interessadas que nem conseguem concordar sobre o que é o sistema, talvez já soubesse há muito tempo que a atenção humana e o julgamento de engenharia sempre foram o gargalo

  • Quando eu estava aprendendo a programar e fazia apps web, ficava preso ao computador até tarde, chutando às cegas e executando coisas pensando “será que isso funciona?”. À medida que melhorei e passei a usar linguagens tipadas, compiladores e LSPs, comecei a entender o que iria funcionar, e consegui entrar em um estado de fluxo satisfatório em vez daquele chute viciante
    Programar com Claude parece voltar àquela fase de adivinhação, então não quero isso. Ainda assim, em áreas que já envolvem muito chute cego por natureza, como trabalho de DevOps conectando APIs complexas e vários componentes, conversar com LLMs é onde isso é mais útil
  • Agora, em vez de chegarem a um acordo, as partes interessadas usam LLMs para criar planos mal amadurecidos e metas de trimestre, e deixam design, histórias, detalhes técnicos, implementação e até revisão de código nas mãos de LLMs. Ao longo de todo o processo, o pensamento crítico e a validação desaparecem, e só se acumulam documentos de design e código com propósito pouco claro, difíceis até de acompanhar
    Os planos mudam a qualquer momento, e a chance de tudo ser reescrito por impulso também aumenta

• Concordo com o ponto central do texto, mas em vários trechos transparece um estilo bem característico do Claude, e ler algo que alguém escreveu com IA é ainda mais cansativo

  • Em vez de ter sido escrito diretamente por IA, é bem possível que tenha passado por edição e revisão para se adequar ao estilo corporativo. O próprio LLM também foi treinado nesse tipo de estilo
  • A maior parte foi escrita por IA, mas houve muito mais intervenção humana do que em textos comuns de IA, então não incomoda tanto quanto de costume
  • Pelos maneirismos de estilo, como a repetição de “It’s not” e o uso de travessões, conclui-se que foi escrito por IA
  • Se a pessoa não teve o trabalho de escrever ela mesma, eu também não quero ter o trabalho de ler

• Isso me lembra o texto de 2021 The Animal is Tired: https://www.robinhobb.com/blog/archives/2021-05

  • Como o site original bloqueia IPs, dá para ler em um mirror menos restritivo: https://archive.is/RWxXP. Sentir o próprio declínio pode ser a maior das tristezas, e isso chega para todo mundo
    Mesmo que você tivesse cuidado melhor do corpo, talvez acabasse no mesmo lugar e perdesse memórias preciosas no processo. Cuide do corpo, mas não o trate como uma poção de jogo que você nunca usa até o fim por achar que vai precisar dela na próxima batalha. Cada parte do nosso corpo só pode ser sacrificada uma vez por um propósito maior — ou não ser sacrificada de forma alguma
    Só de pensar nisso eu quase choro; ainda estou em uma crise emocional

• A divulgação de pesquisa da Berkeley Haas de que o uso de IA aumenta a intensidade do trabalho é interessante, mas já se passaram mais de 5 meses desde que saíram o texto da HBR https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies... e o material de divulgação https://newsroom.haas.berkeley.edu/ai-promised-to-free-up-wo..., e ainda não se encontra o artigo acadêmico nem uma versão preliminar
  O que se sabe até agora é apenas cerca de 40 entrevistas qualitativas feitas em uma empresa de um único setor, então é difícil avaliar a confiabilidade dos resultados sem verificar o método de pesquisa

  • Também vale ler Ironies of Automation https://static1.squarespace.com/static/644321e78cd2dd37613af..., sobre automação em geral; acho que os mesmos princípios podem ser aplicados à automação com IA