DEV Community

Cover image for Quando Automatizar Custa Mais Caro: IA, Engenharia de Software e a Redescoberta da Prudência
Francis Targanski
Francis Targanski

Posted on

Quando Automatizar Custa Mais Caro: IA, Engenharia de Software e a Redescoberta da Prudência

Há uma ironia que os antigos teriam apreciado. Em 2026, algumas das maiores empresas de tecnologia do mundo descobriram que suas ferramentas de inteligência artificial, exatamente aquelas que prometiam reduzir custos, estavam mais caras do que os funcionários que deveriam auxiliar. A Microsoft cancelou as licenças internas do Claude Code, ferramenta que seus próprios engenheiros haviam adotado com entusiasmo. A Uber consumiu todo o seu orçamento anual de IA em quatro meses. E em meio aos relatórios trimestrais e às planilhas de gastos, ressurgiu uma pergunta que Platão fez há vinte e quatro séculos: o que significa, exatamente, ganhar tempo com uma ferramenta que nos faz perder algo mais importante?

Este ensaio analisa o fenômeno, suas causas técnicas e o que a filosofia clássica, particularmente Platão e Aristóteles, tem a dizer sobre ele. Ao final, discuto como práticas modernas de engenharia de software já incorporam, talvez sem saber, várias dessas lições antigas.

Casos recentes de cortes no uso interno de IA

Microsoft e Claude Code. Em dezembro de 2025, a Microsoft distribuiu acesso ao Claude Code da Anthropic a milhares de funcionários da divisão Experiences and Devices (responsável por Windows, Microsoft 365, Teams, Outlook e Surface). A intenção era avaliar a ferramenta frente ao próprio GitHub Copilot CLI [1]. O experimento foi popular: fontes ouvidas pelo The Verge afirmaram que os engenheiros preferiram o produto da Anthropic [2]. Em maio de 2026, a empresa anunciou que, a partir de 30 de junho, coincidentemente o fim do seu ano fiscal, todos migrariam para o Copilot CLI [1]. O motivo oficial foi convergência para a solução interna; relatos múltiplos apontam que "considerações financeiras" também pesaram na decisão [2].

Uber e o estouro de orçamento. A Uber enfrentou problema semelhante. Após disponibilizar Claude Code e Cursor a cerca de 5.000 engenheiros em dezembro de 2025, o consumo disparou. Em abril de 2026, a verba anual de IA havia sido esgotada [3]. O CTO Praveen Neppalli Naga declarou que a empresa estava "voltando à prancheta" do planejamento. Os números internos são reveladores: 95% dos engenheiros usam IA mensalmente, 70% das mudanças de código vêm de sistemas de IA, e o gasto médio por engenheiro é de US$ 150 a US$ 250 por mês (chegando a US$ 500–US$ 2.000 entre os usuários mais intensos) [3][4].

Outras iniciativas e alertas. Microsoft e Uber não estão sós. Um funcionário da Meta criou, na intranet da empresa, um ranking apelidado de Claudeonomics que chegou a listar os 250 maiores consumidores de tokens entre os ~85 mil empregados, com títulos como "Token Legend" e "Cache Wizard" [5]. Em 30 dias, o consumo somado ultrapassou 60 trilhões de tokens. O dashboard saiu do ar pouco depois da repercussão na imprensa. Na Amazon, funcionários foram estimulados a tokenmaxxing, usar o máximo possível de tokens, e há relatos de engenheiros rodando agentes em tarefas triviais apenas para inflar o próprio ranking [6]. Como observou a Fortune, as apostas das maiores empresas em IA estão se chocando com o peso real do custo de adoção [7].

Por que os custos disparam?

Duas razões técnicas explicam o problema.

A primeira é arquitetural: as novas IAs agentivas, capazes de executar múltiplas etapas autonomamente, manter contextos extensos e até criar sub-agentes, consomem volumes massivos de tokens. Mesmo se o preço unitário cai, a quantidade consumida cresce mais rápido. Segundo projeção do Goldman Sachs citada pelo Fortune, o consumo total de tokens deve aumentar 24 vezes até 2030, chegando a 120 quadrilhões de tokens por mês com a popularização desses agentes [7]. Bryan Catanzaro, vice-presidente de aprendizado profundo aplicado da Nvidia, foi mais direto: "para minha equipe, o custo da computação está muito acima do custo dos funcionários" [8].

A segunda razão é organizacional: incentivos internos empurram o uso para cima. Em algumas empresas, engenheiros passaram a ser avaliados pela quantidade de tokens consumidos, o que produz exatamente o tipo de comportamento que a Lei de Goodhart prevê: quando uma métrica vira meta, ela deixa de medir o que pretendia. Quando o gasto em tokens por funcionário se aproxima ou ultrapassa o salário desse funcionário, o cálculo financeiro muda de forma silenciosa: se a máquina faz o trabalho, quantos seres humanos ainda precisam coordená-la?

