Enseñar ingeniería de software cuando la IA programa: análisis de un programa de la UNAM y una propuesta

En tres artículos anteriores planteamos un mismo escenario desde ángulos distintos. Con IA, un equipo genera software más rápido de lo que puede verificarlo, y esa diferencia se acumula como deuda de verificación. Por eso el trabajo humano se mueve a acotar, especificar y auditar. Si el trabajo cambia, la formación tiene que cambiar con él. La pregunta de este artículo es concreta: ¿cómo se adecua un plan de estudios?

Para no quedarnos en lo abstracto, analizamos un documento real y público: el programa de la asignatura Ingeniería de Software (clave 0575) de la Licenciatura en Ciencias de la Computación de la Facultad de Ciencias de la UNAM. Lo contrastamos con lo que la IA puede hacer hoy, según mediciones y no según promesas, y con lo que se sabe de cómo afecta al aprendizaje. Después proponemos cómo debería quedar la asignatura y la licenciatura, y respondemos si conviene que la carrera dure más o menos.

Una precisión sobre el documento: el 0575 no es el temario de una carrera completa, sino el de una asignatura obligatoria de 6.º semestre, con 112 horas. Para hablar de la carrera usamos también el plan de estudios oficial de la licenciatura. Analizamos los documentos oficiales, no lo que cada profesor enseña en su aula, que con frecuencia va por delante del programa escrito.

Lo que la IA puede hacer hoy, y lo que no

Un plan de estudios no debería diseñarse con base en lo que la IA hará algún día ni en lo que hacía hace tres años. Esto es lo medido:

La lectura para la formación es directa. La IA ya hace bien buena parte de lo que un curso tradicional dedica a enseñar: escribir una implementación a partir de una descripción. Lo que no hace, o hace mal, es decidir qué construir, especificar sin ambigüedad, verificar de forma independiente y responder por el resultado. Eso es lo que la formación tiene que reforzar.

Lo que la IA le hace al aprendizaje

Antes de proponer «usar IA en clase», conviene ver qué dice la evidencia sobre aprender con ella.

• Sin guardas, la IA puede dañar el aprendizaje. En un experimento con casi mil estudiantes de bachillerato, quienes practicaron con ChatGPT sin restricciones mejoraron 48% durante la práctica, pero al retirarles la herramienta obtuvieron 17% menos en el examen que el grupo que nunca la tuvo. Un tutor con guardas, que daba pistas en vez de respuestas, eliminó casi todo el daño (Bastani et al., PNAS, 2025).
• La IA da a quien empieza una ilusión de avance. En un estudio con 21 estudiantes de programación, la IA agravó dificultades metacognitivas conocidas y creó tres nuevas: la interrupción constante de sugerencias, las sugerencias que desvían y la falsa sensación de progreso. De diez estudiantes con dificultades, nueve llegaron a la solución usando IA, y la mayoría creía entender más de lo que entendía (Prather et al., ICER, 2024).

Las dos conclusiones tienen límites: son estudios de corto plazo y, el segundo, con una muestra pequeña. Pero apuntan en la misma dirección. No basta con permitir o prohibir la IA: importa cuándo y cómo entra en la formación.

El programa actual: qué tiene y qué le falta

El programa 0575 tiene 112 horas (48 de teoría y 64 de práctica) en siete unidades:

Lo que ya tiene, y es valioso

Buena parte de lo que este nuevo escenario exige ya está en el programa, aunque con poco peso:

• Formalización y rastreo de requerimientos (IV.1, IV.3, IV.7): la base de especificar.
• Desarrollo guiado por pruebas (VI.7) y diseño para facilitar las pruebas (VI.3).
• Integración continua (VI.5) y pruebas de regresión (VII.3).
• Análisis de riesgo e impacto (VII.2), refactoring y reingeniería (VII.5, VII.6).
• Validación de elementos que no son código (VI.8), un tema que muchos programas omiten.
• Domain-Driven Design de Evans en la bibliografía complementaria.

