Por qué la IA no reinventará el software de la noche a la mañana: Benedict Evans sobre los límites de las herramientas generativas

El último ensayo de Benedict Evans, "IA, herramientas y transformación", contradice la fantasía de Silicon Valley de que la IA permitirá a los usuarios generar espontáneamente el software que necesitan, eliminando la necesidad de suites empresariales tradicionales. Su argumento central: el cuello de botella no es construir herramientas, sino saber cuáles construir y lograr que cientos de personas las adopten.

El "chiste del ingeniero" invertido

Evans comienza con el clásico chiste: un ingeniero pasará una hora automatizando una tarea que toma 10 minutos. Pero con la IA, "puedes crear esa herramienta en cinco minutos, y no necesitas ser ingeniero". La idea embriagadora es que el software se vuelve dinámico, generativo, de forma libre: muchas más tareas automatizadas con mucho menos código. Sin embargo, advierte que esto malinterpreta cómo se adopta el software dentro de las empresas reales.

Por qué la mayoría de los usuarios no son creadores de herramientas

Basándose en la realidad de una gran empresa típica —cientos de aplicaciones SaaS, scripts y hojas de cálculo—, Evans señala que la mayoría de las personas no son como los ingenieros de Silicon Valley. "Si eres un abogado matrimonialista excelente, pasas todo el día pensando en tus casos y clientes, no en lo que haría un gran software de descubrimiento legal". Por eso existen las plantillas de hojas de cálculo y las sugerencias de 'Archivo/Nuevo': intentan cerrar la brecha para los no constructores, pero siguen siendo respuestas parciales.

Las oportunidades perdidas a menudo son invisibles para quienes las tienen. Evans cita el papel emergente del 'ingeniero desplegado en el frente' —alguien que puede recorrer un bufete de abogados o un estudio de arquitectura y detectar potencial de automatización que el experto no ve, como un adolescente experto en tecnología podría decir: "Papá, ¿te diste cuenta de que podrías hacerlo así?".

Ver el problema es la parte difícil

Más allá de la percepción individual, muchas automatizaciones transformadoras no eran obvias ni siquiera para los ingenieros. "Todos podemos pensar en ejemplos de cosas que usamos a diario y cuya primera reacción fue '¿Por qué querría eso?'". El problema puede estar incrustado en otro flujo de trabajo, y encontrar la solución adecuada a menudo requiere redefinir el problema en sí —algo que llevó media docena de intentos fallidos para muchas empresas de software exitosas.

La automatización afecta a departamentos, no solo a individuos

Ampliar un cambio de flujo de trabajo más allá de un solo usuario es lo que Evans llama el espectro "institucionalizado a improvisado". Una hoja de cálculo de abajo hacia arriba puede manejar un departamento, pero un nuevo proceso de cuentas por pagar toca cinco departamentos, tres sistemas de registro y cuatro regímenes regulatorios. Ese cambio "tiene que ser una compra, una decisión y un proceso de ventas de 18 meses", no solo un rápido prompt de IA.

Nada de esto se resuelve haciendo más fácil escribir código. Las partes difíciles —reconocer la necesidad, definir la herramienta y impulsar la adopción— siguen siendo obstinadamente humanas y organizativas. Ese es un contrapunto aleccionador a la narrativa de 'democratizar la creación de software' que escuchamos tanto.