Mudança no workflow de programação
- Em novembro de 2024, era 80% manual + autocompletar e 20% de programação com agente, mas em dezembro essa proporção se inverteu para 80% de programação com agente e 20% de correções/ajustes
- Na prática, virou uma situação de programar em inglês, dizendo ao LLM em palavras qual código escrever
- Há algo nisso que fere o orgulho, mas o poder de lidar com software em grandes unidades de "ações de código" é extremamente útil
- Adaptar-se a isso, configurar, aprender a usar e entender o que é ou não possível o torna ainda mais eficaz
- É a maior mudança fundamental no workflow básico de programação em cerca de 20 anos de carreira, e aconteceu em apenas algumas semanas
- É provável que algo parecido esteja acontecendo com uma parcela considerável (percentuais de dois dígitos) dos engenheiros, mas a percepção do público em geral parece estar em percentuais baixos de um dígito
IDE / enxame de agentes / possibilidade de erro
- A hype em torno de "não precisamos mais de IDE" ou de "enxame de agentes" parece exagerada por enquanto
- Os modelos ainda cometem erros e, se houver código realmente importante, é preciso vigiar como um falcão, mantendo uma IDE grande aberta ao lado
- A natureza dos erros mudou: já não são simples erros de sintaxe, mas erros conceituais sutis do tipo que um desenvolvedor júnior um pouco descuidado e apressado cometeria
- O tipo de erro mais comum: fazer suposições erradas no lugar do usuário e seguir em frente sem confirmar
- Problemas adicionais:
- não consegue gerenciar confusão
- não pede esclarecimentos
- não expõe inconsistências
- não apresenta trade-offs
- não contesta quando deveria contestar
- ainda tem certa tendência a ser bajulador (sycophantic)
- No modo de planejamento isso melhora, mas é necessário um modo de planejamento inline mais leve
- Também há uma tendência a complicar demais código e APIs, inflar abstrações e não limpar código morto depois do trabalho
- Às vezes implementa ao longo de 1000 linhas uma estrutura ineficiente, inchada e frágil, e se você pergunta "não daria para fazer assim?", responde "claro!" e reduz para 100 linhas na hora
- Ainda acontece de ele alterar/remover comentários e código de que não gostou ou que não entendeu bem, mesmo que isso não tenha relação com a tarefa
- Esses problemas continuam surgindo mesmo ao colocar instruções no CLAUDE.md e tentar corrigi-los de forma simples
- Apesar disso, ainda é uma melhoria puramente gigantesca, e voltar à programação manual é muito difícil
- Workflow atual: algumas sessões do Claude Code em janelas/abas do ghostty à esquerda, e a IDE à direita para revisar o código e editar manualmente
Persistência (Tenacity)
- É muito interessante ver um agente insistir em algo sem parar
- Não se cansa nem desanima, e continua tentando mesmo em situações em que um humano já teria desistido há muito tempo e deixado para depois
- Ver algo lutando com um problema por muito tempo e finalmente conseguir depois de 30 minutos parece um momento de "sentir AGI"
- Isso faz perceber que stamina é um gargalo central do trabalho, e, ao ter um LLM à mão, isso aumenta dramaticamente
Ganho de velocidade
- Não está claro como medir o "ganho de velocidade" do apoio de um LLM
- Com certeza há a sensação de que o que você ia fazer ficou muito mais rápido, mas o principal efeito é passar a fazer muito mais do que faria:
- agora dá para programar todo tipo de coisa que antes não valeria o esforço
- agora dá para mexer em código que antes não seria acessível por falta de conhecimento/habilidade
- Há ganho de velocidade, mas uma parte ainda maior talvez seja de expansão
Alavancagem
- LLMs são excelentes em rodar loops até cumprir um objetivo específico, e aí está grande parte da magia de "sentir AGI"
- Em vez de dizer o que fazer, dê critérios de sucesso e observe
- Faça-o escrever testes primeiro e então passar neles
- Coloque-o em loop com o Browser MCP
- Peça primeiro um algoritmo ingênuo com alta probabilidade de exatidão, e depois solicite otimização mantendo a exatidão
- Ao mudar a abordagem de imperativa para declarativa, o agente fica mais tempo em loop e gera mais alavancagem
Diversão
- A parte inesperada é que programar com agentes ficou mais divertido
- O trabalho chato de preencher lacunas desaparece e sobra só a parte criativa
- Há menos travamento/estagnação (o estado sem graça), e surge mais coragem — porque sempre existe uma forma de avançar positivamente junto com ele
- Também há quem sinta o oposto: a programação com LLM vai dividir os engenheiros entre os que gostam de programar em si e os que gostam de construir coisas
Atrofia (Atrophy)
- Ele percebeu que a capacidade de escrever código manualmente começou a atrofiar aos poucos
- Gerar (escrever código) e julgar (ler código) são capacidades diferentes no cérebro
- Por causa de pequenos detalhes sintáticos ligados à programação, mesmo tendo dificuldade para escrever, ainda é possível revisar código sem problemas
Slopacolypse
- A expectativa é que 2026 seja o ano da Slopacolypse (inundação de conteúdo de IA de baixa qualidade) em GitHub, Substack, arXiv, X/Instagram e, de modo geral, em toda mídia digital
- Além de melhorias reais, haverá muito mais teatro de produtividade inflado por hype de IA (se é que isso ainda é possível)
Perguntas
- O que está acontecendo com o "engenheiro 10X"? — qual é a relação de produtividade entre engenheiros medianos e os melhores? Essa relação pode aumentar bastante
- Armados com LLMs, os generalistas vão superar cada vez mais os especialistas? LLMs são muito melhores em preencher lacunas (micro) do que em grande estratégia (macro)
- Como será a sensação de programar com LLMs no futuro? Vai parecer jogar StarCraft? Ou Factorio? Ou tocar música?
- Quanto da sociedade está com gargalo em trabalho intelectual digital?
TLDR
- As capacidades de agentes LLM como Claude e Codex teriam cruzado algum tipo de limiar de consistência por volta de dezembro de 2025, provocando uma mudança de fase (phase shift) em engenharia de software e áreas relacionadas
- Parece que a parte da inteligência de repente está bem à frente de todo o resto — integração (ferramentas, conhecimento), necessidade de novos workflows organizacionais, processo e difusão mais ampla
- 2026 será um ano de alta energia para a indústria absorver essas novas capacidades
15 comentários
Parece que também foi publicada uma versão de skills para melhorar o funcionamento do Claude Code com base no conteúdo deste texto.
Karpathy-Inspired Claude Code Guidelines : https://github.com/forrestchang/andrej-karpathy-skills
Essa é uma dúvida que sempre me vem à cabeça: tudo bem para quem já pegou prática com programação manual supervisionar LLMs, mas para quem está aprendendo agora, se só ficar olhando o código que o LLM gera, parece difícil saber se aquilo está certo ou não.
Será que, antigamente, quem programava em assembly pensou algo como “como vou confiar num compilador que cospe uma saída em assembly toda torta?” quando os compiladores surgiram?
Naquela época, mesmo programando em C, provavelmente codavam tentando induzir o compilador a gerar uma saída em assembly do jeito que queriam.
Também fico curioso para saber se, com a era da IA avançando mais, vai chegar um ponto em que uma versão final bem pronta saia em linguagem natural sem supervisão humana.
Mesmo quando as pessoas ainda escreviam código, acho que, se você não estudasse, também não sabia o que estava errado kkk
Especialistas em assembly ainda reclamam de compiladores. No fim, o importante é que, em situações que exigem otimização extrema, esse tipo de especialista continua sendo necessário; aplicando isso à IA, talvez mesmo com todo o avanço da IA ainda seja difícil para ela superar alguém que programa extremamente bem no limite. De forma geral, porém, nenhum humano já consegue vencer a IA. Seria divertido ver mais um momento estilo AlphaGo, desta vez com uma disputa de AlphaCode.
Acho que tudo bem, desde que haja o esforço de analisar e entender o código que ele gera.
Compiladores são um conceito um pouco diferente, porque geram assembly com base em regras, então pertencem a um domínio determinístico; por isso, depois de revisar uma vez, o mesmo problema normalmente não volta a acontecer. Já os LLMs pertencem a um domínio probabilístico, então sempre existe a possibilidade de o problema se repetir.
Talvez, se essa precisão probabilística evoluir mais, ela chegue perto de 100%, mas se a própria exigência em linguagem natural for imprecisa, no fim o resultado também será impreciso. Então acho que um produto final
bomacaba dependendo das pessoas mesmo.Eu também fico preocupado com as pessoas júniores que tiveram contato com LLMs desde a época de estudantes. Também tenho a impressão de que o mercado para contratação de júniores piorou um pouco, mas também é difícil provar isso...
Pessoalmente, acho que se você só tiver conhecimento de CS, não faz tanta diferença assim.
Ou talvez seja porque a forma como uso agora me dá a sensação de fazer pair programming com um amigo que digita absurdamente rápido e escreve todo o código...
No fim das contas, quando você desenvolve a fundo, inevitavelmente chega uma hora em que precisa entender o que há dentro da camada de abstração.
A lacuna entre o prompt em linguagem natural e o código gerado é grande demais, então parece difícil entrar, a partir do prompt, para dentro da camada de abstração do LLM.
Hoje, o que fazemos é pegar o conceito da especificação que estava na nossa cabeça, passá-lo ao LLM por meio de um prompt, e depois reler e validar o código produzido.
Como isso se aproxima mais de revisar código escrito por outra pessoa, não dá muito a sensação de estar entrando por dentro da abstração.
Acho que eu estava negligenciando demais aqueles 20%
Recentemente me deparei com um bug que a IA não consegue resolver... não é uma solução para tudo, mas percebi que eu a estava tratando como se fosse.
Ah... kkk
Concordo muito. No projeto recente, fiz commit de cerca de 100 mil linhas (a quantidade real de código é maior) e estou usando em média 2–3 agentes. Acho que uns 95% estão sendo escritos pelos agentes.
Mas ainda é preciso gerenciar testes e código morto, e também são necessários detalhes sobre os casos de teste e os critérios de sucesso dos testes. É importante controlar o que deve ser feito e até onde isso deve ir. Para isso, além do plano, é preciso atualizar continuamente a arquitetura que cria o harness e as configurações, como as Rules.
Opiniões no Hacker News
É interessante ver o agente não se cansar e continuar tentando
GPUs e NPUs ficam trabalhando no limite, e estamos entregando até dados que normalmente não compartilharíamos
Agora isso parece uma troca conveniente, mas no longo prazo há risco de crescerem a dependência e os problemas sociais
No fim, isso pode virar uma estrutura de dependência desses grandes gatekeepers
Trabalhando com IA, o problema maior que a atrofia mental parece ser virar autossatisfação e apatia
No começo, os resultados rápidos dão um pico de dopamina, mas com a repetição começa a parecer que a IA está puxando o projeto na direção que ela quer
No fim, os experimentos criativos que eu queria fazer desaparecem, e eu sou sugado pela gravidade do espaço latente da IA
Isso é como doomscrolling: um loop viciante em que você quer continuar vendo a próxima saída
Estou fazendo um jogo multiplayer em Rust e Bevy, e mesmo quando o código funciona, ele vira um código que eu não entendo
Antes eu só teria chegado até aqui entendendo completamente as ferramentas, mas agora fiz um jogo meio funcional sem nem saber direito o que é ECS
Pensando em manutenção ou resposta a incidentes, isso é realmente perigoso
Agora estamos focando em aprender a usar os modelos e esquecendo como pensar por conta própria
Como a forma de usar LLM muda o tempo todo, no fim é como ficar numa esteira infinita de aprendizado
Mesmo depois de um longo tempo parado, a sensação fica, e quando você volta pega o jeito rápido
Quando o LLM não sabe, ele simplesmente desiste, e está aumentando o número de desenvolvedores que não querem ler a documentação
Mesmo mostrando a documentação diretamente, com screenshot e tudo, ainda ficam desconfiando e perguntando “será que é isso mesmo?”
Você continua jogando prompts por causa de um prazer curto e fica esperando “o que vai sair desta vez?”
O coding com LLM está virando um ponto de separação entre ‘quem gosta de programar’ e ‘quem gosta de construir’
Eu sou mais do tipo builder, gosto de criar resultados, então essa mudança é divertida para mim
Já quem gosta do ato de programar em si se sente desconfortável com essa tendência
O charme da programação estava no processo de estruturar o problema e executar com as próprias mãos
Agora parece menos que “eu estou programando” e mais que “eu estou mandando fazer”, então perdi parte do interesse
No passado também houve disputas como compilado vs interpretado, tipado vs não tipado, entrega rápida vs manutenibilidade
No fim, software bem-sucedido passa pelo processo de sair de uma fase inicial caótica para uma fase de expansão estável
Ainda não tenho certeza se a IA ajuda nisso ou se acaba deixando tudo mais complexo
A pessoa encontra diversão não só no resultado final, mas no processo de desenhar a estrutura do sistema
Um colega humano tem responsabilidade e confiança, mas um LLM não
Acho interessante a ideia de que a IA pode trazer um ganho de produtividade de 10x
O DevOps mudou a forma de colaboração entre desenvolvimento e operações e criou times de alta performance, o que produziu algo próximo de um 10X em versão de equipe
Para usar bem IA em programação, assim como no DevOps, é preciso um processo de melhoria contínua, mudanças no workflow e construção de confiança com automação/validação
Assim como o DevOps exigiu aprender conceitos novos e mudar a cultura do time, o coding com IA também pode demorar a ser adotado, mesmo com potencial 10X, se não houver aprendizado e mudança cultural
Para se consolidar, isso exige educação e mudança na cultura de engenharia
Senti que LLM é inútil em codebases grandes
Especialmente em código complexo e com muitas interações, quase não ajuda
Colocar isso em codebases existentes, grandes e complexas, é arriscado, a menos que sejam mudanças limitadas com revisão cuidadosa
Em estruturas simples, é impressionante passar a lista de arquivos e deixar o agente implementar, mas conforme a complexidade sobe o prompt precisa descer cada vez mais para instruções detalhadas para ainda gerar resultado
Diferente dos modelos anteriores, agora ele ajuda de forma prática até em monorepos complexos
Vale comparar se ele vai melhor do que um novo integrante do time trabalhando com a mesma informação
Codebases comerciais internas costumam ficar bagunçadas por desenvolvimento repetitivo para atender pedidos de clientes, e com o tempo as hipóteses iniciais e os requisitos vão se desencontrando, gerando dívida técnica
Se você usar LLM para refatorar, separando helpers, modularizando e renomeando para alinhar ao requisito atual, o comportamento do agente depois tende a ficar mais previsível
É preciso um fluxo em etapas: organizar requisitos/critérios de aceitação/user stories em markdown, fazer o modelo escrever o plano em detalhe e só depois partir para a implementação
Impressiona o ponto em que a persistência e a resistência da IA superam os limites humanos
Até em pesquisa se diz que grit está mais ligado ao sucesso do que inteligência
O LLM tem persistência infinita, desde que o orçamento permita
Nos últimos meses, parece que o desempenho da IA na verdade piorou
Ela esquece regras e gera planejamento excessivo e código superengenheirado
Ainda assim, continua útil no frontend (HTML + Tailwind)
Parece cedo demais para tanta expectativa em torno de IDEs ou de enxames de agentes
Ao fazer um app para iPhone, fiquei impressionado com a capacidade do Claude de gerar código a partir de prompts em inglês
> A programação com LLM acaba dividindo os engenheiros entre os que gostam da programação em si e os que gostam de construir coisas
Pelo que eu também tenho ouvido ao meu redor, parece que no fim das contas a divisão é mesmo essa.