Empresas Produtivas com IA: Forma Organizacional, Não Escolha de Ferramenta

Há seis meses, David Heinemeier Hansson escreveu que não usaria ferramentas de IA para escrever código. Hoje, mal escreve código à mão. A filosofia dele não mudou. As ferramentas atravessaram um limiar, e o entorno organizacional da 37signals estava pronto para recebê-las.

Essa é a parte que a imprensa de tecnologia não contou direito. Gergely Orosz gravou uma entrevista longa com DHH para o The Pragmatic Engineer — vale assistir antes de continuar lendo: DHH’s new way of writing code. O vídeo está repleto de detalhes operacionais. O enquadramento dominante depois da publicação foi “até o DHH mudou de ideia”, como se a conversão do criador do Rails fosse a única evidência que importasse. É o enquadramento errado. A história real não é que DHH passou a usar agentes. É que o setup dele é impossível de copiar sem refazer decisões que a sua empresa tomou — ou deixou de tomar — anos atrás.

O Workflow Não É o Produto

Em termos operacionais, o que DHH faz cabe em uma descrição curta. Três painéis no tmux: Gemini 2.5 à esquerda como LLM rápido, Claude Opus à direita como modelo poderoso, NeoVim e Lazygit no centro para revisar diffs. Os agentes trabalham em paralelo. Ele orquestra, lê, aprova, rejeita.

Qualquer engenheiro com uma assinatura dos dois serviços pode montar o mesmo terminal em uma tarde. O terminal não é o produto. O produto é tudo que existe em volta dele e que nenhum tutorial consegue reproduzir.

Comece pelas CLIs. A 37signals constrói interfaces de linha de comando para todos os seus produtos — não porque seja bonito, mas porque agentes precisam encadear ações: verificar um erro em produção, escrever uma correção, abrir um pull request, reportar o resultado no Basecamp. Se o seu produto só fala por uma GUI ou por um painel SaaS fechado, nenhum agente consegue formar uma cadeia. A 37signals escolheu uma superfície programática antes de a IA existir. Essa decisão, que em 2018 parecia uma preferência estética, em 2026 virou a diferença entre “os agentes funcionam aqui” e “os agentes não têm onde se agarrar”.

Continue pela proporção de time. A 37signals tem 20 engenheiros e 10 designers. Um designer para cada dois engenheiros. Designers atuam como product managers e construtores. Eu já escrevi sobre por que a IA amplifica a forma que a organização já tem, e este é o exemplo mais nítido que encontrei. Quando a geração de código fica barata, o gargalo muda para decisão de produto: o que construir, para quem, por quê. Um time com metade do headcount em design já está operacionalmente resolvido para esse gargalo. Um time com um PM para cada oito engenheiros não está, e nenhuma licença de Claude vai arrumar isso.

Revisores Sêniores Como Infraestrutura

O ponto que DHH repete na entrevista, e que é mais importante do que qualquer escolha de modelo: a alavancagem vem de conseguir validar prontidão para produção à primeira vista. Ler um diff de 400 linhas e saber, em segundos, se aquilo pode subir. Essa habilidade não é ferramenta. É senioridade acumulada ao longo de vinte anos de produção.

A Amazon chegou ao mesmo ponto por um caminho diferente e menos glamoroso. Depois de incidentes ligados a código gerado por agente, restringiu engenheiros juniores de fazer merge sem revisão sênior. Não foi uma decisão filosófica sobre o futuro do trabalho. Foi uma resposta operacional ao fato de que a parte cara do desenvolvimento — verificar que o código está certo, não gerá-lo — passou a definir o risco de produção.

Aqui está a consequência desconfortável para líderes de engenharia: o workflow do DHH só produz resultado quando cada agente tem um revisor capaz de dizer não. Se a sua pirâmide de senioridade é larga na base, estreita no topo, e você já tinha fila de revisão antes da IA, multiplicar a taxa de geração por quatro não vai te acelerar. Vai te afogar. A decisão que precede “vamos adotar agentes” é uma decisão de staffing: quantos sêniores você tem, e quanto do tempo deles está disponível para revisão em vez de escrita. Sem essa conta feita, a ferramenta se torna uma bomba de dívida técnica com pretensão de produtividade — um risco que já discuti em A Hora do Acerto de Contas com Agentes.

Por Que Rails Voltou

A parte mais interessante da conversa com Orosz é tangencial, e por isso mesmo reveladora. DHH observa que Rails está vivendo uma espécie de renascimento porque casa bem com agentes. Três razões, nenhuma delas romântica.

Rails é token-eficiente. A convenção sobre configuração significa que um agente não precisa ler mil linhas de boilerplate para entender onde um controller fala com um model. Menos tokens, inferência mais barata, ciclos mais curtos. Rails vem com testes embutidos na cultura da comunidade, e testes são exatamente o sinal de validação que um agente precisa para saber se terminou. E Rails gera código legível — um humano revisando um diff não precisa decifrar mágica de metaprogramação para aprovar.

