Stanford CS146S: cómo enseña ingeniería con agentes

El curso de Stanford que reescribió su tarea porque los agentes la resolvían

El canal de YouTube de AI Engineer acaba de cruzar el millón de suscriptores y, para celebrarlo, Latent Space se sentó con Mihail Eric, profesor adjunto en Stanford y head of AI en Monaco. Su curso, CS146S «The Modern Software Developer», va por su segunda edición y ya no se parece al primero.

En la primera versión, dictada en el otoño de 2025, había nueve tareas y un proyecto final. Una de ellas pedía correr un revisor de código con IA sobre un repositorio y evaluar la calidad de sus comentarios. Para la segunda edición, Mihail calculó que buena parte de esos ejercicios se resolvían con un solo prompt. Cuando preguntó en clase cómo programaban, todos los estudiantes de segundo y tercer año que encuestó ya usaban un agente. Su conclusión: nadie escribe código a mano.

Ese hallazgo reordenó el programa completo. Y es la parte que más le sirve a cualquier equipo que hoy intenta averiguar qué debe aprender un ingeniero de software.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Qué enseña CS146S: el syllabus de diez semanas

El curso no es para principiantes ni reemplaza las materias clásicas de algoritmos: esas son prerequisitos. Es un curso de práctica para gente que ya tiene bases y ahora tiene que aplicarlas en bases de código enormes.

Semana 1 — Internales de los agentes de código. Los alumnos construyen su propio agente desde cero, una suerte de clon de Claude Code, para entender el bucle de herramientas y la capa que envuelve al modelo.
Semana 2 — Context engineering a escala. Más allá del prompt suelto: diseño de herramientas y MCP.
Semana 3 — Skills. Cómo pasar de herramientas puntuales a procedimientos reutilizables.
Semana 4 — Personalización del agente. Archivos de configuración tipo AGENTS.md y CLAUDE.md, hooks y subagentes.
Semana 5 — Repos listos para agentes. Límites entre servicios, documentación y verificabilidad.
Semana 6 — Revisión de código agéntica.
Semana 7 — Seguridad. Nuevos vectores de ataque cuando un sistema autónomo toma acciones.
Semana 8 — Agentes en background. Bots de SRE, disparadores en CI/CD, agentes que corren fuera del IDE.
Semana 9 — Infraestructura de equipo. LLM gateways, portales MCP y cómo cambian los roles.
Semana 10 — Software factories. Dónde quedan los humanos y qué cuellos de botella se dejan a propósito.

Mihail es explícito en que no todo esto es ciencia asentada. Parte del material son patrones que se están consolidando; otra parte son problemas abiertos sin respuesta. Por eso el curso invita a practicantes de frontera como invitados, en lugar de presentar una única versión oficial.

La tarea nueva: un parche revisado por un mantenedor real

El cambio más interesante de esta edición es que parte de la nota consiste en contribuir a un proyecto open source. El mantenedor del repositorio revisa el parche del alumno.

La lógica es sólida. Un agente puede implementar una funcionalidad en una tarde. Lo que no resuelve es si el mantenedor quiere esa funcionalidad, por qué el código se comporta como se comporta y qué más puede romper el cambio. Esa conversación es, además, la forma en que un ingeniero junior aprende de uno senior.

Para el aula, la lección es pedagógica. Para tu equipo, es directa: el valor ya no está en escribir el código, sino en decidir qué cambio merece entrar al proyecto.

Lo que Monaco compra y lo que construye

Mihail no solo enseña: lidera IA en Monaco, donde sus colegas usan agentes para enviar software e investigar incidentes. Su experiencia ahí es el contrapeso práctico del curso.

El equipo evaluó productos de revisión de código y se quedó con Devin. En cambio, los espacios de trabajo para agentes los construyeron ellos mismos: un agente en background necesita un lugar donde correr el producto, reproducir la falla y probar el parche, y esos detalles dependen de cómo está armada la nube de cada empresa. De ahí su regla: «compras para aprender, construyes para conservar».

El resultado es Hal. Un ingeniero puede pedirle que investigue algo que se rompió y abra un pull request. Un vendedor puede consultar al mismo sistema cómo funciona el producto y recibir una explicación para un cliente. Darle a ambos una pared de logs de depuración solo sirve a uno de los dos.

El cuello de botella que nadie vio venir: la revisión

Aquí está el dato que debería hacer ruido en cualquier equipo. Según el estudio de Faros citado en el episodio, los equipos con alta adopción de IA fusionaron un 98% más de pull requests, pero su tiempo de revisión fue 91% más largo.

Es decir: los agentes aceleran la producción y trasladan la presión al otro extremo del flujo. Por eso el curso dedica una semana entera a la revisión agéntica y por eso Mihail insiste en la verificabilidad como pieza de diseño, no como parche posterior.

La pregunta que queda abierta es qué pasa cuando el agente solo ve el código actual. ¿Dónde mira para saber por qué el equipo rechazó ese mismo cambio hace seis meses? Ahí entran herramientas como el Authority Map de Basis, que apuntan a mapear dónde está el comportamiento vigente, las decisiones anteriores y la intención del equipo.

Mihail va más lejos y predice que los repositorios open source se convertirán en fábricas de software operadas por agentes. Alguien tendrá que seguir decidiendo qué cambio pertenece al proyecto. En la conversación también aparece una advertencia de humildad: incluso los equipos que están en la frontera hablan de apenas un 30% de código completamente dirigido por agentes, y varios de los que fueron más lejos con las fábricas oscuras después reconocieron que se habían equivocado.

¿Qué significa esto para tu startup?

Cuatro cosas concretas, y ninguna requiere presupuesto de Stanford.

Mide antes de celebrar. Toma el tiempo promedio de revisión de tus pull requests antes y después de adoptar agentes. Si el volumen sube y la revisión se estira, tu cuello de botella se movió, no desapareció. El dato de Faros sugiere que es lo habitual, no la excepción.
Escribe el contexto del repo, no solo el código. Documentación, límites entre servicios y criterios de verificación son lo que permite que un agente trabaje sobre una base de código grande sin romper cosas. Es la semana 5 del curso y es la inversión con mejor retorno.
Manda a alguien a contribuir a un proyecto open source. No por el código, sino por la conversación con el mantenedor. Es la versión barata y real del aprendizaje que Mihail consiguió meter en la nota del curso.
Decide qué compras y qué construyes. La regla de Monaco es un buen punto de partida: compra la herramienta para aprender cómo se hace, construye lo que depende de tu propia infraestructura.

El curso completo, con las diez semanas y los proyectos open source asociados, está publicado y se puede comparar con la edición anterior para ver qué cambió en un año.