Cómo comprobar código de IA sin programar: 7 comprobaciones

La IA creó para ti una página web o un bot en una tarde. Todo se abre, los botones funcionan y parece que va bien. Enseñas el proyecto a otras personas y, un día después, descubres que el formulario de pago cobra dinero, pero los pedidos nunca llegan. O que la base de datos con los números de teléfono de tus clientes está abierta a todo Internet.

Yo también entregaba así mis primeros proyectos: cosas que parecían funcionar acababan sorprendiendo a los usuarios reales. Ahora, antes de enseñar nada, paso el proyecto por la misma lista de comprobación. Mientras lo hago, no leo ni una línea de código; no vine a esto, y probablemente tú tampoco.

Y esto no es paranoia. Anthropic analizó 400,000 sesiones de Claude Code: durante siete meses, la proporción de trabajo dedicada a reparar código defectuoso bajó del 33 % al 19 %. Disminuyó, pero no desapareció. Una de cada cinco sesiones sigue consistiendo en «arreglar lo que rompió la IA».

Escribir código ya no es el cuello de botella. Ahora lo importante es cuánto entiendes la tarea y qué tan bien puedes comprobar el resultado.

Encontrarás materiales adicionales sobre cómo configurar herramientas en la documentación de Ailoot.

¿Por qué comprobar el código generado por IA si ya funciona?#

La IA escribe código que supera una primera impresión. Se ejecuta, la pantalla se muestra y la demo resulta convincente. Pero ponerlo en marcha no te dice si el dinero se calcula correctamente, si tu base de datos está expuesta al exterior o si todo se bloqueará cuando llegue el usuario número cien.

Las cifras lo respaldan. El benchmark FrontierCode comprobó en junio de 2026 hasta qué punto el código generado por IA estaba listo para trabajar de verdad sin modificaciones. Incluso para los mejores modelos en las tareas más difíciles, la proporción era de alrededor del 13 %. En otras palabras, en tareas serias hay que perfeccionar a mano la mayor parte del código generado por IA antes de poder confiar en él.

La buena noticia es que cualquiera puede hacer estas comprobaciones. Esto es lo que concluyó Anthropic a partir de esas mismas 400,000 sesiones:

Tu ventaja frente a cualquier programador al que contrates es que entiendes tu tarea. Comprobar también consiste en entender; no necesitas leer código. Las comprobaciones que siguen son precisamente de las que puedes encargarte tú, sin complicaciones.

¿Qué puede salir mal de verdad con el código generado por IA?#

Antes de comprobar, conviene saber qué estás buscando. El código generado por IA tiene cinco problemas habituales, y puedes detectar los cinco sin leer código: basta con observar cómo se comporta el proyecto.

A continuación tienes siete comprobaciones, en orden. Las primeras detectan los casos en que «no funciona» o «funciona mal»; las intermedias cubren la seguridad y las invenciones; las últimas son medidas de protección antes de publicar. Lo mejor es hacerlas en secuencia: cada una se basa en haber completado la anterior.

Comprobación 1: pide a la IA que explique su código en lenguaje sencillo#

Describiste la tarea con palabras. La IA la tradujo a código. Entre esos dos pasos se puede perder el significado: quizá la IA te entendió de otra manera, completó cosas por su cuenta o tomó atajos. Puedes detectar la discrepancia sin leer código; solo pídele que describa en lenguaje sencillo lo que hizo.

Explica en lenguaje sencillo, sin código, exactamente lo que acabas de hacer:

qué tarea resuelve este código

qué ocurrirá cuando un usuario haga clic en el botón o envíe el formulario

dónde se almacenan los datos y quién tiene acceso a ellos

qué podría fallar y en qué situación

Escribe como si se lo explicaras a alguien que nunca ha programado. Si no estás seguro de que algo sea correcto, dilo claramente.