Traduzindo: nem toda stack serve. Se a sua empresa vive em um monorepo de microsserviços com convenções locais, ORMs customizados, testes flakey e dependências implícitas entre times, o custo por token de qualquer agente sobe e a taxa de revisão despenca. Isso não significa que você precisa reescrever tudo em Rails. Significa que a escolha de framework, o investimento em testes e a legibilidade do código viraram decisões de produtividade de IA, mesmo que tenham sido tomadas antes de alguém na empresa ter ouvido falar de LLMs.

Mech Suit e Defesa Contra Burnout

Orosz pergunta sobre o risco de exaustão. DHH responde com uma metáfora precisa: orquestrar múltiplos agentes é como operar um mech suit hiper-acelerado. A cadência é mais alta, as decisões são mais densas, e o cansaço cognitivo chega antes. Ele diz que protege explicitamente oito horas de sono por noite durante essa “corrida do ouro da IA”.

Isso não é um detalhe pessoal. É estrutura. Um líder que trata descanso como variável de ajuste voluntária está construindo uma equipe que vai queimar em silêncio enquanto os dashboards mostram aumento de throughput. A defesa contra burnout na era dos agentes precisa ser estrutural: limites de sessão, rotação, horários protegidos, métricas de ritmo em vez de métricas de output. Não é um benefício de RH. É uma precondição para que a velocidade nova seja sustentável.

O Próprio Shape Up Precisa Ser Reescrito

Há uma ironia no ar. Shape Up, o livro de metodologia que a 37signals publicou em 2019 e que influenciou um punhado de times de produto sérios, foi construído em torno de ciclos de seis semanas. DHH admite abertamente que o livro precisa ser reescrito porque a IA comprimiu os tempos de ciclo. O que antes era um apêndice semanal agora é uma iteração de duas horas. Betting tables, cool-downs, scopes — todo o vocabulário precisa ser reaferido.

Isso deveria te incomodar um pouco, e essa é a intenção. Se a metodologia dos próprios autores precisa ser reescrita para acompanhar as ferramentas, o que torna você confiante de que o seu ritual de sprint de duas semanas, seu backlog priorizado por story points, sua reunião de planning de quinta-feira, vão sobreviver ao próximo semestre sem nenhuma pergunta dura? A resposta provável é: nada torna. A disposição para reescrever a própria metodologia é um dos pré-requisitos organizacionais para extrair produtividade de IA. Times que defendem seu processo como identidade vão ver os agentes como intrusos. Times que tratam processo como hipótese vão ajustar o processo e colher o ganho.

A Pergunta Que Antecede a Escolha da Ferramenta

Há um número na entrevista que vale guardar. Um engenheiro da 37signals melhorou a latência do percentil 99 do 1% mais rápido das requisições de 4 milissegundos para menos de 0,5 milissegundo. Antes dos agentes, esse tipo de trabalho era economicamente inviável — o retorno não justificava as horas de investigação. Com os agentes rodando exploração em paralelo sob supervisão sênior, virou viável.

Preste atenção ao que possibilitou isso. Não foi o Claude. Foi: um engenheiro sênior capaz de reconhecer quando a exploração do agente estava no caminho certo, uma base de código legível o bastante para o agente formar hipóteses úteis, CLIs maduras o suficiente para executar benchmarks repetíveis, e uma cultura que deu ao engenheiro tempo para perseguir uma otimização de infraestrutura em vez de empilhar features. Remova qualquer uma dessas quatro coisas e o mesmo modelo produz ruído caro.

Essa é a tese inteira em uma frase: uso produtivo de IA é uma forma organizacional, não uma escolha de ferramenta. Antes de perguntar qual modelo adotar, pergunte se a sua organização tem a forma que torna o modelo produtivo. Senioridade distribuída. Superfícies programáticas. Proporção de design que resolve o gargalo de decisão. Frameworks legíveis. Disposição para reescrever a metodologia. Defesa estrutural contra burnout.

Se essas peças não estão no lugar, a resposta honesta não é “adote agentes mais rápido”. É: construa a forma primeiro. A ferramenta vem depois, e vem mais barata do que você esperava. O que não vem barato é o que precisa vir antes dela. Foi isso que a 37signals fez há anos, sem saber que estava se preparando para este momento. É isso que a maioria das empresas ainda não fez, e é por isso que a maioria das adoções de IA vai decepcionar.

A boa notícia é que o caminho não é secreto. DHH mostrou, na entrevista, cada peça do mech suit. A má notícia é que a peça mais importante nunca aparece no terminal.

Fontes

Gergely Orosz. “DHH’s new way of writing code.” The Pragmatic Engineer, abril de 2026.

O Victorino Group ajuda times de liderança a construir a forma organizacional que torna as ferramentas de IA produtivas — e não apenas presentes: contato@victorino.com.br | www.victorino.com.br