Nos últimos anos, tenho visto uma história específica ser vendida nas salas de reuniões: “O software program em breve será gratuito”. O argumento de venda é simples: Grandes modelos de linguagem pode escrever código, que é a maior parte do que os desenvolvedores fazem. Portanto, as empresas podem dispensar desenvolvedores, apontar um LLM para um backlog e criar sistemas de negócios personalizados na velocidade necessária. Se você acredita nesse argumento, a conclusão é inevitável: a organização que se transfer mais rapidamente para substituir pessoas por IA vence.
Hoje, essa ambição esperançosa está a colidir com a realidade de como os sistemas empresariais realmente funcionam. O que está explodindo não é a codificação de IA como uma capacidade. É a tomada de decisão empresarial que trata a IA como um substituto do desenvolvedor, e não como um amplificador do desenvolvedor. LLMs são inegavelmente úteis. Mas as empresas que os utilizam como substitutos do julgamento da engenharia estão agora a descobrir que não eliminaram custos nem complexidade. Eles apenas o moveram, multiplicaram e, em muitos casos, enterraram-no sob camadas de código gerado insustentável.
Uma história inebriante e incompleta
Essas decisões não são tomadas no vácuo. As empresas são incentivadas e influenciadas por algumas das vozes mais fortes do mercado: CEOs de IA e de nuvem, fornecedores, influenciadores e defensores internos que precisam de uma história transformadora para justificar a próxima mudança orçamentária. A mensagem é direta: os programadores estão se tornando persona non grata. Prompts são a nova linguagem de programação. Sua fábrica de IA produzirá software program de produção da mesma forma que seu CI/CD compilações de saídas do sistema.
Essa narrativa deixa de fora detalhes importantes que todo arquiteto empresarial experiente conhece: software program não é apenas digitação. As partes difíceis são requisitos sem conflitos, dados confiáveis, segurança, desempenho e operações. As compensações exigem responsabilidade, e remover os humanos das decisões de design não elimina o risco. Ele take away exatamente as pessoas que podem detectar, explicar e resolver problemas antecipadamente.
Código que funciona até que não funcione
Aqui está o padrão que vi repetido. Uma equipe começa usando um LLM para trabalhos pesados. Isso vai bem. Em seguida, a equipe o utiliza para gerar módulos. Isso vai ainda melhor, pelo menos no início. Então a liderança faz a pergunta óbvia: se a IA pode gerar módulos, por que não serviços inteiros, fluxos de trabalho inteiros, aplicações inteiras? Em breve, você terá “miniempresas” dentro da empresa, capacitadas para criar sistemas completos sem o atrito de revisões de arquitetura, engenharia de desempenho ou planejamento operacional. No momento, parece velocidade. Em retrospectiva, muitas vezes trata-se apenas de dívida sem preço.
O fato desconfortável é que o código gerado pela IA costuma ser ineficiente. Geralmente aloca demais, abstrai demais, duplica a lógica e perde oportunidades sutis de otimização que engenheiros experientes aprendem com dificuldade. Pode ser “correto” no sentido estrito de produzir resultados, mas será que cumprirá os acordos de nível de serviço, lidará com casos extremossobreviver às atualizações e operar dentro de restrições de custos? Multiplique isso por dezenas de serviços e o resultado será previsível: contas de nuvem que crescem mais rápido que as receitas, latência que aumenta lançamento após lançamento e soluções alternativas temporárias que se tornam dependências permanentes.
A dívida técnica não desaparece
A dívida técnica tradicional é pelo menos visível para os humanos que a criaram. Eles se lembram por que um atalho foi tomado, quais suposições foram feitas e o que precisaria ser mudado para desfazê-lo. Os sistemas gerados por IA criam um tipo diferente de dívida: dívida sem autoria. Não há memória compartilhada. Não existe um estilo consistente. Não há uma lógica coerente que abranja a base de código. Existe apenas uma saída que “passou nos testes” (se os testes foram escritos) e uma implantação que “funcionou” (se a observabilidade foi instrumentada).
Agora adicione a realidade operacional. Quando uma empresa depende destes sistemas para funções críticas, como cotações, faturação, decisões da cadeia de abastecimento, fluxos de trabalho de deteção de fraudes, processamento de reclamações ou relatórios regulamentares, os riscos tornam-se existenciais. Você não pode simplesmente reescrever tudo quando algo quebra. Você precisa corrigir, otimizar e proteger o que existe. Mas quem pode fazer isso quando o código foi gerado em escala, costurado com padrões inconsistentes e refatorado pelo próprio modelo ao longo de dezenas de iterações? Em muitos casos, ninguém sabe por onde começar porque o sistema nunca foi concebido para ser compreendido pelos humanos. Foi projetado para ser produzido rapidamente.
É assim que as empresas se encurralam. Eles têm software program que é simultaneamente de missão crítica e efetivamente insustentável. Ele funciona. Produz valor. Também vaza dinheiro, acumula riscos e resiste à mudança.
Contas, instabilidade e riscos de segurança
A matemática econômica que justifica a dispensa de desenvolvedores geralmente pressupõe que o custo mais alto é a folha de pagamento. Na realidade, os custos recorrentes mais elevados para as empresas modernas tendem a ser operacionais: computação na nuvem, armazenamento, saída de dados, expansão de SaaS de terceiros, resposta a incidentes e o obstáculo organizacional criado por sistemas não fiáveis. Quando o código gerado pela IA é ineficiente, ele não apenas fica mais lento. Ele funciona mais, tem escala mais ampla e falha de maneiras estranhas que são caras para diagnosticar.
Depois vem o lado da segurança e conformidade. O código gerado pode extrair bibliotecas casualmente, manipular segredos incorretamente, registrar dados confidenciais ou implementar padrões de autenticação e autorização que estão sutilmente incorretos. Pode criar integrações paralelas que contornam a governação. Pode produzir infraestrutura como código mudanças que funcionam no momento, mas que violam a postura de plataforma de longo prazo da empresa. As equipes de segurança não conseguem acompanhar uma fábrica de códigos que ultrapassa a capacidade de revisão, especialmente quando a organização reduziu simultaneamente a equipe de engenharia que normalmente faria parceria com a segurança para criar padrões mais seguros.
A empresa acaba pagando pela ilusão de velocidade com custos de computação mais elevados, mais interrupções, maior dependência do fornecedor e maior risco. A ironia é dolorosa: a empresa reduziu o número de desenvolvedores para cortar custos e depois gastou as economias, e mais, em recursos de nuvem e combate a incêndios.
O dano é actual
Um próximo capítulo previsível está se desenrolando em muitas organizações. Eles estão contratando desenvolvedores de volta, às vezes discretamente, às vezes publicamente e às vezes como engenheiros de plataforma ou engenheiros de IA, para evitar admitir que a estratégia authentic da força de trabalho estava equivocada. Essas equipes que retornam são encarregadas do trabalho menos glamoroso em TI: tornar os sistemas gerados compreensíveis, observáveis, testáveis e econômicos. Eles são solicitados a construir proteções que deveriam existir desde o primeiro dia: padrões de codificação, arquiteturas de referência, controles de dependência, orçamentos de desempenho, políticas de implantação e contratos de dados.
Mas aqui está o problema: nem sempre é possível reverter os danos rapidamente. Depois que um sistema amplo e gerado se torna a espinha dorsal das operações de receita, você fica limitado pelo tempo de atividade e continuidade dos negócios demandas. A refatoração se torna uma cirurgia realizada enquanto o paciente está correndo uma maratona. A organização pode se recuperar, mas muitas vezes leva muito mais tempo do que a transformação authentic da IA para criar a bagunça. E a curva de custos é merciless: quanto mais se espera, mais dependente se torna o negócio e mais cara se torna a remediação.
A lição mais antiga de tecnologia
Se parece bom demais para ser verdade, geralmente é. Isso não significa que a codificação de IA seja um beco sem saída. Isso significa que a empresa deve parar de confundir automação com substituição. A IA é excelente na automatização de tarefas. Não é bom assumir resultados. Ele pode redigir código, traduzir padrões, gerar testes, resumir logs e acelerar o trabalho de rotina. Isso pode ajudar um engenheiro forte a avançar mais rápido e detectar mais problemas mais cedo. Mas não pode substituir a responsabilidade humana pela arquitetura, modelagem de dados, engenharia de desempenho, postura de segurança e excelência operacional. Esses não são problemas de digitação. São questões de julgamento.
As empresas que vencerão em 2026 e além não serão aquelas que eliminarão os desenvolvedores. Serão as empresas que combinam desenvolvedores com ferramentas de IA, investem na disciplina da plataforma e exigem qualidade mensurável, capacidade de manutenção, eficiência de custos, resiliência e segurança. Eles tratarão o modelo como uma ferramenta poderosa, não como um funcionário. E lembrar-se-ão que o software program não é apenas produzido; isso é administrado.