Por que a IA não vai reinventar o software da noite para o dia: Benedict Evans sobre os limites das ferramentas generativas

O ensaio mais recente de Benedict Evans, "IA, Ferramentas e Transformação", contesta a fantasia do Vale do Silício de que a IA permitirá que usuários gerem espontaneamente o software de que precisam, eliminando a necessidade de suítes empresariais tradicionais. Seu argumento central: o gargalo não é construir ferramentas, é saber quais ferramentas construir e fazer centenas de pessoas adotá-las.

A "Piada do Engenheiro" Invertida

Evans começa com a piada clássica: um engenheiro gastará uma hora automatizando uma tarefa que leva 10 minutos. Mas com a IA, "você pode fazer essa ferramenta em cinco minutos, e não precisa ser engenheiro". A ideia inebriante é que o software se torna dinâmico, generativo, de forma livre—muito mais tarefas automatizadas com muito menos código. No entanto, ele adverte que isso interpreta mal como o software é adotado dentro de empresas reais.

Por que a Maioria dos Usuários Não São Criadores de Ferramentas

Com base na realidade de uma grande empresa típica—centenas de aplicativos SaaS, scripts e planilhas—Evans observa que a maioria das pessoas não é como os engenheiros do Vale do Silício. "Se você é um advogado matrimonial excelente, passa o dia todo pensando em seus casos e clientes, não no que um ótimo software de descoberta legal faria." É por isso que modelos de planilhas e sugestões 'Arquivo/Novo' existem: eles tentam preencher a lacuna para não-construtores, mas permanecem respostas parciais.

As oportunidades perdidas são muitas vezes invisíveis para as pessoas que as têm. Evans cita o papel emergente do 'engenheiro de implantação direta'—alguém que pode percorrer um escritório de advocacia ou de arquitetura e identificar o potencial de automação que o especialista não vê, como um adolescente antenado em tecnologia poderia dizer: "Papai, você percebeu que poderia simplesmente fazer assim?"

Ver o Problema É a Parte Difícil

Além da percepção individual, muitas automações transformadoras não eram óbvias nem para engenheiros. "Todos podemos pensar em exemplos de coisas que usamos todos os dias em que nossa primeira reação foi 'Por que eu iria querer isso?'" O problema pode estar embutido em outro fluxo de trabalho, e encontrar a solução certa muitas vezes exige redefinir o próprio problema—algo que levou meia dúzia de tentativas fracassadas para muitas empresas de software bem-sucedidas.

A Automação Toca Departamentos, Não Apenas Indivíduos

Escalar uma mudança de fluxo de trabalho além de um único usuário é o que Evans chama de espectro "institucionalizado para improvisado". Uma planilha de baixo para cima pode lidar com um departamento, mas um novo processo de contas a pagar toca cinco departamentos, três sistemas de registro e quatro regimes regulatórios. Essa mudança "tem que ser uma compra, e uma decisão, e um processo de vendas de 18 meses", não apenas um rápido prompt de IA.

Nada disso é resolvido facilitando a escrita de código. As partes difíceis—reconhecer a necessidade, definir a ferramenta e impulsionar a adoção—permanecem teimosamente humanas e organizacionais. Esse é um contraponto sóbrio à narrativa de 'democratizar a criação de software' que ouvimos tanto.