Lee la respuesta y compárala con lo que tenías en mente. Si coincide, sigue adelante. Si la IA «se va por las ramas», se confunde al explicarse o describe algo distinto de lo que pediste, significa que no entiende del todo lo que construyó. Pídele que lo revise y aclara lo que querías, en vez de dar por buena su respuesta.

Por cierto, si la IA suele hacer algo distinto de lo que pediste, el problema suele estar en cómo planteaste la tarea, no en el modelo. Tengo un análisis aparte sobre por qué Claude no hace lo que le pides.

Comprobar el resultado de la IA forma parte de la ingeniería de contexto: controlas tanto lo que le das como entrada como la manera de evaluar el resultado como salida. El conjunto de herramientas incluye un clon de IA, un Second Brain y Context Engineering. Después, Claude deja de ser un «asistente alucinador» y se convierte en una herramienta a la que puedes confiarle un proyecto.

Comprobación 2: recorre los escenarios como lo haría un usuario real#

Una demo de IA siempre sigue el camino ideal: datos correctos, un clic, todo sale bien. Un usuario real no se comporta así. Comete errores, hace clic donde no debe o pone un emoji en el campo del teléfono. Tu tarea es recorrer el proyecto como lo haría esa persona.

1. Completa el escenario principal de principio a fin

   Haz lo que el proyecto existe para hacer: regístrate, haz un pedido o envía una solicitud. Llega hasta el final, no te quedes a medias.

2. Comprueba el pago por separado y de verdad

   Si el proyecto acepta dinero, haz tú mismo un pago por el importe mínimo en modo de prueba. Asegúrate de que se cree el pedido, cambie el estado y se envíe un correo tanto a ti como al cliente. Que un pago «se procese» sin crear un pedido es un fallo silencioso clásico.

3. Provoca problemas a propósito

   Deja campos vacíos. Escribe letras donde se esperan números. Haz clic dos veces seguidas en «Enviar». Sube un archivo con el formato equivocado. Un buen proyecto dirá amablemente «no puedes hacer eso»; uno malo se bloqueará o descartará los datos sin avisar.

4. Ábrelo en un teléfono

   La mitad de tus usuarios llegarán desde un teléfono. Comprueba que el diseño no se haya descompuesto y que allí funcionen los mismos botones.

Dale a la IA todo lo que hayas encontrado, en una sola lista: «Esto es lo que falló en estos pasos; arréglalo y explícame por qué ocurrió». No abordes un problema a la vez: pásale la lista completa para que vea el panorama general y sea menos probable que rompa una cosa mientras arregla otra.

Comprobación 3: pregunta a la IA por la seguridad; aquí tienes un prompt#

Un botón roto se ve enseguida. Un fallo de seguridad no: el proyecto sigue funcionando como si nada hasta que alguien se aprovecha de él. Entre los problemas más comunes en proyectos creados mediante vibe coding están las claves secretas escritas directamente en el código, una base de datos expuesta a Internet y formularios que permiten enviar entradas maliciosas. La IA puede encontrar todo esto si se lo pides directamente.

Audita este proyecto para detectar problemas de seguridad y explica cada hallazgo en lenguaje sencillo, sin jerga. Revisa esta lista:

Comprueba si hay claves secretas, contraseñas o tokens escritos directamente en el código. Los secretos privados deben usarse solo en el servidor, con la configuración local, como .env, excluida de Git. .env y .gitignore no impiden que variables frontend/públicas entren en una compilación para navegador. Inspecciona JavaScript, mapas de código fuente, HTML y respuestas de red realmente entregados al cliente y verifica que no contengan claves privadas.

Comprueba si la base de datos está expuesta a Internet y quién tiene acceso a ella.

Comprueba si las entradas pueden comprometer los formularios: inyecciones en consultas a la base de datos o código adicional en campos de texto.

¿Qué ocurrirá si un usuario envía datos maliciosos?

Comprueba si hay páginas internas o un panel de administración expuestos sin contraseña.

