"Programar está resolvido"? O bug piscante diz que não

"Programar está resolvido"? O bug piscante diz que não

Aqui está o que ninguém que empurra a linha de "programar está resolvido" quer colocar ao lado da sua apresentação de slides: a ferramenta de codificação com IA mais comentada do planeta foi lançada com um bug de cintilação de tela, e levou aproximadamente um ano de patches, um rollback, e finalmente um workaround-que-ainda-está-atrás-de-um-feature-flag antes que alguém pudesse considerar isso resolvido.

Não foi um problema de hardware. Não foi um problema de infraestrutura. Não foi alguma race condition enrolada de sistemas distribuídos que precisasse de uma equipe de pesquisa. Um bug de redesenho de terminal. O tipo de coisa que um engenheiro competente resolve numa tarde — exceto que este sobreviveu a duas gerações de modelo.

Eu quero ficar nessa lacuna por um minuto, porque ela é o argumento inteiro.

A história que continuo ouvindo — no X, em podcasts, naqueles threads sem fôlego de "a era do engenheiro de software está acabando" — vai assim: prompting manual está morto, programar é basicamente um problema resolvido, e a jogada inteligente agora é parar de escrever código e começar a escrever loops que rodam uma IA através de ciclos de prompts até que alguma condição de vitória seja atingida. O difícil que resta, diz a história, é infraestrutura, feedback de usuários e hardware. Programar? Essa é a parte fácil. Já está feito.

Eu uso ferramentas de codificação com IA todos os dias. Não estou aqui para te dizer que elas não funcionam — elas absolutamente funcionam, e vou te mostrar exatamente onde. Mas "programar está resolvido" é o tipo de afirmação que soa inteligente numa keynote e desmorona no segundo em que você aponta para os recibos. E o recibo mais limpo que tenho é um bug tão chato que quase faz o ponto por si só.

Vamos lá.

O que "programar está resolvido" realmente afirma (e quem está dizendo)

Antes de argumentar contra uma posição, quero formulá-la tão forte quanto as pessoas que a defendem fariam. Steelmanning primeiro. É a única forma honesta de fazer isso.

A versão mais completa do argumento vem de dentro da própria Anthropic. Boris Cherny — o criador do Claude Code — disse em entrevistas em meados de 2026 que a IA praticamente resolveu a programação, e que ele não tinha escrito uma linha de código à mão em oito meses (Fortune, junho 2026). O enquadramento que cresceu ao redor disso é ainda mais afiado: pare de fazer prompts ao Claude uma mensagem de cada vez, diz o argumento — construa loops. Construa um harness que deixe o modelo observar, planejar, agir e refletir ao longo de horas, às vezes dias, iterando contra testes e métricas de aceitação até convergir para um estado de aprovação (a explicação do explainx.ai sobre a tese de harness engineering).

Nessa visão de mundo, o trabalho do humano muda. Você não escreve funções. Você escreve a função de pontuação — a condição de vitória — e o loop avança em direção a ela. Escolher um modelo melhor é otimizar a variável errada; construir melhor infraestrutura de feedback é o jogo real. Eu mesmo escrevi sobre a mecânica dessa abordagem na minha própria análise de harnesses de agentes de longa duração, e digo claramente: como técnica, é real e é poderosa.

Depois há o número que todos citam. A Anthropic reportou que linhas de código mergeadas por contribuidor ativo alcançaram aproximadamente 8x a baseline pré-2025 até Q2 2026 — enquadrado em alguns relatos como "dois anos de output de codificação, a cada trimestre, por pessoa" (OfficeChai). Até maio de 2026, Claude supostamente estava escrevendo mais de 80% do código de produção mergeado internamente (VentureBeat).

Essa é uma série de afirmações genuinamente estarrecedora. Se eu parasse aqui, você fecharia a aba convencido de que programar tinha acabado.

Então por que não estou convencido? Por causa de um detalhe enterrado no próprio anúncio da Anthropic — e por causa de um bug. Vamos ao detalhe primeiro.

