La IA no viene por tu trabajo. Viene por tu ventaja

Déjame empezar sin anestesia: creo que estamos frente a uno de los cambios más profundos en la historia del software. Pero no por la razón que todos repiten.

La pregunta no es si la IA va a reemplazar developers. Esa pregunta es cómoda, casi tranquilizadora, porque te deja en el papel de víctima que solo espera el veredicto. La pregunta de verdad, la que incomoda, es otra: ¿qué pasa cuando construir software deja de ser una ventaja competitiva?

Y ahí empieza la conversación que realmente vale la pena tener.

Cuando escribir código deja de ser el valor

Durante décadas, el software tuvo una barrera de entrada clarísima: construirlo era difícil.

Una empresa tenía una idea. Para convertirla en código contrataba developers, armaba equipos, invertía meses y asumía riesgos técnicos. Nosotros éramos los únicos que podíamos transformar una intención en un producto funcional. Esa dificultad era nuestra muralla. Y vivíamos cómodos detrás de ella.

La IA está derribando esa muralla.

Hoy, una persona con suficiente contexto construye en horas lo que antes tomaba días o semanas. No con la misma calidad, seguridad ni mantenibilidad —ojo con eso— pero la barrera inicial está cayendo. Y cuando una habilidad se vuelve más accesible, su valor económico cambia. Siempre.

Piensa en lo que pasó con la fotografía digital, la edición de video o el diseño gráfico. Las profesiones no desaparecieron. Lo que cambió fue qué actividades eran escasas y por cuáles la gente estaba dispuesta a pagar.

El código se está convirtiendo en un medio de producción, no en el producto final de nuestro conocimiento. Eso no significa que programar deje de importar. Significa algo más sutil y más peligroso: que saber programar, por sí solo, podría dejar de diferenciarte.

¿Qué lugar ocupamos ahora en la cadena?

Mi hipótesis es que estamos pasando de ser constructores de software a ser responsables de conseguir resultados mediante software. Mira cómo evoluciona la posición, de abajo hacia arriba:

1. El ejecutor — "Dime qué construir y lo programo." Escribir código, implementar componentes, resolver tareas bien definidas. Cada vez más automatizable.
2. El ingeniero de sistemas — "Determino cómo debe funcionar y qué puede fallar." Arquitectura, integración, seguridad, observabilidad, rendimiento, fiabilidad. El código generado también necesita criterio técnico.
3. El diseñador de soluciones — "Identifico el problema correcto y diseño la solución." Entender el negocio, cuestionar requisitos, evaluar alternativas, coordinar a quienes (o lo que) ejecuta el trabajo.
4. El propietario del resultado — "Me hago responsable de que esto produzca valor." Conectar la tecnología con ingresos, costes, experiencia de usuario, riesgos y decisiones de producto.

No creo que todos tengamos que volvernos managers ni fundadores. Tampoco que estos niveles se reemplacen de forma lineal. Un ingeniero puede seguir programando gran parte del día y ser extremadamente valioso.

La diferencia está en dónde se apoya ese valor: cada vez menos en la cantidad de código que produces, y cada vez más en las decisiones que tomas, los problemas que evitas y los resultados que consigues.

Y aquí la parte inquietante: puede que hagan falta menos ingenieros

Seamos honestos, porque esto es lo que casi nadie te dice a la cara.

No hay ninguna garantía de que la productividad extra genere más puestos para developers. Y esto no es un pronóstico lejano: ya está pasando. Empresas que antes necesitaban diez personas para construir y mantener un producto hoy consiguen resultados parecidos con cuatro. Equipos que se achican, costes que se recortan, y cada vez más decisiones delegadas a la IA.

¿Significa eso el apocalipsis? No necesariamente. Esa misma empresa también puede construir productos que antes no eran viables económicamente, y abrir nuevas oportunidades. Las dos cosas pueden pasar a la vez. La consecuencia incómoda es esta: podríamos tener más software en el mundo y, al mismo tiempo, menos puestos dedicados a producirlo.

Eso cambia las reglas de la competencia profesional. Antes, una empresa justificaba un equipo grande porque necesitaba capacidad de ejecución. Si esa capacidad se multiplica, mantener el mismo tamaño deja de ser una decisión obvia.

La pregunta que vas a escuchar cada vez más no será "¿cuántos developers necesitamos?". Será:

"¿Qué resultados necesitamos y cuál es el equipo más pequeño capaz de conseguirlos?"

No sabemos hasta dónde llega este proceso ni a qué ritmo. Pero construir tu carrera asumiendo que las estructuras actuales van a seguir intactas me parece, hoy, un error.

Entonces, ¿en qué deberíamos convertirnos?

Yo apostaría por cinco capacidades. Y presta atención a cuál dejo para el final, porque creo que es la que casi nadie está mirando.

1. Criterio técnico profundo. No necesitas memorizar más sintaxis que un modelo —esa carrera ya la perdiste, y está bien—. Necesitas detectar cuándo una solución es incorrecta, frágil, insegura o demasiado cara. Revisar, verificar y depurar sistemas complejos puede valer mucho más que producir código rápido.

2. Pensamiento de producto. Entender por qué se construye algo. Qué problema resuelve, quién lo necesita, cómo se mide el éxito. La IA te ayuda a implementar una solución; no garantiza que estés resolviendo el problema correcto.

