Incorporar a ingenieros júnior con IA: un plan de aprendizaje

La incorporación de ingenieros júnior que trabajan con IA necesita práctica supervisada, reglas claras sobre las herramientas y comprobaciones que permitan distinguir el trabajo terminado de lo aprendido. Designa a un evaluador sénior, reserva tiempo para esa labor y amplía las responsabilidades cuando la persona pueda explicar, probar y volver a abordar tareas relacionadas. Concreta ese compromiso de formación antes de abrir la vacante.

Una startup puede pagar un salario júnior y carecer de capacidad para formar a esa persona. El problema aparece cuando todo el equipo sénior está ocupado, el asistente sigue generando cambios que parecen razonables y nadie tiene tiempo para comprobar qué entiende el nuevo compañero. Un buen plan de aprendizaje hace visible ese trabajo.

¿Qué anuncia el programa PRAISE de CMU y Microsoft?

PRAISE es un programa de desarrollo recién anunciado cuyos resultados aún están por comprobar. Su anuncio invita a revisar cómo ayudará tu equipo a los ingenieros que comienzan su carrera a aprender mientras utilizan IA.

El 15 de octubre, Carnegie Mellon University anunció una colaboración con Microsoft para formar a ingenieros de software al inicio de su carrera. Los empleados de Microsoft seleccionados, que están al inicio de su carrera, ya reciben orientación de ingenieros sénior y pueden cursar formación de CMU. La explicación de Microsoft describe una tutoría inspirada en la enfermería: profesionales con experiencia ayudan a sus nuevos compañeros a desarrollarse mediante trabajo supervisado.

Ambas explicaciones proceden de organizaciones que participan en el programa. Describen un enfoque y sus aspiraciones. No aportan resultados comparativos de aprendizaje, beneficios de productividad, resultados de promoción profesional ni una proporción de mentores contrastada. Del anuncio no se puede deducir que este modelo funcione ni que una startup necesite colaborar con una universidad para formar a ingenieros júnior.

Puedes aprovecharlo para plantear una pregunta concreta de gestión: ¿quién ayudará a un nuevo ingeniero a convertir un resultado obtenido con IA en algo que comprenda? Los cursos, el acceso a los repositorios y un asistente útil aportan parte del entorno. Sigue haciendo falta alguien que observe las decisiones, corrija conceptos erróneos y valore cuándo puede cambiar el apoyo.

El plan que sigue es una propuesta de trabajo para un equipo pequeño. Las investigaciones citadas orientan las preguntas que plantea. Ningún estudio citado evalúa este ciclo de aprendizaje completo ni demuestra que genere conocimientos de ingeniería duraderos.

Distingue el resultado obtenido con IA del aprendizaje

Un cambio terminado aporta datos sobre lo que se ha entregado en unas condiciones concretas. Para entender qué se ha aprendido, también hay que comprobar qué puede explicar la persona y cómo resuelve después tareas relacionadas.

En el estudio de Shen y Tamkin sobre la ayuda de la IA y la adquisición de competencias, 52 ingenieros, en su mayoría júnior, trabajaron con Trio, una biblioteca de Python que no conocían. La explicación de la investigación de Anthropic recoge unas puntuaciones medias en el cuestionario inmediato del 50 % entre quienes disponían de ayuda de IA y del 67 % entre quienes no la tenían. Son 17 puntos porcentuales de diferencia. No hubo una diferencia significativa en la rapidez con la que completaron la tarea.

Mantén presente el contexto del resultado. Fue un ejercicio breve y de alcance reducido, con un asistente en un panel lateral. No puso a prueba un flujo moderno de programación autónoma, un aprendizaje prolongado ni si la mentoría humana cambia el resultado. El cuestionario inmediato no permite demostrar una pérdida duradera de competencias. Las diferencias observadas entre las formas de utilizar el asistente tampoco prueban que un hábito concreto al formular instrucciones mejore el aprendizaje.