Además, la licenciatura en su conjunto tiene una ventaja que no es menor: una base fuerte de lógica, matemáticas discretas, autómatas, complejidad y algoritmos. Ese razonamiento formal es justo el que hace falta para verificar.

Lo que le falta

1. Proporción. Requerimientos y verificación, las dos unidades que más ganan valor, suman 28 de 112 horas (25%). Procesos, que incluye cascada y métodos guiados por plan, tiene 21 horas.
2. La IA no aparece. Ni como herramienta de desarrollo, ni como fuente de errores con patrones propios, ni como algo que hay que auditar.
3. No hay verificación independiente. No aparecen la falla de causa común (código y pruebas que comparten el error), las pruebas de mutación, las pruebas basadas en propiedades, la revisión de código ni la auditoría por muestreo.
4. No hay seguridad de aplicaciones. El modelo de amenazas no está en el curso, y la asignatura de Criptografía y Seguridad llega hasta el 8.º semestre.
5. No hay operación. Despliegue gradual, reversión y observabilidad no aparecen. La guía SWEBOK v4 (IEEE, 2024) agregó justamente tres áreas nuevas: arquitectura, operación y seguridad.
6. La responsabilidad profesional no está explícita. Con IA, la pregunta «¿quién responde por este código?» deja de ser filosófica.
7. La evaluación pierde validez. El programa evalúa con exámenes y el «desarrollo de una aplicación». Hoy una aplicación funcional ya no demuestra que quien la entrega sepa construirla ni juzgarla.
8. Antigüedad. El plan de la licenciatura se modificó por última vez en 2011, y la bibliografía básica es de 2010.
9. Peso en la carrera. Es la única asignatura obligatoria de ingeniería de software: 10 de 376 créditos (2.7%). Ingeniería de Software II, Arquitectura y Diseño de Software, y Pruebas de Software existen, pero como optativas.

La propuesta para la asignatura

La propuesta mantiene las 112 horas y la proporción de 48 de teoría y 64 de práctica. Lo que cambia es el reparto: especificar y verificar pasan de 28 a 48 horas, y procesos e introducción se compactan.

Contenido de cada unidad

I. Introducción: el desarrollo de software con IA (8 h). Ciclo de vida y disciplinas, como hoy. Se agregan el nuevo reparto de roles (acotar, especificar, auditar, operar), la deuda de verificación, las capacidades y los límites medidos de la IA y la responsabilidad profesional: una persona responde por lo que se integra, lo haya escrito quien lo haya escrito. Se reduce el recorrido histórico de modelos de desarrollo.

II. Diseño de componentes y contratos (14 h). Se mantienen componentes, cualidades de las APIs, su diseño y los patrones. Se agregan los contratos versionados (OpenAPI, JSON Schema) como fuente de verdad entre componentes, y la verificación de dependencias: la IA sugiere a veces paquetes que no existen o que no son de quien parecen. Los patrones se acotan a los que habrá que reconocer al auditar.

III. Proceso y control de cambios (12 h). Cascada y métodos guiados por plan quedan como contexto, sin desaparecer. Se refuerzan el control de versiones, los PRs pequeños, la revisión según el riesgo, la integración continua con compuertas y los límites al trabajo en curso. Sale el tema de herramientas para el desarrollo acelerado de aplicaciones (IV.8): los agentes de IA ocuparon ese lugar.

IV. Requerimientos y especificación ejecutable (22 h). Es la unidad que más crece. Se mantienen clasificación, formalización, incertidumbre aceptable y rastreo. Se agregan historias de usuario con criterios de aceptación verificables, Gherkin o EARS, propiedades e invariantes, y especificar para un agente: un agente implementa literalmente, así que cada ambigüedad acaba en un defecto. El rastreo se lleva hasta la prueba que comprueba cada requerimiento. Los casos de uso se mantienen, con menos peso.

V. Arquitectura y límites (16 h). Se mantienen capas, componentes, vistas, características sistémicas y patrones. Se agregan los registros de decisiones (ADR), la modularidad y el acoplamiento como lo que decide si la deuda crece lineal o exponencialmente, y los límites que restringen lo que un agente puede tocar. Se reducen los métodos tradicionales de diseño de arquitecturas.

