Cómo los agentes de código van a reconfigurar el mercado del software reduciendo el tamaño de las grandes empresas de la industria y aumentando el número total de desarrolladores
Un compilador de C en dos semanas
Nicholas Carlini, de Anthropic, publicó los resultados de un experimento notable. Encargó a dieciséis agentes que escribieran, desde cero, un compilador de C. No un prototipo. Un compilador funcional en Rust, capaz de compilar Linux 6.9 para x86, ARM y RISC-V. El resultado fueron 100.000 líneas que superan el 99% de los test suites de compiladores, incluyendo el riguroso GCC torture test[i].
El proyecto duró dos semanas. El coste en tokens fue alrededor de $20.000. Mi estimación de lo que se tardaría en hacer lo mismo a mano es de alrededor de un año y medio de trabajo. Aunque el dato sobre hacerlo a mano se puede discutir, el salto de magnitud a la hora de desarrollar un compilador parece claro.
Pero hay otro detalle además de los números. Carlini no es especialista en compiladores. Su trabajo no fue escribir el código, sino diseñar el entorno donde los agentes pudieran trabajar. Los tests que los guiaban. El sistema de feedback. La infraestructura para dos mil sesiones. Después, en gran medida, se apartó.
Lo que importa es que Carlini no necesitaba ser especialista. Entendía cómo construir sistemas verificables, cómo estructurar el problema o cómo evaluar resultados. Eso es ser generalista.
El software pasa de ser caro de desarrollar a ser accesible, con un coste marginal que tiende a cero. Una industria construida sobre el supuesto de que es caro y difícil tiene que repensar todo. El tipo de conocimiento que importa, o los procesos con los que se construye, cambian completamente.
Vibe coding y por qué el código sigue importando
Pero esta conclusión requiere matices. Hay que distinguir entre dos fenómenos que a veces se confunden porque comparten herramientas.
El vibe coding es la evolución natural de low-code y no-code. La premisa principal es que lo que importa es el resultado. Describe qué quieres, la herramienta de IA lo genera. Cualquiera puede crear funcionalidad en horas sin formación técnica. Es muy potente y su alcance sigue creciendo.
Pero “funciona” no es suficiente para el software profesional. El vibe coding tiene límites que vale la pena entender alrededor de la mantenibilidad, escalabilidad y seguridad al menos.
Los modelos de lenguaje necesitan código legible. Cuando acumula deuda técnica, como código enmarañado, sin estructura, el modelo pierde coherencia. Puede parecer una paradoja, pero el modelo que genera el código necesita que ese código esté bien escrito.
Una aplicación puede funcionar con diez usuarios, pero colapsar con diez mil. Las decisiones de arquitectura no se toman solas. Requieren criterio y dirección. Este criterio requiere, a su vez, entender qué está pasando por debajo.
Un CRM puede funcionar durante meses y tener una brecha que exponga todos los datos. Sin formación técnica, no sabes qué preguntar, no sabes qué pedir. No sabes qué no sabes.
El proyecto del compilador no es vibe coding. Carlini diseñó un entorno de tests riguroso. Aplicó criterios de ingeniería. Y tenía algo que no siempre existe: décadas de tests que definen qué es “correcto”.
Es un espectro en el que en un lado está el vibe coding. Software simple, rápido, con bajo riesgo. En el otro, el desarrollo profesional. Software que escala, que se mantiene, que es seguro. En este último importan el código y la arquitectura. Hay que entender esa arquitectura, aunque no escribas el código a mano.
La formación en informática e ingeniería de software no desaparece como requisito, sino que se aplica de forma diferente. El desarrollador pasa de escritor de código a director de un proceso que produce código. Para dirigir ese proceso con criterio hay que entender lo que se está produciendo.
La paradoja de Jevons aplicada al software
En 1865, William Stanley Jevons notó algo paradójico. La máquina de vapor mejoró y el carbón se volvió barato. Se esperaba un menor consumo de carbón, pero pasó lo opuesto. El carbón barato y la optimización de su uso permitió usos antes impensables y el consumo se disparó.
La paradoja de Jevons dice que cuando un proceso se vuelve eficiente en el consumo de un recurso, la demanda de ese proceso puede crecer, y el consumo del recurso en lugar de bajar, crece. Esto ha aplicado al software hasta ahora. Cuanto más eficiente ha sido hacer software, más software se ha hecho y más programadores se han necesitado. Es posible que esta paradoja siga afectando al desarrollo de software en esta nueva etapa. Incluso hay gente que defiende que la demanda del software es infinita[ii].
Si el software cuesta diez veces menos, generaremos lo mismo por menos dinero. Eso es lo intuitivo. Pero la realidad es que haremos mucho más porque hay una demanda latente esperando a salir. Pymes sin software a medida porque era caro, necesidades particulares adaptándose a productos genéricos, o procesos en hojas de cálculo que podrían ser software. El coste nunca justificaba que se hiciera ese software, pero ahora es más barato.
Según un estudio de Anthropic[iii], más del 90% de tareas en Computer & Math podrían ser realizadas por un LLM, aunque la adopción real hoy en día aún está alrededor del 3%. Esa brecha indica que podemos estar al inicio de una gran automatización.
Ilustración 1. Capacidad teórica y exposición observada por categoría ocupacional Proporción de tareas laborales que los LLM podrían realizar teóricamente (área azul) y cobertura laboral derivada de los datos de uso (área roja).
Sin embargo, las señales de crecimiento empiezan a ser visibles. El mercado laboral técnico, lejos de contraerse, muestra incrementos ya en el primer trimestre de 2026. La demanda de ingenieros de software sube un 11% interanual en EE.UU., según datos de Indeed analizados por Citadel Securities[iv]. Morgan Stanley proyecta que el tamaño del mercado de desarrollo de software podría crecer un 20% anual hasta 2029[v].
Un ejercicio rápido. Si el 90% de las tareas se automatizan, queda un 10% que requiere criterio: arquitectura, evaluación de sistemas, seguridad. Si al mismo tiempo la demanda crece un orden de magnitud los puestos de trabajo que se necesitarán serán los mismos, pero si crece dos órdenes de magnitud , ese 10% representará más trabajo del que existe hoy, hasta un 1.000%. El argumento de “la IA destruye el empleo” implica que la demanda no crece o que se automatiza el 100% de las tareas de un puesto de trabajo. Cómo de elástica es la demanda del valor creado por una profesión es es la parte que rara vez se discute y que marcará la diferencia entre unas profesiones y otras.
La paradoja de Jevons no promete que todo sea sencillo. Promete que la demanda puede crecer cuando el coste baja. Lo que no dice es quién y cómo captura esa demanda ni qué forma toma el mercado resultante.
La nueva economía del software
El cambio no es solo de velocidad, también es de estructura de costes.
Hasta ahora, fabricar software significa, principalmente, pagar salarios. Los desarrolladores son prácticamente el único coste. Las herramientas de desarrollo tradicionales son una línea marginal. El software es una industria de personas, como la consultoría o la abogacía.
Con los sistemas multi-agente, esto puede cambiar. Los tokens de un modelo de lenguaje se convierten en coste real y significativo. En sistemas multi-agente con alta autonomía, pueden llegar a representar entre el 60% y el 80% del total del proyecto. El compilador de C costó unos $20.000 en tokensi. El equivalente humano, durante 18 meses, habría costado cerca de 10 veces más. Así que el coste total cae, pero se distribuye de otra manera. La mayor parte del coste ya no es mano de obra, es computación.
Como consecuencia parece que el desarrollador con experiencia y criterio es más demandado. El que principalmente ejecutaba instrucciones de otros tiene poco espacio para proteger su trabajo.
También aparece un riesgo nuevo. Si el 60-80% del coste de un proyecto son tokens, un cambio de precios de Anthropic, OpenAI o Google puede hundir la viabilidad del proyecto. Antes, el coste era trabajo propio. Ahora depende de proveedores externos. La mayoría de las organizaciones que construyen software aún no ha añadido esto a sus análisis de riesgo.
Tres mundos en colisión
El impacto no llega igual a todos. Hay tres actores principales dentro del mercado del software, y sus movimientos se encadenan. Lo que decide un gran departamento de IT presiona a sus integradores, y lo que hacen ambos cambia el espacio disponible para los fabricantes de producto.
Los departamentos de IT de las grandes empresas
Un gran departamento de IT, con 10.000 desarrolladores, con un 30% internos y un 70% contratistas, podría producir diez veces más software con las herramientas de hoy con ese mismo equipo.
Pero la mayoría de las grandes empresas no quieren diez veces más software. Quieren el mismo software por menos dinero. O quizá más software (¿tres veces más?), pero con el mismo presupuesto. Para muchas grandes empresas, donde IT es un gasto, no una inversión, el objetivo es contener costes.
Por otro lado, el cuello de botella se desplaza. Si desarrollar es diez veces más rápido, lo que importa es saber qué construir. Hay que tener 10 veces más ideas o necesidades. El equipo de producto pasa a ser el nuevo cuello de botella. Hay datos que apuntan en esta dirección[vi]. En el primer trimestre de 2026 hubo más de 7.300 posiciones de product mánager abiertas globalmente en tech, en máximos de tres años y creciendo un 20% desde el inicio del año. Cuando la capacidad de ejecución deja de ser el cuello de botella, lo que escasea es quien sabe qué es lo que hay que construir.
Lo que parece más probable en esos departamentos es que se reduzcan los desarrolladores externos, que es la partida más fácil de recortar a priori, y se dé más peso a los perfiles internos y con experiencia. Son perfiles que ahora pueden hacer solos lo que antes hacía un equipo de diez personas coordinadas por ellos. Son los que saben qué construir, en qué dirección, y tienen el criterio para evaluar si lo que producen los agentes es bueno.
Los integradores de software
Las grandes consultoras tecnológicas y empresas de outsourcing lo pueden sufrir dos veces. Son las primeras afectadas por la reducción de desarrolladores de sus clientes, y sus modelos de negocio son los más expuestos.
Los datos también parece que empiezan a mostrar este movimiento. Accenture ha despedido 11.000 empleados y ha hecho de la adopción de IA un requisito para las promociones sénior[vii]. Las grandes IT indias (TCS, Infosys, Wipro) han eliminado más posiciones en EE.UU. en los tres primeros meses de 2026 que en todo 2025[viii].
Los integradores que viven de vender horas de programador son las más expuestas. Su ventaja era escalar equipos rápido. Esa ventaja desaparece cuando un equipo más pequeño con agentes produce lo mismo. Los especialistas de nicho, los que ofrecen know how (regulación financiera, salud, seguridad…) tienen más margen porque ese conocimiento profundo es difícil de replicar con herramientas genéricas. Pero el grueso del negocio generalista va a contraerse fuertemente.
El camino natural para muchos integradores sería bajar hacia segmentos de clientes más pequeños. El problema es que eso requiere estructuras de coste mucho más ligeras que las que tienen hoy, y además se van a encontrar con competidores nuevos que han nacido sin ese lastre.
Las empresas de producto y SaaS
Las empresas SaaS, o simplemente de producto, tienen un problema distinto, pero igual de serio. Las barreras de entradas que han construido se difuminan.
Si el software es barato de hacer, también es barato de copiar. Un CRM, un ERP vertical, una plataforma de gestión de proyectos… cualquiera puede recrearse a una fracción del coste original. Quizá no con toda su funcionalidad, pero sí con la funcionalidad suficiente, y sin necesidad, para el cliente, de adaptarse al producto. El “SaaSpocalypse” de 2026 refleja esta presión con una caída en la valoración de las empresas de software de 300 mil millones de dólares en la primera semana de febrero de 2026[ix]. En casos concretos, empresas como Atlassian, Workday o Monday.com, por ejemplo, empiezan a notar una caída en licencias[x].
Aunque estos datos observados en el inicio de 2026 son generales, no todos los productos son igual de vulnerables. Hay al menos tres palancas que pueden proteger a estos fabricantes de productos de software. Los que tienen efectos de red potentes (redes sociales, marketplaces) no se sustituyen simplemente porque el software sea más barato porque su valor está en los usuarios, no en el código. Los vinculados a infraestructura física o procesos regulados tienen barreras de entradas que no se ven afectadas porque el coste marginal de la creación de software tienda a cero. Y los que tienen canales de distribución consolidados (Microsoft y Google a través de productos como el correo y la ofimática, o Salesforce con su red comercial global) pueden defender su posición porque la integración o el acceso al cliente puede valer más que el coste del producto.
Los que no tienen ninguna de esas defensas, los que compiten principalmente en funcionalidad y precio, están en un territorio difícil de proteger a medio plazo.
Las tres perspectivas convergen en que, al igual que los departamentos de IT, todas demandarán menos desarrolladores, potenciando los perfiles con experiencia con criterio propio. Todas generarán un excedente de profesionales que necesitarán encontrar nuevos espacios.
El florecimiento del software local
Mientras las grandes empresas del sector se encogen, algo diferente puede crecer en el margen.
Un desarrollador conoce un centro de buceo que forma parte de un grupo de diez centros de buceo que operan en zonas de reserva natural con acceso regulado y limitado. Cada año, estos centros necesitan coordinarse para planificar quién entra cuándo, respetando cupos y condiciones de cada uno. Hasta hace poco, ese proceso les consumía dos meses de trabajo compartido al inicio del año. Usar un software para esto estaba fuera de su alcance porque es un problema demasiado específico para un software genérico, demasiado pequeño para justificar un desarrollo profesional por parte de un integrador, y, también, demasiado caro para los presupuestos de estos centros de buceo.
Hoy ese desarrollador les ofrece la solución a cambio de una suscripción anual que cada centro puede asumir. El siguiente paso natural es contactar con otros grupos de centros en otras reservas y ofrecer el mismo servicio. Es un negocio pequeño, muy especializado, que resuelve un problema real para gente real. Antes no existía porque los costes de crear esa solución no permitían que pudiera existir, ni por la parte del centro de buceo, ni por la del desarrollador.
Este patrón se va a reproducir miles de veces. La mayor parte de las pymes y empresas medianas del mundo no tiene software a medida porque el coste nunca lo permitió. Millones de coordinaciones, flujos de trabajo y necesidades específicas han vivido siempre con soluciones genéricas que no encajan bien, o directamente sin solución tecnológica. Al bajar drásticamente el coste de desarrollo, esa demanda latente se puede convertir en mercado real.
Una parte de esa demanda se cubrirá con vibe coding con seguridad. Necesidades simples, sin requerimientos de seguridad complejos, con ciclos de vida cortos. Pero en cuanto la solución necesita mantenerse de una temporada a otra, incorporar nuevos requisitos, escalar a más usuarios o manejar datos sensibles, el desarrollador necesita la formación sólida de la que hablábamos: saber cómo estructurar el sistema, cómo asegurar los datos, cómo hacer que funcione cuando las cosas se complican. El desarrollador de los centros de buceo no está haciendo vibe coding. Está construyendo un producto real que tiene que funcionar bien cada temporada.
Estas nuevas empresas tienen, no obstante, un techo de crecimiento natural. Las de servicios dependen de la proximidad y la confianza personal, que son difíciles de escalar más allá de un radio geográfico o un nicho concreto. Las de producto se enfrentan a un problema estructural porque la misma facilidad que les permite crear su solución permite a otros replicarla. Las barreras de entrada bajas son buenas para entrar en un mercado, pero también dejan entrar a los competidores.
En mi opinión, en este segmento ya no hay espacio para que nazca un nuevo unicornio alrededor de un producto de software. Una empresa con valoración de cien millones de dólares puede ser posible, pero llegar a los mil millones es muy difícil. En cuanto una solución demuestra tracción, la facilidad para replicarla es tan grande que la competencia aparece antes de que se pueda consolidar una posición dominante. Los unicornios históricos del software pudieron crecer porque el software era caro de hacer y difícil de copiar. Esas condiciones han cambiado.
El nuevo desarrollador
Las primeras señales del mercado laboral en 2026 cuentan una historia que parece contradictoria a primera vista.
A pesar de la explosión en productividad en desarrollo de software, hay más posiciones de ingeniería abiertas que hace un año. Más de 67.000 globalmente en tech, con 26.000 solo en EE.UU. y acelerándose desde inicio de año, según datos de Lenny Rachitskyv. La demanda de desarrolladores sube. Al mismo tiempo, las ofertas para roles de pura implementación (desarrolladores cuya función principal es traducir especificaciones en código) han caído un 17%[xi]. Se demandan más desarrolladores, pero desarrolladores diferentes. Las ofertas que piden experiencia con herramientas de desarrollo asistida por IA han subido un 340% entre enero de 2025 y enero de 2026[xii].
El mercado está recomponiendo la demanda, no reduciéndola. No busca a quien escribe código; busca a quien sabe qué código debería existir, cómo debe estar estructurado, y puede evaluar si lo que producen los agentes cumple los requisitos de un sistema profesional.
La formación de base no desaparece. Arquitectura, diseño de sistemas, bases de datos o seguridad siguen siendo el núcleo de conocimiento necesario. Simplemente, este conocimiento se aplica de manera diferente. El código pasa a ser un subproducto del proceso, pero para dirigir ese proceso hay que entender lo que produce. Quien no comprende lo que genera el agente no puede evaluarlo ni escalarlo.
Hay una preocupación legítima sobre cómo se adquiere experiencia. Si los proyectos de entrada que antes hacían los juniors los absorbe la automatización, la cantera de futuros desarrolladores expertos puede reducirse sensiblemente. El aprendizaje de los primeros años ocurre resolviendo problemas reales. Si esos problemas los resuelven los agentes, el camino se complica.
Pero hay un camino alternativo que me parece subestimado. En el escenario que hemos descrito, con miles de necesidades de pymes y nichos que antes no podían permitirse software, los desarrolladores con poca experiencia tienen la posibilidad de crear sus propias soluciones para clientes que antes no existían. El desarrollador de los centros de buceo no necesitó años de experiencia en una gran empresa para construir ese producto. Necesitó una formación sólida, capacidad de entender el problema del cliente, y herramientas que hacen accesible lo que antes requería un equipo. Es un camino de emprendimiento, no de carrera corporativa. No garantiza estabilidad ni crecimiento lineal. Pero es un camino donde se puede adquirir experiencia real.
El resultado final es una industria con una forma diferente. Las grandes empresas de software (integradores, producto, SaaS y departamentos de IT corporativos) se encogen. Mientras, lo que crece es el long tail, formado por miles de soluciones pequeñas para problemas específicos, creadas por personas que entienden tanto el problema como la tecnología necesaria para resolverlo.
La industria del software se encoge. La actividad de crear software se expande. Y la profesión de desarrollador se parece cada vez menos a escribir código y cada vez más a saber qué construir y asegurarse de que funciona como estaba previsto.
[i] Carlini, N. (2025). «Building a C Compiler with Claude.» Anthropic Engineering Blog. https://www.anthropic.com/engineering/building-c-compiler
[ii] Stack Overflow (2026). «Why Demand for Code Is Infinite: How AI Creates More Developer Jobs.» https://stackoverflow.blog/2026/02/09/why-demand-for-code-is-infinite-how-ai-creates-more-developer-jobs/
[iii] Anthropic (2025). «The Labor Market Impacts of AI: Measuring Exposure with Real-World Data.» https://www.anthropic.com/research/labor-market-impacts
[iv] Citadel Securities (2026). «The 2026 Global Intelligence Crisis.» https://www.citadelsecurities.com/news-and-insights/2026-global-intelligence-crisis/
[v] Morgan Stanley Research (2026). «How AI Coding Is Creating Jobs.» https://www.morganstanley.com/insights/articles/ai-software-development-industry-growth
[vi] Rachitsky, L. (2026). «State of the Product Job Market in Early 2026.» Lenny’s Newsletter. Datos no verificados directamente; fuente secundaria con amplia cobertura. https://www.lennysnewsletter.com/p/state-of-the-product-job-market-in-ee9
[vii] India TV News (2026). «Accenture Lays Off 11,000 Employees: Makes AI Adoption Mandatory.» https://www.indiatvnews.com/technology/news/accenture-lays-off-11000-employees-makes-ai-adoption-mandatory-2026-02-20-1031052
[viii] Unbox Future (2026). «AI’s Silent Layoff Wave: Indian IT Giants Cut US Jobs as Automation Accelerates.» https://www.unboxfuture.com/2026/04/ais-silent-layoff-wave-indian-it-giants_01924283433.html
[ix] Forbes (2026, 4 febrero). «$300 Billion Evaporated. The SaaS -Pocalypse Has Begun.«
https://www.forbes.com/sites/donmuir/2026/02/04/300-billion-evaporated-the-saaspocalypse-has-begun/
[x] Market Minute (2026). «The 2026 ‘SaaSpocalypse’: Why B2B Software Stocks Are Plunging 20%.» https://markets.financialcontent.com/stocks/article/marketminute-2026-3-24-the-2026-saaspocalypse-why-b2b-software-stocks-are-plunging-20
[xi] CIO (2026). «Demand for Junior Developers Softens as AI Takes Over.» https://www.cio.com/article/4062024/demand-for-junior-developers-softens-as-ai-takes-over.html
[xii] CNN Business (2026, 8 abril). «The Demise of Software Engineering Jobs Has Been Greatly Exaggerated.» https://www.cnn.com/2026/04/08/tech/ai-software-developer-jobs
joseluiscalvo.es 