Cómo evaluar programación con IA en FP sin prohibirla

En el artículo Cuando la IA hace las tareas pero no hay aprendizaje real dejé una solución pendiente.

El diagnóstico era bastante claro: una entrega final limpia no demuestra que haya comprensión detrás. Lo que quedaba por explicar era cómo evaluar en ese contexto sin convertir cada actividad en una investigación para descubrir si el alumno ha utilizado una herramienta.

Mi punto de partida es sencillo: no creo que prohibir la IA resuelva el problema. Tampoco creo que haya que aceptarla sin límites. En programación puede ser un apoyo muy útil, pero solo si el alumno sigue siendo responsable de entender, revisar y validar lo que entrega.

La cuestión no es conseguir que la IA no aparezca. La cuestión es diseñar actividades en las que utilizarla no permita ocultar la falta de conocimiento técnico.

Prohibir la herramienta no es evaluar mejor#

La prohibición puede parecer una respuesta clara porque simplifica la norma. Si no se puede utilizar la IA, pensamos, todo lo que aparezca en la entrega tendrá que salir del alumno.

Pero una evaluación no mejora solo porque retiremos una herramienta. También podemos pedir una solución completamente manual y seguir sin saber si el alumno entiende el código, si memoriza procedimientos sin comprenderlos o si sabe transferir lo aprendido a un problema distinto.

Además, programar con herramientas de apoyo forma parte del contexto profesional al que queremos preparar al alumnado. La solución no es fingir que ese contexto no existe, sino enseñar a trabajar dentro de él sin delegar el pensamiento.

No plantearía una actividad en la que la IA pueda generar la solución completa y la única evidencia sea el resultado final. Pero tampoco plantearía otra cuyo objetivo principal fuera demostrar que nadie ha abierto un asistente. En los dos casos estaríamos prestando demasiada atención a la herramienta y demasiado poca al aprendizaje.

La misma ayuda no sirve igual para todos los niveles#

La IA no tiene el mismo papel cuando alguien está construyendo sus primeras nociones de programación que cuando ya puede analizar una solución con cierta autonomía.

Para quien está empezando, puede ser útil pedir más ejemplos de un concepto, solicitar una explicación con un nivel de dificultad menor o pedir que una explicación se reformule como lo haría un profesor. También puede ayudar a adaptar un texto para un alumno que tiene dificultades de comprensión lectora.

Eso no significa aceptar cualquier respuesta como correcta. Un ejemplo puede estar mal elegido. Una explicación puede simplificar tanto un concepto que termine deformándolo. Un texto adaptado puede perder una idea importante. La ayuda sirve si después se contrasta con el contenido que se está aprendiendo y se comprueba que conserva su sentido.

En esta etapa, probablemente pediría al alumno que explique con sus palabras qué ha entendido, que compare dos ejemplos y que construya uno propio. La IA puede aportar más caminos para llegar al concepto, pero no puede recorrerlos por él.

Cuando el alumno ya tiene una base, la herramienta puede utilizarse para comparar alternativas, localizar posibles errores o discutir decisiones de diseño. La pregunta interesante no es “¿qué código me da?”, sino “¿por qué esta solución podría ser mejor que esta otra?, ¿qué problema resuelve?, ¿qué coste introduce?”.

Y en niveles más avanzados sí tiene sentido acercar la actividad a un contexto parecido al de una empresa. Se puede plantear un requisito, una incidencia o una solución inicial y pedir que el alumno utilice la IA como parte de su proceso de trabajo. Tendrá que hacer preguntas, analizar las respuestas, separar lo útil de lo dudoso, probar el código y validar que realmente resuelve el problema.

Ahí la IA deja de ser un atajo para terminar antes y se convierte en una herramienta dentro de una tarea profesional. Pero solo funciona así cuando el alumno tiene conocimientos suficientes para discutir con ella.

La frontera no está en el prompt, sino en el conocimiento técnico#

Se habla mucho de aprender a escribir mejores instrucciones para la IA. Es una habilidad útil, pero no es la base de la programación.