A ressalva que a Anthropic colocou na sua própria nota de rodapé

Aqui está algo que os threads de hype quase nunca incluem, e é a frase mais honesta de toda a conversa.

Quando a Anthropic publicou o número de 8x, o próprio blog post da empresa alertou que o número era "quase certamente um exagero", porque contar linhas de código recompensa volume, não qualidade — e as contagens de linhas por PR tiveram que ser limitadas ao percentil 99 apenas para filtrar commits atípicos (como reportado na cobertura de produtividade).

Leia isso de novo. A organização que faz o argumento mais forte de "programar está resolvido" anexou um rótulo de advertência à sua própria métrica de manchete. Linhas de código é um proxy notoriamente quebrado — todo engenheiro que está há tempo suficiente sabe que mais código geralmente é pior, não melhor. Uma ferramenta que te deixa gerar oito vezes o diff não é evidentemente uma ferramenta que resolveu a programação. Pode ser simplesmente uma ferramenta que resolveu digitar.

E essa é a costura que quero puxar. Porque há uma diferença entre três afirmações que se misturam quando as pessoas dizem "programar está resolvido":

1. A IA acelera a produção de código. Verdade. Obviamente, mensuravelmente verdade.
2. A IA melhora a qualidade do código quando usada bem. Frequentemente verdade, com ressalvas reais.
3. Programar, como problema humano difícil, acabou. Este é o salto. E não sobrevive ao contato com a evidência.

As duas primeiras são avanços reais. Eu brigaria com qualquer um que dissesse a um dev júnior para ignorar essas ferramentas. Mas a terceira afirmação — a de acabou — é onde o marketing ultrapassa a máquina. E a prova não é alguma objeção filosófica sobre criatividade ou artesanato. É muito mais embaraçoso que isso. É uma cintilação.

O bug de cintilação que ninguém conseguiu resolver silenciosamente

Se programar estivesse resolvido — se você pudesse simplesmente apontar um loop para um problema e deixá-lo avançar até uma condição de vitória — então o time de codificação com IA mais bem equipado do planeta, fazendo dogfooding da sua própria ferramenta, escrevendo 80% do seu código com o próprio modelo em questão, deveria ser capaz de esmagar um bug de renderização de terminal sem tropeçar.

Não foi isso que aconteceu.

Claude Code é um app de terminal — codificação com IA agêntica que vive na sua linha de comando, lançado em fevereiro de 2025. Desde o início, tinha um notório problema de cintilação de tela. O conteúdo do terminal rolava rapidamente, tremia e exibia flashes de texto de antes na sessão — causado pelo renderer redesenhando todo o buffer do terminal a cada atualização de streaming em vez de fazer atualizações incrementais por linha. Você pode rastrear o rastro por conta própria através de um cemitério de issues no GitHub: #769, e uma longa cauda de follow-ups como #16939, #18084, e #18827, abrangendo Windows Terminal, VS Code, Cursor, e os terminais integrados do Android Studio.

Agora observe a linha do tempo, porque a linha do tempo é o argumento:

• Início de 2025 em diante: Cintilação reportada repetidamente. Especialmente brutal em terminais baseados em xterm.js (VS Code, Cursor), onde o redesenho completo do buffer 2–3 vezes por segundo fazia a tela estroboscópica.
• Por volta de dezembro 2025: Anthropic aborda publicamente, supostamente alegando uma grande redução de cintilação com um renderer diferencial reescrito — aproximadamente um terço das sessões ainda via pelo menos uma cintilação, segundo relatos da comunidade do rollout.
• Pouco depois: Instabilidade. Uma mudança de renderização sem cintilação foi implantada, e uma regressão se seguiu — issue #41965 documenta como a renderização "sem cintilação" de tela alternativa do v2.1.89 destruía o scrollback do terminal por padrão. A correção criou um novo problema. As coisas foram revertidas. Final de 2025: ainda não resolvido limpo.
• Por volta de 1 de abril de 2026: Um "no flicker mode" chega — CLAUDE_CODE_NO_FLICKER=1 — usando uma abordagem de alternate-screen-buffer, o mesmo truque que o Vim usa quando toma conta do seu terminal e o devolve intacto ao sair (piunikaweb). Funciona. Mas é uma evasão, não uma correção de causa raiz: contorna o problema de redesenho renderizando em outro lugar completamente. E foi lançado como um research preview, atrás de um feature flag, com um flag complementar para desabilitar a captura de mouse porque isso introduzia sua própria fricção.
• Final de maio 2026: Uma interface de terminal mais nova ainda exibia mensagens de erro pouco informativas, "misteriosas" — o tratamento de erros em si mesmo sem polimento.

