Como manter o prazer de programar na era dos LLMs

Em um texto publicado no fórum Haskell Community em setembro de 2026, o autor turion argumenta que é possível manter o prazer de programar na era dos LLMs, desde que o desenvolvedor continue escrevendo o código principal e reserve os agentes para tarefas acessórias. Ele deixa claro que não trata das preocupações éticas amplamente discutidas sobre LLMs de big techs, com as quais afirma concordar, e destaca que o texto é 100% humano, sem assistência de IA.

O problema: virar engrenagem

O autor usa a metáfora do livro "Souls in the Great Machine", de Sean McMullen: assim como humanos funcionam como componentes de um grande computador na ficção, os programadores veem seu papel sendo degradado de agentes ativos para engrenagens - recebem uma especificação, empurram-na para o LLM e ficam reféns dos tokens distribuídos por um "senhor tecnofeudal". Ele contrasta isso com seu próprio prazer em escrever Haskell, prazer que a geração de código ameaça.

Por que continuar escrevendo código

Dois argumentos centrais: quem deixa tudo ser gerado transforma a base de código em um "terreno baldio de LLM" que só agentes conseguem habitar; e habilidades se perdem por falta de prática - após poucas semanas entregando tudo a agentes, é difícil voltar a codar. Ele avalia que LLMs são bem piores em produzir código legível para humanos do que o divulgado, embora razoáveis quando só eles mesmos vão trabalhar naquele código.

O ganho de produtividade vem das tarefas ao redor

A produtividade moderada, segundo o autor, vem de delegar quase tudo exceto a codificação. No planejamento, usar LLMs como ferramenta de registro em linguagem natural: converter conversas entre especialistas em tarefas acionáveis, organizar resultados de testes em planos - mas nunca deixar o modelo tomar decisões cruciais; ele deve perguntar ao humano. Na pesquisa, o autor recomenda pesquisar em paralelo com um buscador tradicional, exigir que o agente registre resultados com links e questionar propostas estranhas: em cerca de metade dos casos ele mesmo descobre o erro.

"Você é o codificador"

A peça-chave do fluxo: recusar o padrão dos harnesses de "planeje e deixe o agente codar". Em vez disso, planejar junto, mas escrever o código você mesmo - o LLM pesquisa a base, lista os pontos a editar, aponta armadilhas e lembra o contexto. O autor relata que trabalha assim e se diverte, às vezes mais que antes dos LLMs. Vantagens: manter o que se gosta, saber sempre o estado do código, detectar planos ruins cedo e aprimorar habilidades. Agentes ficam com casos úteis e limitados: limpeza, tarefas rotineiras, refatorações de baixo risco, completar casos óbvios - desde que se pergunte se aquilo não pede uma abstração (uma lente, uma type class como Traversable), coisa que LLMs tendem a não reconhecer.

Ciclo de revisão e custo dos modelos de fronteira

Inspirado em redes adversariais generativas, o autor propõe um ciclo automático de revisão: nenhum artefato gerado por LLM deve ser lido sem que um agente revisor não tenha mais apontamentos - valendo para código e planos. Ele também usa revisores no próprio código e diz que às vezes encontram bugs reais.

Sobre modelos de fronteira, ele reconhece que seu fluxo os subutiliza - e assume isso. Argumentos: custo energético (com a ressalva de que é uma estimativa, pela falta de transparência das empresas), a dificuldade de confiar em algo que finge ser mais esperto e a responsabilidade intransferível pelo código, o risco de limites de token imprevisíveis e a possibilidade futura de trocar por modelos open weights e escapar da dependência. Para ele, os LLMs teriam de ser muitas vezes melhores, mais baratos, mais confiáveis e responsáveis para substituir desenvolvedores em sua atividade central.

Tokens, saúde mental e relações humanas

O esgotamento de tokens deve ser tratado como interrupção de serviço, não como falha pessoal; o fluxo deve prever trabalho offline com listas de tarefas tangíveis. Texto confuso de LLM deve ser tratado como potencialmente nocivo à saúde mental - ler artefatos só após revisão automatizada e conversar com pessoas sobre código. Programar é um esforço social: não enviar PRs totalmente gerados, e tratar saídas de agente como anexos técnicos, não como comunicação.

O autor conclui que se tornou talvez duas vezes mais rápido - menos do que vibecoders se gabam, mas sustentável, como um jardineiro usando adubo orgânico em vez de produtos químicos industriais, e que assim recuperou o gozo de programar Haskell profissionalmente.