Minha jornada de adoção de IA

• Mitchell Hashimoto, que fez o exit da HashiCorp e está criando o Ghostty, organizou o processo até integrar ferramentas de IA ao trabalho real
• Divide a trajetória em três etapas — ineficiência → adaptação → ganho de produtividade — e registra de forma concreta os erros, tentativas e aprendizados de cada fase
• Depois de reconhecer os limites da programação baseada em chatbot, passou a usar ferramentas baseadas em agentes e foi aí que começou a encontrar valor de verdade
• Ao treinar a reprodução, com agentes, de commits que antes fazia manualmente, percebeu na prática que decomposição de tarefas, separação entre planejamento e execução e validação automática são elementos centrais
• Usando os últimos 30 minutos do dia para tarefas automatizadas noturnas e delegando trabalhos simples e repetíveis aos agentes, obteve ganhos reais de produtividade
• Hoje, está na fase de sempre manter um agente em execução, combinando isso com “harness engineering” para maximizar a eficiência da colaboração entre IA e humanos

---

Contexto de adoção e abordagem

• Sempre que uma nova ferramenta é adotada, é preciso passar por três etapas: ineficiência → adaptação → inovação
  • Como já estamos acostumados ao fluxo de trabalho existente, a adoção inicial é desconfortável, mas no longo prazo leva a ganhos de produtividade
• Em vez de expectativas exageradas ou críticas excessivas sobre ferramentas de IA, ele apresenta uma visão equilibrada baseada em experiência real de uso

Etapa 1: sair dos chatbots

• Programar por meio de interfaces de chatbot como ChatGPT e Gemini depende de conhecimento prévio do modelo, e a correção de erros depende de feedback humano repetido, o que é ineficiente
• O primeiro “momento surpreendente” foi colar no Gemini uma captura de tela da command palette do Zed e reproduzi-la em SwiftUI; isso virou a base da command palette do Ghostty no macOS
• Porém, no contexto de projetos brownfield (bases de código já existentes), os chatbots frequentemente geravam resultados ruins, e o processo de copiar e colar código e saídas era menos eficiente do que fazer o trabalho diretamente
• Para extrair valor, é indispensável usar agentes; aqui, agente significa uma ferramenta em que o LLM pode chamar ações externas repetidamente, precisando no mínimo ler arquivos, executar programas e fazer requisições HTTP

Etapa 2: reproduzir seu próprio trabalho com agentes

• Quando usou o Claude Code pela primeira vez, não ficou satisfeito com os resultados, e corrigir o trabalho levava mais tempo do que fazer tudo manualmente
• Em vez de desistir, repetiu o exercício de reproduzir com agentes os mesmos commits feitos manualmente
  • Era um processo doloroso, já que o mesmo trabalho era feito duas vezes (manual + agente), mas esse atrito é natural ao adotar novas ferramentas
• Nesse processo, descobriu três princípios centrais:
  • Dividir a sessão em tarefas unitárias claras e executáveis
  • Em pedidos ambíguos, separar sessões de planejamento e de execução
  • Quando o agente recebe meios de validar o próprio trabalho, consegue corrigir erros e evitar regressões por conta própria
• Entender em que áreas o agente não vai bem e saber quando não usá-lo também se tornou um grande fator de eficiência
• Nessa etapa, ele ainda não sentiu ganho líquido de eficiência, mas passou a aceitar o agente de forma satisfatória como ferramenta

Etapa 3: usar agentes no fechamento do dia

• Passou a adotar um padrão de reservar os últimos 30 minutos de cada dia para iniciar trabalhos com agentes
  • A hipótese era que haveria ganho de eficiência se o agente conseguisse avançar enquanto ele não estivesse trabalhando
• Três tipos de tarefas funcionaram bem:
  • Sessões de deep research: investigar bibliotecas com determinada licença em uma linguagem específica e gerar resumos de múltiplas páginas com prós, contras, atividade de desenvolvimento e reação da comunidade
  • Exploração de ideias ambíguas com agentes em paralelo: não com objetivo de lançamento, mas para descobrir variáveis desconhecidas antes do trabalho do dia seguinte
  • Classificação e revisão de issues e PRs: usando gh (GitHub CLI) para fazer triagem de issues com agentes em paralelo; os agentes não respondiam diretamente, apenas geravam relatórios para consulta no dia seguinte
• Ele não deixava os agentes repetindo execuções a noite toda; na maioria dos casos, tudo terminava em menos de 30 minutos
• Ao transferir para agentes esse período de cansaço no fim do dia, conseguiu o efeito de “warm start” na manhã seguinte