Um engenheiro independente intitulou sua análise "A correção que levou um ano para chegar." Outra pessoa lançou um patch de terceiros chamado Claude Chill apenas para lidar com a cintilação, e chegou à primeira página do Hacker News. Quando usuários constroem ferramentas externas para consertar sua renderização, a renderização não está resolvida.

Aqui está por que esse único bug carrega tanto peso: não há desculpa de hardware. Não há desculpa de infraestrutura. Não há escapatória de "a parte realmente difícil está em outro lugar". Cintilação de tela num terminal é um problema de software puro e autocontido — exatamente a categoria que a narrativa de "programar está resolvido" diz que é a parte fácil, a parte terminada. E levou um ano, um rollback, e um workaround controlado por flag na empresa melhor posicionada da Terra para resolvê-lo.

Se programar estivesse resolvido, esse bug teria morrido num fim de semana. Não morreu. Isso não é um gotcha. São dados.

"Só escreva loops" funciona — até encontrar o bug sem glamour

Quero ser justo com a tese do loop, porque genuinamente gosto dela. Eu rodo automação baseada em loops no meu próprio trabalho — escrevi sobre agendar Claude Code em cron loops e sobre a mudança mais ampla de um SDLC manual para um ciclo de vida de desenvolvimento agêntico. Quando o problema tem uma condição de vitória clara e verificável por máquina — testes passam, tipos batem, o benchmark fica verde — um loop bem construído é algo lindo de assistir. Ele converge. É a coisa mais próxima de "defina a função de pontuação e vá embora" que experimentei em quinze anos escrevendo software.

Mas note a forma dos problemas onde os loops brilham: todos têm uma condição de vitória clara.

Um terminal cintilante não tem. Qual é o teste que fica verde? "Parece menos instável para um olho humano através de quarenta emuladores de terminal diferentes, cada um com seu próprio renderer, em três sistemas operacionais, em taxas de atualização variáveis"? Não há asserção para isso. Não há expect(screen).not.toFlicker(). A condição de vitória é difusa, dependente do ambiente e parcialmente subjetiva — que é precisamente por que um ano de loops não conseguiu resolver. O loop é apenas tão inteligente quanto a função de pontuação que você consegue escrever, e alguns dos problemas de software mais importantes são exatamente aqueles que você não consegue pontuar de forma limpa.

Essa é a parte que o enquadramento de "programar está resolvido" pula. Ele silenciosamente assume que todo problema restante se parece com um teste unitário. A maioria dos difíceis não. Eles se parecem com cintilação. Eles se parecem com "a mensagem de erro está tecnicamente correta mas não diz nada ao usuário." Eles se parecem com a vulnerabilidade de carregamento de projeto que pesquisadores encontraram no vazamento de código fonte, onde requisições de API disparavam antes do prompt de confiança aparecer — um descuido de design que nenhum teste pegou porque ninguém pensou em pontuar para isso.

Se você preferir que alguém construa e mantenha esses loops agênticos corretamente — com as proteções e o tratamento de erros entediante-mas-crítico que as demos pulam — isso é uma boa parte do que eu assumo. Você pode ver o que entreguei em fiverr.com/s/EgxYmWD.

