Por qué tu creador de apps con IA te muestra datos falsos primero (y por qué es lo correcto)

Le describes una app a tu creador de apps con IA. Un minuto después estás viendo una interfaz funcional — páginas, botones, una tabla de usuarios con nombres como “Alex Rivera” y “Priya Shah”, precios que no tienen sentido, un “Plan Pro” que no pediste. Nada se guarda. Si recargas, los datos siguen ahí. Si agregas un usuario nuevo, desaparece.

Parece un truco de magia a punto de venirse abajo. No lo es. Esa es la parte buena del proceso. Los datos de prueba en tu pantalla son un primer paso deliberado, y son la razón por la que la base de datos que viene después de verdad va a coincidir con la app que querías.

Qué significa de verdad “datos falsos primero”

Cuando un creador de apps con IA recibe tu brief, no va directo a la base de datos. Uno bueno escribe primero las pantallas, las llena con datos de relleno plausibles y luego — y solo entonces — diseña la base de datos para que coincida.

Los datos de relleno no son decoración. Son un contrato. Una vez que tu app dice “cada pedido tiene un nombre de cliente, tres líneas de producto, un total y un estado”, la base de datos que se construye después tiene que tener exactamente esas cosas, exactamente con esas formas. Las pantallas deciden cómo se ven los datos, no al revés.

Esto es al revés de cómo suele empezar un desarrollador humano. Un desarrollador tradicional diseña primero la base de datos y luego construye las pantallas sobre ella. Los creadores con IA invirtieron eso, y la mayoría de la gente no se da cuenta — solo ve los usuarios falsos y supone que el creador está fingiendo.

Por qué este orden funciona mejor con IA

Probamos construir la base de datos y las pantallas al mismo tiempo. No funcionó. Esta es la versión corta del porqué.

Cuando dos agentes de IA trabajan en partes distintas de una app sin ver lo que produce el otro, hacen suposiciones incompatibles. El agente de la interfaz decide que los usuarios tienen un campo “name”. El agente de la base de datos decide que los usuarios tienen un campo “fullName”. Los dos se ven correctos. Juntos, nada funciona. Se trae a un tercer agente a parchar el desajuste. Él también adivina. Ahora hay tres suposiciones sueltas, y la app que ves en la vista previa es una especie de Frankenstein de todas.

La solución es casi vergonzosa: haz una cosa primero, luego la otra. La interfaz se construye. Anota qué datos necesita en un único archivo de usuarios falsos, pedidos falsos, falso-lo-que-sea-que-trate-tu-app. El agente de la base de datos lee ese archivo y lo iguala campo por campo. Sin suposiciones. Sin negociación. Sin desajuste.

Por eso tu creador de apps con IA puede mostrarte una app que parece terminada en un minuto. No fingió el proceso. Hizo una cuarta parte del proceso — la parte que decide todo lo demás — y la base de datos son los siguientes diez segundos de trabajo, no las siguientes diez horas.

Qué buscar cuando los datos falsos están en pantalla

Este es el momento que la mayoría de la gente se salta. Ven los datos de relleno y empiezan a pedir cambios de color. Pero los datos de relleno son una pregunta que te están haciendo. Léela.

Algunos ejemplos de qué hay que vigilar:

• Vocabulario equivocado. La app que querías rastrea “envíos”. Los datos de relleno los llaman “pedidos”. Dile al creador. Si lo dejas pasar ahora, cada pantalla, cada campo de la base de datos, cada reporte usará la palabra equivocada — y renombrar después no es una operación de un solo clic en ninguna herramienta, diga lo que diga el marketing.
• Campos faltantes. La factura falsa tiene un total y una fecha. También necesitas un número de orden de compra. Mejor agrégalo ahora, cuando hay cinco facturas de prueba en una pantalla, que después de que la base de datos esté construida y sembrada con datos reales de clientes.
• Formas equivocadas. Los datos de prueba muestran “1 cliente, 1 dirección”. Tus clientes reales tienen varias direcciones. El creador no puede deducir eso de tu brief. Díselo ahora, mientras cambiar la forma no cuesta nada.
• Entidades inesperadas. El creador inventó un concepto de “equipo” que no pediste, porque supuso una app multiusuario. Quizá lo querías. Quizá no. En cualquier caso, decide antes de que la base de datos se construya alrededor de él.

Una regla útil: si tu app tiene un sustantivo que no está representado en los datos de relleno en pantalla, el creador todavía no sabe de él. Menciónalo antes de darle “guardar” a la primera vista previa.

Por qué el orden importa para lo que viene después

Una vez que los datos de relleno están bien, construir la base de datos es algo mecánico. El creador lee tus datos falsos, genera un esquema que coincide, escribe las consultas que las pantallas ya están intentando invocar y, al final, cambia los imports de relleno por los reales. Las mismas pantallas que mostraban usuarios falsos ahora muestran lo que de verdad pusiste.

Por lo general puedes ver el cambio en tiempo real. Una página que cargaba al instante porque leía un archivo local ahora tiene medio segundo de estado de carga — esa es la pantalla hablando con una base de datos real por primera vez. La mayoría de la gente se pierde esto y no se da cuenta de que la app acaba de cruzar la línea de “demo” a “cosa que puede guardar datos reales”.

La razón por la que esto funciona es que todo lo que viene después — el diseño de la base de datos, las consultas, los estados de carga, los estados vacíos — lo decidió lo que viste en pantalla durante la fase de relleno. Si aprobaste tres columnas, obtienes tres columnas. Si aprobaste un campo “status” con los valores “draft” y “sent”, eso es exactamente lo que la base de datos acepta. No hay un segundo paso de traducción donde un traspaso entre diseñador y desarrollador estropee las cosas.

Una pequeña prueba que puedes hacer

La próxima vez que construyas algo, intenta esto: cuando aparezcan los datos de relleno, cambia una cosa de ellos antes de pedir cualquier otra. Renombra un campo. Agrega una columna. Reemplaza “usuarios” por “miembros”. Luego observa qué pasa cuando se construye la base de datos.

Verás el cambio aparecer en todos lados — en el diseño de la base de datos, en las consultas, en los datos de prueba que el creador mete cuando la app está terminada. Una palabra en la etapa de relleno se propagó por toda la app. Esa es la palanca que tienes durante esta fase, y es la razón por la que “datos falsos primero” no es un truco para recortar camino. Es donde la app se decide de verdad.

Si quieres profundizar más, nuestro post anterior sobre lo que de verdad hay dentro de una app hecha con IA recorre las otras piezas en movimiento que no ves a primera vista. El patrón es el mismo: casi toda la palanca está en las partes que parecen no importar.