15 pontos por GN⁺ 2026-02-09 | 14 comentários | Compartilhar no WhatsApp
  • Depois de usar repetidamente ferramentas de geração de código baseadas em LLM, o autor redescobriu a imersão e o prazer de escrever código diretamente
  • Escrever código não é apenas um ato de produção, mas um processo de entender o espaço do problema e refinar o pensamento, e a geração automática atrapalha isso
  • É difícil verificar a exatidão de um código que você não escreveu, e só ao escrever diretamente é possível internalizar o contexto
  • Ao usar LLMs de forma limitada — fornecendo o contexto manualmente e usando-os apenas para pequenas alterações de código e geração de testes — é possível manter o controle sobre o próprio raciocínio
  • O texto enfatiza a necessidade de priorizar a profundidade do pensamento e a sensação de felicidade acima da produtividade, e de desconfiar de ferramentas que atrapalham o ato de pensar

Experiência com geração de código por LLM e ceticismo

  • Ele usou claude-code várias vezes, mas em todas sentiu depressão e apatia, e acabou removendo a ferramenta
    • O código gerado automaticamente “parecia plausível”, mas fazia com que ele perdesse o sentido do próprio trabalho
    • Sempre que parava de usar a ferramenta, recuperava novamente o prazer de programar
  • Programar não é apenas implementar, mas um processo de explorar o espaço do problema e aprender por meio de falhas
    • Para entender de verdade uma API, é preciso usá-la diretamente; só ler a documentação não basta
    • O próprio ato de escrever código é um meio de concretizar o pensamento

A relação entre pensamento e exatidão

> "Se você não escreve, e apenas pensa, está apenas se enganando achando que está pensando." - Leslie Lamport

  • É muito mais difícil verificar a exatidão de um código que você não escreveu
  • No processo de escrever diretamente, o contexto do problema é internalizado, e isso é essencial para compreender a qualidade do código
  • Ao depender de LLMs, esse processo é pulado, o que enfraquece a compreensão do domínio do problema

O caráter viciante e os efeitos colaterais do ‘vibe coding’

  • A geração de código por LLM tem um aspecto viciante por oferecer uma recompensa imediata de dopamina
    • Ela induz a ilusão de que “se eu ajustar só mais um pouco o prompt, vai dar certo”
  • Esse modo de trabalhar aumenta a inércia do pensamento, torna o cérebro passivo e faz a pessoa depender do LLM até para tarefas simples
    • Como exemplo, até uma tarefa simples de find-and-replace foi delegada ao LLM e acabou levando mais tempo
  • Mesmo que muito código seja gerado, no fim a responsabilidade de revisar e entender continua sendo humana, o que pode acabar criando mais gargalos

Como as ferramentas moldam o pensamento

  • Partindo da ideia de que “ferramentas não são neutras”, ferramentas que atrapalham o pensamento são ferramentas ruins
    • A competência central de quem trabalha com conhecimento é a capacidade de pensar profundamente, e tecnologias que atrapalham isso devem ser vistas com cautela
  • Ainda assim, ele não exclui totalmente os LLMs, e os utiliza de forma intencional e limitada
    • Copia apenas os arquivos necessários para fornecer contexto e os usa somente para pequenas alterações no código ou para escrever testes
    • Assim, o escopo das mudanças geradas fica pequeno, e ele consegue entender por conta própria a estrutura geral da base de código
    • Isso leva a uma transição da geração passiva para uma ‘geração reflexiva’, preservando a atividade mental e o estado de flow

O equilíbrio entre felicidade e produtividade

  • A vida é curta, e é preciso priorizar a felicidade
    • Gerar automaticamente uma funcionalidade inteira pode até aumentar a produtividade, mas se isso provocar ansiedade existencial e depressão, então no longo prazo é contraproducente
  • O autor reconhece que você pode ou não se identificar com esses sentimentos,
    "Não tenha medo de escolher de forma diferente"

14 comentários

 
nimgnos 2026-02-09

Há quem tenha calculadora, mas ainda assim goste de fazer as contas à mão ou de cabeça.

 
su79eu7k 2026-02-09

Acho, com certa cautela, que o processo de escrever à mão as partes extremamente complexas e centrais para a lógica de negócio, refletir sobre elas e depois transmiti-las aos engenheiros de IA talvez possa ajudar na produtividade. Matemáticos também usam ferramentas como calculadoras, mas, quando pensam nas ideias centrais, costumam fazer muitas anotações à mão.

 
naruchingu 2026-02-10