Então o loop não está errado. Ele é estreito. É uma ferramenta fantástica para o meio bem especificado do espaço do problema e inútil nas bordas difusas — e as bordas difusas são onde o software realmente quebra em produção. Chamar isso de "resolvido" é tomar a parte que você consegue medir pelo trabalho todo.

O custo humano de fingir que a parte difícil acabou

Agora quero falar sobre a parte que realmente me incomoda, porque o bug é apenas a evidência — estas são as consequências.

A narrativa de "programar está resolvido, só faz deploy pra prod, escreva o loop, atinja a condição de vitória" não aterrissa no vácuo. Ela aterrissa em desenvolvedores que, neste momento, estão mais esgotados e mais ansiosos sobre seus empregos do que eu os vi em muito tempo. E a mensagem está piorando ambas as coisas.

Aqui está o mecanismo cruel, e ele é bem documentado. Quando organizações decidem que a IA tornou a programação trivial, elas não guardam o tempo economizado como folga — elas tratam cada minuto economizado como um minuto que é devido de volta como mais output. O volume de PR pula 40–60%, e o gargalo simplesmente se move para downstream na revisão. Agora as mesmas pessoas estão se afogando em código que não escreveram, no qual não conseguem confiar totalmente, e estão pressionados a aprovar rápido. Isso não é menos burnout. É um novo e pior tipo de burnout, e está atingindo as pessoas que mais abraçaram a IA. Até existe um gênero inteiro de post-mortems de "a IA deveria consertar o burnout dos desenvolvedores" agora, o que te diz como o experimento está indo.

Junte as duas metades e a desonestidade se afia. A gerência ouve "programar está resolvido" e define expectativas como se fosse verdade. Os desenvolvedores vivem na lacuna entre essa afirmação e a realidade cintilante, cuspindo erros, ocasionalmente quebrada — e levam a culpa pela lacuna. Te dizem que a parte difícil acabou enquanto você gasta sua terça-feira depurando por que o loop implantou com confiança algo sutilmente errado, com uma mensagem de erro que não explicava nada.

Há uma metáfora direta circulando para esse tipo de mensagem — que alguém está fazendo algo na sua perna e insiste que é o tempo. Vou manter isso com bom gosto, mas o sentimento está certo. Dizer a engenheiros esgotados que seu trabalho duro, real, ainda necessário é "a parte fácil" — enquanto eles limpam a bagunça das mesmas ferramentas que são chamadas de solução — não é otimismo. É gaslighting disfarçado de estatística de produtividade.

E eu digo isso como alguém que está abertamente, quase vergonhosamente viciado em Claude Code. Não sou a resistência. Sou um usuário pesado te dizendo que o marketing está passando cheques que as ferramentas ainda não conseguem descontar.

O que está genuinamente resolvido, o que genuinamente não está

Deixe-me ser específico, porque pessimismo vago é tão inútil quanto hype vago. Aqui está meu balanço honesto depois de usar essas ferramentas diariamente em 2025 e em 2026.

Genuinamente acelerado por IA hoje:

• Boilerplate, scaffolding, código cola, configuração — quase instantâneo, quase perfeito.
• Refactors bem especificados com cobertura de testes forte — loops os esmagam.
• Traduzir intenção num primeiro rascunho — o que levava 45 minutos leva 6.
• Explorar uma codebase ou API desconhecida — mais rápido que documentação.

Genuinamente melhorado, com ressalvas:

• Qualidade de código, quando você construiu o harness (testes, lint, tipos, métricas de aceitação) contra o qual o loop pode pontuar. Sem harness, sem ganho de qualidade — só bagunça mais rápida.

Genuinamente NÃO resolvido:

• Problemas difusos, não pontuáveis — renderização através de ambientes heterogêneos, polimento de UX, "isto está tecnicamente correto mas parece errado."
• Tratamento de erros e design de modos de falha — os 80% sem glamour que demos nunca mostram, e onde o próprio Claude Code ainda tropeça.
• Saber o que construir, e se deveria existir em absoluto.
• O julgamento para anular o loop quando sua condição de vitória é sutilmente o alvo errado.