También hay datos que cuestionan la afirmación general de que la IA impide aprender en el trabajo. El artículo de 2025 de QJE Generative AI at Work estudió una implantación gradual entre 5 172 agentes de atención al cliente. Señala un aumento medio del 15 % en las consultas resueltas por hora. La mejora del rendimiento se mantuvo durante las interrupciones de la herramienta, una observación compatible con el aprendizaje.

Ese estudio trata de atención al cliente en una sola empresa. No determina los efectos en ingenieros de software júnior ni valida un plan de aprendizaje. En conjunto, estas fuentes justifican prestar atención a la tarea, la herramienta, el apoyo y la comprobación de lo aprendido. No justifican suponer que todos los ingenieros que usan IA aprenden, ni que ninguno pueda hacerlo.

En tu equipo, registra por separado lo entregado y lo comprendido. «El cambio superó la revisión» y «la persona explicó el fallo y resolvió un caso relacionado» responden a preguntas distintas. Ambas tienen cabida en una conversación útil sobre su desarrollo.

Reserva tiempo sénior antes de contratar a un ingeniero júnior

Un puesto júnior necesita un evaluador designado que tenga tiempo para enseñar y comentar el trabajo. Incluye ese compromiso junto a las expectativas de entrega del puesto para que el equipo decida si puede asumir ambas cosas.

Redacta un plan breve con el componente en el que trabajará inicialmente la persona, las competencias que esperas al incorporarse y las que te comprometes a enseñar. Designa a un profesional sénior para las revisiones habituales y a un sustituto para sus ausencias. Especifica las herramientas de IA disponibles, la información que pueden recibir y los cambios que podrá intentar con supervisión.

Después, reserva tiempo en el calendario y reduce otro compromiso. «Pregunta cuando te atasques» ayuda poco si la única persona que puede responder está atendiendo una incidencia. La dedicación concreta depende del trabajo y de las personas. Ni el anuncio de PRAISE ni los estudios anteriores establecen un número universal de horas de mentoría.

Imagina un equipo que contrata a su primer ingeniero backend júnior. La persona que iba a revisar su trabajo también se encarga de las incidencias de facturación. El responsable puede reservar tiempo para las revisiones, designar a alguien que la sustituya o acotar las primeras tareas del júnior mientras el apoyo sea limitado. Si no resuelve ninguna de esas tres cosas, la espera para recibir ayuda resulta previsible.

Registra esa espera como una condición del entorno de aprendizaje. Si el ingeniero pasa un día bloqueado por una pregunta sin respuesta, el registro debe explicar la falta de apoyo. No debe convertirse sin más en una prueba de que trabaja despacio.

Revisa la capacidad disponible antes de ampliar el alcance del puesto. Nuestra guía para contratar a un ingeniero Rails distingue las competencias necesarias desde el primer día de las convenciones que un equipo puede enseñar. Esa distinción crea una obligación real: cuando contratas por potencial en un ámbito desconocido para la persona, alguien debe estar disponible para enseñárselo.

Relaciona lo observado en la selección con el primer objetivo de aprendizaje

Utiliza las pruebas de la selección para identificar un punto de partida y acuerda qué debe aprender la persona tras incorporarse. Evita convertir cada carencia observada durante la contratación en un requisito de entrada.

Las orientaciones sobre muestras de trabajo de la Oficina de Gestión de Personal de Estados Unidos distinguen las competencias esperadas al incorporarse de las actividades que se enseñarán después de la selección. Advierten sobre el uso de muestras de trabajo para evaluar estas últimas. Son orientaciones sobre evaluación, no una validación de un ejercicio concreto de programación con IA.

Supón que las pruebas de selección muestran que una persona puede reproducir un defecto y explicar una prueba, pero nunca ha trabajado con tu sistema de tareas en segundo plano. Si el puesto incluye aprender a utilizarlo, fija un primer objetivo: seguir una tarea pequeña desde que entra en la cola hasta que termina. No reinterpretes después la decisión de contratación como si hubiera sido necesario conocer previamente tu configuración interna.