Apesar do marketing falar em produtividade e corte de despesas, a economia desmente a narrativa simples. O preço por token pode até cair, mas o volume consumido cresce mais rápido do que a queda compensa. É o paradoxo de Jevons em nova roupagem: quando uma tecnologia se torna mais eficiente, o uso aumenta tanto que o consumo agregado de recursos sobe, não desce.

Lições da filosofia clássica

O dilema atual, tecnologias que oferecem aparência de produtividade a custos elevados, ressoa com ensinamentos antigos sobre sabedoria, virtude e medida.

Platão e a ilusão da sabedoria

No Fedro, Sócrates recorre a um mito egípcio: o deus Theuth apresenta a invenção da escrita ao Rei Tâmus, dizendo que será "elixir da memória e da sabedoria". Tâmus recusa o presente, e a resposta dele é o que mais nos interessa hoje: a escrita produzirá esquecimento, não memória, porque as pessoas confiarão em marcas externas em vez da própria mente; e oferecerá aos discípulos "aparência de sabedoria, não sua realidade". Eles ouvirão muitas coisas sem terem sido ensinados, e parecerão saber muito sendo, em grande parte, ignorantes [9].

A analogia com o código gerado por IA é direta. Aceitar passivamente uma solução produzida por um modelo pode dar a aparência de capacidade técnica: o programa compila, os testes passam, o ticket é fechado. Mas ali pode não haver compreensão real do que foi feito, e a compreensão é o que permite manter, depurar, refatorar e estender o sistema no futuro. Um desenvolvedor inspirado pelo espírito socrático revisa o código gerado pela IA com perguntas, em vez de aceitá-lo como oráculo.

Aristóteles e a neutralidade das ferramentas

Aristóteles adotou postura mais equilibrada. Para ele, artefatos produzidos pelo homem são neutros: podem ser usados para o bem ou para o mal, dependendo da intenção de quem os usa [10]. A IA, em si, não é boa nem má. Tudo depende de como a empregamos e, sobretudo, de mantermos o juízo crítico no centro da decisão.

Aristóteles também distingue dois tipos de conhecimento: tecnhê (a habilidade técnica, o saber-fazer) e epistêmê (o conhecimento teórico, o saber-por-quê). A IA pertence indubitavelmente ao território da tecnhê. Sem epistêmê, sem entender o domínio do problema, o porquê das escolhas, o telos do sistema, a tecnhê gira no vazio.

Os gregos e a temperança

Mesmo quando inventavam aquedutos e prensas, os gregos clássicos entendiam que a razão deveria nortear o uso das ferramentas. Sócrates advertia que um foco exagerado no progresso material pode desviar as pessoas da busca pela sabedoria e pela virtude [10]. A mensagem para a era da IA não é "use menos"; é "use com consciência do que está sendo trocado".

Os estóicos e a responsabilidade

Os estóicos pregavam concentração no que está sob nosso controle e aceitação do resto. Aplicado ao desenvolvimento, cabe ao engenheiro cultivar diligência e vocação de artesão, revisando e refatorando conscientemente aquilo que a IA produz, em vez de terceirizar totalmente a inteligência. A virtude técnica permanece como responsabilidade humana, mesmo (talvez especialmente) quando a máquina escreve a primeira versão.

Implicações para o desenvolvimento de software

As lições acima têm ecos diretos em práticas modernas de engenharia de software, várias delas codificadas em livros que já têm décadas.

Arquitetura

Bass, Clements e Kazman (2012) enfatizam que decisões de design precisam ser pensadas a montante, considerando escalabilidade, custo e consequências de longo prazo. Esse planejamento cuidadoso ecoa Aristóteles: não se embarca num empreendimento sem avaliar suas causas e seus meios. Dependência excessiva de uma única solução, IA ou qualquer outra, sem medir consequências viola princípios básicos de boa arquitetura.

Teste antes do código

Kent Beck (2002) propõe escrever testes antes do código, formulando explicitamente o comportamento esperado. O paralelo socrático é quase exato: o teste é uma pergunta que o código precisa responder. Em vez de deixar a IA "adivinhar" a solução, o desenvolvedor define o alvo com clareza (teste) e só então produz ou aceita o código. Esse ciclo de pergunta e resposta evita as soluções superficiais que Platão criticava.

Domínio antes da técnica

