XXVI. Que PINSAPIA no se invente errores de sintaxis (ni deje de ver los reales)

Esta entrada nace directamente de la anterior. Al escribir la ficha de repaso confirmamos, con un caso real, el límite más incómodo del modelo que corre en ROCKY: puede sonar convincente y equivocarse en un detalle técnico concreto, incluso citando bien una fuente de verdad. Ese mismo día nos preguntamos: si eso pasa explicando algoritmos, ¿qué pasa cuando un alumno le pega un trozo de código y le pregunta por qué no funciona? Ahí el riesgo es el mismo, solo que con otro disfraz: que PINSAPIA “diagnostique” un error de sintaxis que no existe, o que no vea uno que sí está ahí.

La solución: no dejar que la IA lo decida

La respuesta es la misma que ya usamos para la calculadora, el tiempo o la búsqueda en internet: antes de que el modelo entre en juego, un paso determinista en Python comprueba el dato de verdad. En este caso, el dato es muy concreto — ¿tiene este código un error de sintaxis real, sí o no? — y Python ya trae de serie una herramienta que lo sabe con certeza: ast.parse(), la misma función que usa el propio intérprete para leer un programa antes de ejecutarlo. Si ast.parse() no se queja, no hay error de sintaxis. Si se queja, dice exactamente en qué línea y por qué. No hace falta que lo adivine un modelo de 3B parámetros: lo puede saber con seguridad absoluta un módulo de la biblioteca estándar.

Así que ahora, cuando un mensaje incluye un bloque de código señalado con las tres comillas invertidas (“`), PINSAPIA lo comprueba con ast.parse() antes de responder, y le pasa al modelo el resultado ya verificado — en los dos sentidos: tanto si hay un error real como si no lo hay. La instrucción es explícita: no lo contradigas, no inventes uno distinto, no digas que hay un error si ast.parse() dice que no lo hay.

Una aclaración importante, que también se le dice al propio modelo en el prompt: esto solo comprueba la sintaxis, no la lógica. Un programa puede estar perfectamente bien escrito y aun así no hacer lo que su autor pretendía (un bucle que nunca termina, una condición al revés). Eso sigue siendo terreno del razonamiento del modelo, como siempre — lo que ya no es terreno suyo es decidir si el código, tal cual está escrito, es sintácticamente válido.

Cómo se usa

No hace falta ningún botón nuevo ni cambiar de modo: se usa en el chat normal, con cualquier corpus seleccionado. Solo hay que escribir el código dentro de un bloque delimitado por “`, idealmente marcado como Python:

Ayúdame con este código, no me funciona:
```python
def es_par(numero)
    return numero % 2 == 0
```

Con ese ejemplo (le falta el : al final del def), PINSAPIA responde con la certeza de que hay un error real en esa línea, en vez de tener que suponerlo por el estilo del código.

Y con un bloque correcto:

Revísame este código:
```python
def es_par(numero):
    return numero % 2 == 0

print(es_par(4))
```

confirma que no hay ningún error de sintaxis, sin inventarse uno que no existe — que es justo el fallo contrario, y el que más preocupaba después de lo visto con la búsqueda en internet.

Qué detecta y qué no (límites honestos)

• Solo mira bloques de código delimitados con “`. Si el alumno pega el código suelto, sin ese formato, esta comprobación no se activa — es una limitación real, no un descuido: detectar código Python suelto dentro de una frase cualquiera, sin confundirlo con otra cosa, es mucho menos fiable.
• Si el bloque va marcado explícitamente como otro lenguaje (“`javascript, “`java…), no se toca: no es su sitio, y ast.parse() de Python no tiene nada que decir sobre JavaScript o Java.
• Si el bloque no lleva ninguna etiqueta, solo se analiza si “parece” Python de verdad (si aparecen palabras como def, import, return, for, class…). Sin este filtro, ast.parse() aceptaría como válida cualquier frase suelta — la palabra “hola” sola, por ejemplo, es una expresión Python perfectamente válida, aunque no sea código de nadie — y diríamos “no tiene errores de sintaxis” de algo que ni siquiera es código.
• Solo sintaxis, nunca lógica. Un código que compila puede seguir estando mal.

Casos de prueba

Antes de subir esto a ROCKY se probó con una batería de 20 comprobaciones, todas en verde. Algunos de los casos, para que quede constancia de qué se ha comprobado de verdad y no solo “se supone que funciona”:

• Un mensaje normal, sin ningún bloque de código → no dice nada (no interfiere en la conversación habitual).
• Un bloque “`python con un error real (falta un :) → detecta el error y da la línea.
• El mismo código, corregido → confirma que no hay ningún error.
• Un bloque marcado como “`javascript con errores → no se toca, como debe ser.
• Un bloque marcado como “`java, válido → tampoco se toca: no es su terreno.
• Un bloque sin etiqueta pero con pinta clara de Python (def, return) → sí se analiza.
• Un bloque sin etiqueta que en realidad es solo una lista de tareas de clase → no se analiza, para no confundirlo con código.
• Un bloque vacío, o un mensaje vacío → no dice nada.
• La palabra “hola” sola, sin etiqueta → no se analiza (no parece código de verdad); la misma palabra, pero con la etiqueta “`python puesta a propósito por el alumno → sí se analiza, y como es una expresión Python válida (aunque no haga nada útil), confirma que no hay error de sintaxis.
• Dos bloques de código en el mismo mensaje → solo se analiza el primero (límite conocido, aceptado por sencillez).
• Un error de indentación (que en Python es técnicamente un tipo distinto de error, pero viene de la misma familia que un error de sintaxis) → también se detecta correctamente.

Siguiente paso

Seguir probándolo con código real de alumnos, no solo con los ejemplos de prueba, para ver cómo se comporta el modelo al explicar el error una vez que ya lo tiene verificado. Y, cuando toque, decidir si merece la pena ampliar esto a otras comprobaciones deterministas del mismo estilo antes de meternos con algo más vistoso, como los diagramas Mermaid.js que también están sobre la mesa.