Para cada punto, indica si hay un problema, da un ejemplo claro del riesgo y explica cómo solucionarlo. Empieza por el problema más peligroso.

Comprueba también que tu proyecto no haga a ciegas todo lo que recibe del exterior. Esto se llama inyección indirecta de prompts: se oculta un comando en un correo, un comentario o un archivo de otra persona, y tu agente de IA lo sigue al confundirlo con una tarea. Si el proyecto lee datos externos y actúa en consecuencia, pregunta a la IA qué ocurriría si esos datos contuvieran una instrucción oculta.

Es un tema complejo, y un solo prompt no puede cubrirlo por completo. Si el proyecto gestiona dinero o datos personales de clientes, lee la guía aparte sobre seguridad en vibe coding.

Comprobación 4: ¿se inventó la IA bibliotecas o datos?#

La IA escribe con seguridad cosas que no existen. Puede añadir una biblioteca con un nombre que parece plausible, pero que en realidad no existe. También puede dejar marcadores de posición de prueba en el proyecto: un producto llamado «Example», la dirección de correo example@example.com o texto de relleno en lugar de contenido real. Es fácil pasarlo por alto en una demo, pero resulta vergonzoso o hace que el proyecto no funcione para un usuario real.

Puedes detectarlo en dos pasos. Primero, pregunta directamente:

Revisa el proyecto y comprueba con honestidad:

¿Existen realmente todas las herramientas y bibliotecas externas que has añadido, y se instalan correctamente? ¿Te has inventado algo?

¿Queda algún marcador de posición de prueba, ejemplo o texto de relleno en lugar de datos reales?

¿Son reales todos los enlaces, direcciones y datos de contacto del proyecto, en vez de ser marcadores de posición?

Enumera lo que has encontrado y sugiere con qué reemplazarlo.

En segundo lugar, ejecuta el proyecto y revísalo. Una biblioteca inventada casi siempre provoca un error al iniciarse. Y los marcadores de posición son fáciles de detectar: si la página dice «Producto 1», todavía no los has reemplazado.

Las bibliotecas inventadas representan un peligro aparte porque los atacantes registran deliberadamente herramientas con nombres que a la IA le gusta inventar. Si instalas una, el código de otra persona acaba en tu proyecto. Por eso debes tomarte en serio la pregunta «¿esta biblioteca existe siquiera?»: tiene que ver directamente con la seguridad de tu proyecto.

Comprobación 5: pide a un segundo modelo que revise el primero#

La IA tiene un rasgo desagradable: está de acuerdo. Pregunta «¿está todo bien aquí?» y confirmará que todo está bien porque se adapta a la respuesta que espera. Esto se llama adulación de la IA, y escribí sobre ello por separado. Un interlocutor así será indulgente con su propio trabajo.

La solución es sencilla: pide una segunda opinión. Abre una sesión nueva o usa otro modelo y pídele que revise el proyecto con el mismo prompt de la comprobación 3, añadiendo: «otra IA escribió este código; encuentra sus puntos débiles». Un modelo nuevo no está condicionado por la conversación anterior y es más probable que señale los problemas.

1. Abre una sesión limpia o usa otro modelo

   Usa un segundo modelo, o el mismo en una ventana nueva sin historial de tareas.

2. Dale el proyecto y el enfoque adecuado

   Di claramente: «otra IA escribió este código; tu tarea es encontrar errores y riesgos, no elogiarlo». Esto reduce la adulación.

3. Compara las dos opiniones

   Si ambos coinciden, probablemente tengan razón. Si no están de acuerdo, investiga ese punto: ahí es donde se pone interesante.

Esto es precisamente lo que ocurre ahora en el sector: la IA escribe, la IA comprueba y la decisión final sigue correspondiendo a una persona. No puedes dejar esa decisión en manos del modelo; es tu tarea.

Comprobación 6: ¿cómo puedes volver atrás si una modificación rompe algo?#

