Inteligencia artificial Programación con IA

La IA ha escrito el código: cómo comprobar que funciona

Le pides a una IA una aplicación sencilla. En un minuto tienes el código, lo ejecutas y aparece una pantalla con buena pinta y sin errores en la consola. Es tentador cerrar el portátil y darse una palmadita en la espalda.

Pero que el programa arranque solo demuestra eso: que arranca. Un coche con el motor encendido no ha demostrado que frene bien ni que llegue a donde querías ir. Con el código generado por IA pasa lo mismo. Puede ser correcto, puede ser solo plausible, y la diferencia únicamente se ve probándolo.

Esta guía es para principiantes. No hace falta saber de testing avanzado; basta con tener claro qué esperas y comprobarlo con método.

Primero, qué debería hacer exactamente

Antes de probar, convierte los requisitos en comportamientos observables. «Que gestione tareas» es tan vago que nadie puede comprobarlo. Comparemos con una lista de tareas de ejemplo, con datos ficticios:

Si añado «Comprar pan», aparece al final de la lista.
Si la marco como hecha, se ve tachada.
Si la borro, desaparece.
Si recargo la página, las tareas siguen como las dejé.

Cada frase es una prueba que puedes hacer con tus propios ojos. Si no sabes cómo verías que algo se cumple, el requisito aún no está bien definido. Y una instrucción así de concreta también le sirve a la IA para acertar a la primera.

Ilustración horizontal de seis capas conectadas que representan una revisión ordenada de código generado por IA: REQUISITOS, COMPORTAMIENTO, DEPENDENCIAS, ERRORES, CLAVES y DATOS, con recordatorios 404, 500 y un candado.

El caso normal y sus primos incómodos

Empieza por el camino feliz: añade «Comprar pan», «Llamar a Marta» y «Regar la albahaca». Todo funciona. Es una buena señal, pero todavía no dice casi nada. Ahora toca portarse mal con la aplicación:

Entrada vacía. Envía el formulario sin texto, o solo con espacios. ¿Rechaza la tarea con un mensaje claro o crea una tarea fantasma sin nombre?
Entrada repetida. Añade «Comprar pan» dos veces. No hay una única respuesta correcta: puede permitirlo o avisar. Lo importante es que decidas qué quieres y que el programa se comporte así siempre.
Entrada muy larga. Pega un texto de 5.000 caracteres. ¿Se rompe el diseño, se corta, da error o lo gestiona con elegancia?
Borrar y recargar. Borra «Llamar a Marta» y recarga la página. Si la tarea reaparece, solo se había escondido tras la cortina; no estaba borrada de verdad donde se guardan los datos. (Marta, por cierto, sigue esperando esa llamada.)

Cuando algo falla fuera de tu pantalla

Casi cualquier aplicación habla con un servidor, y los servidores fallan. Un buen programa no se limita a funcionar cuando todo va bien: sabe qué hacer cuando no. Conviene probar estos casos:

Error de red. Desconecta el wifi, o usa el modo sin conexión de las herramientas de desarrollo del navegador, e intenta añadir una tarea. Debería avisarte. No debería quedarse con un círculo girando eternamente ni decir «guardado» cuando no lo está.
Ruta inexistente (404). Visita una dirección que no existe, por ejemplo la de una tarea con un identificador inventado. El código 404 significa «no encontrado», y la aplicación debería responder con claridad en lugar de romperse.
Error interno (500). Este código indica que el servidor falló por su cuenta. Provócalo en un entorno de pruebas, nunca con datos reales, y comprueba que el usuario ve un mensaje comprensible y no un volcado de detalles internos.
Permisos. Si hay usuarios, prueba que una persona sin permiso no pueda borrar la lista de otra. Lo esperable es una denegación, normalmente con un 401 (no identificado) o un 403 (prohibido).
Formato inesperado. ¿Qué pasa si el servidor devuelve texto en lugar de datos estructurados, o una tarea sin el campo «título»? Una pantalla en blanco es mala señal.

