Enseñar arquitectura de software con IA como andamiaje, no como atajo.
Este manual le proporciona todo lo necesario para implementar las cinco guías de prompts pedagógicos en sus cursos de programación orientada a objetos, con evidencia empírica validada en 37 estudiantes costarricenses.
¿Qué es GuíaPrompt-CR?
Es un programa pedagógico de integración de IA generativa en la enseñanza de arquitectura de software por capas, diseñado y validado empíricamente como Trabajo Final de Graduación de la Licenciatura en Docencia, Universidad San Marcos, Costa Rica, 2026. Su producto central son cinco guías de prompts que enseñan al estudiante a interactuar con modelos de lenguaje de manera que construya comprensión arquitectónica real en lugar de depender de código generado que no puede explicar.
Principios rectores
Fundamento teórico
Vygotsky (1978) — Zona de Desarrollo Próximo: Las guías de prompts actúan como el andamiaje que opera en la brecha entre lo que el estudiante puede hacer solo (nivel real) y lo que puede alcanzar con apoyo estructurado (nivel potencial). A medida que el estudiante internaliza los principios arquitectónicos, el andamiaje se retira progresivamente.
Bloom revisado (Anderson y Krathwohl, 2001 — Churches, 2008): Las cinco guías progresan desde Comprender hasta Crear, asegurando que la IA actúe con mayor intensidad en los niveles cognitivos donde la mediación docente individual es más difícil de garantizar en grupos numerosos.
Guía 1
Guía 2
Guías 3 y 4
Guía 5
Tabla de referencia: Las tres capas
| Capa | Nombre alternativo | ¿Qué hace? | Ejemplo de clase |
|---|---|---|---|
| UI Presentación | Frontend / Vista | Interactúa con el usuario. Captura datos y muestra resultados. No valida ni accede a datos. | FormularioEstudiante, PanelPrincipal |
| BLL Lógica de Negocio | Servicio / Service | Aplica las reglas del sistema. Valida datos. Coordina entre UI y DAL. No muestra nada al usuario. | ServicioEstudiante, ServicioFactura |
| DAL Acceso a Datos | DAO / Repository | Ejecuta operaciones CRUD sobre la base de datos. No valida reglas de negocio. | EstudianteDAO, ClienteRepository |
El Protocolo de Tres Momentos
Todas las actividades del programa siguen este protocolo sin excepción. El Momento PRE-IA es el más crítico: sin él, la IA opera como sustituto del pensamiento.
El estudiante intenta primero
Resuelve el problema arquitectónico de forma autónoma antes de abrir cualquier IA. Registra su propuesta por escrito. El docente no interviene.
⏱ 15 minutosDialoga con la IA
Usa el prompt de la guía correspondiente. Solo puede pedir razonamiento y explicaciones, nunca código completo directamente. El docente observa y registra.
⏱ 30–40 minutosReflexiona y se apropia
Compara su propuesta PRE-IA con lo que aprendió. Responde las preguntas de reflexión con sus propias palabras. Es el insumo principal de la rúbrica.
⏱ 15 minutosNotas específicas para cada momento
Indicadores de éxito por sesión
| Indicador | Meta mínima | Meta óptima |
|---|---|---|
| % de estudiantes que completan el PRE-IA | 80% | 100% |
| % que usan el prompt de la guía sin modificarlo | 60% | — |
| % que formulan al menos un prompt de seguimiento | 40% | 70% |
| % que completan las reflexiones POST-IA | 90% | 100% |
| Cambio observable en la forma de preguntar entre inicio y fin de sesión | Parcial | Claro y documentado en bitácora |
Las Cinco Guías de Prompts Pedagógicos
Cada guía corresponde a un nivel cognitivo de Bloom y a una función pedagógica concreta. Los prompts base son adaptables al lenguaje, nivel y contexto del curso.
Guía 1 — Prompt Explicativo
¿Cuándo usarla? Al inicio del tema de arquitectura, antes de que los estudiantes vean código de sistema completo. Ideal como primera guía de la secuencia.
Explícame con un ejemplo concreto en [Java / C# / Python] qué diferencia hay entre la capa de [capa A] y la capa de [capa B] en una arquitectura de software por capas. No me des el código completo de un sistema. Solo usá una clase de ejemplo pequeña por capa para que pueda ver el contraste. Explica después por qué esa responsabilidad pertenece a esa capa y no a la otra.
Guía 2 — Prompt de Depuración Guiada
¿Cuándo usarla? Cuando el código del estudiante compila y corre pero tiene problemas de diseño arquitectónico. También para interpretar stack traces.
Tengo este fragmento de código en [lenguaje]. Sin corregirlo directamente, dime:
1. ¿Qué principio de separación de capas está violando y por qué?
2. ¿A qué capa debería pertenecer el código que está en el lugar equivocado?
3. Dame una pista de por dónde empezar a corregirlo, pero no me escribas el código corregido.
Mi código tiene este error: [pegá el stack trace]. Sin darme el código corregido:
1. ¿En qué archivo y línea ocurre el problema?
2. ¿Qué tipo de error es (sintaxis, lógica, null, tipo de datos)?
3. ¿Qué debería revisar primero para encontrar la causa?
Guía 3 — Prompt de Comparación Arquitectónica
¿Cuándo usarla? Cuando el estudiante puede identificar violaciones (Guía 2 completada) y está listo para juzgar la calidad relativa de dos soluciones.
Tengo estas dos implementaciones de [nombre de la funcionalidad] en [lenguaje]:
Implementación A: [código A]
Implementación B: [código B]
Sin decirme directamente cuál es la correcta:
1. ¿Cuál de las dos respeta mejor el principio de responsabilidad única de cada capa?
2. ¿Cuál tendría más problemas si tuviéramos que cambiar la base de datos por otra?
3. ¿Qué criterio arquitectónico diferencia a una de la otra?
Guía 4 — Prompt de Refactorización Justificada
¿Cuándo usarla? Cuando el estudiante tiene código funcional pero mal estructurado. Opera en dos fases: diagnóstico primero, luego iteración.
Tengo este código en [lenguaje] que funciona pero tiene problemas de arquitectura:
[código]
Sin reescribir el código completo todavía:
1. ¿Cuántas clases debería tener un sistema bien estructurado para esta funcionalidad?
2. ¿Qué responsabilidad debería tener cada clase?
3. ¿Qué líneas de mi código actual deberían moverse a otra clase y por qué?
Luego acompañame en la refactorización: voy a proponer la nueva estructura y vos me decís si respeta la separación de capas.
Guía 5 — Prompt de Consultor de Diseño
¿Cuándo usarla? Sesión final. Requiere que las Guías 1–4 ya estén trabajadas. Es la que produce las reflexiones más ricas para la bitácora y para el análisis cualitativo.
Voy a diseñar un sistema de [descripción del sistema] en [lenguaje] con arquitectura por capas.
Estas son las clases que propongo y sus capas:
[tu lista de clases con capa y responsabilidad]
Actuá como mi consultor de arquitectura:
1. ¿Mi distribución de responsabilidades respeta la separación de capas?
2. Si encontrás problemas, explicame cuáles son pero no me los corrijas directamente. Dejá que yo proponga la solución primero.
3. ¿Hay alguna responsabilidad que olvidé asignar a alguna capa?
Plan de Cinco Sesiones
Sesiones de 2 horas aplicables a lo largo de un cuatrimestre dentro de cursos de programación orientada a objetos. La Sesión 0 (prueba diagnóstica PRE) se aplica en la clase inmediatamente anterior.
| Sesión | Guía | Actividad principal (2 h) | Producto del estudiante | Criterios rúbrica |
|---|---|---|---|---|
| Sesión 0 Previa |
— | Aplicación Instrumento 3 PRE: prueba de competencias (Dimensiones A, B, C) | Puntajes PRE por dimensión — línea base | — |
| Sesión 1 | Guía 1 Explicativo |
Análisis de la tabla de capas + 3 preguntas explicativas a la IA sobre diferencias arquitectónicas entre pares de capas | Respuestas escritas con sus propias palabras a las 3 reflexiones POST-IA | Criterios 1 y 2 |
| Sesión 2 | Guía 2 Depuración |
Identificación de violaciones en el código FormularioVenta + lectura guiada de un stack trace real | Tabla completa de violaciones con capa correcta, descripción del problema y justificación | Criterios 1, 3 y 4 |
| Sesión 3 | Guía 3 Comparación |
Comparación arquitectónica de las dos implementaciones ServicioEstudiante vs. RegistroEstudiante | Análisis escrito con criterio arquitectónico que justifica la elección y la penalización del mantenimiento | Criterios 1, 3 y 4 |
| Sesión 4 | Guía 4 Refactorización |
Refactorización del AppPrestamo monolítico en tres capas usando protocolo completo PRE/CON/POST | Código refactorizado + documentación de cada decisión de diseño + diagrama de flujo entre capas | Criterios 1, 4 y 5 |
| Sesión 5 | Guía 5 Diseño original |
Diseño del Sistema de Gestión de Notas desde cero con la IA como consultor + implementación de 2 clases | Propuesta de arquitectura + 2 clases implementadas + reflexión final de cierre del programa | Criterios 2, 3, 4 y 5 |
| Sesión 5+ Misma sesión |
— | Aplicación Instrumento 3 POST + Sección E del Instrumento 1 (encuesta de impacto) | Puntajes POST por dimensión — medición de ganancia | — |
Rúbrica de Evaluación de Ingeniería de Prompts
Evalúa la competencia del estudiante en ingeniería de prompts pedagógicos como contenido curricular explícito. Se aplica a las reflexiones POST-IA de cada sesión. Puntaje máximo: 20 puntos (5 criterios × 4 puntos máximo). Comunique la rúbrica a los estudiantes antes de la primera sesión.
| Criterio | Excelente (4) | Satisfactorio (3) | En desarrollo (2) | Insuficiente (1) |
|---|---|---|---|---|
| 1. Tipo de prompt utilizado | Usa prompts orientados al razonamiento (depuración guiada, comparación, consultor) | Usa prompts explicativos con buena especificidad | Usa prompts genéricos que piden la solución directa | Solo pide el código completo sin razonamiento |
| 2. Especificidad del prompt | Incluye lenguaje, nivel y objetivo arquitectónico concreto | Incluye lenguaje y objetivo pero sin detalle arquitectónico | Menciona el lenguaje pero el objetivo es vago | El prompt no indica contexto ni objetivo |
| 3. Evaluación crítica de la respuesta | Identifica errores o limitaciones en la respuesta de la IA y los señala explícitamente | Acepta la respuesta pero la verifica con un prompt de seguimiento | Acepta la respuesta sin verificar | Copia la respuesta directamente sin leer ni evaluar |
| 4. Reflexión POST-IA | Responde todas las preguntas con argumentos arquitectónicos propios y referencias a su propio código | Responde la mayoría con argumentos parcialmente desarrollados | Responde brevemente sin argumentos propios | No completa la reflexión POST-IA o la copia de la IA |
| 5. Autonomía en el diseño (PRE-IA) | Propone su propio diseño antes de consultar la IA (PRE-IA documentado y específico) | Propone diseño parcial antes de la IA | Solo consulta la IA sin propuesta previa documentada | No realiza el Momento PRE-IA |
18–20 = Excelente · 14–17 = Satisfactorio · 10–13 = En desarrollo · <10 = Insuficiente
Esquema de Evaluación Integrado
Integra el uso de los instrumentos del TFG con la evaluación curricular del curso. Los pesos son orientativos y pueden ajustarse según el sílabo institucional.
| Componente | Instrumento | Ponderación | Momento |
|---|---|---|---|
| Prueba diagnóstica pre-intervención | Instrumento 3 PRE (Dimensiones A, B, C) | 10% | Sesión 0 |
| Reflexiones POST-IA × 4 sesiones (Guías 1–4, 5 pts c/u) | Rúbrica de ingeniería de prompts | 20% | Sesiones 1–4 |
| Proyecto de diseño original con Guía 5 | Rúbrica + revisión de código arquitectónico | 30% | Sesión 5 |
| Prueba post-intervención | Instrumento 3 POST (mismas dimensiones) | 20% | Al finalizar Sesión 5 |
| Participación y trabajo en sesiones | Observación docente + bitácora de campo | 20% | Continua 1–5 |
Indicadores de impacto del programa
| Indicador | Meta mínima | Basado en |
|---|---|---|
| Ganancia en Dimensión C (Arquitectura por capas) | +10 puntos respecto al PRE | Datos piloto: +16.7 puntos |
| Desviación estándar en Dimensión C POST | Menor a 8.0 (mayor homogeneidad) | Datos piloto: DE=1.1 |
| Media del ítem E4 POST ("Cambié cómo le pregunto a la IA") | ≥ 4.00/5.00 | Datos piloto: media=4.50 |
| Media del ítem E6 POST ("Recomendaría guías en otros cursos") | ≥ 4.00/5.00 | Datos piloto: media=4.62 |
Guía de Bitácora de Campo
Durante cada sesión el docente registra observaciones sistemáticas. La bitácora es el instrumento cualitativo que complementa los datos cuantitativos del Instrumento 3.
Indicadores cuantitativos a registrar por sesión
| # | Indicador | Cómo medirlo |
|---|---|---|
| 1 | Número de estudiantes que completan el PRE-IA antes de abrir la IA | Recuento visual al inicio del Momento 2 |
| 2 | Número de estudiantes que intentaron obtener código completo directamente | Observación durante Momento 2 |
| 3 | Número de estudiantes que usaron más de un prompt (prompts de seguimiento) | Observación o revisión de pantallas al finalizar |
| 4 | Número de estudiantes que completaron todas las reflexiones POST-IA | Recuento al recoger el formulario |
| 5 | Tiempo promedio dedicado al Momento 2 por el grupo | Registro en bitácora |
Indicadores cualitativos a registrar por sesión
- Citas textuales de comentarios espontáneos sobre la respuesta de la IA (tanto positivos como críticos)
- Cambios observables en la calidad de las preguntas entre el inicio y el final de la sesión
- Patrones de frustración, sorpresa o comprensión durante la actividad
- Intervenciones del docente que fueron necesarias y el motivo
- Diferencias de comportamiento entre estudiantes con mayor y menor dominio previo
- Guía 5 solamente: número de iteraciones que necesitó cada estudiante antes de que la IA validara su diseño
Preguntas de cierre por sesión (para consignar en bitácora)
Gestión de Riesgos
Cuatro riesgos documentados con respuesta pedagógica concreta para cada uno, basados en las entrevistas docentes (12/12) y la bitácora de campo de la sesión piloto.
El estudiante pide el código completo ignorando el prompt de la guía
- Preguntale: "¿Te explicó el razonamiento arquitectónico o solo te dio el código?"
- Si persiste: pedile que reformule el prompt añadiendo explícitamente la restricción "NO me des el código, solo el razonamiento arquitectónico"
- Recordatorio al grupo: el objetivo no es que el código funcione sino que el estudiante entienda por qué funciona. Un código que funciona y no se puede explicar no vale nada en una evaluación oral.
- Para la bitácora: registre cuántos estudiantes lo hacen en cada sesión — debería disminuir entre la Sesión 1 y la Sesión 5.
La IA comete errores arquitectónicos en su propia respuesta
- No corrija de inmediato — es una oportunidad pedagógica de alto valor.
- Pregúntele al estudiante: "¿Estás de acuerdo con lo que dice la IA aquí? ¿Por qué sí o por qué no?"
- Si el estudiante no detecta el error, úselo como punto de discusión grupal al final de la sesión.
- Conclusión que quiere que el grupo extraiga: la IA no tiene criterio arquitectónico propio — el criterio lo tiene el programador. La IA responde lo que se le pide; el programador es quien juzga si la respuesta es correcta.
Estudiantes sin acceso a internet estable
- Garantice al menos una sesión semanal en el laboratorio institucional para estas actividades.
- ChatGPT, Claude y Gemini tienen versiones accesibles desde celular con datos básicos — no requieren computadora.
- En casos extremos: prepare capturas de pantalla de conversaciones con la IA que el estudiante pueda analizar offline usando los prompts como referencia de qué debería haber preguntado.
- No asigne estas actividades como tarea fuera del aula si no puede garantizar acceso equitativo.
Deshonestidad — el estudiante copia reflexiones generadas por la IA
- Indicador más claro: reflexiones genéricas que no mencionan el código específico del ejercicio ni referencias a su propia propuesta PRE-IA.
- Respuesta pedagógica: pedirle al estudiante que explique oralmente una de sus reflexiones. Si genuinamente aprendió, puede hacerlo; si copió, no puede.
- Diseño preventivo: las preguntas de reflexión incluyen referencias explícitas al propio código del estudiante ("revisá tu propuesta PRE-IA y compará"), lo que hace difícil generar una respuesta válida con IA sin haber hecho el ejercicio.
- No es necesario perseguir casos individuales — el componente oral de evaluación (30%) desincentiva estructuralmente la copia.
Preguntas frecuentes de estudiantes
| Pregunta del estudiante | Respuesta recomendada |
|---|---|
| "¿Puedo usar cualquier herramienta de IA o solo ChatGPT?" | Cualquiera que quieras — ChatGPT, Claude, Gemini, u otra. Las guías funcionan con cualquier LLM porque se centran en principios, no en herramientas. |
| "¿La IA siempre tiene razón sobre arquitectura?" | No. La IA comete errores arquitectónicos. Tu criterio como programador es el que tiene el valor final — la IA es un interlocutor, no un árbitro. |
| "¿Por qué no puedo pedirle el código directamente si es más rápido?" | Porque más rápido no es lo mismo que aprender. En el examen no vas a tener acceso a la IA, y si solo obtuviste el código sin entenderlo, no vas a poder resolver problemas nuevos. |
| "¿El PRE-IA se califica?" | No se califica en puntos, pero forma parte del criterio 5 de la rúbrica. Hacer el PRE-IA bien es lo que hace que tu reflexión POST-IA tenga valor real. |