A MOTOSSERRA CHEGOU. VOCÊ AINDA ESTÁ COM O MACHADO?

O que está acontecendo com o desenvolvimento de software nos EUA e o que esperar no Brasil

Por Marcos Bozza, CEO da Axoma

Há algumas semanas assisti ao filme “Train Dreams”, que acompanha a vida de um um lenhador no início do século XX nos Estados Unidos, um homem que vive de trabalhos pesados na construção de ferrovias e na extração de madeira. Uma cena ficou na minha cabeça:  o momento em que o personagem, já mais velho, depois de uma vida trabalhando com o machado, se depara com um  grupo de jovens trabalhadores cortando árvores com motosserras. Tudo acontece em um ritmo que ele nunca viu. O lenhador pega, então, uma das motosserras. Tenta ligar e não consegue. Ele não reage, não responde com uma indignação aberta, silencia diante do barulho das máquinas num incômodo, numa espécie de deslocamento, como se ele próprio tivesse se tornado obsoleto junto com as ferramentas que usava.

Isso foi numa sexta à noite. Na semana seguinte, eu estava em reuniões com equipes de desenvolvimento nos Estados Unidos ouvindo exatamente a mesma história só que com código, não com árvores.

O que estou vendo, na prática

Uma das conversas mais diretas que tive recentemente foi com o CTO de um cliente.

Ele abriu uma reunião com seu time mostrando algo simples: pediu para o Google Gemini gerar uma API gateway. Tempo total: 263 segundos.

Na mesma reunião, ele mostrou outra coisa. Pegou uma tarefa real do backlog que uma engenheira da equipe havia levado cerca de três horas para implementar. Refez a mesma tarefa com IA, levando cerca de 30 minutos. E encerrou a reunião com uma frase que ninguém ali esqueceu: “After next week, nothing is coded the old way ever again.”

Situações similares a essa tem se repetido e, entre a euforia e as discussões técnicas nos quais as equipes se vêem envolvidas, fica no ar uma pergunta que ninguém se atreve a fazer em voz alta: onde eu fico nisso tudo?

A pergunta é legítima e, em muitos casos, urgente. Desenvolvedores experientes, altamente competentes dentro do modelo tradicional, começam a perceber que parte do que dominavam deixa de ser diferencial. O que antes era valorizado nesses profissionais, como velocidade de implementação, domínio de sintaxe e capacidade de transformar rapidamente uma especificação em código, passa a ser parcialmente absorvido pelas ferramentas. Isso não elimina a necessidade de  um  profissional, mas muda o tipo de contribuição que se espera dele.

Um exemplo concreto ajuda a ilustrar melhor.

O líder do time de backend de um cliente praticamente parou de escrever código diretamente. Com o apoio do GitHub Copilot, ele estrutura o que precisa ser feito, gera pull requests, revisa o resultado, ajusta e aprova.

Ele não foi substituído, mas o foco do seu trabalho deixou de ser a escrita de código.

Aqueles que não se adaptarem a esse novo modelo, de fato, passam a correr risco. Emerge agora um novo perfil profissional, menos centrado na execução e mais na capacidade de interpretar, estruturar e validar. Isso exige um conjunto diferente de habilidades. Clareza de raciocínio para definir requisitos de forma precisa. Capacidade de decompor problemas complexos em partes que possam ser delegadas à IA. Visão sistêmica para entender como diferentes componentes interagem. E, principalmente, julgamento crítico para avaliar se o que foi gerado está correto, não do ponto de vista sintático, mas funcional.

Ao mesmo tempo em que esse modelo mais estruturado começa a se consolidar, tenho visto também movimentos em que o desenvolvimento com a IA é feito com níveis mínimos de supervisão humana, abordagem conhecida como vibe coding. Código sendo gerado por IA, validado superficialmente e enviado para produção com base na premissa de que “se funciona, está bom”.

Na prática, esse modelo tende a acumular riscos que não são imediatamente visíveis. O primeiro deles é a perda de rastreabilidade e a capacidade de responder perguntas como: De qual requisito esse código surgiu? Quem decidiu essa implementação? Por que essa abordagem foi escolhida? Que mudanças foram feitas ao longo do tempo?

Em engenharia tradicional, isso vem de artefatos como tickets, PRs, revisões de código, histórico de decisões. Com IA sem supervisão, surgem lacunas como decisões não documentadas: o modelo gera código, mas não há registro claro do racional. Em caso de falha, incidente ou questionamento legal, não há trilha clara de responsabilidade. 

Outro ponto, talvez o  mais relevante, é o risco de inconsistência sistêmica. A IA pode gerar soluções localmente corretas, mas desalinhadas com a arquitetura, com padrões internos ou com regras de negócio que não estavam explícitas no contexto. Isso cria sistemas que funcionam em partes, mas não se sustentam como conjunto.

Por isso, a ideia de desenvolvimento totalmente automatizado, sem supervisão qualificada, ainda me parece prematura.

