Code is cheap: por que Joanna Wang acha o dev ainda valioso na era dos agentes

Saiu no blog do Ruby on Rails↳Ruby3 conteúdosComo migrei meus testes automatizados de Java para Ruby… Será que fiz bem?Dev (Back & Front) · jun 2019Refatoração em RubyDev (Back & Front) · mai 20197 exemplos de linguagens de programação server-sideGestão Dev & TI · jun 2024Ver tudo em Dev (Back & Front) → um episódio do podcast On Rails com Joanna Wang, engenheira sênior da Sixfold (empresa que constrói ferramentas de underwriting com IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → para seguradoras). O título é uma provocação que vale a discussão: Code Is Cheap Now; Developers Still Valuable. Código ficou barato, o dev não.

Eu recebo essa frase com desconfiança profissional, porque "código é commodity agora" virou refrão de vendedor de ferramenta. Mas o episódio tem substância técnica, não só filosofia de LinkedIn, e é por isso que vale destrinchar. Wang chegou ao Rails depois de rodar Java, Go, Python e Node, então é exatamente o tipo de voz poliglota que me interessa: quem já apanhou em vários ecossistemas costuma ter opinião menos tribal.

O caso concreto: orquestração caseira que apodreceu

A parte mais honesta da conversa não é sobre IA, é sobre dívida técnica. O time da Sixfold tinha construído a própria orquestração de workflows em cima de state machines e callbacks do Rails. Funcionou por um tempo e depois virou o que o blog descreve como brittle: frágil, difícil de mudar sem quebrar coisa.

Quem já manteve monolito Rails de verdade reconhece o filme. Callback é a mágica que te dá produtividade no primeiro ano e te dá pesadelo no terceiro. after_save, before_validation, um callback disparando outro model que dispara outro callback: a lógica de negócio some dentro do ciclo de vida do ActiveRecord e ninguém mais consegue traçar o fluxo lendo o código.

A solução deles foi migrar para o Hatchet, um orquestrador de tarefas distribuídas. Trocar orquestração implícita (callbacks) por orquestração explícita (um workflow engine) é uma decisão de arquitetura clássica, e o trade-off é claro: você ganha rastreabilidade e perde a conveniência de deixar o framework resolver por você. Em Laravel o dilema é gêmeo, só troca Eloquent observers por jobs e um orquestrador externo. O ponto não é Rails contra X; é orquestração implícita contra explícita, e essa escolha te persegue em qualquer stack.

O detalhe que ninguém gosta de admitir: a gem abandonada

Segundo o blog, o episódio aborda também os trade-offs de depender de uma gem que não é mais mantida. Isso merece aplauso, porque é o tipo de coisa que a gente esconde da apresentação de arquitetura e assume no code review às escondidas.

A verdade desconfortável: às vezes a biblioteca abandonada resolve seu problema melhor que a mantida. Você assume o custo de virar mantenedor de fato daquele pedaço (fork, patch, ler o código-fonte inteiro), em troca de estabilidade. É uma decisão legítima, desde que consciente. O anti-padrão é depender de gem morta sem saber que ela está morta. No ecossistema Ruby isso é mais comum do que em Node, onde o churn de pacotes é maior mas a rotatividade também expõe o abandono mais rápido.

"Fully agentic" e a mágica do Rails que o agente traça pra você

Aqui está o gancho que dá título ao episódio. Segundo a descrição do blog, o time foi fully agentic, ou seja, colocou agentes de IA de fato no fluxo de desenvolvimento. E o próprio resumo do episódio destaca um ponto que eu achei o mais interessante: why Rails magic is easier to understand when an agent can trace it for you, ou seja, por que a mágica do Rails fica mais fácil de entender quando um agente consegue traçá-la pra você.

Pensa no que isso inverte. Durante quinze anos, o argumento contra a "Rails magic" (convention over configuration, metaprogramação, método que existe mas você não vê declarado em lugar nenhum) foi que ela esconde o comportamento de quem está lendo. O júnior não sabe de onde vem o método. Com um agente que consulta o código-fonte, roda a stack e explica a convenção, o custo de entender a mágica cai.

Se isso se confirmar na prática, muda um cálculo antigo: frameworks "mágicos" e implícitos, historicamente penalizados por curva de aprendizado, podem ficar mais atraentes numa era em que o agente é seu decodificador. É especulação minha, não da fonte, mas é uma inversão que vale acompanhar.

Onde eu discordo do refrão "código é barato"

Agora o contra-argumento, porque opinião que só bate palma não é opinião.

Dizer que "código ficou barato" é meia-verdade perigosa. O que ficou barato foi gerar linhas de código plausíveis. O caro sempre foi a outra parte, e continua caro: decidir qual código escrever, entender por que a orquestração caseira apodreceu, saber que o Hatchet resolve o problema certo, e ter o discernimento de assumir uma gem abandonada de olhos abertos. Nada disso o agente decide sozinho hoje.

A própria narrativa do episódio prova o ponto contra o slogan: toda decisão relevante que a Sixfold tomou foi de julgamento de engenharia, não de digitação. O agente traça a mágica; quem decide que a arquitetura estava errada é o humano. Então "code is cheap" é literalmente verdade e estrategicamente enganosa ao mesmo tempo, porque escrever código nunca foi o valor central do trabalho. Era o entregável mais visível, não o mais valioso.

O que isso muda pro dev brasileiro

No debate BR de carreira, essa conversa cai num momento de ansiedade real: "vou ser substituído?". Minha leitura pragmática:

• A commodity é a sintaxe, não a decisão. Se o seu diferencial hoje é conhecer decor de sintaxe de uma linguagem, esse é exatamente o pedaço que barateou. Especialização em problema de domínio (seguros, fintech, logística) e em arquitetura é o que o agente não replica.
• Saber ler código ganhou valor, não perdeu. Num fluxo agentic, você revisa muito mais do que digita. Quem lê código mal vai aprovar bug bonito.
• Trade-off explícito virou skill de sobrevivência. A capacidade de dizer "essa gem está morta, assumo o custo por causa de X" é o tipo de decisão que sustenta senioridade.

O episódio dura 43 minutos e está no player de podcast de sempre, com os links pra Sixfold e Hatchet. Vale menos pelo case de migração (embora ele seja sólido) e mais pela inversão de premissa: a era do agente não desvaloriza o dev, ela desloca o valor da mão pro cérebro. Quem já trabalhava assim não muda nada. Quem se vendia pela velocidade de digitação tem uma conversa difícil pela frente.

Fonte: Ruby on Rails Blog