# La IA siempre necesitará humanos detrás. Y cuanto más sepas, más valioso serás

Hay una frase que lleva meses circulando por redes, podcasts y cafeterías de *startups* como si fuera un mantra de iluminados: **"La IA hoy todavía necesita programadores, pero en unos meses o años eso habrá desaparecido."**

Y yo me pregunto... ¿de verdad? ¿Estamos hablando de tecnología o de esoterismo?

Vamos a hablar con propiedad. Sin humo. Con los datos encima de la mesa.

## Los Transformers tienen nueve años. Y siguen siendo los mismos.

En 2017, un equipo de Google Brain publicó un *paper* que cambió todo: **"Attention Is All You Need"**. Ahí nacieron los Transformers, la arquitectura que está debajo de prácticamente todo lo que hoy llamamos IA generativa en cuanto a modelos de lenguaje: GPT, Claude, Gemini, GLM, DeepSeek...

Nueve años después, la arquitectura base sigue siendo la misma. No es una opinión, es un hecho constatable. Se ha escalado brutalmente —más parámetros, más datos, más VRAM, más dinero— y se ha rodeado de capas y capas de herramientas, guardrails, pipelines de agentes y técnicas de entrenamiento avanzadas. Pero el núcleo, el mecanismo de atención que hace funcionar a un LLM, no ha cambiado en su esencia.

¿Y eso qué significa en la práctica? Que los problemas de base tampoco han desaparecido. Solo se han maquillado mejor.

## Cómo "sabe" cosas un LLM. O cómo no las sabe.

Aquí viene la parte que nadie explica porque suena demasiado a clase de matemáticas y la gente desconecta. Pero es la clave de todo.

Un LLM no almacena información como lo haría una base de datos. No tiene una tabla donde ponga "la Tierra es redonda: TRUE". Lo que tiene es un espacio vectorial de altísima dimensión —piensa en un mapa, pero con miles de dimensiones en lugar de dos— donde cada palabra, concepto o *token* ocupa una posición. Y lo que define esa posición es la proximidad a otros conceptos según cómo aparecían relacionados en los datos de entrenamiento.

Eso se llama *embedding*. Y funciona así: si durante el entrenamiento el modelo lee millones de textos donde la palabra "rey" aparece cerca de "corona", "trono" y "palacio", el vector de "rey" en ese espacio quedará cerca de todos esos conceptos. El modelo no "entiende" qué es un rey. Sabe que esa palabra vive en ese vecindario.

Ahora aplica lo mismo a algo más delicado. Si un modelo se entrena con una cantidad significativa de textos donde "tierra" aparece junto a "plana", "disco", "bordes" o "conspiración"... el vector de "tierra" adquiere una proximidad estadística con esos conceptos. El modelo no tiene criterio para saber que eso es falso. Simplemente reproduce la distribución probabilística de lo que ha aprendido.

Un LLM es, en esencia, un sistema que predice cuál es la siguiente palabra más probable dado un contexto. **No razona. No evalúa. No juzga. Calcula probabilidades.** Y esas probabilidades son el reflejo directo de aquello con lo que fue alimentado.