Note que a coluna "não resolvido" é exatamente onde o bug de cintilação vive. Isso não é coincidência. O bug não é um caso atípico — é uma amostra representativa do trabalho que o hype declarou acabado.

Então programar está resolvido? Não — e a resposta honesta é mais útil que o hype. Programar está acelerado, às vezes dramaticamente. As partes bem especificadas são cada vez mais automatizáveis através de loops. Mas o núcleo duro, difuso, pesado em julgamento — a parte que faz da engenharia de software uma profissão e não uma competição de velocidade de digitação — está exatamente tão não resolvida como estava, e os próprios bug trackers das ferramentas provam isso.

Perguntas frequentes

A programação está realmente resolvida pela IA em 2026?

Não — a programação está dramaticamente acelerada, não resolvida. Ferramentas de IA se destacam em tarefas bem especificadas e verificáveis por máquina (boilerplate, refactors, testes que passam) mas ainda lutam com problemas difusos e não pontuáveis como renderização cross-environment, polimento de UX e design de modos de falha. A prova é que até ferramentas de codificação com IA são lançadas com bugs de longa duração que seus próprios loops não conseguem consertar.

O que significa "só escreva loops" na codificação com IA?

"Só escreva loops" se refere a harness engineering — em vez de fazer prompts a uma IA uma mensagem de cada vez, você constrói um sistema que roda o modelo através de ciclos repetidos de observar-planejar-agir-refletir até atingir uma condição de vitória definida como testes que passam. É uma técnica genuinamente poderosa, mas só funciona onde você consegue escrever uma função de pontuação clara, o que exclui muitos problemas do mundo real.

Por que o bug de cintilação do Claude Code é significativo?

O bug de cintilação é um problema de software puro sem desculpa de hardware ou infraestrutura, no entanto levou aproximadamente um ano, um rollback, e um workaround controlado por flag para ser endereçado — na empresa melhor posicionada para consertá-lo. Isso o torna o contraexemplo mais limpo à afirmação de que "programar é a parte fácil" do software moderno. Para a linha do tempo completa, veja a seção acima.

A codificação com IA está causando burnout em desenvolvedores?

Relatórios e post-mortems de 2026 sugerem que sim — não porque a IA faz menos trabalho, mas porque as organizações convertem tempo economizado em mais output, aumentando o volume de PR em 40–60% e deslocando a carga para revisão de código sobrecarregada. A narrativa de "programar está resolvido" agrava isso ao definir expectativas que não correspondem à realidade mais bagunçada que os desenvolvedores realmente enfrentam.

O recibo ao qual continuo voltando

Abri com um terminal cintilante, então deixe-me fechar ali.

Quando alguém te disser que programar está resolvido, faça uma pergunta: se isso é verdade, por que as pessoas que dizem isso mais alto passaram um ano consertando uma tela que não parava de tremer — e depois lançaram a correção atrás de um feature flag? Não há hardware para culpar. Não há infraestrutura para se esconder atrás. Apenas um problema de software difícil e sem glamour fazendo o que problemas de software difíceis sempre fizeram: resistir às pessoas que o subestimaram.

Use as ferramentas. Construa os loops. Lance mais rápido — eu faço, todo dia, e sou melhor por isso. Mas segure a linha na verdade: programar não está resolvido, está amplificado. A parte difícil não desapareceu. Ela se mudou para onde os loops não conseguem alcançar, e ainda é sua.

E honestamente? Essas são boas notícias. Porque significa que o julgamento que você passou anos construindo é a parte que não foi automatizada — é a parte que ficou mais valiosa. Não deixe um slide de produtividade te convencer do contrário.

Esta noite, aqui está a única coisa que vale a pena fazer: da próxima vez que encontrar um bug que sua IA falhou com confiança em consertar, não se sinta atrasado. Tire um screenshot. Esse bug é a parte do trabalho que ainda é sua — e é a parte que paga.

Vamos trabalhar juntos

Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.

• Fiverr (builds personalizados e integrações): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io