VI. Verificación independiente (26 h). Es la unidad central de la propuesta. Se mantienen las diferencias entre validación y verificación, los tipos de pruebas, el diseño para la prueba, el manejo de errores, la integración continua, el desarrollo guiado por pruebas y la validación de lo que no es código. Se agregan:

• Pruebas escritas antes del código y congeladas, para que el agente no las edite.
• La falla de causa común: por qué más pruebas de la misma IA no bajan el riesgo (Knight y Leveson, 1986).
• Pruebas de mutación y pruebas basadas en propiedades: medir si las pruebas atrapan errores.
• Análisis estático y de seguridad.
• Modelo de amenazas STRIDE, con una prueba por amenaza.
• Revisión de código según el riesgo y auditoría por muestreo.

VII. Evolución, riesgo y deuda (14 h). Se mantienen mantenibilidad, análisis de riesgo e impacto, regresión, reutilización, reingeniería y refactoring. Se agregan la medición de la deuda de verificación, el despliegue gradual con reversión, la observabilidad y la modernización de sistemas heredados con IA, que es hoy uno de sus usos más frecuentes.

Cómo entra la IA durante el semestre

La evidencia sobre aprendizaje sugiere que la IA no debería entrar de golpe:

Cómo evaluar

Bibliografía para actualizar

