Cuando las respuestas llegan antes que el criterio
La inteligencia artificial es una realidad ineludible. Aunque comprendo la intensidad de los debates que suscita en nuestra industria y en muchas otras, mi preocupación a día de hoy no está ahí. Considero la IA una herramienta extraordinariamente poderosa que ya está transformando nuestra profesión y que seguirá haciéndolo en el futuro.
Partiendo de esa base, no me siento capacitado para anticipar cómo será ese futuro. Sí tengo bastante clara, en cambio, la importancia de prepararnos para él en el presente.
En ese sentido, mi postura no es nueva. Siempre he creído que la formación continua es la única manera de crecer profesionalmente y de ofrecer mejores soluciones a las compañías que confían en nosotros. Lo que ha cambiado no es esa necesidad, sino el contexto.
Hoy el acceso a respuestas técnicas es inmediato, relativamente barato y, en muchos casos, suficiente para avanzar. Podemos generar código, explorar alternativas y llegar a soluciones en una fracción del tiempo que necesitábamos hace unos años.
El problema es que disponer de una respuesta no implica comprenderla.
El criterio para evaluar si una solución es la más adecuada, si es correcta, incompleta o excesivamente compleja, no aparece de forma automática junto con ella. Sigue siendo el resultado de la experiencia, del análisis comparativo, de una formación sólida y, muy a menudo, de haber cometido y analizado errores previos.
La experiencia no se construye al mismo ritmo que el acceso a la información.
Esta diferencia introduce una situación nueva. Cada vez es más fácil producir resultados con una apariencia razonable, incluso cuando todavía no se dispone de las referencias necesarias para evaluarlos. Los errores no solo siguen existiendo. Pueden aparecer antes y con una apariencia de acierto que los hace más difíciles de detectar.
Soy defensor del vibe coding como herramienta para explorar, prototipar y avanzar con rapidez. Lo utilizo y creo que abre posibilidades extraordinarias. Pero precisamente por eso conviene separar dos capacidades distintas: producir una solución y decidir si esa solución merece formar parte de un sistema real. Producir más código no significa decidir mejor.
Aunque una solución venga sugerida por una IA, la decisión de aplicarla y las consecuencias que se derivan siguen siendo humanas. La responsabilidad técnica no desaparece por apoyarse en herramientas más avanzadas.
Ante esta nueva realidad, ¿qué esperamos que haga alguien con todas esas respuestas cuando todavía no sabe formular las preguntas correctas?
Aprender a decidir sigue necesitando tiempo
En la ingeniería del software rara vez decidimos con toda la información. Tomamos decisiones bajo incertidumbre, con restricciones de tiempo, conocimiento incompleto y consecuencias que muchas veces no se hacen visibles hasta meses después.
Aprender a moverse en ese contexto no consiste simplemente en conocer más tecnologías o acumular respuestas.
Una decisión técnica implica analizar alternativas, entender qué coste tiene cada opción, qué riesgos introduce y cómo puede afectar al sistema y al negocio a medio y largo plazo. También implica aceptar que la solución técnicamente más sofisticada no siempre es la más adecuada.
Ese criterio no aparece de forma espontánea. En mayor o menor medida, todos hemos visto sistemas que fallan al aplicar una solución correcta en el contexto equivocado. Una arquitectura válida para un problema puede ser una carga innecesaria para otro. Una abstracción útil puede introducir complejidad sin aportar valor. Una intervención técnicamente impecable puede resolver algo que nunca necesitó ser resuelto.
Desarrollar criterio también es aprender a reconocer cuándo una intervención aporta valor y cuándo es mejor no actuar.
Para llegar ahí hace falta enfrentarse a problemas reales, equivocarse y analizar las consecuencias de las decisiones. Es un proceso lento, pero imprescindible bajo mi punto de vista.
Además, las mejores decisiones suelen pasar desapercibidas. Su éxito consiste muchas veces en evitar problemas que nunca llegan a materializarse. Eso hace que el valor del criterio no siempre sea evidente ni fácil de medir.
Una persona puede aprender una tecnología en semanas. Puede utilizar una herramienta nueva en días. Puede obtener una solución en segundos. Aprender a decidir qué hacer con ella requiere otro ritmo.
Y esa diferencia importa especialmente cuando hablamos de quienes están empezando.
El problema no es el talento junior, sino nuestras expectativas
Un perfil junior, aunque utilice la IA de forma intensiva, no es un perfil senior ni puede desempeñar ese rol con las mismas garantías.
Puede producir más. Puede avanzar más rápido. Puede enfrentarse a problemas que hace pocos años habrían requerido mucho más tiempo. Pero el acceso a herramientas más potentes no convierte la falta de experiencia en criterio ni sustituye el juicio técnico que se construye con los años.
Los perfiles junior siempre han sido capaces de producir resultados. La diferencia es que ahora pueden producir mucho más y hacerlo con una apariencia de madurez técnica difícil de distinguir desde fuera.
Hasta ahora no esperábamos que una persona que empezaba validase por sí sola todas las implicaciones de lo que producía. Había una responsabilidad compartida y, al menos en teoría, un proceso de revisión y aprendizaje. Dar acceso a herramientas más potentes y trasladar al mismo tiempo toda la responsabilidad hacia quien las utiliza no supone haber resuelto el problema. Solo hemos aumentado la capacidad de producción.
A esto se suma otra situación que merece una reflexión aparte. En muchos casos estamos introduciendo niveles de complejidad que presuponen una base que todavía no existe. Se enseña a trabajar con estructuras y enfoques avanzados antes de haber consolidado habilidades básicas de diseño, lectura de código o razonamiento sencillo sobre el problema.
Aprender a manejar soluciones complejas puede dar sensación de madurez técnica, pero sin una base sólida esa complejidad no ordena, sino que confunde. Se aprende el cómo antes que el porqué, interiorizando formas sin entender realmente qué problema resuelven.
Es posible construir una arquitectura compleja sin comprender las fuerzas que justifican sus decisiones. Aplicar patrones sin saber qué coste introducen. Dividir un sistema en servicios sin haber aprendido antes dónde están sus límites naturales.
El resultado no son necesariamente profesionales más preparados. En algunos casos son profesionales dependientes de esquemas que no dominan y que necesitan reproducir porque todavía no tienen referencias suficientes para decidir cuándo dejarlos atrás.
Sin esas referencias, distinguir entre una buena solución y una que solo lo parece es difícil. A menudo lo es incluso para perfiles con mucha experiencia.
Por lo tanto, el problema no reside en la capacidad del talento junior, sino en cómo estamos diseñando su aprendizaje y en las expectativas que construimos sobre ellos. No podemos entregar herramientas que multiplican su capacidad de producir y asumir que también hemos multiplicado, en la misma proporción, su capacidad para evaluar las consecuencias.
Exigir autonomía total sin haber construido antes las condiciones para alcanzarla no es una muestra de confianza. Es desplazar hacia abajo una responsabilidad que corresponde al equipo y a quienes tienen más experiencia.
Y en un contexto en el que producir parece cada vez más sencillo, esa responsabilidad puede ser más fácil de ignorar.
Formar también es diseñar el equipo
La formación no debería ser un complemento ni una iniciativa que aparece cuando sobra tiempo. Es una parte estructural del diseño de los equipos técnicos.
La productividad tampoco es solo una cuestión individual. Es el resultado de cómo un equipo comparte conocimiento, revisa decisiones y crea espacios para aprender. Un equipo puede parecer muy eficiente cuando cada persona avanza de forma autónoma, pero esa autonomía tiene poco valor si depende de que nadie se equivoque en decisiones que todavía no está preparado para tomar.
Diseñar equipos sostenibles implica aceptar que el aprendizaje forma parte del trabajo.
Revisar una decisión, explicar por qué se descarta una solución o acompañar a alguien en un razonamiento complejo no es una interrupción de la productividad. Es parte de ella. El tiempo dedicado a construir criterio hoy reduce la dependencia, los errores evitables y la necesidad de corregir mañana decisiones que ya se han propagado por el sistema.
Cuando la formación desaparece de la agenda, no desaparece la necesidad de aprender. Lo que ocurre es que ese aprendizaje se produce de forma desordenada y, normalmente, a través de errores más caros.
En un contexto como el actual, además, formar para una tecnología concreta ofrece cada vez menos garantías. No existe un stack blindado ni una herramienta capaz de asegurar la relevancia profesional a largo plazo.
No sé qué nos deparará el futuro de nuestra profesión. Se cuestionan los roles, las responsabilidades y el propio valor del trabajo técnico. El ruido sobre la sustitución, la automatización total y la desaparición de perfiles es constante, y es comprensible que ese discurso genere incertidumbre, especialmente entre quienes están empezando. Pero la incertidumbre no se combate con recetas predefinidas.
Aunque cambie el cómo hacemos las cosas, siguen siendo necesarias la capacidad de análisis, el criterio para decidir y la responsabilidad sobre las consecuencias. Formar no debería consistir en preparar a alguien para una herramienta concreta, sino en darle una base desde la que pueda moverse cuando esa herramienta deje de ser la importante.
Quien desarrolla esa base puede redefinir su rol. Quien solo aprende a ejecutar queda mucho más expuesto al siguiente cambio.
Por eso, formar no consiste únicamente en transmitir conocimiento. Consiste en acompañar en la toma de decisiones, construir referencias internas y compartir responsabilidad mientras esa base se consolida.
Cuando las respuestas llegan solas, el valor ya no está en encontrarlas, sino en saber qué hacer con ellas. Si queremos profesionales capaces de adaptarse a un futuro incierto, no podemos dejarlos solos en el presente.