Hay una escena que se repite cada vez más en los equipos de desarrollo. Un programador junior entrega un código que funciona. Se le pregunta qué hace una parte concreta. No sabe responder.
No porque sea descuidado. Sino porque no lo escribió él.
Un cambio que ya está ocurriendo
La incorporación de herramientas como ChatGPT, Copilot o Claude al flujo de trabajo diario de los desarrolladores no es una tendencia futura. Es una realidad presente en la mayoría de los equipos tecnológicos.
Y está generando un perfil nuevo: el programador que produce código funcional sin comprender completamente lo que produce.
Esto no es necesariamente negativo. Pero tampoco es inocuo.
Lo que la IA no puede hacer por ti
Trabajar con IA para generar código requiere tres capacidades que no se adquieren automáticamente y que no se pueden delegar al modelo.
La primera es saber qué necesitas y cómo lo necesitas.
La IA no conoce el contexto del negocio, las restricciones del sistema, los requisitos no escritos ni las decisiones arquitectónicas previas. Traducir todo eso a un prompt preciso requiere criterio técnico.
Sin ese criterio, el resultado puede funcionar en abstracto y fallar en producción.
La segunda es saber leer lo que la IA produce.
Un programa que compila no es necesariamente un programa correcto.
Detectar que la lógica no responde al problema real, que hay un caso no contemplado, que la solución es frágil o que el enfoque es incorrecto requiere capacidad de lectura crítica del código. No necesariamente de escritura, pero sí de comprensión.
La tercera es saber depurar cuando algo falla.
Y algo siempre falla.
La IA genera código con errores, con dependencias incorrectas y con asunciones sobre el entorno que no siempre se cumplen.
Sin capacidad de depuración, el ciclo de desarrollo se convierte en una secuencia de prompts esperando que el modelo corrija lo que el propio modelo introdujo.
La bola de nieve de complejidad
Y aquí aparece un problema que todavía no se está nombrando con suficiente claridad.
Cuando un desarrollador no entiende completamente el sistema que está construyendo, cada error tiende a resolverse añadiendo más código generado por IA:
- una nueva librería,
- una capa adicional,
- un parche temporal,
- una excepción específica para un caso que no debería existir.
El problema es que la IA casi siempre propone una siguiente solución. Pero no necesariamente una solución mejor.
Poco a poco, el sistema entra en una dinámica donde cada corrección incrementa la complejidad general.
El desarrollador deja de entender el flujo completo y llega un punto donde ya no sabe cómo simplificar, rehacer o volver atrás.
Preguntar a la IA cómo simplificar un sistema que la propia IA ayudó a complicar raramente produce el resultado esperado.
El resultado es software que funciona parcialmente, que nadie del equipo comprende del todo y que se vuelve progresivamente más difícil de mantener, depurar y evolucionar.
No es un fallo puntual. Es una deuda técnica que se acumula silenciosamente hasta que el coste de mantener el sistema supera el coste de rehacerlo.
El sistema parece avanzar rápido hasta que alguien necesita mantenerlo, modificarlo o entender por qué está fallando.
Este patrón no lo genera la IA. Lo genera la ausencia de criterio sobre cómo utilizarla.
El papel del mentoring en este contexto
El problema no es que los desarrolladores usen IA. El problema es que nadie les está enseñando a usarla bien.
Las empresas han dado acceso a las herramientas sin acompañar ese acceso de un proceso de formación sobre cómo integrarlas en el trabajo real.
El resultado es productividad aparente: código que se entrega rápido, que funciona en los casos básicos y que nadie del equipo entiende completamente.
Aquí es donde la figura del mentor técnico adquiere un valor que antes no tenía.
No para enseñar sintaxis, sino para enseñar a pensar antes de escribir el prompt, a leer críticamente el resultado, a depurar con método cuando algo no funciona y a reconocer cuándo la solución correcta no es añadir más código sino simplificar lo que ya existe.
El mentoring en este contexto no consiste únicamente en transferir conocimiento técnico.
Consiste en desarrollar criterio.
Y el criterio no lo genera la IA.
El nuevo perfil que sí tiene sentido
Lo que está cambiando no es que haya que saber programar para producir software. Lo que está cambiando es qué tipo de conocimiento resulta realmente importante.
Hoy es posible construir software funcional sin dominar completamente la sintaxis de un lenguaje.
Pero sigue siendo imprescindible entender la lógica de lo que se está construyendo, saber leer el resultado y tener criterio para evaluar si realmente resuelve el problema.
Es un perfil diferente al del programador clásico. Ni mejor ni peor. Simplemente distinto, y todavía sin un nombre claro dentro del sector.
Una figura necesaria que el mercado aún no ha formalizado
En Intercyd llevamos tiempo observando este patrón tanto en equipos propios como en los de clientes.
La brecha no está en el acceso a las herramientas. Está en la capacidad de utilizarlas con intención.
Los perfiles más valiosos no son necesariamente los que generan más código con IA.
Son los que saben exactamente qué pedirle, evalúan lo que reciben y se responsabilizan del resultado.
Ese perfil no surge solo. Se desarrolla con acompañamiento.
La industria lleva años hablando de la escasez de talento técnico.
Quizás el debate debería desplazarse: no se trata únicamente de encontrar más programadores, sino de formar mejor a quienes ya están aprendiendo a trabajar con las herramientas que van a definir cómo se desarrolla software a partir de ahora.
Conclusión
La IA ha cambiado lo que significa programar.
Pero no ha eliminado la necesidad de entender lo que se está construyendo.
El reto para las organizaciones no es decidir si sus equipos usan IA. Eso ya está decidido.
El reto es asegurarse de que la usan con criterio.
Y el criterio, todavía, lo desarrollan las personas.
Con tiempo, con práctica y, en muchos casos, con alguien al lado que sepa guiarlos.