En JavaScript, la instrucción try...catch permite capturar un error y responder con orden. Pero ojo con los catch vacíos: capturar un fallo y callarlo es como quitarle la pila al detector de humo porque pita. El problema sigue ahí; solo has dejado de enterarte.

Diagrama editorial horizontal sobre pruebas de una aplicación de tareas con los casos NORMAL, VACÍA, REPETIDA, MUY LARGA y BORRAR Y RECARGAR, conectados con RESULTADO ESPERADO y FALLO.

Dependencias: el equipaje que trae el código

Las IA suelen añadir paquetes de terceros sin avisar demasiado. En un proyecto con npm, el archivo package.json separa dos grupos:

dependencies: lo que la aplicación necesita para funcionar.
devDependencies: herramientas para desarrollar, como los programas de pruebas o los formateadores de código.

Revisa cada paquete nuevo y pregúntate si lo necesitas, si está en el grupo correcto y si es realmente el que crees: un nombre parecido no es lo mismo.

Además, npm puede generar un archivo package-lock.json, un lockfile que fija las versiones concretas que se resolvieron al instalar. Gracias a él, otra persona, o tú dentro de seis meses, instalará lo mismo y no lo que haya salido más nuevo ese día. En aplicaciones suele guardarse en el repositorio, aunque conviene mirar qué corresponde según el tipo de proyecto.

En Python existe una idea comparable: venv crea un entorno aislado para que los paquetes de un proyecto no se mezclen con los de otro. Es solo un ejemplo de la misma filosofía: cada proyecto, con su propio equipaje bien etiquetado.

Claves y datos: lo que no se sube

Las API keys, las contraseñas, los tokens y los certificados son secretos. No deben vivir en el código ni subirse al repositorio, ni siquiera «solo un momentito». Lo habitual es guardarlos en variables de entorno o en un archivo local que Git ignore (por ejemplo, .env incluido en .gitignore), y compartir un archivo de ejemplo sin valores reales.

Con los datos pasa algo parecido. Para probar, usa datos ficticios como los de Marta y la albahaca, no información real de personas.

Si una clave se filtra, hay que revocarla o rotarla: invalidar la antigua y crear una nueva. Borrar el texto del código no basta, porque el historial de Git conserva versiones anteriores y pueden existir copias o bifurcaciones. Es como dejar la llave de casa en el buzón comunitario: lo que importa es cambiar la cerradura, no pasarle un trapo al buzón.

Las herramientas de secret scanning, como la de GitHub, ayudan a detectar secretos, pero no lo detectan todo. Y las comprobaciones de este artículo son higiene básica, no una auditoría de seguridad completa. Si tu proyecto maneja datos sensibles o usuarios reales, necesita una revisión más seria.

Tarjeta horizontal del Señor Idea, conservando su identidad visual aprobada, junto a una aplicación que parece arrancar y elementos visuales de comprobación. Incluye la intervención completa: «—¿Arranca? —Ahora comprueba que cumple.»

Lista práctica para empezar

Antes de probar, escribe cuatro o cinco comportamientos observables.
Prueba el caso normal y también la entrada vacía, repetida, muy larga, y el borrar y recargar.
Simula una caída de red, un 404, un 500, un permiso denegado y un formato inesperado.
Revisa cada dependencia nueva y comprueba que está en dependencies o devDependencies con sentido.
Conserva el lockfile cuando corresponda y usa un entorno aislado.
Busca claves, contraseñas y tokens antes de subir nada; usa .gitignore y variables de entorno.
Si un secreto se filtra, revócalo o rótalo; no te conformes con borrarlo.
Pide a la IA que explique qué ha hecho, pero comprueba tú el resultado.
Anota qué has probado y qué no, para no confundir «no he visto fallos» con «no hay fallos».

Que el código arranque es el principio de la revisión, no el final. La IA puede ahorrarte mucho tecleo, pero comprobar que hace lo que pediste sigue siendo cosa tuya, y con un poco de método es más sencillo de lo que parece.