Etapa 4: delegar tarefas com confiança

• Depois de identificar tarefas que o agente quase certamente executaria bem, passou a delegá-las a agentes em segundo plano enquanto se concentrava em outros trabalhos
• Todas as manhãs, filtrava manualmente os resultados da triagem da noite anterior, selecionava issues adequadas para agentes e executava uma por vez
• Nesse tempo, em vez de redes sociais ou vídeos, fazia diretamente trabalho de reflexão profunda no estilo pré-IA
• Desativar notificações desktop dos agentes foi essencial: o custo da troca de contexto é alto, então é mais eficiente que o agente não interrompa a pessoa e seja verificado apenas em pausas naturais
• Em resposta ao paper de formação de habilidades da Anthropic: ele abre mão da formação de habilidade nas tarefas delegadas a agentes, mas continua desenvolvendo habilidades naturalmente nas tarefas que ainda faz manualmente
• Nessa etapa, chegou a um nível de “não dá para voltar atrás”, e a principal vantagem foi poder focar no tipo de trabalho de que mais gosta

Etapa 5: harness engineering

• Os agentes são mais eficientes quando acertam de primeira ou quando precisam apenas de correções mínimas
• A ideia de “harness engineering” é que, sempre que um agente cometer um erro, seja criada uma solução para que ele nunca mais repita o mesmo erro
• Há duas formas disso:
  • Melhoria implícita de prompting (AGENTS.md): quando o agente executa o comando errado ou encontra a API errada, isso é registrado no arquivo AGENTS.md para resolver o problema — há exemplos reais no repositório do Ghostty
  • Ferramentas programadas: escrever scripts para captura de tela, execução de testes filtrados etc. e avisar no AGENTS.md que essas ferramentas existem
• Ele está atualmente nessa etapa, investindo ativamente em evitar maus comportamentos dos agentes e validar os bons comportamentos

Etapa 6: manter sempre um agente em execução

• Em paralelo à etapa 5, definiu como meta sempre ter um agente rodando em segundo plano
• Prefere modelos lentos, mas de alta qualidade, como o deep mode do Amp (baseado em GPT-5.2-Codex), que leva mais de 30 minutos, mas entrega resultados melhores
• Atualmente, não executa múltiplos agentes em paralelo e considera adequado o equilíbrio entre um agente e o trabalho manual
• Na prática, agentes em segundo plano estão ativos em apenas 10% a 20% do horário de trabalho, e ele ainda busca melhorar essa proporção
• Rodar agentes não é um fim em si; eles só devem ser usados quando houver uma tarefa realmente útil, e criar fluxos de trabalho delegáveis e de alta qualidade é importante independentemente de haver IA ou não

Situação atual e visão

• Ele vem obtendo resultados com ferramentas de IA e mantém uma visão equilibrada baseada na realidade
• Não trabalha, investe nem presta consultoria para empresas de IA, e sua motivação central, exista ou não IA, continua sendo o prazer de construir como artesão de software
• Demonstra grande preocupação com o problema de formação de habilidades entre desenvolvedores juniores com base fraca
• Como a velocidade de inovação dos modelos é alta, é preciso reavaliar continuamente o julgamento sobre as áreas em que agentes ainda não funcionam bem
• Usar ou não IA é uma escolha individual, e este texto tem como objetivo compartilhar um caso pessoal de exploração e uso de ferramentas

[GN⁺]

Comentários do Hacker News

• O principal é dividir a sessão em unidades de trabalho claras e executáveis
  Se você der instruções detalhadas demais, não há motivo para usar um LLM; por outro lado, se for amplo demais, como “faça um app tipo Facebook para cachorros”, só sai um protótipo inútil
  No fim, usar LLMs para código com sucesso é encontrar esse escopo ideal

  • A parte de usar ferramentas de IA de que mais gosto é justamente formar essa intuição
    Entender que tipo de tarefa gera bons resultados e ajustar o escopo de acordo dá um prazer parecido com modularizar um programa
  • Já fracassei ao fazer pedidos grandes demais, como no exemplo de “Facebook para cachorros”
    No Lovable, até o onboarding parecia induzir ao fracasso; já com o Claude Code, ao quebrar em partes menores, tive muito mais sucesso
  • Usar LLMs só para buscar exemplos de sintaxe de for é prático porque reduz a troca de contexto
    No começo, eu usava muito como auxílio simples para escrever código
  • À medida que os modelos evoluem, parece que o limite superior desse escopo ideal sobe a cada 6 a 8 semanas
  • Às vezes eu dizia “imprima a saída”, e ele respondia literalmente adicionando só print(output)
    Trabalhar indo e voltando entre linguagem natural e código chega a ser psicologicamente confortável