O que estamos vivendo dentro da Axoma

Aqui na Axoma também estamos atravessando esta transição. Assim como em muitas empresas, o que existe hoje é um processo em andamento, com experimentação, ajustes e, em alguns casos, revisão de premissas que pareciam sólidas até muito pouco tempo atrás.

Começamos, como praticamente todo o mercado, com ferramentas de autocomplete. O ganho inicial foi claro: aceleração na escrita de código, redução de tarefas repetitivas, mais fluidez no dia a dia dos desenvolvedores.

Rapidamente ficou evidente que esse era apenas o primeiro estágio. O passo seguinte, mais complexo, tem sido a adoção de modelos de codificação agêntica. Não como uma mudança abrupta, mas como uma construção gradual. Temos testado diferentes abordagens e ferramentas, como o uso de interfaces mais integradas ao fluxo de desenvolvimento e também ferramentas em linha de comando, como o Cursor CLI e o Claude Code, avaliando onde elas realmente agregam valor.

Ao mesmo tempo, começamos a integrar IA em partes menos óbvias do processo, fora da escrita direta de código. Por exemplo, no fluxo de suporte estamos utilizando IA para pré-analisar tickets antes mesmo de chegarem ao desenvolvedor. Isso reduz o tempo gasto com triagem e ajuda a priorizar melhor o que realmente precisa de atenção humana.

Em gerenciamento de tarefas, iniciamos testes em que a IA faz uma triagem inicial de novos tickets, sugerindo classificações e até primeiros desdobramentos. Isso não elimina o papel do time, mas reduz o esforço inicial de organização.

Em produção, temos explorado automações mais avançadas. Quando um erro é detectado, agentes conseguem acionar fluxos que vão desde a análise do problema até a abertura de um pull request com uma possível correção. Naturalmente, isso ainda passa por revisão humana, mas já altera significativamente o tempo de resposta.

Também estamos experimentando o uso de agentes na geração de testes. Em alguns casos, eles conseguem cobrir rapidamente cenários básicos e aumentar a cobertura, liberando o time para focar em validações mais críticas.

E há situações em que a IA já começa a cobrir lacunas operacionais. Em projetos mobile, por exemplo, conseguimos avançar em tarefas específicas contando com desenvolvedores que tenham apenas experiência na web, algo que antes demandaria um profissional com conhecimentos mais profundos em desenvolvimento nativo. O ponto é que partes da stack que exigem conhecimento muito específico começam a se tornar muito mais manejáveis.

Mas nada disso é linear. E talvez esse seja o ponto mais importante: a adoção de IA não é apenas uma decisão de ferramenta. Ela exige ajustes no processo, no papel dos profissionais e na forma como o trabalho é estruturado. Estamos aprendendo isso na prática.

E é justamente esse aprendizado, com suas incertezas, testes e refinamentos, que tem orientado a forma como apoiamos nossos clientes nessa mesma transição.

E no Brasil?

No Brasil, esse movimento tende a chegar rapidamente e, em alguns casos, já começou, com implicações diretas.

A primeira é uma pressão crescente por produtividade. Times de engenharia passam a ser cobrados não apenas por entregar, mas por entregar mais, com menos esforço operacional.

A segunda é a revisão das estruturas de equipe. Não necessariamente equipes menores, mas equipes com papéis diferentes, com maior concentração de responsabilidade em profissionais mais experientes.

A terceira é a adoção acelerada de ferramentas, muitas vezes antes mesmo de uma reflexão mais profunda sobre como elas se encaixam no fluxo de trabalho.

E talvez a mais importante: a necessidade de evolução em processos, não apenas em tecnologia. Empresas que se anteciparem e tratarem essa mudança de forma estruturada tendem a ganhar vantagem real. As que enxergarem IA apenas como uma ferramenta de produtividade isolada correm outro risco: aumentar a complexidade, gerar mais retrabalho e, no limite, perder controle sobre os próprios sistemas.

A motosserra chegou

No fim, o problema do lenhador não era a motosserra. Era não saber o que fazer com ela. A tecnologia estava ali e era claramente mais eficiente, mas exigia outra forma de trabalhar. 

No desenvolvimento de software, estamos entrando exatamente nesse ponto. A capacidade de produzir código aumentou, mas isso não resolve o problema central: entender o que precisa ser construído, por quê, e como isso gera valor. Mais do que ferramentas, isso passa a ser uma questão de direção.

O que tenho visto no mercado americano é que as empresas que estão avançando de forma consistente não são necessariamente as que adotaram mais ferramentas, mas as que conseguiram combinar tecnologia com decisões estruturais bem fundamentadas:  arquitetura, processo e governança.

É nesse espaço que a Axoma tem atuado, acompanhando de perto essa transformação e apoiando empresas nessa transição e conectando decisões técnicas com objetivos de negócio

A motosserra chegou. Você está preparado para trabalhar com ela ou ainda está tentando fazer funcionar como se fosse um machado?