
Mitchell Hashimoto Acabou de Escrever o Único Guia Honesto sobre Programação com IA — E Não é o que os Influencers Querem Ouvir
A jornada de adoção de IA em 6 passos do fundador da HashiCorp é o antídoto para o hype. Sem promessas de 10x. Sem mágica. Apenas honestidade brutal de...
✨TL;DR / Sumário Executivo
A jornada de adoção de IA em 6 passos do fundador da HashiCorp é o antídoto para o hype. Sem promessas de 10x. Sem mágica. Apenas honestidade brutal de...
💡 TL;DR (Muito Longo; Não Li)
Principais Pontos em 60 Segundos:
- Mitchell Hashimoto (criador do Terraform, Vagrant, Vault, Consul) publicou um guia de adoção de IA brutalmente honesto.
- Sem conflito de interesse: Ele não trabalha, investe ou aconselha nenhuma empresa de IA — é pura experiência de praticante.
- Passo 1: Largue o chatbot. Use agentes que tocam no seu sistema de arquivos, não middleware de Ctrl+C/Ctrl+V.
- Passo 2: Faça cada tarefa duas vezes (manual + agente) para calibrar quando usar IA.
- Passo 3: Agentes de fim de dia para pesquisa/triagem dão um "warm start" na manhã seguinte.
- Passo 4: Terceirize as tarefas "garantidas" para um agente em background enquanto VOCÊ faz trabalho profundo.
- Passo 5: Construa guardrails (AGENTS.md) — cada erro do agente vira uma correção permanente.
- Passo 6: Tenha sempre um agente rodando (10-20% do dia, não 100%).
- A verdade honesta: ~10-20% de ganho de produtividade, não 10x. E isso é real.
1. O Gancho: Por Que Isso Importa Agora
Eu escrevo software desde que o Borland Turbo C vinha em disquetes. Vi applets Java falharem em entregar, SOAP virar piada e microsserviços irem de revolucionários a "por que temos 400 repositórios?". Desenvolvi um faro para hype. É um mecanismo de sobrevivência.
Então, quando abri o novo post do Mitchell Hashimoto ontem de manhã — "Minha Jornada de Adoção de IA" — eu esperava o evangelho usual do Vale do Silício. O zelo missionário. A demo escolhida a dedo. O vídeo de "construí um SaaS inteiro em 47 minutos".
Em vez disso, recebi algo que não via em dois anos de discurso sobre IA: um relatório de campo genuinamente honesto de alguém que não tem um único dólar apostado se você adota IA ou não.
E isso me abalou. Não pelo que dizia sobre a IA. Mas pelo que dizia sobre nós.
2. Quem é Mitchell Hashimoto e Por Que Você Deveria Se Importar?
Se você não conhece o Mitchell, não tem prestado atenção.
Ele co-fundou a HashiCorp em 2012 e criou o Terraform, Vagrant, Vault e Consul — ferramentas que coletivamente definem como a maioria de nós faz deploy de software hoje. Quando Mitchell constrói algo, a indústria adota. Isso não é hype. É um histórico.
Depois de sair da HashiCorp, ele mergulhou na construção do Ghostty, um emulador de terminal acelerado por GPU escrito em Zig. Não Rust. Não Go. Zig. Porque Mitchell não segue tendências — ele avalia ferramentas a partir dos primeiros princípios e escolhe o que melhor resolve o problema.
Aqui está o detalhe crítico: Mitchell não tem "skin in the game" financeiro na IA. Ele não trabalha para Anthropic, OpenAI ou qualquer startup de IA. Ele não investe nelas. Ele não as aconselha. Ele deixa isso explícito em seu post. Quando ele diz que algo funciona, você pode confiar que não é um pitch disfarçado de post de blog.
Essa lacuna de credibilidade é tudo.
3. Os Seis Passos Que Ninguém Comenta
O post de Mitchell é estruturado como uma jornada de seis passos. Mas o que o torna notável não são os passos em si — é a honestidade brutal sobre o fracasso em cada estágio.
Aqui está a progressão:
Quero destrinchar as partes mais reveladoras.
4. Passo 1: "Largue o Chatbot" — A Verdade Inconveniente
O primeiro passo de Mitchell é parar de usar o ChatGPT como ferramenta de codificação.
Leia isso de novo. O produto de IA mais visitado da história. A coisa que todo recrutador agora lista como "habilidade necessária". Mitchell diz: pare.
Seu raciocínio é preciso e devastador. Interfaces de chat para codificação são uma esteira de copiar e colar. Você é o middleware humano — transportando código e mensagens de erro entre seu editor e uma caixa de texto, esperando que o modelo lembre do contexto que já esqueceu três mensagens atrás. Você se torna um gateway de API de baixa largura de banda entre sua base de código e um LLM que não consegue ver seus arquivos, rodar seus testes ou verificar sua própria saída.
A alternativa é um agente — um LLM que pode ler arquivos, executar programas e fazer requisições HTTP em um loop. Isso é Claude Code, Codex CLI, Amp ou qualquer ferramenta que realmente toque seu sistema de arquivos.
Essa distinção parece simples, mas é a divisão entre "IA é um truque" e "IA é um multiplicador de força". Vi equipes inteiras desperdiçarem meses em workflows baseados em chat, convencidas de que estavam "usando IA", quando o que estavam realmente fazendo era um 'copiar e colar' sofisticado com passos extras.
5. Passo 2: O Movimento Que Separa Profissionais de Turistas
Aqui foi onde Mitchell me perdeu — e depois me ganhou de volta.
Ele descreve forçar a si mesmo a fazer cada pedaço de trabalho duas vezes. Primeiro manualmente. Depois com um agente. Sem deixar o agente ver sua solução manual. Repetidamente, dia após dia.
Minha reação inicial: "Isso é loucura. Ninguém tem tempo para isso."
Mas então me lembrei: é exatamente assim que aprendi vim. E git. E Kubernetes. E toda outra ferramenta que eventualmente se tornou fundamental no meu workflow. Você engole a ineficiência no início porque não está otimizando para hoje — você está construindo a memória muscular e o modelo mental que renderão juros compostos por anos.
O que Mitchell descobriu através desse exercício doloroso:
- Quebre tarefas em unidades atômicas. Não peça a feature inteira. Peça uma função, um teste, uma migração.
- Separe o planejamento da execução. Metas vagas geram código vago. Faça o agente planejar primeiro, depois executar separadamente.
- Dê ao agente uma maneira de verificar seu próprio trabalho. Se ele pode rodar testes e ver falhas, ele se autocorrige mais do que você esperaria.
E criticamente, o espaço negativo: saber quando NÃO usar um agente é tão valioso quanto saber quando usar um. Recorrer a um agente em uma tarefa que ele vai estragar desperdiça mais tempo do que simplesmente fazer você mesmo. Essa calibração só vem do exercício doloroso de via dupla.
6. Passo 3: "Agentes de Fim de Dia" — Recuperando Tempo Morto
Esse foi meu insight pessoal favorito. Mitchell notou que, no final de cada dia de trabalho, ele estava cansado, sem foco e queimando a última hora em trabalho de baixo valor. Então ele começou a usar esses 30 minutos finais para iniciar agentes:
- Sessões de pesquisa profunda: "Encontre todas as bibliotecas HTTP Zig com licenças MIT, compare-as em 12 critérios, produza um relatório detalhado."
- Protótipos exploratórios: Ideias vagas que ele não tinha começado, rodando em paralelo. Não esperando código pronto para envio — esperando iluminação.
- Triagem de issues: Agentes usando a CLI
ghpara escanear issues abertas e produzir resumos para a manhã seguinte. Crucialmente: os agentes NÃO tinham permissão para responder às issues. Apenas relatar.
A frase chave: "Em vez de tentar fazer mais no tempo que tenho, tente fazer mais no tempo que não tenho."
Isso não é um hack de produtividade. Isso é um reframe filosófico da relação humano-IA. Você não está substituindo sua cognição. Você está estendendo suas horas de trabalho para períodos onde seu cérebro já bateu o ponto.
Quando Mitchell chegava na manhã seguinte, ele tinha um "warm start" — pesquisa pré-digerida, issues triadas, protótipos semi-explorados. Em vez do ritual de partida a frio de abrir o Slack, ler e-mails e lembrar lentamente o que estava fazendo ontem, ele podia começar correndo.
7. Passo 4: "Terceirize o Garantido" — O Ponto de Inflexão Real
É aqui que Mitchell diz que cruzou o ponto sem retorno.
No Passo 4, ele sabia quais tarefas os agentes lidam de forma confiável. Então ele começou a delegar essas tarefas — e apenas essas tarefas — para um agente em background enquanto trabalhava em outra coisa completamente diferente.
Duas coisas me chamaram a atenção.
Primeiro: "Desligue as notificações de desktop do agente." Mitchell é explícito sobre isso. Mudança de contexto é caro. Você decide quando checar o agente, não o contrário. Isso é tão contrário à cultura de "alertas em tempo real" que construímos que quase parece rebeldia. Mas é obviamente correto. O agente não precisa que você o note. Você precisa de foco ininterrupto.
Segundo: Mitchell aborda diretamente o paper da Anthropic sobre formação de habilidades — que descobriu que desenvolvedores que delegam codificação para IA pontuam 17% a menos em testes de compreensão. Seu contra-argumento é elegante: você não está delegando seu aprendizado — você está delegando a parte chata para poder continuar aprendendo na parte difícil. O agente faz os tickets do JIRA. Você faz a arquitetura. Ambos são feitos. Habilidades se formam onde importa.
8. Passo 5: "Engenharia de Harness" — A Meta-Habilidade
É aqui que Mitchell está agora, e é onde vive a verdadeira sofisticação.
O conceito: cada vez que um agente comete um erro, você investe em prevenir que esse erro aconteça novamente. Dois mecanismos:
1. AGENTS.md — Um arquivo markdown no seu repositório que dá instruções específicas do projeto aos agentes. O repositório do Ghostty de Mitchell tem vários, cada um nascido de uma falha real do agente:
# src/inspector/AGENTS.md (Ghostty)
#
# Cada linha abaixo existe porque um agente
# estragou algo pelo menos uma vez.
- Veja a API C completa encontrando dcimgui.h na
pasta .zig-cache na raiz:
find . -type f -name dcimgui.h
- Use a versão mais nova.
- No macOS, rode builds com -Demit-macos-app=false
para verificar o uso da API.2. Ferramentas Programáticas — Scripts que permitem ao agente verificar seu próprio trabalho. Ferramentas de screenshot, executores de teste filtrados, linters que pegam anti-padrões específicos do projeto.
Mitchell chama isso de "Engenharia de Harness" (arreios). Eu chamo de a única habilidade de IA que ainda importará em cinco anos. Os modelos ficarão mais espertos. Técnicas de prompt mudarão. Mas a disciplina de construir guardrails — loops de feedback que previnem categorias de falha — é um princípio universal de engenharia vestindo roupas novas.
Este é o padrão AGENTS.md que desde então foi adotado pelo ecossistema mais amplo — agora administrado pela Agentic AI Foundation da Linux Foundation.
9. Passo 6: A Aspiração Honesta
O passo final de Mitchell é aspiracional: sempre tenha um agente rodando. Não múltiplos agentes. Não um exército de bots paralelos. Um agente. Rodando em uma tarefa. O tempo todo.
Ele é refrescantemente honesto sobre onde está: 10-20% do seu dia de trabalho tem um agente em background rodando. É isso. Não 100%. Nem mesmo 50%. E ele está ativamente tentando melhorar isso.
Ele diz explicitamente: "Eu não quero rodar agentes por rodar agentes." Apenas quando há uma tarefa que genuinamente ajudaria. A disciplina de identificar trabalho delegável — manter uma "fila" de tarefas adequadas — é em si uma habilidade que requer desenvolvimento.
Essa contenção é o que separa Mitchell da multidão de "engenheiro 10x da noite para o dia". Ele não está reivindicando transformação. Ele está reivindicando melhoria incremental, honesta e composta através da adoção sistemática. O tipo de melhoria que realmente fica.
10. O Que o Post de Mitchell Revela Sobre Nossa Indústria
Aqui está o que não consigo parar de pensar.
Mitchell Hashimoto é sem dúvida um dos engenheiros de infraestrutura mais realizados de sua geração. O Terraform sozinho mudou como milhões de desenvolvedores trabalham. E sua avaliação honesta após meses de adoção dedicada de IA é: "Sou talvez 10-20% mais produtivo, e gosto muito de poder focar no trabalho que aprecio."
Não "10x". Não "100x". Não "demiti minha equipe". Não "desenvolvedores juniores estão obsoletos".
10-20%. E gostando mais do seu trabalho.
Compare isso com sua timeline do Twitter. Compare com a falta de ar financiada por VC. Compare com as threads de "construí um SaaS de $10M em um fim de semana" que são iscas de engajamento transparentemente fabricadas.
A lacuna entre o que praticantes sérios relatam e o que a economia da atenção recompensa é assombrosa. E essa lacuna é ativamente prejudicial — está fazendo empresas definirem expectativas irreais, gerentes pressionarem equipes para adoção "cargo cult", e desenvolvedores juniores entrarem em pânico ou confiarem demais em ferramentas que não entendem.
O post de Mitchell é remédio para essa doença. Ele diz: as ferramentas são reais, os ganhos são modestos, o caminho é longo e o trabalho de aprendê-las é trabalho genuíno.
11. Conclusões Práticas
Depois de ler o post dele, identifiquei três mudanças imediatas:
1. Mate a aba de codificação do ChatGPT. Pare de usá-lo para "perguntas rápidas" — que invariavelmente viram sessões de debugging de 20 minutos. Mova-se inteiramente para workflows baseados em agentes para qualquer coisa que toque código.
2. Implemente o ritual do "Agente de Fim de Dia". Os últimos 30 minutos do dia de trabalho vão para iniciar tarefas de pesquisa e triagem. As manhãs começam dramaticamente mais produtivas.
3. Crie seu primeiro AGENTS.md. Comece um arquivo no seu repositório principal documentando cada erro de agente que você pegou. Cada entrada previne uma categoria de falha futura.
12. A Mensagem Real
O post de Mitchell Hashimoto foi para o #8 no Hacker News com 358 pontos e 97 comentários em horas. Não porque anunciou algo novo. Não porque tinha uma opinião polêmica. Porque foi honesto em uma paisagem afogada em hype.
A mensagem real não é sobre IA. É sobre como profissionais adotam ferramentas:
- Aceite a fase estranha.
- Faça o trabalho duas vezes para construir entendimento.
- Encontre as bordas — o que funciona, o que não funciona.
- Construa guardrails para que o que funciona continue funcionando.
- Recupere tempo. Delegue a parte chata. Proteja a parte criativa.
- Mantenha a humildade sobre os ganhos. Mantenha a honestidade sobre os limites.
Foi assim que o Terraform foi adotado. Como o Docker foi adotado. Como toda ferramenta transformadora em nossa indústria eventualmente passou do hype para a infraestrutura. Não através de threads no Twitter. Através de praticantes moendo pelo meio doloroso até que a ferramenta se provasse.
Mitchell fecha com uma linha que vou pensar por muito tempo:
"Sou um artesão de software que apenas quer construir coisas pelo amor ao jogo."
Em uma indústria que cada vez mais se mede por rodadas de financiamento e contagem de seguidores, essa frase é um farol.
Vá ler o post dele. Depois feche o Twitter e faça o trabalho.
Principais Lições
- Largue o chatbot — agentes que tocam seu sistema de arquivos são fundamentalmente diferentes de copiar e colar.
- Faça o trabalho duas vezes — calibração dolorosa é como você aprende quando usar IA.
- Agentes de fim de dia — estenda suas horas de trabalho para períodos que você não usaria de qualquer maneira.
- Terceirize o garantido — delegue a parte chata, proteja o trabalho profundo, desligue notificações.
- Construa AGENTS.md — cada erro se torna um guardrail permanente.
- Seja honesto — ganhos de 10-20% são reais; alegações de 10x são marketing.
Leitura Adicional
- Mitchell Hashimoto: Minha Jornada de Adoção de IA
- Repositório GitHub do Ghostty
- Padrão AGENTS.md - Agentic AI Foundation
- Paper da Anthropic sobre Formação de Habilidades (arXiv 2601.20245)
- Discussão no Hacker News
Este artigo foi estruturado por humanos e sintetizado com o auxílio de IA sob a persona de Icarus (IA).