Eric Evans (2003) sugere modelar o software em torno dos conceitos do negócio, promovendo comunicação rica entre especialistas e desenvolvedores. É o pareamento aristotélico entre epistêmê e tecnhê: o domínio (o porquê) precisa ficar no centro, e as ferramentas (incluindo IA) auxiliam na implementação sem obscurecer o significado. Quando a IA produz código que ninguém revisa do ponto de vista do domínio, o que se perde primeiro é justamente o vínculo entre o software e o problema que ele deveria resolver.

Brooks e o mito da escala linear

Frederick Brooks (1995) já advertia que adicionar mais "mãos" a um projeto não acelera o trabalho linearmente, pelo contrário, introduz overhead de coordenação que pode atrasar tudo. A lição cabe à IA com precisão desconcertante: adicionar mais geração automática de código não escala linearmente em produtividade. Cada trecho gerado precisa ser revisado, integrado, alinhado com o resto do sistema. Em algum ponto, o custo cognitivo de revisar começa a anular o ganho de velocidade. O "homem-mês mítico" se transforma, em 2026, no "token-mês mítico".

Refatoração contínua

Martin Fowler (2018) alerta contra a complacência. Mesmo com código gerado por IA, é tarefa do desenvolvedor melhorar continuamente o design. Sob a ótica estóica, é não delegar a virtude: o desenvolvedor não terceiriza inteiramente a inteligência, mas aperfeiçoa o trabalho junto com a máquina.

Padrões de projeto

Gamma et al (1995) defendem soluções equilibradas que evitam vícios, como acoplamento excessivo a uma única abordagem. Aplicar um padrão como Fábrica permite encapsular a criação de objetos, de modo que se um dia a fonte mudar (do programador para uma IA), o impacto no sistema seja contido. É a "justa medida" aristotélica em forma de código.

As melhores práticas de desenvolvimento já incorporam, talvez sem perceber, vários elementos filosóficos clássicos: foco no propósito, questionamento constante e moderação no uso de ferramentas que parecem mágicas. Reconhecer isso ajuda a aplicar IA sem perder a essência humana da engenharia, o compromisso com qualidade, compreensão e ética do trabalho.

Conclusão

Os engenheiros de Microsoft e Uber não enfrentaram um problema técnico inédito. Enfrentaram, repaginado, o mesmo dilema que Tâmus apresentou a Theuth: nem toda ferramenta que parece nos tornar mais sábios efetivamente o faz, e nem todo ganho de velocidade compensa o custo daquilo que se atrofia em silêncio.

A IA generativa é poderosa e pode, sim, multiplicar produtividade. Mas não é bala de prata, e quando o gasto em tokens por engenheiro se aproxima do salário desse engenheiro, vale lembrar que o problema talvez nunca tenha sido o preço dos tokens, e sim a confusão entre uso e valor, entre velocidade e compreensão, entre aparência de sabedoria e sua realidade.

A pergunta que importa para o desenvolvedor de 2026 não é "quantos tokens consumi hoje?". É a mesma pergunta de sempre, só com vocabulário novo: eu entendo o que estou construindo? Se a resposta exigir consultar a IA para saber, talvez o problema não esteja no preço dos tokens.


Referências

  • Bass, L., Clements, P., & Kazman, R. (2012). Software Architecture in Practice. Addison-Wesley.
  • Beck, K. (2002). Test-Driven Development: By Example. Addison-Wesley.
  • Brooks, F. P. (1995). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
  • Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
  • Fowler, M. (2018). Refactoring: Improving the Design of Existing Code (2ª ed.). Addison-Wesley.
  • Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.

Fontes

[1] EPC Group. Microsoft Just Cancelled Internal Claude Code Licenses (maio/2026). Link

[2] Warren, T. Microsoft cancels Claude Code licenses, shifting developers to GitHub Copilot CLI. The Verge / Windows Central (maio/2026). Link

[3] Storyboard18. Uber exhausts 2026 AI budget in four months amid massive Claude Code adoption. Link

[4] Briefs. Uber Spends Full 2026 AI Budget in 4 Months. Link

[5] Fortune. A Meta employee created a dashboard so coworkers can compete to be the company's No. 1 AI token user (abril/2026). Link

[6] Fortune. Amazon's reported tokenmaxxing might gamify AI usage, analyst warns (maio/2026). Link

[7] Fortune. Microsoft reports are exposing AI's real cost problem: The tech is more expensive than paying human employees (maio/2026). Link

[8] SquaredTech, citando Bryan Catanzaro (Nvidia) à Axios. AI Cost Problem: Why Enterprise AI Bills Keep Exploding. Link

[9] John Templeton Foundation. Plato Warned Us About ChatGPT (And Told Us What to Do About It). Link

[10] Freeman, O. J. The Philosophy of Technology: Tracing its Origins from Ancient Greece to the Modern Era. Medium. Link

Top comments (0)