Vivemos em um mundo em que é possível tirar uma foto com um único clique no celular, mas ainda assim também é um mundo em que alguém pode passar horas desenhando. Parece que a diferença está apenas no processo e na direção, e não em uma questão de certo ou errado.

 
wkdehf555 2026-02-09

Parece, no máximo, uma proposta de entrar em choque frontal com a direção que as empresas estão buscando..

 
dolsangodkimchi 2026-02-09

Respeito o ideal de felicidade e satisfação pessoal de cada um, mas, do ponto de vista de um trabalho em que se oferece mão de obra e se recebe dinheiro, isso me parece uma mentalidade inadequada.

 
foriequal0 2026-02-09

Se alguém está ignorando métricas de longo prazo e perseguindo apenas métricas de curto prazo, acho que até mesmo uma pessoa completamente sem relação com isso, ao passar, sentiria vontade de dar pitaco dizendo: “não é assim que se faz, tsc tsc”.
Mas se for um programador que acredita estar compartilhando os altos e baixos da empresa, fazendo grandes contribuições e desempenhando um papel importante nela, quanto mais forte não seria esse sentimento.

 
geeksk553 2026-02-09

Na verdade, os desenvolvedores realmente talentosos, que programam muito bem, é que curtem vibe coding...

Não sou eu quem está dizendo isso (Linus Torvalds ou Robert Martin)

 
dieafterwork 2026-02-10

Eu só usava isso em scripts Python. Acho difícil dizer que eu gostava.

 
cocofather 2026-02-10

