La mitad de los errores de mis alumnos no están en el código

Hay una escena que se repite constantemente en soporte. Un alumno me manda un script, lo reviso línea por línea y está bien. No tiene errores. Sin embargo, lleva tres días atascado, ha copiado el mensaje de la consola en una IA quince veces y cada respuesta le ha roto una cosa distinta.

El problema no estaba en el script. Estaba a pocos centímetros de distancia, en una ventana del editor que la IA no podía ver.

Después de años corrigiendo proyectos, sobre todo de programación y desarrollo de videojuegos, he llegado a una conclusión un poco incómoda: muchos errores que parecen errores de código son, en realidad, errores de estado del proyecto. Están en una referencia no asignada, un componente ausente, la configuración de una capa, la versión de una librería o una API que ya no existe.

Y claro, cuando le das a una IA únicamente el código y una línea de error, le estás enseñando una pieza de un puzle enorme. Después le pides que te diga qué falla. No es que el modelo sea malo o inútil. Es que está intentando diagnosticar un proyecto al que le faltan paredes, puertas y media instalación eléctrica.

El script sin errores que no funcionaba

Un alumno estaba creando una mecánica de disparo en Unity. Quería que su personaje lanzase una bala, así que utilizó un script que instanciaba el prefab y aplicaba velocidad a través de un Rigidbody, usando el sistema de físicas.

La lógica era correcta. El código pedía un componente físico, tomaba su referencia y le aplicaba movimiento. Lo ejecutó y el juego lanzó el clásico error:

Object reference not set to an instance of an object.

Ese mensaje es especialmente traicionero para quien empieza. No te explica la causa real, no señala de forma clara qué referencia falta y tampoco te dice dónde mirar. Entonces llega la reacción natural: copiar el error, abrir ChatGPT, Claude, Gemini o el modelo que toque, y escribir: “No funciona”.

La IA responde con mucha seguridad. Sugiere comprobar valores nulos, probar a buscar el componente con GetComponent, añadir condiciones, evitar que el objeto se destruya antes de tiempo o reescribir el script entero. Todas esas ideas pueden ser técnicamente razonables.

Pero ninguna solucionaba el problema.

El prefab de la bala no tenía un Rigidbody. El código lo buscaba, pero ese objeto nunca había tenido el componente asignado. La solución fue un clic en “Añadir componente”. Tres días perdidos, quince conversaciones con IA y un script cada vez más grande para resolver algo que no vivía en el código.

En Unity esto se ve clarísimo porque una parte enorme del programa vive en el Inspector, en la jerarquía y en los prefabs. Pero no es un problema exclusivo de Unity. En aplicaciones web, móviles, ciencia de datos o trading algorítmico ocurre exactamente lo mismo.

Las cinco cosas que la IA no puede ver de tu proyecto

La IA ve el texto que le pegas. Tu proyecto, en cambio, es un sistema completo. Estas son las cinco zonas ciegas que más errores generan.

1. El estado real de la escena o de la aplicación

¿Qué objetos existen? ¿Cuál depende de cuál? ¿Qué elemento está activo, desactivado, oculto o destruido? En Unity hablamos de jerarquía y escena. En desarrollo web, el equivalente sería el DOM real una vez que la página ha ejecutado scripts, renderizado componentes y aplicado sus cambios.

El archivo puede estar perfecto y aun así fallar porque el objeto que debía existir no está, está desactivado o no es el que creías que era.

2. Los componentes y las referencias asignadas

Un prefab puede llamarse igual que otro y ser completamente diferente. Puede faltar un Rigidbody, un Collider, un script o una referencia serializada. También es muy habitual arrastrar un objeto desde la escena cuando lo que tocaba era asignar el prefab que está guardado en la carpeta del proyecto.

La diferencia puede parecer mínima, pero cambia todo. Y no aparece en el fragmento de código que has pegado en el chat.

3. La versión exacta de tus herramientas

La IA suele darte la respuesta más probable entre todo lo que ha leído. El problema es que Internet está lleno de ejemplos antiguos. Si una API funcionó durante diez años y cambió hace poco, es fácil que recibas código obsoleto presentado como si fuera actual.

Esto afecta a Unity, paquetes, librerías, frameworks, SDKs y servicios externos. La versión de Unity, del paquete o de la dependencia no es un detalle menor. Puede ser literalmente el motivo de que algo funcione en un proyecto y se rompa en otro.

4. La configuración del proyecto

Capas, etiquetas, matrices de colisión, sistema de entrada, permisos, variables de entorno, credenciales o ajustes de compilación. Nada de eso está necesariamente en un script, pero todo puede decidir si el script funciona o no.

En un juego, dos objetos pueden tener componentes perfectos y no detectar nunca una colisión porque las capas no interactúan entre sí. El código no tiene por qué estar roto. La configuración es la que está diciendo que no ocurra nada.

5. Todo lo que ya has probado

Este es el punto más frustrante. La IA no recuerda automáticamente que su recomendación de hace diez minutos ya falló, salvo que se lo indiques de forma explícita. Por eso puede volver a sugerirte la misma solución, reformulada con otras palabras y con la misma seguridad.

Tú tienes un sistema completo. La IA solo ve texto. Si le pegas errores aislados, le estás dando una pequeña parte del problema y, muchas veces, no la parte culpable.

Por qué la IA no suele decir “no puedo saberlo”

No te culpes por caer en este bucle. La interfaz está diseñada para que pegues un error y recibas una solución inmediata. La respuesta suena profesional, está bien escrita y parece convincente. Haces exactamente lo que la herramienta te ha enseñado a hacer.