• 2025 foi o ano em que as ferramentas de IA para programação realmente entraram na fase prática
  Antes, modelos iniciais como o GPT-3 só mostravam potencial, e isso acabou gerando hype e ceticismo em excesso
  Mas agora muitos desenvolvedores já estão integrando IA aos fluxos de trabalho reais
  Se você ainda é cético, recomendo ler o texto do Mitchell e testar o Claude Code por conta própria

  • Penso o mesmo. Fico curioso sobre que momento será lembrado como ponto de virada daqui a 10 anos
    Houve uma época em que se falava muito em “limite de dados”, mas com a chegada do Claude Code, Sonnet 4.5 e Opus 4.5 o clima mudou completamente
  • Fico curioso se existe um motivo para usar Claude Code em vez de Codex ou Gemini
    Os dois modelos me pareceram parecidos, mas ainda não testei Claude por causa dos relatos de que o limite de uso do plano acaba rápido
  • Mesmo assim, ainda me preocupa uma estrutura de indústria centrada em hype
    Tenho medo de que a gestão priorize apenas velocidade e volume e acabe produzindo pilhas de código impossíveis de manter

• A abordagem “Don’t draw the owl” também bate com a minha experiência
  O problema era que o LLM ia cada vez mais derivando para fora das restrições do mundo real
  Então separei as coisas: chat para discussão de design, e agentes só para diffs estreitos e verificáveis
  Quando esse loop ficou estável, deixou de ser brinquedo e virou uma alavanca de verdade, e já publiquei várias funcionalidades reais em projetos

  • Disseram que o estilo do texto se parece com o de um LLM
    É interessante como essas estruturas de frase padronizadas estão ficando mais comuns até entre pessoas
  • Também dá a impressão de que essa abordagem não é tão diferente da forma como sempre deveríamos ter desenvolvido software

• Como se falou muito do Opus 4.5, fui testar por conta própria e senti que o paradigma de agentes realmente ficou mais útil
  Ainda estou em tarefas mais simples, mas estou satisfeito

• LLMs não servem para mim
  A capacidade de pensar e criar é o que nos distingue, e sinto que entregar isso às máquinas acaba nos enfraquecendo
  Como desenvolvedor Rails, usei Zed com Claude Sonnet 4.x e Opus, mas percebi que minha capacidade de escrever RSpec estava diminuindo
  No fim, voltei para o neovim e trabalho sem agentes
  Conveniência pode acabar trazendo atrofia do pensamento
  LLMs são a maior ferramenta de conveniência já criada por humanos, mas eu prefiro preservar minhas habilidades e meu raciocínio

• Este texto pareceu muito mais prático e menos exagerado do que outras postagens da front page

  • Finalmente saiu um guia passo a passo que até pessoas céticas podem tentar seguir
    Em vez de exageros do tipo “criei um sistema operacional no vibe coding”, a abordagem aqui é realista

• É interessante ver que todo mundo está passando por uma jornada parecida de uso de IA
  Muita gente usa vários modelos em paralelo em partes diferentes do codebase e faz os próprios modelos se validarem mutuamente
  Ainda dou git reset com frequência, mas estou aprendendo cada vez mais a evitar isso com eficiência
  É como viver na era do autocompletar do cérebro

• Alguém comentou que “um agente precisa ser capaz de ler arquivos, executar programas e fazer requisições HTTP”,
  e isso é quase o mesmo nível da ‘tríade letal’ de que Simon Willison fala

  • Por isso, eu nunca pretendo rodar isso na minha máquina local

• Ter que ficar dizendo ao agente o que melhorar é irritante
  Toda vez preciso editar o agent.md para dar feedback, e seria ótimo se ele aprendesse sozinho e melhorasse

  • Mas a melhoria de uma pessoa pode ser um code smell para outra
    Adicionar algumas linhas ao AGENTS.md também não é nada demais
    Se você criar um comando /fix para ele corrigir e documentar tudo automaticamente, isso já economiza bastante tempo
  • Eu, pelo contrário, gosto de dar feedback
    Isso me dá a sensação de manter o controle da engenharia
    Especialmente porque permite iterar rapidamente em pesquisa e implementação de novas funcionalidades

• Se quiser ver como essa abordagem fica na prática,
  vale conferir o post antigo do blog do OP, “Non-trivial Vibing”, e a discussão no HN sobre ele