[Teaching Foundations of AI Programming] - PL Reflection - Project Planning

Discussion Questions:

:one: How will you support students in breaking down their ideas into manageable coding tasks while still allowing for creative freedom in their projects?

:two: What strategies will you use to ensure that students engage in constructive and actionable peer feedback during the review process?

:three: What methods will you use to assess both the process and the final product to ensure students gain both coding proficiency and problem-solving experience?

These questions are just starting points for reflection and discussion — there is no need to answer all of them. Focus on the ones that resonate most with your teaching experience and goals.

Strategies I will use to ensure students engage in constructive and actionable peer feedback during the review process are: having a paper form created, where the sentence starters are printed and students fill in the end of the sentence, or even anchor charts with sentence starters that students can refer to when giving feedback.

I will also model how to engage in feedback with the class and ask for suggestions from the students during the process.

:one: How will you support students in breaking down their ideas into manageable coding tasks while still allowing for creative freedom in their projects?

Helping students identify algorithms that could be written as functions, or to help them identify different repeating steps that could be put into a loop.

:two: What strategies will you use to ensure that students engage in constructive and actionable peer feedback during the review process?

I use TAG- Tell something you like, ask a question, give an “I wonder if” statement

:three: What methods will you use to assess both the process and the final product to ensure students gain both coding proficiency and problem-solving experience?

I think a rubric would be nice. We are a schoology school and I use rubrics often for projects such as this.

These questions are just starting points for reflection and discussion — there is no need to answer all of them. Focus on the ones that resonate most with your teaching experience and goals.

1 Like

:one: How will you support students in breaking down their ideas into manageable coding tasks while still allowing for creative freedom in their projects?
I find many students benefit by saying the steps out loud. If there is a step that is too broad (like draw a circle) can can be prompted to break it down into smaller steps. "Is there a command to make a circle? What commands could you combine to do that?
:two: What strategies will you use to ensure that students engage in constructive and actionable peer feedback during the review process?
I will monitor all student comments for appropriateness. I will also have students underline the “actionable” part of the feedback before turning it back to the other student.
:three: What methods will you use to assess both the process and the final product to ensure students gain both coding proficiency and problem-solving experience?
I would grade both the activity guide (including giving and recieving peer feedback) and the final code/product/pixel art. I would add questions to the guide about how the student used problem solving in their work.

Como docente, considero que es importante ayudar a los estudiantes a dividir sus proyectos en pequeñas tareas alcanzables. Para lograrlo, les pediría que primero identifiquen el objetivo principal de su programa y después lo descompongan en pasos sencillos, como diseñar el algoritmo, programar una función a la vez, probar cada parte y, finalmente, integrar todos los elementos. De esta manera, mantienen la libertad de crear proyectos originales sin sentirse abrumados por la complejidad.

Para que la retroalimentación entre compañeros sea útil y respetuosa, utilizaría una guía con preguntas específicas, por ejemplo: ¿Qué funciona bien?, ¿Qué podría mejorarse? y ¿Qué sugerencias concretas ayudarían a fortalecer el proyecto? Esto fomenta comentarios constructivos y permite que los estudiantes aprendan tanto al recibir como al ofrecer retroalimentación.

En cuanto a la evaluación, combinaría la valoración del proceso y del producto final. Observaría aspectos como la planificación, la descomposición del problema, las pruebas realizadas, la capacidad para corregir errores y la colaboración durante el desarrollo. Además, evaluaría si el programa cumple con los objetivos planteados y si el estudiante puede explicar las decisiones que tomó para resolver el problema. De esta forma, se reconoce no solo el resultado final, sino también el desarrollo del pensamiento computacional y de las habilidades de resolución de problemas.

1.- Descomponer ideas en tareas manejables sin perder creatividad
Mapas de proyecto: pedir a los estudiantes que dibujen un esquema de su idea y luego lo traduzcan en pasos concretos (ej. “mover al pintor”, “pintar color”, “verificar condición”).

Mini‑funciones: enseñarles a encapsular acciones repetidas en funciones (move_fast(), paint_line()) para que puedan construir proyectos más grandes sin perder control.

Plantillas flexibles: darles ejemplos básicos de código que ellos puedan modificar libremente, como un “esqueleto” que admite creatividad.

Analogías visuales: comparar un programa con una receta: primero se listan ingredientes (variables), luego pasos (funciones), y finalmente se ajusta el sabor (creatividad).
2.- Estrategias para retroalimentación entre pares
Guías de retroalimentación: proporcionar una rúbrica sencilla con frases modelo (“Me gustó cómo usaste…”, “Podrías mejorar si…”).

Roles rotativos: asignar a cada estudiante un rol (revisor de lógica, revisor de estilo, revisor de claridad) para que la retroalimentación sea específica.

Tiempo estructurado: dedicar unos minutos al final de cada sesión para que los pares intercambien proyectos y den comentarios.

Ejemplos de retroalimentación constructiva: mostrar cómo un comentario vago (“está mal”) se convierte en uno útil (“la función no se ejecuta porque falta sangría en la línea 5”).
3.- Evaluar proceso y producto final
Proceso:

Revisar bitácoras o diarios de programación donde los estudiantes anoten errores y cómo los resolvieron.

Observar si aplican estrategias de depuración y si dividen el problema en pasos.

Producto final:

Evaluar si el programa cumple la tarea propuesta.

Analizar claridad del código (uso de funciones, comentarios, legibilidad).

Balance:

Usar rúbricas que ponderen tanto la solución técnica como la creatividad y la reflexión.

Valorar la capacidad de explicar su propio código, no solo que “funcione”.

Para garantizar que los estudiantes desarrollen tanto habilidades de programación como capacidades para resolver problemas, utilizaría estrategias de evaluación formativa, colaborativa y basada en evidencias.

  • Rúbrica sencilla de revisión entre pares: los estudiantes revisarían el trabajo de un compañero considerando criterios como funcionamiento del programa, claridad del código, creatividad y solución del problema.

  • Protocolo “Dos fortalezas y una sugerencia”: cada estudiante identificaría dos aspectos positivos y propondría una mejora concreta.

  • Preguntas guía: en lugar de limitarse a decir “está bien” o “está mal”, utilizarían preguntas como: ¿Qué parte del código funciona mejor? ¿Dónde encontraste una dificultad? ¿Qué cambiarías para mejorar la solución?

  • Revisión del código en parejas: los estudiantes explicarían a su compañero cómo funciona su programa y recibirían preguntas o sugerencias.

  • Retroalimentación durante el proceso: se realizarían varias revisiones antes de entregar el producto final, de manera que los estudiantes puedan aplicar las sugerencias recibidas.

  • Autoevaluación y reflexión: después de recibir comentarios, cada estudiante señalaría qué sugerencia incorporó y por quéMétodos para evaluar el proceso y el producto final

    Evaluación del proceso:

    • Observación del trabajo individual y colaborativo.
    • Registro de avances, errores y modificaciones realizadas.
    • Revisión de los intentos de solución y de la capacidad para depurar el código.
    • Diario o bitácora de programación donde expliquen qué problema encontraron, qué estrategias utilizaron y cómo lo solucionaron.
    • Autoevaluación y coevaluación.
    • Participación en las revisiones entre pares.