Checklist app con IA: errores que Claude no te avisa

Publicado el 16 de octubre de 2026.

Los errores que más se cuelan en una app generada con IA son textos que ya no coinciden con lo que hace la app, formularios sin validar, permisos demasiado abiertos y datos de prueba mezclados con los reales. Se detectan antes de publicar probándola como un usuario torpe, revisando permisos a mano y pidiéndole a Claude una auditoría con instrucciones concretas.

Si estás empezando, antes de esta lista te conviene tener clara la base con la guía para crear una app sin saber programar. Aquí doy por hecho que ya tienes algo funcionando en pantalla y te da miedo publicarlo. Es el momento exacto en el que conviene frenar un día y revisar.

Una checklist de revisión es una lista fija de comprobaciones que repites antes de cada publicación, para que no dependa de tu memoria ni de tu estado de ánimo. Te la dejo armada al final, pero antes necesitas entender de dónde vienen los fallos.

¿Por qué una app hecha con IA puede fallar aunque parezca perfecta?

Porque Claude escribe código que funciona en el camino feliz: el usuario que rellena todo bien, con buena conexión y sin intentar nada raro. Una app falla en los caminos que nadie probó, y eso depende de lo que tú pediste, no solo de lo que Claude generó.

En corto: una app con IA falla porque nadie probó los caminos incómodos: datos vacíos, usuarios torpes, permisos mal cerrados y textos que ya no cuentan la verdad.

Mi opinión: el error de fondo no es técnico, es de confianza. Si la pantalla se ve bien, damos por hecho que el resto también está bien. Pero el aspecto no dice nada sobre lo que pasa cuando alguien deja un campo vacío, pega un texto larguísimo o abre el enlace de otra persona. Claude responde a lo que le pides. Si no le pides que cuestione los permisos, lo normal es que no los cuestione por su cuenta. Por eso para mí es más importante saber lo que no sabes que saber usar la IA: saber qué necesita una app para alcanzar los estándares de hoy es justo lo que te enseño desde mis 22 años como desarrollador [N1].

La guía de Google sobre contenido generado con IA insiste en revisar a mano lo que se publica. Está escrita pensando en contenido web, pero la lógica sirve igual para una app: lo generado no se publica sin que una persona lo mire.

¿Qué errores de textos y formularios debo buscar primero?

Los primeros errores están en lo que el usuario ve y escribe: textos desfasados, mensajes de error técnicos y formularios que aceptan cualquier cosa. Son los más baratos de arreglar y los que antes hacen desconfiar a quien entra en tu app.

En corto: lee cada texto en voz alta y rellena cada formulario mal a propósito, porque ahí aparecen los fallos más rápidos de encontrar.

Un formulario es cualquier pantalla donde el usuario introduce datos que tu app guarda o envía. Pruébalo con esta secuencia:

• Déjalo vacío y pulsa enviar.
• Escribe un email sin arroba y un teléfono con letras.
• Pega un texto larguísimo en un campo pensado para una palabra.
• Pulsa el botón de enviar dos veces seguidas, rápido.
• Fíjate en el mensaje que sale: ¿lo entendería cualquier persona o dice «undefined» o «error 500»?

Revisa también los textos de ejemplo. Pueden quedar frases de relleno, nombres de prueba o promesas que ya no son ciertas porque cambiaste la app a mitad de camino. Comprueba el idioma: si tu público habla español, ningún botón ni aviso debería quedarse en inglés. Y lee el texto del botón principal: tiene que decir lo que realmente ocurre al pulsarlo.

¿Qué fallos de permisos y datos son los más peligrosos?

Los más peligrosos son los que dejan a un usuario ver o modificar datos de otro, las claves expuestas y los datos de prueba mezclados con los reales. No se ven a simple vista, y por eso son los que más sustos dan después de publicar.

En corto: el fallo más grave es que un usuario acceda a datos ajenos, y solo lo encuentras probando con dos cuentas distintas.

El control de acceso roto, que es cuando alguien puede hacer algo que no le corresponde, figura como primer riesgo en la lista OWASP Top 10 (edición 2021). Por eso conviene probarlo antes que el resto:

• Crea dos cuentas de prueba, A y B.
• Con la cuenta A, abre un registro propio y copia su dirección.
• Cierra sesión, entra con B y pega esa dirección. Si ves los datos de A, tienes un problema serio.
• Pregúntale a Claude dónde están guardadas las claves y comprueba que no aparecen en código visible desde el navegador.
• Borra los datos de prueba y los usuarios ficticios antes de abrir la app.

