Stanford cambia la tarea: el estudiante debe defender el código del agente

Stanford cambió las tareas de CS146S después de que los coding agents pudieran terminar con un prompt los ejercicios del año anterior. Ahora el alumnado entra en un proyecto open source desconocido, propone un cambio y lo explica a la persona que podría aceptarlo.

Los deberes anteriores dieron paso a un repositorio ajeno y un maintainer real

Latent Space describe la segunda edición de The Modern Software Developer, impartida por Mihail Eric. La entrevista de 121 minutos recorre diez semanas sobre agent harness, context engineering, security, background agents y software factory.

El principal cambio está en la tarea. Maintainers de open source llevan repositorios reales al curso. El estudiante debe entender código desconocido, proponer una intervención y defender el patch ante quien responde del merge. La web oficial indica 3 units y busca enseñar a diseñar agent workflows, combinar tools y skills y comprender los límites de los coding agents actuales.

El valor de un perfil junior pasa de la sintaxis a ganarse la confianza

Cuando un agente resuelve un ejercicio aislado, una tarea tradicional deja de medir bien el trabajo del estudiante. Un repositorio ajeno añade lo que un prompt no puede evitar fácilmente: contexto incompleto, convenciones locales, decisiones históricas y una persona capaz de rechazar el cambio.

Para las empresas, el escenario se parece más a incorporar a un perfil junior. Producir un diff será habitual. Importará más elegir un problema útil, verificar el comportamiento y explicar el cambio para que el equipo pueda confiar en él. El curso evalúa la supervisión de AI, no la resistencia a usarla.

La experiencia de un curso aún no fija un estándar para el sector

La fuente es una entrevista con el profesor, que también dirige AI en Monaco. Ofrece detalles del curso y de la práctica de su equipo, pero no es un estudio comparativo sobre resultados académicos. No permite saber si sus estudiantes construyen software más fiable que quienes siguen un curso tradicional.

El review open source también mide solo parte del trabajo. El maintainer ve el patch y su explicación, pero quizá no sepa cuántas decisiones se delegaron ni si el estudiante diagnosticaría solo un fallo en producción. La evaluación aún necesita lectura independiente de diffs, pruebas e incidentes.

Los patches aceptados y los errores hallados sin ayuda darán la respuesta

Una señal sólida serán los cambios que los maintainers acepten y la capacidad de corregirlos tras un review crítico. Más valioso será comprobar si el estudiante explica un comportamiento inesperado, detecta un error del agente e interviene con seguridad cuando se pierde el contexto.

Si estas tareas se extienden, las universidades dejarán de competir con las herramientas mediante prohibiciones. Pondrán al estudiante delante de una persona con derecho a decir que ese patch no pertenece al proyecto.

El veredicto de Lilith

Un agente puede escribir el patch del estudiante. Ante el maintainer sigue estando el estudiante, y ahí empieza la parte de la educación que no se resuelve con un botón.