IA para EstudiarPrompts de programación y datos
Entender un fragmento de código línea a línea
Programación y datosCuando te dan código en clase o en un ejercicio y lo ejecutas sin saber por qué funciona.
Eres un/a profesor/a de programación. Estoy aprendiendo [LENGUAJE] y quiero comprender este código: [CÓDIGO]. Tarea: explícalo línea a línea con una traza de ejemplo (valores de las variables paso a paso con la entrada [ENTRADA]). Formato: tabla con número de línea, qué hace y estado de las variables; al final, tres preguntas de comprobación sobre qué ocurriría si cambio algo concreto. Restricciones: no modifiques el código ni me lo reescribas «mejorado»; si ves un error, solo indícame en qué línea sospechas y por qué, sin darme el arreglo, y pregúntame primero cómo lo arreglaría yo. No inventes funciones de bibliotecas: si no estás seguro de que existan o de su comportamiento, dilo y dime qué documentación oficial consultar. Avisa de cualquier incertidumbre.
- Ejecuta el código tú mismo y compara con la traza que propone la IA.
- Intenta predecir el resultado antes de leer cada explicación.
Qué esperar: Una traza del código con estado de variables y tres preguntas de comprobación, sin código nuevo. La IA puede describir con aplomo un comportamiento que no es real. Ejecuta, depura y consulta la documentación oficial.
Depurar con pistas en vez de soluciones
Programación y datosCuando tu programa falla y quieres aprender a encontrar el error en lugar de pegar un arreglo.
Quiero aprender a depurar. Mi programa en [LENGUAJE] debería [COMPORTAMIENTO ESPERADO] pero ocurre [COMPORTAMIENTO REAL]. Código: [CÓDIGO]. Mensaje de error, si existe: [ERROR]. Tarea: guíame con pistas progresivas en cuatro niveles: 1) qué debería comprobar o imprimir, 2) en qué zona del código mirar, 3) qué concepto podría estar fallando, 4) solo si te lo pido, la corrección. Entrega un nivel por turno y espera mi respuesta. Restricciones: no me des el código arreglado antes del nivel 4. Si hay varias causas posibles, enuméralas con tu grado de certeza y no afirmes una como cierta si no lo es. Evita inventar nombres de funciones o errores; si dudas, recomiéndame buscar el mensaje en la documentación oficial.
- Cuenta qué pruebas hiciste en cada turno, no solo que sigue fallando.
- Escribe al final en una línea qué causó el fallo para no repetirlo.
Qué esperar: Pistas escalonadas con una hipótesis priorizada y, solo bajo petición, la corrección. No pegues claves, datos personales ni código ajeno confidencial. Prueba cualquier arreglo propuesto antes de darlo por bueno.
Depurar un error pensando tú, no copiando la solución
Programación y datosCuando tu programa falla y quieres aprender a encontrar la causa.
Actúa como mentor/a de programación en [LENGUAJE]. Mi código: [CÓDIGO]. Qué debería hacer: [COMPORTAMIENTO ESPERADO]. Qué hace en realidad: [COMPORTAMIENTO OBSERVADO O MENSAJE DE ERROR]. Tarea: no me des el código corregido. Hazme una pregunta cada vez que me lleve a localizar la causa: qué valor tiene tal variable en tal línea, qué ocurre con la entrada vacía, qué supone esta condición. Si tras tres preguntas no avanzo, dame una pista sobre la zona del código a revisar, no sobre la corrección. Restricciones: no inventes funciones ni opciones de la biblioteca; si sospechas de una función cuyo comportamiento no estás seguro, dilo y dime que mire la documentación oficial. Indica tu nivel de certeza en cada hipótesis.
- Añade impresiones de variables o usa el depurador y cuenta lo que ves.
- Cuando lo arregles, explica la causa con tus palabras.
Qué esperar: Una sucesión de preguntas y pistas que localizan el fallo sin entregar el parche. Prueba cualquier cambio con tus propios casos de prueba; una hipótesis plausible puede ser falsa.
Entender un fragmento de código línea a línea
Programación y datosCuando tienes que estudiar código de apuntes, ejemplos o un compañero y no lo entiendes.
Eres profesor/a de programación de nivel [NIVEL] y el lenguaje es [LENGUAJE]. Te paso un fragmento: [CÓDIGO]. Tarea: 1) resume en dos frases qué hace en conjunto; 2) explícalo en bloques de pocas líneas, diciendo qué hace cada uno y por qué está ahí; 3) haz una traza con una entrada que te daré yo: [ENTRADA]; 4) lista tres cambios pequeños en el código y pídeme que prediga el efecto antes de contártelo. Formato: secciones numeradas. Restricciones: no reescribas el código ni lo optimices; no afirmes qué hace una función de biblioteca si no estás seguro, di «revisar documentación». Si ves algo que parece un error, señálalo como sospecha y no como hecho.
- Ejecuta tú el código con la entrada propuesta y compara con la traza.
- Pide después un ejercicio parecido sin el código resuelto.
Qué esperar: Resumen, explicación por bloques, traza paso a paso y tres predicciones propuestas. La traza puede equivocarse: ejecuta el código y compáralo con lo que dice la explicación.
Revisión de código de práctica con criterios de clase
Programación y datosCuando entregas un ejercicio de programación y quieres un repaso previo.
Actúa como revisor/a de código para estudiantes de [LENGUAJE] en [CURSO O ASIGNATURA]. Enunciado de la práctica: [ENUNCIADO]. Mi solución: [CÓDIGO]. Criterios de evaluación de mi profesor: [CRITERIOS]. Tarea: revisa el código según esos criterios y devuelve una lista de observaciones, cada una con línea o zona, el problema, por qué importa y una pregunta para que lo resuelva yo. Ordénalas de más a menos importante. Restricciones: no me des el código corregido; no añadas requisitos que no estén en el enunciado; no inventes convenciones de estilo, usa solo las de mis criterios. Si no puedes comprobar que el código compila o funciona sin ejecutarlo, dilo claramente. Cierra con tres casos de prueba que yo debería ejecutar, incluido un caso límite.
- Ejecuta los tres casos de prueba antes de entregar.
- Revisa que la entrega sea realmente tuya y respeta la normativa de tu asignatura sobre IA.
Qué esperar: Lista priorizada de observaciones con pregunta guía y tres casos de prueba para ejecutar. La revisión no sustituye ejecutar el código ni a tu profesor; el asistente no lo ha corrido.
Serie de ejercicios graduados de un concepto
Programación y datosCuando quieres practicar un concepto de programación con dificultad creciente.
Eres profesor/a de [LENGUAJE]. Concepto a practicar: [CONCEPTO, POR EJEMPLO BUCLES O RECURSIVIDAD]. Mi nivel actual: [NIVEL]. Tarea: propón cinco ejercicios de dificultad creciente, cada uno con enunciado, ejemplo de entrada y salida esperada, y la competencia que entrena. Sin soluciones. Cuando te envíe mi código para un ejercicio, responde solo con dos cosas: si cumple la salida esperada en el ejemplo según tu lectura y una pista sobre el siguiente paso. Restricciones: los ejemplos de entrada y salida deben ser verificables a mano; si no estás seguro de una salida, dilo; no uses funciones de biblioteca que dispensen de practicar el concepto. Indica al final qué conceptos previos debería repasar si fallo el cuarto ejercicio.
- Resuelve cada ejercicio antes de pedir el siguiente.
- Comprueba tú las salidas esperadas calculándolas a mano.
Qué esperar: Cinco ejercicios graduados con entradas y salidas esperadas, sin soluciones. Verifica las salidas de ejemplo ejecutando o calculando; puede haber ejemplos mal resueltos.