El nuevo plan de estudios de ingeniería de IA de Stanford desplaza el foco de la codificación a la revisión

Mihail Eric, quien imparte The Modern Software Developer en Stanford y lidera la división de IA en Monaco, ha actualizado su plan de estudios para abordar cómo deben aprender los ingenieros de software en una era dominada por agentes de codificación. En una reciente discusión con el canal de YouTube AI Engineer, Eric detalló cómo las tareas académicas y los flujos de trabajo profesionales están pasando de escribir código a evaluarlo, gestionar entornos de agentes y comprender el contexto histórico dentro de las bases de código.

Qué ocurrió

La estructura del curso CS146S de Stanford ha cambiado significativamente entre su primera y segunda edición. Inicialmente, el curso incluía nueve tareas y un proyecto final, uno de los cuales requería que los estudiantes ejecutaran un revisor de código de IA en un repositorio y evaluaran sus comentarios. Sin embargo, Eric observó que los estudiantes ya estaban utilizando agentes extensivamente, completando a menudo ejercicios anteriores con una sola instrucción (prompt). Como consecuencia, el programa actual reemplaza muchas de esas tareas aisladas con el requisito de contribuir a proyectos de código abierto, donde los mantenedores humanos revisan los parches de los estudiantes.

Este cambio obliga a los estudiantes a interactuar con las realidades sociales y técnicas del desarrollo de software más allá de la mera implementación. Aunque un agente puede generar la implementación de una función en una tarde, el estudiante aún debe determinar si el mantenedor desea el cambio, entender por qué el código existente se comporta como lo hace y anticipar posibles fallos. Este proceso refleja la dinámica de aprendizaje entre ingenieros junior y senior, donde el valor reside en la conversación y la crítica, no solo en la salida bruta.

En Monaco, el equipo de Eric ha adoptado una filosofía similar en sus prácticas de ingeniería profesional. Evaluaron diversos productos de revisión de código y decidieron seguir usando Devin para ciertas tareas. No obstante, descubrieron que los espacios de trabajo de agentes comerciales no satisfacían sus necesidades porque los agentes en segundo plano requieren entornos específicos para ejecutar el producto, reproducir fallos y probar parches. Dado que estos detalles dependen en gran medida de la configuración específica de la nube de Monaco, el equipo construyó su propia infraestructura de espacio de trabajo, dando lugar a una herramienta interna llamada Hal.

Cómo funciona

Hal sirve como una interfaz unificada para diferentes roles dentro de la empresa, demostrando cómo las salidas de los agentes deben adaptarse a la intención del usuario. Un ingeniero puede pedirle a Hal que investigue un problema de producción y genere una solicitud de extracción (pull request) con una corrección. Un vendedor puede preguntar al mismo sistema cómo funciona una característica del producto. En el primer caso, la salida es un cambio de código listo para revisión humana; en el segundo, es una explicación adecuada para la comunicación con clientes. Esta distinción resalta que la salida bruta de depuración solo es útil para los ingenieros, mientras que otras partes interesadas necesitan respuestas sintetizadas.

Un componente crítico de este flujo de trabajo es abordar el problema del "mapa de autoridad". Cuando un agente propone un cambio, normalmente solo ve el estado actual del código. Carece de visibilidad sobre por qué cambios similares fueron rechazados hace seis meses o qué decisiones arquitectónicas impulsaron la implementación actual. Para resolver esto, los equipos deben proporcionar a los agentes acceso al contexto histórico, como discusiones pasadas de solicitudes de extracción y registros de decisiones. Sin este contexto, los agentes pueden proponer repetidamente soluciones que previamente fueron consideradas incorrectas o indeseables.

Eric también destaca técnicas para mejorar la comprensión humana del código generado por IA. Un método implica usar herramientas como la habilidad explain-diff de Geoffrey Litt, que convierte un cambio de código en una guía visual y cuestiona al desarrollador sobre las modificaciones. Este enfoque asegura que los ingenieros no fusionen ciegamente código escrito por agentes, sino que verifiquen su comprensión de la lógica y los posibles efectos secundarios antes de la integración.

Detalles clave

• El CS146S de Stanford ahora requiere que los estudiantes contribuyan a proyectos de código abierto con revisiones de mantenedores humanos, en lugar de completar ejercicios aislados de evaluación de IA.
• Monaco construyó su propia herramienta de espacio de trabajo de agentes, Hal, porque las soluciones existentes no podían replicar adecuadamente su entorno específico de nube para pruebas y reproducción.
• Hal genera diferentes salidas según el rol del usuario: solicitudes de extracción para ingenieros y texto explicativo para vendedores.
• Un estudio citado en la discusión señala que los equipos con alta adopción de IA fusionaron un 98% más de solicitudes de extracción, pero su tiempo de revisión aumentó un 91%.
• Los flujos de trabajo efectivos de agentes requieren acceso a un "mapa de autoridad" que incluya decisiones históricas y razones de rechazos pasados para evitar propuestas redundantes o incorrectas.
• Las herramientas que visualizan diffs y cuestionan a los desarrolladores sobre los cambios ayudan a mitigar el riesgo de fusionar código generado por IA mal comprendido.

Por qué importa

Para los ingenieros de software y líderes técnicos, este cambio indica que la competencia con agentes de codificación ya no se trata solo de la ingeniería de prompts. El cuello de botella se ha desplazado de escribir código a revisarlo y proporcionar el contexto necesario para que los agentes operen correctamente. Los equipos que no inviertan en entornos personalizados de agentes o bases de conocimiento histórico probablemente verán un aumento en el churn de las solicitudes de extracción y ciclos de revisión más largos, ya que los agentes tendrán dificultades para alinearse con patrones arquitectónicos establecidos.

El aumento en el tiempo de revisión a pesar de las tasas de fusión más altas sugiere que la supervisión humana sigue siendo crítica. Los ingenieros deben desarrollar nuevas habilidades para auditar eficientemente los cambios generados por IA, enfocándose en la intención, los casos límite y la consistencia histórica. Esto requiere un cambio cultural donde la revisión de código se convierta en un proceso de investigación más profundo en lugar de una comprobación superficial, asegurando que la velocidad no comprometa la estabilidad ni la mantenibilidad del sistema.

Qué puedes hacer

• Reemplaza los ejercicios de codificación aislados con tareas que requieran contribuir a proyectos reales de código abierto o bases de código heredadas internas con revisión humana estricta.
• Construye o configura espacios de trabajo de agentes que puedan reproducir con precisión tu entorno de producción para pruebas e investigación de fallos.
• Implementa herramientas que visualicen diffs de código y cuestionen a los desarrolladores sobre los cambios para asegurar una comprensión profunda antes de fusionar.
• Crea un "mapa de autoridad" indexando comentarios pasados de solicitudes de extracción, documentos de diseño y razones de rechazo para el acceso de los agentes.
• Adapta las salidas de los agentes a roles específicos, asegurando que los ingenieros reciban código accionable mientras que las partes interesadas no técnicas reciben explicaciones claras.
• Monitorea de cerca las métricas de las solicitudes de extracción, rastreando específicamente el tiempo de revisión versus la tasa de fusión para identificar cuellos de botella en los flujos de trabajo asistidos por IA.