3. Orquestación de sistemas y agentes. Pasar de hacer cada tarea con tus manos a diseñar flujos donde los agentes investigan, programan, prueban y revisan. Tu trabajo será definir límites, validar resultados y saber cuándo intervenir.

4. Comunicación y toma de decisiones. Traducir problemas ambiguos en decisiones concretas. Defender una arquitectura, negociar prioridades, explicar riesgos, lograr que un equipo avance. Cuando la ejecución se acelera, esto se vuelve oro.

5. Propiedad y distribución. Saber construir es una cosa. Tener acceso a clientes, audiencia, distribución o participación en un producto es otra muy distinta. Si construir se abarata, encontrar a quién le sirve lo que construiste puede ser una ventaja todavía mayor.

La última me parece la más importante. Porque hay una diferencia enorme entre ser quien construye el producto de otra empresa y ser quien tiene la relación con los usuarios, decide qué construir y captura parte del valor. No todos tienen que emprender. Pero depender exclusivamente de que una empresa necesite tus horas de programación es una apuesta cada vez más arriesgada.

La trampa: perseguir la próxima moda

Y aquí cuidado, porque hay una salida falsa que se siente como la solución.

Pareciera que basta con aprender a usar agentes, dominar el prompting, conocer el último modelo o cambiar de editor cada tres meses. Eso ayuda. Pero hay una paradoja que tienes que ver: si todos aprendemos a usar las mismas herramientas, esa habilidad deja de diferenciarte y se vuelve un requisito básico.

Hoy saber usar IA te distingue. Mañana va a ser tan esperado como saber usar Git. Por eso separo las capacidades en dos grupos:

• Las que se deprecian: sintaxis específica, flujos manuales repetitivos, el conocimiento de herramientas que cambian cada trimestre.
• Las que se acumulan: criterio, experiencia en sistemas reales, comprensión de dominios, confianza, reputación, relaciones, conocimiento de los usuarios.

No es una división absoluta —los fundamentos técnicos van a seguir siendo útiles mucho tiempo—. Pero invierte más en lo que acumula valor con los años que en perseguir lo que está de moda este trimestre. Eso último es una cinta de correr: corres muchísimo para quedarte en el mismo lugar.

Y ahora, una pregunta más incómoda, casi filosófica

Durante mucho tiempo construimos parte de nuestra identidad alrededor de una habilidad difícil de adquirir. Resolvíamos problemas que otros no podían. Construíamos cosas que otros ni entendían cómo hacer. Esa habilidad nos dio autonomía, reconocimiento y, muchas veces, una buena posición económica.

¿Qué pasa cuando una parte importante de esa capacidad deja de ser exclusiva?

Creo que ahí aparecen dos crisis distintas, y conviene no confundirlas:

• La económica: ¿cómo gano dinero en un mercado que necesita menos horas de trabajo humano?
• La personal: ¿quién soy cuando una habilidad que me definía deja de ser excepcional?

Y sospecho que la segunda es la más difícil de resolver. Porque si tu valor depende de ser mejor que una máquina escribiendo código, estás compitiendo en un terreno que se mueve bajo tus pies todos los días.

Pero si tu identidad se apoya en entender problemas, construir cosas útiles, aprender, colaborar y asumir responsabilidad, entonces la programación sigue siendo una herramienta extraordinaria. Quizá más poderosa que antes.

No tenemos que defender el valor de escribir código. Tenemos que descubrir qué queremos hacer con la capacidad de construir casi cualquier cosa.

Mi apuesta, si tienes experiencia en ingeniería

No abandonaría la ingeniería para convertirme en un supuesto "experto en IA". Haría exactamente lo contrario: usaría la IA para ampliar el alcance de mi experiencia.

Intentaría volverme alguien capaz de:

• Diseñar un sistema completo y explicar por qué debe existir.
• Dirigir agentes para acelerar su construcción sin perder el control.
• Evaluar calidad, seguridad, costes y fiabilidad.
• Entender el negocio lo suficiente para priorizar bien.
• Lanzar productos y comprobar si alguien de verdad los necesita.
• Construir activos propios: productos, propiedad intelectual, reputación, distribución.

La combinación es poderosa porque une capacidad técnica, criterio y autonomía. Y no, no todos necesitan llegar a director de ingeniería, arquitecto empresarial o fundador. Puede seguir existiendo una carrera técnica excelente para quien disfruta resolviendo problemas complejos. Lo que sí hay que cuestionar es si las rutas tradicionales van a seguir recompensando las mismas habilidades de la misma manera.

Mi objetivo no sería ser el developer que produce más código. Sería ser alguien capaz de convertir una oportunidad ambigua en un resultado real, con menos recursos y menos dependencia de otros. No porque quiera que desaparezcan los equipos, sino porque quiero tener opciones cuando cambie la forma de trabajar.

Y quiero cerrar devolviéndote la pelota, porque esta conversación no se resuelve leyendo, se resuelve pensando. De todo este futuro, ¿qué es lo que de verdad te preocupa?

• ¿Que haya menos empleos y bajen los salarios?
• ¿Que tu experiencia y tu conocimiento pierdan valor?
• ¿Que la riqueza se concentre en pocas empresas y personas?
• ¿O que programar deje de darte el sentido y la satisfacción de antes?

No es lo mismo responder una que otra, porque cada una te lleva a una estrategia distinta. Yo ya te dije dónde estoy parado. Ahora te toca a ti. Cuéntame en los comentarios: sigamos la conversación por ahí.