Comenta el objetivo con el nuevo compañero. Explica cómo sería un buen resultado, dónde puede pedir ayuda y qué decisiones quedan fuera de sus atribuciones. Un objetivo como «explicar por qué esta tarea puede ejecutarse dos veces y demostrar la protección correspondiente» da a ambos algo concreto que examinar.

Mantén separados los registros de selección y los del trabajo posterior. Lo observado en una entrevista puede orientar la primera conversación, pero es una muestra limitada obtenida en condiciones de selección. Deja margen para que la persona muestre otras fortalezas cuando disponga del contexto y el apoyo habituales. La guía anterior de evaluación de perfiles júnior aborda la selección; ahora toca el desarrollo.

Aplica un ciclo de anticipar, intentar, explicar, revisar y retomar

Utiliza tareas acotadas y repetidas para comprobar la comprensión y ajustar la ayuda. La siguiente secuencia es una propuesta para probar en tu equipo, sin atribuirle un efecto demostrado sobre el aprendizaje ni garantizar un calendario.

Anticipar e intentar

Antes de abrir el asistente, pide al júnior que describa el comportamiento esperado y una comprobación que permita distinguir un buen resultado de un fallo. Pueden bastar unas frases o un esquema pequeño. El objetivo es conocer su interpretación actual del sistema para que el evaluador sepa qué comentar.

Ante un defecto hipotético que duplica notificaciones, podría anticipar lo siguiente: «Reintentar el mismo evento debería dejar una sola notificación. Reproduciré el duplicado y después probaré la ruta de reintento». El evaluador puede corregir una premisa errónea antes de que dé lugar a un cambio mayor.

A continuación, el ingeniero intenta resolver la tarea con las herramientas aprobadas. Pídele que conserve las pruebas pertinentes: reproducción, cambio, resultado de las pruebas y preguntas pendientes. Puede pedir ayuda cuando se bloquee. Practicar con autonomía no exige fingir que los compañeros y la documentación no están disponibles.

Explicar y revisar

Durante la revisión, pide al ingeniero que recorra la ruta modificada y explique un enfoque que haya descartado. Elige una pregunta relacionada con el trabajo real: ¿por qué la prueba reproduce el defecto?, ¿qué ocurre en un segundo intento?, ¿qué supuesto haría insegura la corrección?

Si la explicación no se sostiene, identifica el concepto erróneo y trabajad sobre él. Una explicación pulida generada por un asistente también necesita comprobación. Haz una pregunta relacionada, examinad juntos el comportamiento o cambiad una condición y comentad sus consecuencias. Evita convertirlo en un examen sorpresa con criterios que no se habían comunicado.

El estudio sobre aprendizaje de programación da motivos para comprobar la comprensión por separado. No demuestra que pedir explicaciones, o este formato de revisión, resuelva el problema de aprendizaje. Utiliza la conversación para orientar la siguiente tarea.

Retomar tareas relacionadas

Más adelante, elige una incidencia relacionada que requiera aplicar la misma idea en otro lugar. Mantén disponible la revisión y reduce la ayuda solo donde lo justifiquen las pruebas anteriores. Registra si la persona reconoció la relación, necesitó un recordatorio o tuvo que volver a intentarlo con orientación.

Por ejemplo, después del reintento de notificación, examinad una importación pequeña que pueda procesar dos veces la misma entrada. La cuestión es comprobar si el razonamiento anterior se aplica a otro caso. Resolverlo bien una vez tampoco demuestra una competencia amplia en concurrencia, gestión de pagos o recuperación en producción.

Puedes organizar el primer mes en torno a la lectura y reproducción, un cambio supervisado y otro relacionado con menos ayuda. Las fechas sirven como recordatorios de revisión. Repite un paso o acota la tarea cuando sea necesario; el calendario por sí solo no demuestra que alguien esté preparado para asumir más responsabilidades.