Las comprobaciones de esta lista suelen dar lugar a modificaciones, y a veces estas rompen lo que funcionaba. Para evitar que eso se convierta en un desastre, guarda la versión funcional en git antes de cada ronda de correcciones. Es como guardar una partida: si rompes algo, cargas el último punto guardado.

No necesitas leer código para esto. Solo pide a la IA: «guarda la versión funcional actual en git con una etiqueta clara antes de cambiar nada». Y si todo sale mal después de las modificaciones: «restaura el proyecto a la versión guardada anteriormente».

Si git todavía te resulta desconocido, tengo dos guías: cómo deshacer cambios en Claude Code y qué hacer si la IA borró tu base de datos. La segunda sirve cuando ya es demasiado tarde para volver atrás, pero todavía puedes recuperar los datos.

Comprobación 7: ¿qué deberías revisar al final, antes de publicar?#

Las primeras seis comprobaciones se centran en lo que hace el código. La séptima se centra en si el proyecto está listo para presentarse a la gente. Es aquí donde muchos tropiezan: el proyecto funciona, pero olvidaron pasar el pago de la clave de prueba a la clave real, así que los primeros clientes pagan «de mentira».

1. Pago: de prueba a real

   Si aceptas pagos, asegúrate de que esté conectada la clave real del sistema de pago, no la de prueba. Haz un pago real por el importe mínimo y reembólsatelo.

2. Los secretos están donde deben

   Pregunta a la IA: «¿Se usan las claves privadas solo en el servidor y está .env excluido de Git? ¿Contiene alguna clave privada la compilación real del navegador o alguna respuesta al cliente, incluidas variables frontend/públicas o mapas de código fuente?». Comprueba archivos compilados y respuestas de red del navegador, no solo el .env original. La exclusión de Git no evita que un valor entre en un paquete frontend.

3. Haz una copia de seguridad de los datos

   Asegúrate de que la base de datos se guarde automáticamente en algún lugar. Si tu proyecto funciona en tu propio servidor, explico qué hacer para publicarlo en la guía de Coolify.

4. La publicación funciona también fuera de tu dispositivo

   Abre el proyecto en tu teléfono mediante un enlace externo, no solo en tu propio ordenador. Algo que funciona en local no siempre funciona después de publicarlo.

Repasa los cuatro puntos y podrás enseñar el proyecto a otras personas con tranquilidad. Si algo no cuadra, es mejor dedicarle media hora ahora que lidiar después con clientes descontentos.

¿Y si comprobarlo lleva demasiado tiempo? ¿Deberías confiar sin más en la IA?#

Entiendo la tentación. Comprobar parece aburrido y «no es para eso que conseguí una IA». Pero tú, no el modelo, eres responsable del resultado. La IA no tiene reputación que proteger ni sufre consecuencias: produjo el código y se olvidó de él. Tú tendrás que responder ante un cliente cuyo pago no se procesó.

El creador de Claude Code ofrece una perspectiva aún más amplia:

Escribir código dejó de ser el cuello de botella: la IA se encargó de ello. Ahora el valor está en otra parte: en entender la tarea y comprobar el resultado. Esa es tu fortaleza: conoces mejor que cualquier desarrollador externo el resultado que necesita tu cliente.

¿Por qué comprobar es una habilidad y no una tarea puntual?#

Estas siete comprobaciones son el mínimo que distingue entre «lo publiqué y espero que funcione» y «lo publiqué y sé que funciona». Hazlas una vez y ya detectarás la mayoría de las sorpresas antes que tus clientes.

A partir de ahí, se convierte en un hábito. Dale a la IA el contexto adecuado como entrada y comprueba el resultado como salida. Así, cada proyecto nuevo se completará más rápido porque no empiezas desde cero.

Clon de IA, Second Brain y Context Engineering: encontrarás materiales adicionales sobre cómo trabajar con herramientas en la documentación de Ailoot.