Un alumno puede redactar una petición muy detallada y seguir sin entender qué hace el código que recibe. Puede describir perfectamente una funcionalidad y no saber por qué falla cuando cambia una entrada, qué supuesto ha hecho la solución o qué parte debería modificar.

La frontera que no podemos mover es la del conocimiento técnico. Para trabajar con una propuesta generada por IA, el alumno tiene que poder leerla, explicar sus decisiones principales, seguir el recorrido de los datos, identificar sus supuestos y reconocer cuándo el resultado no encaja con el problema.

También tiene que saber probarla. No basta con ejecutar el caso feliz y comprobar que aparece algo en pantalla. Hay que pensar qué ocurre con una entrada vacía, con un valor inesperado, con un límite o con una combinación que la solución no haya contemplado. Hay que observar el resultado, corregir lo necesario y justificar por qué la versión final es válida.

No hace falta saberlo todo antes de pedir ayuda. Aprender también consiste en preguntar. Pero sí hace falta saber lo suficiente para distinguir una explicación razonable de una respuesta que solo suena convincente.

Si el alumno no puede explicar, probar, corregir y validar la solución, entonces la IA no le está apoyando. Está haciendo la parte más importante del trabajo.

Evaluar el proceso en lugar de perseguir la herramienta#

La forma más útil de saber si hay aprendizaje no es intentar adivinar si la IA se ha utilizado. Es pedir evidencias que una respuesta copiada no pueda sustituir fácilmente.

No me refiero a exigir una transcripción completa de cada conversación con el modelo. Eso convertiría la evaluación en una colección de prompts y tampoco demostraría comprensión. Me refiero a hacer visible el razonamiento que hay entre el problema y la solución.

En una actividad de programación pediría, por ejemplo, varias piezas de evidencia conectadas entre sí:

• La interpretación del problema. Qué se pide, qué restricciones hay y qué parte necesita aclaración antes de escribir código.
• El plan inicial. Qué solución propone el alumno antes de apoyarse en una herramienta, aunque sea un esquema breve o pseudocódigo.
• Las preguntas y decisiones relevantes. Qué ha preguntado, qué alternativas ha considerado y por qué ha aceptado, modificado o rechazado una propuesta.
• La explicación técnica. Qué hace la solución, qué conceptos utiliza y qué partes son especialmente importantes o delicadas.
• Las pruebas. Qué casos ha elegido, qué esperaba que ocurriera, qué ocurrió realmente y qué ha cambiado después de probar.
• La validación final. Por qué considera que la solución responde al requisito y qué límites o supuestos siguen existiendo.

No todas las actividades necesitan exactamente el mismo documento. En una tarea breve bastará con una explicación y algunas pruebas. En un proyecto más abierto tendrá sentido conservar decisiones, alternativas y cambios. Lo importante es que la evidencia acompañe al código en lugar de aparecer únicamente cuando llega la entrega.

Una conversación breve también puede aportar mucho. Pedir al alumno que explique una función, que justifique una decisión o que adapte la solución a un cambio de requisito permite observar si el conocimiento se puede transferir. No como un interrogatorio para descubrir una trampa, sino como una parte normal de defender un trabajo técnico.

Qué debería mirar una rúbrica#

La rúbrica no debería tener un criterio oculto llamado “no ha usado IA”. Si la herramienta está permitida dentro de unos límites claros, su uso no puede ser automáticamente positivo ni negativo.

Lo que sí se puede observar es otra cosa:

• si el alumno ha entendido el problema antes de buscar una solución;
• si maneja los conceptos técnicos necesarios para explicar el código;
• si hace preguntas que ayudan a avanzar y no solo a obtener una respuesta completa;
• si detecta errores, supuestos débiles o decisiones que no encajan con el requisito;
• si diseña y ejecuta pruebas con sentido;
• si corrige la solución a partir de la evidencia;
• si puede defenderla y adaptarla cuando cambia una condición.