Comprueba el progreso antes de ampliar responsabilidades

Conserva un registro breve del trabajo terminado, la ayuda recibida y el razonamiento observado. Úsalo para decidir la siguiente oportunidad de aprendizaje y el apoyo necesario.

Una nota semanal puede ser breve. Este ejemplo hipotético ya completado retoma la tarea de las notificaciones duplicadas. Ilustra el registro propuesto; no es un resultado observado ni un formato validado por un estudio.

Pide una explicación de la ayuda que haya sido relevante para el trabajo. No necesitas una transcripción de cada interacción privada con una herramienta para comentar si la persona entiende un cambio. Acordad qué se registra y quién puede leerlo.

Incluye en las conversaciones de gestión el tiempo dedicado por los sénior a revisar, la espera para recibir ayuda, los malentendidos repetidos y el trabajo que haya que rehacer. Son señales propuestas para vuestro equipo. Ninguna fuente revisada establece un umbral universal, y las cifras no deben convertirse en una clasificación de empleados júnior.

Antes de ampliar responsabilidades, una persona debe decidir sobre el trabajo concreto que viene después. ¿Puede el ingeniero identificar posibles fallos, verificar el cambio, describir cómo recuperarse y reconocer cuándo pedir intervención? Distingue una explicación autónoma de otra alcanzada con mucha orientación. Ambas pueden mostrar avances, aunque requieren un apoyo distinto en la siguiente tarea.

Mantén los controles de acceso y las aprobaciones de despliegue habituales. Un curso terminado, un cambio integrado o una lista de comprobación completada registran un hecho. Por sí solos no demuestran que alguien esté preparado para producción. Al decidir reducir la supervisión, concreta el alcance de esa decisión y las pruebas que aún faltan.

Reconsidera el plan cuando el progreso se estanque. La tarea puede ser demasiado grande, los comentarios pueden llegar demasiado tarde o el mentor puede carecer de tiempo. Examina esas condiciones junto a las dificultades del ingeniero antes de decidir qué debe cambiar.

Conserva en Kit registros útiles de selección y aprendizaje

Guarda los registros que faciliten las conversaciones sobre el trabajo y deja la responsabilidad del aprendizaje en manos de tu equipo de ingeniería. Las herramientas pueden almacenar instrucciones y notas; el equipo dedica tiempo a enseñar y decide cuándo la persona está preparada.

El área de Contratación de Kit admite ejercicios de código a partir de repositorios plantilla de GitHub, con instrucciones, esfuerzo estimado y ajustes de plazos. Son necesarias las conexiones y la configuración de GitHub. Las revisiones del equipo permiten registrar recomendaciones, puntuaciones por criterio y comentarios escritos. Estas funciones organizan las pruebas de los candidatos; no miden cómo aprende un empleado después de incorporarse.

Por separado, los objetivos y las actualizaciones de seguimiento del área de Rendimiento de Kit permiten guardar un objetivo y notas de progreso con fecha. Un porcentaje de avance es una actualización registrada, no una medición de competencias verificada de forma independiente. La documentación de objetivos y seguimiento explica ese espacio de trabajo.

Kit no ofrece un programa propio de mentoría al estilo de PRAISE, tiempo sénior reservado, una transición automática de la contratación al aprendizaje ni una medición de competencias de ingeniería a lo largo del tiempo. Sus planes de incorporación de compañeros preparan a las personas para utilizar Kit Hiring; no proporcionan un currículo de ingeniería de software.

Empieza con un objetivo de aprendizaje, un evaluador que tenga tiempo y una tarea relacionada que retomar más adelante. Si aún estás diseñando el proceso de selección, consulta la plantilla de proceso para ingenieros júnior. Añade el compromiso de aprendizaje tras la incorporación y revisa lo que tu equipo observa realmente antes de ampliar responsabilidades.