El 99% muere en localhost

Hace unos días, Christian Klein, el CEO de SAP, una de las empresas de software más grandes del planeta, se subió al trend donde los CEOs dicen que algunas profesiones, en poco tiempo, van a ser solo un recuerdo.

En esa entrevista soltó que existe la posibilidad de que en tres o cuatro años no haya nadie desarrollando software dentro de SAP. Nadie. La función más impactada por la IA, dijo, es el desarrollo de software.

Bueno, eso ya lo sabemos hace rato. El vibe coding, eso de generar código a partir de inspiración e instrucciones en lenguaje común sin saber programar, cambió las reglas. Supuestamente. Y según él, lo que viene son product managers que vibecodean y entienden el negocio, más data scientists, menos desarrolladores.

Si sos ABAPer, o devops, o cualquier cosa que termine en "developer", esa frase capaz te pega en el centro del pecho. Y viene del CEO de la empresa donde muchos de nosotros construimos carrera.

Antes de que salgas corriendo a actualizar el CV o te anotes en un curso de data science, quiero ponerte arriba de la mesa el otro dato. El que Klein no menciona en la entrevista, y que cambia por completo cómo hay que leer su predicción.

El 99% muere en localhost

Hay una frase que circula entre la gente que construye software de verdad, no en los keynotes:

El vibe coding tiene una tasa de mortalidad del 99%.

La gran mayoría de las aplicaciones que se generan con IA nunca salen de localhost. Nunca llegan a un usuario real. Funcionan en la máquina del que las hizo, sacan una captura de pantalla, juntan unos likes en el feed, y no las vuelve a abrir nadie más.

Le pusieron un nombre: la economía del screenshot.

Desde 2024 se construyen más apps que nunca, pero cada vez menos se usan de verdad. El vibe coding hizo que "compila y corre" sea gratis, así que el feed se llena de cosas que funcionan en localhost, ganan un screenshot, y mueren ahí.

Dos aclaraciones que valen la pena. Localhost es la dirección de tu propia máquina, donde corre un servidor y probás una app antes de que la vea nadie. Y el "compila y corre" siempre fue una pequeña victoria para cualquiera que haya programado en serio alguna vez. La diferencia es que de ahora en más nadie va a sufrir por un punto y coma de más o por un error de sintaxis que no te deja arrancar nada.

Y volviendo al tema, lo más honesto del diagnóstico es esto: nadie está mintiendo. La gente simplemente confunde el 20% fácil con el trabajo completo, y postea la prueba del 20%.

Lo mismo pasa adentro de las empresas, pero con presupuesto. El piloto que deslumbra al comité de dirección es una app de localhost con un logo puesto encima. Demo impecable, cero usuarios, cero ingresos. Cientos de horas perdidas en reuniones inútiles que nadie contabiliza.

Acá está el punto que conecta todo con todo. Sí, ya sabemos que nunca fue tan fácil construir software, y que muchos product managers creen ahora en una versión del teorema del mono infinito: la idea de que mil monos escribiendo al azar (o menos, gracias a los layoffs) eventualmente van a producir una obra de Shakespeare.

Pero no es más fácil construir algo que valga la pena usar. La parte difícil sigue siendo exactamente la misma de siempre: entender una necesidad real, construir una solución que alguien quiera usar, ganarse la confianza con el tiempo, y encontrar la forma de llegar a la gente correcta.

Construir es "fácil" ahora. Lo pongo entre comillas porque también se ha vuelto caro desde que las grandes empresas de IA están des-subsidiando sus precios: ya hay empresas como Uber que se gastaron el presupuesto del año en cuatro meses de esta fiesta. Pero cuando todos pueden construir, construir nunca fue la ventaja. La distribución, la confianza, la arquitectura sólida detrás de esa app, y alguien dispuesto a pagar por ella dos veces o más, eso siempre fue lo escaso.

Entonces, ¿Klein tiene razón o no?

Las dos cosas, y por eso es interesante.

Tiene razón en que escribir código, la parte mecánica de traducir una idea a sintaxis, se está automatizando rápido. Eso es real y no tiene vuelta atrás. El que viva de teclear ABAP a destajo sin entender el negocio que hay detrás, está en problemas. Klein no se equivoca ahí. Y encima, con la política de Clean Core, la gente está cada vez más delimitada para ponerse creativa: muchos clientes ya no quieren inventar la rueda. Lo que no me queda claro es cómo se van a diferenciar todos haciendo lo mismo, pero eso es otro tema para otro día.

Ahora, donde para mí Klein hace una jugada de lenguaje es acá: confunde, o elige confundir, escribir código con desarrollar software. A su nivel no creo que confunda nada. Es un mensaje que quiere mandar. Pero son dos cosas distintas. Escribir código es el 20% fácil que el vibe coding ya resuelve. Desarrollar software es entender qué hay que construir, por qué, para quién, decidir qué NO construir, mantener la coherencia del sistema cuando crece, y sostenerlo en producción cuando algo se rompe a las tres de la mañana. Eso es criterio, y el 99% de death rate demuestra que la máquina sola todavía no lo tiene. Ya sé que estamos a punto de salir en vivo en cualquier momento con el "Autonomous Enterprise", pero la industria todavía no está tan madura como argumentan los PowerPoints.

