El cursor parpadea sobre una pantalla vacía. Un desarrollador junior escribe un requisito, lo borra, añade una excepción y señala al agente de programación la parte del repositorio que no debe romper. Pocos minutos después hay cambios en varios archivos. Ejecuta el resultado y pide a otro modelo que revise el diff.
Ya no es una escena extraña. Muchos perfiles junior pasan menos tiempo tecleando código y más tiempo decidiendo qué pedir, leyendo cambios generados y buscando el punto en el que una respuesta casi correcta deja de serlo. La velocidad es real. También lo es la inquietud: si una herramienta produce en minutos lo que antes ocupaba un día, ¿en qué debe hacerse bueno quien empieza?
“Aprende los fundamentos” sigue siendo un buen consejo, pero se queda corto. “Aprende a usar las herramientas” es aún más débil. La salida no está en elegir uno de los dos bandos, sino en conservar los fundamentos y cambiar el orden de aprendizaje y la forma de demostrar que se dominan.
Escribir menos código no elimina las decisiones
La ruta tradicional de un junior se apoyaba en la repetición: crear un endpoint pequeño, corregir un bug, preparar una migración y entender el framework a fuerza de tocarlo. Ahora la IA puede entregar un primer borrador completo antes de que el desarrollador haya construido un modelo mental sólido.
Ahí aparece el hueco. Que el código funcione no significa que se entienda. El camino feliz puede pasar mientras un pago se duplica, un token termina en los logs o una petición repetida deja el estado incoherente.
La encuesta de Stack Overflow de 2025 refleja esa tensión. Más participantes desconfiaban de la precisión de las respuestas de IA que quienes confiaban en ellas. La frustración más habitual era recibir algo casi correcto, pero no del todo. Un 45% dijo que depurar código generado por IA podía llevar más tiempo.
Eso no convierte a la IA en una mala herramienta. Significa que la velocidad de generación y la responsabilidad de ingeniería están en lugares distintos. El riesgo para un junior no es usar un agente, sino integrar un cambio que ya no puede explicar cuando la conversación termina.
Los fundamentos tienen ahora un trabajo más concreto
Estructuras de datos, redes, bases de datos y sistemas operativos mantienen su valor. Ha cambiado la razón por la que se consultan.
Si un agente añade una caché, una revisión sensata debería responder al menos a estas preguntas:
- ¿El sistema sigue siendo correcto si la caché está vacía?
- ¿Qué evento invalida una entrada?
- ¿Puede volver a la fuente de verdad durante una caída?
No son trucos de prompting. Surgen de entender el estado y los fallos. Un junior no necesita memorizar todas las cabeceras HTTP, pero sí seguir el recorrido de las credenciales. No hace falta escribir cada consulta SQL a mano, aunque conviene reconocer un plan de ejecución que no va a resistir datos reales.
Los fundamentos dejan de parecer un examen de acceso y se convierten en instrumentos para detectar errores que suenan convincentes.
La responsabilidad no empieza al llegar a senior
En la misma encuesta, la mayoría no tenía previsto delegar en la IA el despliegue y la monitorización, ni tampoco la planificación de proyectos. En esas fases ya no basta con preguntar si algo funciona. Hay que saber quién lo detendrá, lo explicará y lo recuperará cuando falle.
Un junior no tiene que diseñar la arquitectura de toda una empresa. Sí debería poder explicar los límites de la función pequeña que mantiene: de dónde llega la entrada, qué estado cambia, qué queda después de un fallo y quién puede repetir la operación con seguridad.
Ese criterio también mejora un portfolio.
| Evidencia que merece guardarse | Qué demuestra |
|---|---|
| Primer requisito y motivo del cambio | Capacidad para acotar el problema |
| Propuestas de IA descartadas | Criterio técnico |
| Un fallo reproducible | Disciplina de depuración |
| Pruebas y logs de operación | Hábitos de verificación |
| Plan de reversión o recuperación | Responsabilidad ante el fallo |
No es una disculpa por haber usado IA. Es la prueba de que la decisión siguió teniendo dueño.
Sentirse más rápido no siempre significa terminar antes
Las herramientas de IA parecen rápidas porque el primer resultado aparece enseguida. El trabajo total puede contar otra historia.
METR estudió a colaboradores experimentados de proyectos open source trabajando en repositorios que ya conocían, con herramientas de principios de 2025. Esperaban ahorrar tiempo; la medición mostró que tardaron un 19% más de media.
No es una cifra que pueda trasladarse sin más a juniors o a modelos actuales. El estudio tenía un grupo, repositorios y herramientas concretos. Su advertencia más limitada sí es útil: revisar, reparar y revertir también consume tiempo. Medir líneas generadas oculta precisamente ese coste.
Un plan de doce semanas con resultados comprobables
Basta con un servicio pequeño: autenticación, datos persistentes, una API externa y una pantalla básica de administración. No se trata de lanzar una empresa, sino de responsabilizarse de un sistema acotado desde la idea hasta la operación.
Semanas 1–3: construir con IA y leer cada cambio. Escribe una frase sobre la función de cada archivo modificado. No integres un cambio que no puedas explicar.
Semanas 4–6: provocar fallos. Añade latencia, entradas incorrectas, peticiones duplicadas y credenciales caducadas. Acota la causa con logs antes de pedir al agente una solución.
Semanas 7–9: dejar huellas de operación. Registra las peticiones importantes, convierte cada fallo en una prueba de regresión y documenta cómo volver a la última versión estable.
Semanas 10–12: entregar el servicio. Otra persona debería poder arrancarlo con el README, entender la decisión principal y ver qué limitación queda abierta. Si no hay compañero disponible, déjalo un día y prueba con tu yo del futuro.
Cuatro líneas por semana son suficientes:
- El problema que se intentaba resolver
- Qué propuso el agente y qué se descartó
- Un fallo observado de verdad
- Qué revisar primero la próxima vez
Ese registro sobrevivirá al próximo nombre de modelo.
También conviene apagar el agente por momentos
No hace falta volver a construirlo todo a mano. Un periodo corto sin IA ayuda a localizar el límite del propio entendimiento. Dibuja el flujo de datos antes de abrir el chat. Escribe los casos de prueba antes de pedir código. Explica el fallo con tus palabras antes de solicitar un diagnóstico.
Cuando la IA esté disponible, úsala sin complejos: para eliminar repetición, encontrar el punto de entrada de una librería desconocida y ampliar la lista de pruebas. La separación útil no es IA frente a no IA, sino trabajo delegado frente a trabajo verificado.
El espacio que sigue abierto para los juniors
Aunque la IA escriba código, alguien debe definir el problema, detectar la frustración del usuario, frenar un despliegue peligroso y explicar por qué se eligió una opción. Esas responsabilidades no están reservadas a perfiles senior.
Un junior no necesita competir con un agente en velocidad de escritura. Necesita aprender a notar cuándo un resultado huele mal, comprobar la evidencia y llevar una función pequeña hasta un estado que otra persona pueda operar. Quien viene del backend puede colocar la IA sobre los sistemas que ya entiende. Quien trabaja en frontend puede diseñar interfaces que hagan visible la incertidumbre en vez de ocultarla.
Los nombres de las herramientas y de los puestos seguirán cambiando. Acotar un problema, comprender su contexto y responder por el resultado es mucho más difícil de automatizar. Ahí merece la pena invertir.