Pelo que encontrei sobre a matéria do Linus Torvalds, parece que ele usou isso como hobby e ainda não usa no desenvolvimento do Linux.

 
GN⁺ 2026-02-09
Comentários do Hacker News
  • Compara programação à marcenaria. Mesmo que máquinas possam fabricar móveis, ainda existem pessoas que fazem isso à mão. Codificar à mão também pode continuar sendo algo prazeroso, mas no futuro deve ficar difícil como profissão

    • Essa analogia parece inadequada. Uma serra elétrica é uma tecnologia centauro guiada por humanos, enquanto a GenAI é o oposto: uma tecnologia centauro reversa, em que o humano atua como auxiliar. A serra elétrica não substitui a pessoa, mas a AI pode reduzir uma equipe pela metade
    • A marcenaria produz o mesmo produto repetidamente, mas código não se repete. Na maioria dos projetos, o gargalo está em levantar requisitos ou fazer o design, então a diferença de produtividade entre codificação manual e com AI é limitada
    • Pergunta se a transição de linguagem natural → código é parecida com a transição de linguagem de alto nível → assembly. A ‘complexidade essencial’ de Brooks está desaparecendo, e graças a padrões padronizados está chegando a era em que a AI converte intenções ambíguas em código executável. No fim, o valor dos especialistas aumenta, mas a demanda por engenheiros padrão diminui
    • Levanta a pergunta: “Se não pudermos mais codificar à mão profissionalmente, pelo que estaremos sendo pagos?” Questiona se vamos acabar reduzidos a atendimento ao cliente ou a redatores de prompts para LLM
    • Seria triste se codificar à mão deixasse de ser visto como algo valioso. Ainda continua sendo prazeroso, mas a desvalorização machuca
  • Eu escolho, no longo prazo, o método que gera os resultados mais rápidos e melhores. No momento, isso é neovim e codificação manual. Ao digitar tudo diretamente e entender o projeto em profundidade, consigo entregar funcionalidades mais rápido no longo prazo. Deixo para o LLM o que não ajuda no aprendizado, mas como há bastante desse tipo de tarefa, meu uso de LLM é alto

    • A visão de que “entendimento profundo acelera no longo prazo” é marcante
    • Eu também trabalho assim. Aconselho a equipe a otimizar não para 6 meses, mas para daqui a 2 anos
    • Faço diretamente só o que traz aprendizado e tento automatizar ao máximo o resto
    • Ao usar vários agentes, há muita troca de contexto, e dá até a sensação de perder o contexto geral
  • O problema do vibecoding é que a sensação de “estar se sentindo bem” atrapalha a percepção do resultado real

    • Só algumas pessoas se sentem bem com isso; eu encontro prazer em entender profundamente o problema e o código
    • “Ler vibe docs” é legal, mas vibe coding produz código prolixo e com abstrações excessivas, difícil de entender e no qual eu reluto em colocar meu nome
    • Mesmo com planejamento, muitas vezes acabamos tendo que refazer tudo do zero, o que é frustrante
    • É difícil distinguir se a produtividade realmente aumentou ou se só parece que aumentou
    • Fiz experimentos com o Windows Copilot, mas era lento e de baixa qualidade, então não havia prazer nenhum
  • Faz a pergunta cínica: “Ser feliz aumenta a produção de código em 200 vezes?”

  • O valor da AI é claro. Por exemplo, ao converter uma tabela de banco de dados com 300 colunas em uma struct Rust, com um prompt de 15 palavras ela gera 900 linhas de código. Para esse tipo de trabalho repetitivo, a AI é perfeita. Mas eu não quero delegar tudo a ela. Uso só até um nível de uso que me deixe feliz

    • Essa abordagem pode acabar impedindo melhorias em esquemas ou designs ruins
    • Parece melhor escrever um script de geração de código em Python. A AI tem problemas de confiabilidade, como mudar sutilmente nomes de campos
    • O custo energético de um humano codificando enquanto toma café é muito maior do que o da AI
    • Usar AI parece um vício em dopamina
  • A pergunta central é: “O que eu faço enquanto o LLM escreve o código no meu lugar?” Não dá para simplesmente entregar tudo a ele; a sensação é de ficar cuidando dele ao lado. Um desenvolvedor júnior cresce, mas o LLM não aprende. Por isso, dá a sensação de que a satisfação de mentorar desapareceu

    • Eu rodo vários agentes ao mesmo tempo e toco desenvolvimento de funcionalidades, correção de bugs e atualização de documentação em paralelo. Ainda há muito o que fazer, não é doomscroll
  • Fica a curiosidade sobre como o recrutamento de desenvolvedores mudou ultimamente. É permitido usar LLM? Ainda exigem codificação manual?

    • As grandes empresas ainda mudam devagar. Por causa de questões de propriedade legal, hesitam em usar código gerado por AI
    • No futuro, vão exigir tanto codificação manual quanto codificação com AI. Contratação sempre foi assim: só se adiciona mais uma barreira
    • Empresas de médio porte estão congelando contratações ou escolhendo apenas desenvolvedores que usam AI. Grandes empresas ainda exigem Leetcode e design de sistemas
    • A maioria das empresas ainda não percebe o alcance da cola com LLM
  • Antes mesmo dos LLMs, eu já desenvolvia com velocidade de vibecoding usando desenvolvimento orientado por modelos (MDD). O modelo de dados é o próprio aplicativo, e o LLM apenas escreve os procedimentos um pouco mais rápido em cima disso. A direção do modelo de dados ainda sou eu quem decide

  • Há três tipos de codificação com AI

    1. Buscar código que já existe online
    2. Código totalmente novo, com a AI servindo apenas como ajuda de digitação
    3. Geração de código repetitivo e cheio de boilerplate — isso é uma falha do framework
    • O que a AI faz bem talvez seja justamente o tipo de coisa que não deveríamos estar fazendo. O verdadeiro desafio é encontrar uma linguagem que expresse com elegância o que queremos fazer
    • Os frameworks não evoluíram, e o LLM acabou virando uma ferramenta que vê tudo como martelo
  • A sociedade moderna está se transformando em uma estrutura que entrega dopamina ao clicar em botões. Por isso tudo parece uma bagunça

    • Critica a realidade em que a máquina caça-níquel virou a UX definitiva
 
redline2151 2026-02-09

Ultimamente, continuam aparecendo textos de desenvolvedores ultrapassados tentando se convencer. De qualquer forma, não dá para impedir o fluxo dos tempos.

 
cjm01115 2026-02-09

Isso já passou muito dos limites.

 
geeksk553 2026-02-09

Também concordo com essa opinião: mesmo que a própria pessoa insista em programar tudo manualmente, a menos que toque o negócio sozinha, isso inevitavelmente acaba sendo substituído, mas parece que ela não percebe isso.

 
hmmhmmhm 2026-02-09

Nossa, isso foi pesado demais 😭