El resultado final sigue importando. Un programa que no funciona no se convierte en una buena entrega porque el proceso esté documentado. Pero el resultado tampoco puede ser la única medida, porque un código correcto por casualidad o por delegación completa no demuestra el mismo aprendizaje que una solución comprendida y validada.

La diferencia está en qué hacemos visible. Si solo evaluamos el producto, la IA puede ocultar el proceso. Si evaluamos producto, razonamiento y validación, la herramienta pierde capacidad para maquillar una carencia técnica.

La dificultad de la tarea debe cambiar con el nivel#

También sería un error pedir exactamente la misma relación con la IA a todo el alumnado.

Cuando todavía se están construyendo los fundamentos, la actividad debe ayudar a consolidarlos. Se puede permitir la búsqueda de ejemplos o una explicación alternativa, pero exigir que el alumno reconstruya el concepto, escriba una solución propia y pueda explicar cada paso. La autonomía se construye antes de poder delegar partes del trabajo sin perder el control.

Cuando existe una base más sólida, la tarea puede tener más incertidumbre. En vez de pedir únicamente que se implemente una función, se puede pedir que se interprete un requisito incompleto, se comparen dos aproximaciones, se detecten riesgos en una propuesta o se revise una solución que parece correcta pero tiene un caso límite.

En ese segundo escenario la IA puede acercar bastante la actividad a una situación profesional. Pero lo que se evalúa no es la velocidad con la que el alumno obtiene código. Se evalúa si sabe convertir una necesidad en preguntas, analizar una respuesta, comprobarla y hacerse responsable de la decisión final.

Ese es el tipo de criterio que no desaparece cuando cambia el lenguaje, el framework o la herramienta.

Primero los fundamentos, después el apoyo#

Esto conecta con algo que he aprendido enseñando programación: todo conocimiento técnico tiene prerequisitos. No se puede pedir que alguien evalúe una arquitectura si todavía no entiende qué problema resuelve una función, del mismo modo que no se puede pedir que valide código generado si no sabe leerlo.

La IA no elimina esa secuencia. Si acaso, la hace más visible. Cuanto más fácil es producir una solución aparentemente terminada, más importante es haber construido antes los modelos mentales que permiten revisarla.

Por eso no empezaría enseñando a buscar la respuesta perfecta en un modelo. Empezaría enseñando a entender el problema, descomponerlo, escribir una primera hipótesis y comprobarla. A partir de ahí, la IA puede aportar ejemplos, otras explicaciones o una propuesta para discutir.

Con el alumnado que necesita más apoyo, adaptar un texto o pedir una explicación diferente puede abrir una puerta que estaba cerrada. Con el alumnado que ya tiene una base, trabajar con una solución propuesta puede acercarle a la forma de analizar que encontrará en un equipo profesional. En los dos casos, el objetivo sigue siendo el mismo: que la ayuda aumente su capacidad, no que la sustituya.

La pregunta que deberíamos hacer#

No quiero que el alumnado termine aprendiendo a producir código que parece profesional sin saber qué está entregando. Tampoco quiero que llegue a una empresa pensando que pedir ayuda es una debilidad o que tiene que resolver todo desde cero para demostrar su valor.

Quiero que sepa pedir ayuda, pero también que sepa juzgarla. Que pueda aceptar una propuesta cuando está bien fundamentada, modificarla cuando no encaja y rechazarla cuando el problema exige otra cosa. Que entienda que probar y validar no son trámites posteriores, sino parte de programar.

Por eso la pregunta de una evaluación no debería ser únicamente “¿has usado IA?”. Debería ser: ¿qué has entendido, qué decisiones has tomado y cómo sabes que tu solución funciona?

No prohibir la IA no significa dejarla entrar en el aula sin diseño. Significa cambiar el foco: de perseguir una herramienta a observar el conocimiento, el proceso y el criterio técnico.

La IA puede escribir una parte del código. La responsabilidad de entenderlo, probarlo y validarlo sigue siendo del alumno. Y esa responsabilidad es, precisamente, lo que tenemos que enseñar y evaluar.