Si tu app recoge datos personales, suele ser obligatorio informar de qué haces con ellos, así que prepara tu propia política de privacidad y consúltala con un profesional del derecho. Esto no es asesoría legal.

¿Qué puedo pedirle a Claude que revise por mí?

Puedes pedirle una auditoría por áreas, con instrucciones concretas y un formato de respuesta fijo. Claude revisa bien lo que le señalas, así que cuanto más específica sea la petición, más útil será el resultado. Lo que no puede hacer es sustituir tu prueba como usuario.

En corto: pídele una revisión por áreas (permisos, validación, textos y errores) y exige una lista de hallazgos ordenada por gravedad, con el archivo donde está cada uno.

Un ejemplo de petición como punto de partida:

Revisa este proyecto como si fueras un auditor. Busca: 1) rutas o consultas a datos sin comprobar quién es el usuario, 2) claves o secretos escritos en el código, 3) formularios sin validación, 4) mensajes de error que muestran detalles técnicos. Dame una lista ordenada de más a menos grave, con el archivo y la línea de cada hallazgo, y no cambies nada todavía.

La última frase importa. Si dejas que Claude corrija sin revisar, puedes romper algo que ya funcionaba. Primero pide el informe, léelo, decide qué arreglar y después pide los cambios de uno en uno. Cuando termine, vuelve a pasar tus pruebas manuales: que Claude diga «arreglado» no es lo mismo que comprobarlo tú.

¿Cómo convierto estos errores en una checklist reutilizable?

Guardas cada comprobación como una fila con tres datos: qué pruebas, cómo lo pruebas y qué resultado esperas. Así la repites idéntica antes de cada publicación y vas añadiendo filas cada vez que un fallo se te escapa.

En corto: una checklist reutilizable es una tabla de comprobaciones con resultado esperado, guardada en un archivo que Claude y tú podéis consultar siempre.

Esta es la versión mínima que te propongo:

Área	Qué compruebas	Resultado esperado
Textos	Ningún texto de ejemplo ni botón en otro idioma	Todo coherente con lo que hace la app
Formularios	Vacío, email inválido, texto largo, doble envío	Mensajes claros, sin duplicados
Permisos	Dos cuentas, enlace de una abierto desde otra	La cuenta B no ve datos de A
Secretos	Claves fuera del código visible	Ninguna clave expuesta
Datos	Registros y usuarios de prueba borrados	Base de datos limpia
Legal	Política de privacidad enlazada	Visible desde la app

Guárdala en un archivo de tu proyecto y pídele a Claude que la tenga en cuenta al revisar. Cada vez que algo falle en producción, añade una fila nueva. Con el tiempo tendrás una lista hecha a la medida de tu app. Si quieres ver cómo otras personas presentan sus productos terminados, échale un ojo al portafolio de alumnos y compara con lo tuyo.

¿Cómo sé que mi app está lista para publicar?

Está lista cuando pasa todas las filas de tu checklist con el resultado esperado, en una revisión hecha de principio a fin y después del último cambio. Si tocaste algo después de revisar, la revisión ya no vale y toca repetirla.

En corto: tu app está lista cuando la checklist completa pasa en verde después del último cambio, no antes.

Tres criterios prácticos para decidir:

• Ninguna fila de permisos o secretos está en rojo. Estas no admiten un «ya lo arreglo luego».
• Los fallos pendientes son solo de textos o de aspecto, y los tienes apuntados con fecha.
• Alguien que no seas tú ha usado la app sin que le expliques nada y ha completado la tarea principal.

El último punto es el que más se salta y el que más enseña. Tú sabes qué botón pulsar porque lo construiste; otra persona no. Mírala usarla en silencio y apunta cada duda que tenga: cada duda es una fila candidata para tu checklist o un texto que reescribir.

Empieza por aquí esta semana

• Crea dos cuentas de prueba en tu app y haz la prueba del enlace cruzado: abre con una el registro de la otra.
• Rellena cada formulario mal a propósito (vacío, email sin arroba, texto larguísimo, doble envío) y apunta los mensajes que no se entienden.
• Pídele a Claude la auditoría por áreas del apartado anterior, con la condición de que no cambie nada hasta que leas el informe.
• Copia la tabla de checklist a un archivo de tu proyecto y añade una fila propia con el fallo que más te preocupe.
• Borra los datos y usuarios de prueba, relee todos los textos en voz alta y pídele a una persona que pruebe la app antes de compartir el enlace.

Escrito por Rupo.