Pero un modelo de lenguaje, cuando tiene información incompleta, no se queda necesariamente callado. Genera la opción que considera más probable. El problema es que la respuesta correcta para el error medio de Internet puede no tener nada que ver con tu error concreto.

Ahí comienza la espiral:

• Pegas el error y pides una solución.
• La IA cambia código que tal vez ya estaba bien.
• Aparece un error nuevo.
• Pegas el error nuevo.
• El archivo crece con parches sobre parches.

Llega un momento en el que ya no reconoces tu propio script. No sabes qué escribiste tú, qué añadió la IA y qué partes son intentos desesperados para arreglar otro intento anterior. No estás depurando. Estás enterrando el fallo bajo más código y más tokens.

Los cuatro errores que aparecen una y otra vez

Hay decenas de variantes, pero durante años he visto los mismos cuatro problemas disfrazados de errores de programación.

Algo no está donde crees

Puede ser un campo serializado vacío, un prefab equivocado, un objeto arrastrado desde el lugar incorrecto o una referencia que apuntaba a un elemento de escena y ya no existe. El error suele aparecer donde se usa ese recurso, no donde debió configurarse.

Estás utilizando una API que ya no existe

Esto da especialmente rabia porque la IA puede insistir con código que parece impecable. Ha ocurrido con APIs de datos financieros, librerías y servicios que han cambiado su forma de autenticarse, sus endpoints o sus métodos disponibles.

La solución no es generar más adaptaciones del mismo código antiguo. Es comprobar la documentación y la versión real de la herramienta que estás usando.

Has creado un proyecto Frankenstein

El copia y pega no nació con la IA. Antes se hacía desde foros y respuestas de Stack Overflow. La diferencia es que ahora el proceso va muchísimo más rápido. En pocos minutos puedes acumular decenas de líneas que no entiendes y que pertenecen a enfoques distintos.

Si no sabes qué hace cada bloque, no puedes aislar el problema cuando algo falla. El objetivo no es escribir todo a mano por orgullo. El objetivo es no incorporar código que no eres capaz de leer, explicar y modificar.

Has entrado en el bucle de regeneración

Este no es tanto el error como su síntoma. Si llevas tres intentos, el fallo sigue donde estaba y el script tiene el doble o el triple de líneas, para. No estás progresando. Estás convirtiendo un problema pequeño en uno más difícil de entender.

Antes de abrir la IA: tres preguntas para aislar el fallo

La solución empieza por mirar el sitio correcto durante treinta segundos. Antes de pedir código, responde estas tres preguntas en orden.

1. ¿Puedo reproducir el error a voluntad?

Si no sabes exactamente qué pasos provocan el fallo, todavía no tienes un error definido. Tienes una sensación. Y una sensación no se puede depurar.

Descríbelo en una frase concreta: “Cuando pulso disparar con este objeto seleccionado, el juego falla”. Solo el hecho de formularlo así ordena tu cabeza y, muchas veces, hace aparecer la causa.

2. ¿Es un error de código o de estado?

Si el compilador señala una línea, la lógica hace algo diferente a lo esperado o hay una instrucción mal escrita, la IA puede ser muy buena compañera. Ahí sí tiene sentido pedir ayuda.

Pero si el código parece correcto, a otra persona le funciona el mismo archivo, funcionaba ayer sin cambios aparentes o falla solo en tu proyecto, sospecha primero del estado del sistema.

En Unity hay un atajo muy útil: si tienes una NullReferenceException, empieza por el Inspector antes de tocar el script. Comprueba qué tiene realmente el objeto, qué referencias están asignadas y qué componente falta.

3. ¿Qué información debo aportar además de los errores?

Un mensaje de consola aislado es uno de los peores prompts posibles. Para obtener una respuesta útil, añade el contexto que el modelo no puede ver:

• La versión de Unity, del paquete, la librería o la API.
• El estado relevante del objeto, la escena o la configuración.
• Los componentes y referencias que ya están asignados.
• Las pruebas que has hecho y que no han funcionado.
• El comportamiento esperado y el comportamiento real.

Y añade una instrucción muy simple que cambia por completo la conversación: “Si te falta información para diagnosticarlo, pregúntame antes de darme código”.

Con esa frase le das permiso al modelo para hacer algo que no suele hacer por defecto: parar y pedir contexto.

La habilidad que la IA no te ha quitado

Esto no va de estar contra la inteligencia artificial. Yo la utilizo todos los días y es una herramienta brutal para producir, aprender, explorar alternativas y acelerar muchas tareas. El problema aparece cuando delegamos el criterio.

Generar código ya no diferencia a casi nadie. Con una suscripción, cualquiera puede producir cientos de líneas en segundos. Entender por qué un sistema no funciona, en cambio, sigue siendo una habilidad enorme.

Cada vez que sales de un atasco mirando el Inspector correcto, comprobando una versión, revisando una referencia o reduciendo el problema hasta poder reproducirlo, estás construyendo un mapa mental de tu proyecto. La próxima vez no necesitarás tres días para resolver el mismo tipo de fallo.

Quien solo regenera empieza desde cero en cada error. No porque sea peor programando, sino porque no ha llegado a mirar dentro del sistema.

Si quieres aprender a utilizar la IA con más criterio, pasar de generar código a ciegas y dirigir herramientas y agentes sabiendo qué pedirles y cuándo, puedes conocer la formación De Vibe Coder a Ingeniero Agéntico. Y si estás construyendo juegos, también tienes disponibles nuestros cursos de Unity para trabajar estas bases con proyectos reales.

No es que no valgas para programar, crear videojuegos o desarrollar una web. Probablemente estabas intentando depurar con los ojos vendados. La buena noticia es que el interruptor de la luz está ahí, y se enciende mucho antes de escribir otra línea de código.