Cuando Klein dice "no va a haber desarrolladores", en realidad está describiendo el fin de un tipo de desarrollador: el que solo tecleaba. No el fin del que entiende el sistema. Ese se vuelve más valioso, no menos, justo porque ahora hay un océano de código generado que alguien tiene que saber leer, podar y sostener. Y más todavía cuando hay otros que vibecodean sin criterio y se sienten empoderados para mandar cualquier cosa a producción a la medianoche.

Los cinco roles que vienen

Boris Cherny, de Anthropic, uno de los que construyó Claude Code, publicó antes de ayer una observación que le da forma a esto. Dice que, a medida que los roles tradicionales (ingeniero, product manager, diseñador) se funden en algo nuevo, lo que ve en su equipo son cinco arquetipos que ya no están atados al título que tenés en la descripción de cargo:

• El Prototyper, que tira ideas nuevas a alto volumen, la mayoría de las cuales no van a ningún lado.
• El Builder, que convierte un prototipo en producto de verdad.
• El Sweeper, que limpia, simplifica el código y el sistema, desarma lo que sobra, optimiza.
• El Grower, que toma algo que ya funciona y lo itera para que calce mejor con el mercado.
• El Maintainer, que se hace dueño de un sistema maduro para que sea seguro, confiable y rápido a escala.

Lo interesante no es la lista. Es que casi todo el mundo que usa IA para trabajar opera en dos o tres de esos roles a la vez, y que el rol que hace falta cambia según la etapa del producto.

Ahora cruzá esto con el death rate del vibe coding (no supe cómo traducir eso y que se entienda). La IA es brutal en el primer arquetipo, el Prototyper. Tira prototipos a velocidad infinita. Por eso el feed se llena de demos de localhost. Pero el death rate del 99% pasa justo en el salto del Prototyper al resto. Limpiar, simplificar, decidir qué desarmar, hacer que algo madure y aguante en producción: ahí es donde la agencia humana sigue siendo insustituible. El vibe coding produce un ejército de prototipos huérfanos que nadie sabe convertir en producto.

El profesional que se vuelve irreemplazable en este mundo no es el que prototipa más rápido. La máquina le gana siempre, y la gente se va a dar cuenta con el tiempo de que las slides con ideas nuevas de cada townhall mueren ahí. El irreemplazable es el Sweeper y el Maintainer con criterio: el que sabe qué, de todo ese océano de código generado, merece vivir, qué hay que podar, y cómo sostener lo que queda.

El gran problema de fondo es si las organizaciones de hoy tienen la madurez para armar equipos de alto rendimiento alrededor de estos roles, soltando de a poco las viejas escuelas que dieron forma al negocio, sin descuidarlo y evolucionando al ritmo que la industria les impone.

Qué haría yo con esto, si estuviera empezando hoy

No te voy a decir que ignores a Klein. Tiene razón en lo incómodo: el que solo teclea está en problemas. Pero la conclusión no es "aprendé a vibecodear y listo, sos product manager", porque eso te convierte en uno más de los que llenan el feed de demos muertas, y el GitHub de clones y de "proyectos" que son producto de un par de prompts a medianoche.

La jugada es la inversa. Dejá que la IA haga el 20% fácil, el prototipo, y poné tu energía en el 80% que ella no puede: entender el problema real del negocio, decidir qué merece construirse y qué no, y desarrollar el músculo de podar y mantener sistemas en lugar de solo generarlos. En un mundo donde construir demos es relativamente gratis, el que sabe qué vale la pena construir, y qué desarmar, es el que manda. Bueno, a veces el que manda es otro y no el que más sabe, pero se entendió la idea.

Klein dice que SAP va a necesitar product managers que entiendan el negocio y vibecodeen. Leélo de nuevo: lo escaso ahí no es el vibecodear, eso lo va a hacer cualquiera. No sos un héroe por hablar un rato con Claude Code, aunque te genere ese feeling. Lo escaso es entender el negocio. El criterio sobre qué construir. Esa parte de la frase es la que importa, y es la que nadie repite porque no asusta tanto como el titular.

Construir dejó de ser el cuello de botella. Lo dejó de ser para cualquier área tecnológica, no solo el mundo SAP, para vos, y para los miles que publican una captura de su app de localhost y juntan likes. La única pregunta que vale la pena hacerse sobre cualquier proyecto de IA hoy es la misma de siempre: ¿construiste algo que la gente necesita, o algo que podías sacar en un fin de semana?

El que entiende la diferencia no le teme a la frase de Klein. La frase de Klein es sobre el que solo teclea. El que piensa sigue siendo el que orquesta, y se vuelve cada vez más inamovible en este mundo cada vez más artificial.

Pablo / Above Average

P.D. Si esto te sirvió, mandáselo al ABAPer que entró en pánico con el titular del CEO de SAP. Decile que lea hasta el final.

---

Referencias:

• Smith, Paul. "SAP chief predicts AI will replace its human coders within four years." Australian Financial Review, 21 de junio de 2026. Entrevista a Christian Klein.
• Cherny, Boris (@bcherny). Reflexión sobre los cinco arquetipos de roles (Prototyper, Builder, Sweeper, Grower, Maintainer) en equipos de producto e IA. X, junio de 2026.
• Concepto de "localhost economy" / "screenshot economy" y la tasa de mortalidad del vibe coding. Discusión en circulación en la comunidad de desarrollo, junio de 2026.