![Inyectando prompts a un LLM...](https://image.service.eu.axinom.net/transform/72a20w8irkd812lj5hqycl0ft-3dl5y1dj0seejmhh8wynzscv2/GGKGYXwqT64KbSTzJWQ8pq.jpg)

## RL, RLVR y el arte de afinar sin reentrenar

Ahora bien, seamos justos. La industria no se ha cruzado de brazos mirando este problema. Las técnicas de **Reinforcement Learning from Human Feedback (RLHF)** y su evolución, el **RLVR (Reinforcement Learning with Verifiable Rewards)**, han supuesto un avance real y significativo en cómo se mejoran los modelos después del preentrenamiento. La idea es elegante: en lugar de reentrenar el modelo entero —lo cual es absurdamente caro en tiempo y dinero— se le da *feedback* sobre sus propias respuestas. Respuestas que humanos evalúan o que se contrastan con resultados verificables, generan una señal de recompensa que guía al modelo hacia comportamientos más deseables.

El RLVR va un paso más allá: en lugar de depender de evaluadores humanos para todo, usa recompensas objetivas cuando el resultado es verificable. ¿La respuesta matemática es correcta? Premio. ¿El código compila y pasa los tests? Premio. Esto permite afinar el modelo de forma mucho más escalable en dominios donde hay verdad objetiva. Si aceptamos como verdad objetivo que un código que compila y pasa *tests* lo hace ser correcto. **Spoiler: NO.**

Y aquí hay algo importante que entender: estas técnicas permiten crear nuevas versiones del modelo sin reentrenarlo desde cero. Es como un *fine-tuning* continuo y dirigido que mejora comportamientos concretos sin tocar los fundamentos. Eso es un avance real, no humo. Pero el problema del criterio no desaparece. Solo se desplaza.

## ¿Quién decide qué es correcto?

Si para entrenar un modelo con RLHF necesitas humanos que evalúen respuestas... ¿qué humanos? ¿Con qué criterio? ¿Con qué nivel de conocimiento del dominio?

Pongamos un ejemplo concreto. Para mí, usar TCA (The Composable Architecture) en una app SwiftUI es añadir una capa de complejidad innecesaria que va en contra del propio diseño de los *frameworks* de Apple. Una aberración. Para otros, es la solución arquitectónica más robusta que existe. ¿Cuál de las dos respuestas refuerza el modelo con RLHF? ¿La más votada? ¿La más extendida en GitHub? ¿La de quien tiene más seguidores en X? Porque ambos tenemos razón, ya que hemos encontrado la solución óptima a nuestro problema.

O más grave aún: ¿qué ocurre con la seguridad? Un LLM puede sugerirte código que funciona perfectamente pero que tiene una vulnerabilidad de inyección SQL o que expone datos sensibles. ¿Cómo sabe el modelo que eso es un problema si nadie le ha dicho explícitamente —con criterio técnico riguroso— que eso está mal? Y si alguien se lo ha dicho... ¿con qué criterio lo hizo ese alguien?

El círculo no se cierra solo. Los *guardrails* —capas de filtrado y restricción que se añaden sobre el modelo— son exactamente eso: **parches**. Correcciones externas que intentan compensar lo que el modelo, por su propia naturaleza, no puede resolver internamente. Son necesarios y útiles, pero no son inteligencia. Son reglas. Y las reglas las escriben personas. Y las personas tienen distintos conocimientos, criterios, opiniones y sesgos.

![Enseñando Spec-Driven Development](https://image.service.eu.axinom.net/transform/72a20w8irkd812lj5hqycl0ft-3dl5y1dj0seejmhh8wynzscv2/4fN2ntL1Q1FtopAnzyFTrU.jpg)

## Software no es solo código. Nunca lo ha sido.

Hay otro argumento en la narrativa del "pronto no harán falta programadores" que me parece directamente de ciencia ficción: la idea de que una IA puede construir software de principio a fin con solo decirle qué quieres.

¿Qué quieres? Ahí está el problema. Porque **"hazme una app de gestión de tareas" no es una especificación**. Es el punto de partida de una conversación que dura semanas con el cliente, el equipo de diseño, el equipo de negocio, de *marketing*...

¿Qué flujo de usuario tiene? ¿Qué modelo de datos subyace? ¿Se sincroniza con un *backend*? ¿Con cuál? ¿Qué normativa de privacidad aplica? ¿Cómo se monetiza? ¿Qué metadatos necesita para el App Store? ¿Cuál es la propuesta de valor diferencial frente a las 1.500 apps que se publican al día? ¿Y su accesibilidad? Porque el diseño depende de esta y mucho.

Y cuando todo eso está definido y el código existe... ¿quién lo audita? ¿Quién valida que no hay un *data race* en la concurrencia si no usamos Swift 6 por defecto? ¿Quién revisa que los datos del usuario están cifrados correctamente? ¿Quién decide qué arquitectura usar o cómo va a escalar cuando la app pase de 100 a 100.000 usuarios?

El software es diseño, es estrategia, es arquitectura, es criterio técnico, es comprensión del negocio y es responsabilidad legal. **El código es solo la forma en que todo eso toma cuerpo.** Y esa comprensión no se delega en un sistema probabilístico. Por eso la evolución de la programación se llama *Spec Driven Development*... desarrollo conducido por especificaciones. Más claro, agua.

## El único hecho constatable

El sector ha cambiado para siempre. Verdad. **La IA ha eliminado la capa más mecánica del desarrollo:** el código *boilerplate*, las búsquedas repetitivas en la documentación, el *scaffolding* inicial de un proyecto. Ha acelerado procesos que antes llevaban horas. Ha democratizado el acceso a ciertos niveles de implementación.

Y en ese nuevo mundo, la distinción tradicional entre junior y senior está evolucionando hacia algo diferente: **analista frente a arquitecto**. Quien sabe qué pedirle a la IA, qué revisar en su salida, qué validar, qué descartar y por qué. Quien tiene el criterio técnico para dirigir la herramienta y no al revés.

**La IA amplifica lo que ya sabes. Si sabes poco, amplifica poco. Si sabes mucho, te convierte en algo muy difícil de sustituir.**

Por eso el camino no es aprender a usar ChatGPT: el camino en desarrollo Apple pasa inexorablemente por entender Swift 6, concurrencia estricta, arquitectura de datos, seguridad, diseño de APIs y el ecosistema Apple en profundidad. Con esa base, la IA es un multiplicador extraordinario. Sin ella, es una caja negra que genera código que no sabes si funciona bien... hasta que falla en producción. Deuda técnica que explotará... dadlo por hecho.

![Piensa](https://image.service.eu.axinom.net/transform/72a20w8irkd812lj5hqycl0ft-3dl5y1dj0seejmhh8wynzscv2/DdP5tyxtLa7Rpu2u7B7TeN.jpg)

## Conclusión: no dejes que el humo te ciegue

Los *transformers* llevan nueve años entre nosotros y su naturaleza fundamental no ha cambiado: son sistemas probabilísticos que predicen texto basándose en proximidad estadística de conceptos en un espacio vectorial. Las mejoras en entrenamiento —RLHF, RLVR, *fine-tuning* dirigido— son avances reales y significativos. Pero no resuelven el problema del criterio, porque **el criterio siempre lo aporta una persona**.

Lo que cambia con la IA no es que los programadores desaparezcan. Lo que cambia es el nivel de conocimiento que se les exige para ser relevantes. Y eso, si lo piensas bien, es exactamente lo opuesto a lo que dicen los titulares.

Así que sigue aprendiendo. Con profundidad, con criterio, leyendo el código como quien lee en su propio idioma. Porque cuando la capa superficial del desarrollo la gestione la IA, lo que quede será exactamente lo más difícil y lo más humano: **pensar**.