Stanford enseña a sus estudiantes a enviar parches a los mantenedores: así es CS146S

Qué tareas poner a los estudiantes si un agente lo hace todo

Es un problema conocido: le asignas una tarea a un desarrollador júnior y Claude Code u otro agente la resuelve con un solo prompt. Los docentes se han encontrado con lo mismo. Los deberes del año pasado ya no permiten evaluar qué ha aprendido el estudiante.

Mihail Eric imparte en Stanford el curso CS146S, The Modern Software Developer, y dirige el área de IA en la startup Monaco. En la segunda edición del curso cambió el propio formato de evaluación. Se incorporaron mantenedores de proyectos de código abierto. El estudiante debe entender un repositorio desconocido, proponer un cambio y explicar el parche a la persona que podría incorporarlo.

El planteamiento encaja bien con el trabajo real. Generar código ahora es barato. Lo costoso es entender una base de código ajena, mantener el contexto y responsabilizarse del diff. Un mantenedor no valorará lo elegante que sea el prompt: preguntará para qué hace falta el cambio y qué va a romper.

Qué sobrevivió al contacto con producción

En un episodio del pódcast Latent Space dedicado al millón de suscriptores del canal AI Engineer, Eric repasa el programa de diez semanas del curso. Explica qué lecciones resultaron útiles en su propio equipo de ingeniería. Los temas incluyen la arquitectura del bucle, las herramientas y el entorno de ejecución (harness) de un agente de programación; la ingeniería de contexto para un repositorio grande; y las habilidades que permiten entender un diff en lugar de aceptarlo a ciegas.

Otra sección aborda la decisión de desarrollar o comprar. Monaco creó internamente sus agent workspaces, es decir, entornos de trabajo para cada agente. Las herramientas de revisión de código las compró. Además, dio a su agente de guardia acceso a Datadog y GitHub para que pudiera examinar las alertas y relacionarlas con el código por su cuenta. Eric resume así la fórmula: comprar para aprender, desarrollar para conservar.

También se habla de cómo preparar un repositorio para los agentes, qué hacer cuando la revisión de código se convierte en un cuello de botella, seguridad, dependencias y permisos de acceso, agentes en segundo plano como Stripe Minions, portales MCP y qué trabajo les queda a los desarrolladores.

Limitaciones y conclusiones prácticas

Se trata de una conversación de dos horas, no de un estudio con métricas. Por ahora solo hemos visto el anuncio y el índice, así que habrá que consultar el episodio para conocer los detalles y las cifras concretas. Parte del contenido es abiertamente promocional: tanto el propio canal del pódcast como Monaco impulsan sus propios temas.

La conclusión práctica sigue siendo útil. Si contratas o formas a desarrolladores júnior, sustituye la evaluación de si han escrito código por la de si han entendido código ajeno y defendido un cambio. Si estás creando un equipo que trabaje con agentes, decide de antemano qué consideras una capacidad central que mantendrás dentro de la empresa y qué vas a comprar. Y, sobre todo, prepara el repositorio para el agente: una estructura clara, pruebas, acceso a la observabilidad y permisos limitados. De lo contrario, el cuello de botella será la revisión, no la generación.