• SWEBOK Guide v4 (IEEE Computer Society, 2024): marco de referencia de la disciplina.
• ACM/IEEE-CS/AAAI, Computer Science Curricula 2023: integra sociedad, ética y profesión en la mayoría de las áreas.
• Sommerville, Software Engineering, 10.ª edición (2015), en lugar de la 9.ª.
• Winters, Manshreck y Wright, Software Engineering at Google (O'Reilly, 2020): ingeniería de software a escala, revisión de código y pruebas.
• Shostack, Threat Modeling: Designing for Security (Wiley, 2014).
• Se conservan Evans (Domain-Driven Design) y Boehm y Turner, que siguen vigentes.

La propuesta para la licenciatura

La asignatura sola no alcanza: llega en 6.º semestre y nada antes la prepara para el nuevo rol. La propuesta toca diez asignaturas de las 34 obligatorias y mantiene los 8 semestres y los 376 créditos.

Qué se mantiene: toda la base matemática y teórica. Álgebra, cálculo, autómatas, complejidad, compiladores y algoritmos no pierden valor con la IA; lo ganan. Juzgar si un resultado es correcto exige entender por qué funciona, y esa capacidad se construye con fundamentos.

El costo: Ingeniería de Software II ocupa el lugar de una optativa, así que las optativas pasan de 6 a 5 y las obligatorias, de 34 a 35. Se pierde flexibilidad, que es una de las virtudes del plan actual. A cambio, la ingeniería de software obligatoria pasa de 10 a 20 créditos (de 2.7% a 5.3% de la carrera).

Optativas recomendadas para quien se oriente a la industria: Semántica y Verificación, Pruebas de Software y Administración de la Configuración, Arquitectura y Diseño de Software, Métricas de Software, Riesgo Tecnológico e Interacción Humano-Computadora. Todas existen ya en el plan.

El servicio social y los talleres de ejercicio profesional como aprendizaje supervisado. El plan ya exige 480 horas de servicio social y ofrece dos talleres de ejercicio profesional. Orientarlos a auditar y especificar bajo supervisión, en proyectos reales, forma el criterio que el mercado pide sin añadir tiempo a la carrera.

¿Más tiempo o menos?

Es la pregunta más tentadora: si la IA escribe el código, ¿no debería durar menos la carrera? Hay tres opciones razonables:

Recomendación: mantener los 8 semestres y cambiar el contenido y la evaluación. No hay evidencia que justifique acortar, y sí hay evidencia de que aprender con IA mal integrada puede dejar peores resultados. Alargar tampoco hace falta, porque el plan ya tiene espacios (optativas, servicio social, talleres) que pueden reorientarse.

Para la asignatura vale lo mismo: las 112 horas alcanzan, siempre que se redistribuyan y que Ingeniería de Software II se vuelva obligatoria. La ingeniería de software obligatoria pasa así de 112 a 224 horas sin alargar la carrera.

Lo que sí debe cambiar es el ritmo de revisión. El plan lleva quince años sin modificarse, y el horizonte de tareas que la IA completa se duplica cada siete meses. La propuesta separa dos capas:

• Un núcleo estable, que va en el plan formal: especificar, verificar, diseñar límites, razonar formalmente y responder por el resultado. Esto no cambia cada año.
• Las herramientas y prácticas concretas, que la academia revisa cada año sin reformar el plan: qué agentes se usan, qué herramientas de mutación o análisis, qué políticas de uso.

Lo que puede salir mal

1. El profesorado. El perfil que pide el programa es «amplia experiencia de programación». Para esta propuesta hace falta también experiencia en verificación y en desarrollo con IA, y eso exige formación docente antes que cualquier cambio en el papel.
2. La equidad. Si el curso depende de herramientas de pago, quien no puede pagarlas queda en desventaja. La institución tiene que dar acceso o diseñar las prácticas para que funcionen con opciones gratuitas.
3. La escala. Una defensa oral por estudiante funciona en un grupo de 30, no en uno de 120. Hay que diseñar evaluaciones que escalen, como la auditoría con defectos sembrados, que se puede calificar de forma automática.
4. Perseguir la moda. Las capacidades de la IA cambian rápido. Por eso la propuesta apuesta por principios (especificar, verificar, responder) y deja las herramientas fuera del plan formal.
5. La evidencia todavía es corta. Los estudios sobre IA y aprendizaje son de corto plazo y, varios, con muestras pequeñas. Ninguna generación ha egresado todavía de un plan diseñado así. Conviene medir: comparar grupos, seguir a los egresados y ajustar.

Lo que este artículo no afirma

• No afirma que el programa actual sea malo. Tiene una base teórica sólida y contiene, con poco peso, buena parte de lo que este escenario exige. El problema es la proporción y la antigüedad, no la dirección.
• No afirma que ya no haya que enseñar a programar. Al contrario: el primer semestre sin IA existe para aprender a programar de verdad, porque sin esa base no hay forma de auditar.
• No es una propuesta oficial. Es un análisis independiente para abrir la discusión, hecho sobre los documentos públicos y no sobre lo que se enseña en cada aula.
• No afirma que este reparto de horas sea el único correcto. Es una propuesta razonada que conviene probar, medir y corregir.

Fuentes

• UNAM, Facultad de Ciencias, programa de la asignatura Ingeniería de Software (clave 0575), Licenciatura en Ciencias de la Computación.
• UNAM, plan de estudios de la Licenciatura en Ciencias de la Computación (sistema escolarizado), modificado en 2011.
• Bastani, Bastani, Sungu, Ge, Kabakcı y Mariman, Generative AI without guardrails can harm learning: Evidence from high school mathematics, PNAS 122(26) (2025).
• Prather et al., The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers, ICER (2024).
• Kwa et al., Measuring AI Ability to Complete Long Software Tasks, METR (2025).
• Becker, Rush, Barnes y Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR (2025).
• Brynjolfsson, Chandar y Chen, Canaries in the Coal Mine?, Stanford Digital Economy Lab, versión de agosto de 2026.
• DORA, Accelerate State of DevOps Report (2024).
• Leu et al., ESEM (2026); Knight y Leveson, IEEE Transactions on Software Engineering 12(1) (1986).
• IEEE Computer Society, SWEBOK Guide v4 (2024).
• ACM/IEEE-CS/AAAI, Computer Science Curricula 2023 (2024).
• Lee et al., Reshaping Undergraduate Computer Science Education in the Generative AI Era, arXiv (2026): informe de talleres que también recomienda desplazar la enseñanza hacia comprender y verificar lo que genera la IA.
• Dixi-Project: Deuda de verificación y Acotar, especificar y auditar (2026).