Qué hay realmente dentro de una app hecha con IA: un recorrido para no desarrolladores

Tecleaste una descripción, presionaste “ir” y veinte minutos después tenías una app funcional. Genial. Pero ahora hiciste clic en “ver archivos” y estás mirando un árbol de carpetas que parece escrito en otro idioma. ¿Qué es package.json? ¿Por qué hay cuarenta cosas en node_modules? ¿Qué significa “esquema” y por qué tienes uno?

Este artículo es un recorrido guiado. No un tutorial — un recorrido. Después de leerlo no vas a saber cómo escribir ninguno de estos archivos tú mismo, pero la próxima vez que algo se vea raro, vas a saber a qué rincón de la app apuntar.

Voy a usar tres ejemplos a lo largo del texto, para que las partes abstractas tengan algo concreto a lo que aferrarse:

• Maya, una líder de marketing, que construyó una tabla de posiciones de referidos para su equipo.
• Jordan, un instructor de yoga, que construyó un sitio de reservas de clases.
• Sam, que tiene una panadería, que construyó una página de “pre-ordena los croissants de mañana”.

Los tres usaron un creador de apps con IA. Las tres apps se ven completamente distintas para un cliente. Por dentro, tienen una forma sorprendentemente parecida.

El frontend: lo que tu cliente realmente ve

El frontend es todo lo que carga en el navegador de alguien. Botones, diseños, fuentes, animaciones, la forma en que un formulario se limpia solo después de que lo envías. Si lo puedes ver, es frontend.

Para Maya, el frontend es una tabla de posiciones con rango, nombre y número de referidos. Para Jordan, es un calendario de clases con un botón de “reservar”. Para Sam, es una lista de panes con pequeños botones de más y menos junto a cada uno.

Dentro del proyecto, el frontend normalmente vive en una carpeta llamada algo como app/, pages/ o src/. Vas a ver archivos que terminan en .tsx o .jsx. Cada uno es más o menos “una pantalla” o “una parte de una pantalla”. La fila de la tabla de posiciones es un archivo. El encabezado es otro archivo. La página que lo une todo es un tercero.

Cuando le pides al creador con IA que “haga los botones más redondeados” o “mueva la tabla de posiciones a la derecha”, esta es la parte que cambia.

El backend: la parte que piensa

El backend es la parte que nadie ve, pero de la que todos dependen. Es el código que corre en otro lado — en un servidor, no en el navegador del cliente — cuando algo necesita ocurrir que no se le puede confiar al navegador del cliente hacer por sí solo.

¿Por qué no puede el navegador hacerlo todo? Porque el navegador es la máquina del cliente, y no puedes confiar en ella. Si la tabla de posiciones de Maya actualizara los conteos de referidos puramente en el navegador, cualquiera podría hacer clic derecho y agregarse 9,000 referidos a sí mismo. Así que el backend es donde viven las reglas: “esta persona puede hacer esto, pero no aquello”, “de verdad guarda esto en la base de datos”, “envía este correo”.

El backend normalmente vive en una carpeta llamada api/, server/ o app/api/. Los archivos ahí suelen ser cortos. Cada uno maneja una petición específica: “crea una reserva”, “lista los croissants de hoy”, “agrega un referido”.

Cuando algo funciona en tu app pero el resultado no se queda — haces clic en enviar, ves una confirmación, pero mañana los datos ya no están — el backend es casi siempre donde está el bug.

La base de datos: la memoria de tu app

Imagina la memoria de tu app como una hilera de archiveros. Cada archivero tiene una etiqueta en el frente. Uno dice “users”. Uno dice “bookings”. Uno dice “croissant_orders”. Dentro de cada archivero, cada cajón es una fila. Cada cajón tiene el mismo conjunto de ranuras: un nombre, un correo, un created_at, un estado.

Esa estructura — “qué archiveros existen, qué ranuras tiene cada fila” — se llama esquema. Es el archivo más importante del proyecto, aunque también sea probablemente el de aspecto más aburrido. Busca un archivo llamado schema.ts, schema.prisma, o algo dentro de una carpeta llamada db/ o migrations/. Ábrelo. Vas a ver una lista que refleja lo que tu app de verdad recuerda sobre el mundo.

El esquema de Jordan tiene una tabla classes, una tabla bookings y una tabla users. El de Sam tiene products, orders y order_items. El de Maya tiene members y referrals. La forma del esquema es la forma del producto, y por eso cambiarlo después es más difícil que cambiar cómo se ven los botones.

Un truco útil: si puedes describir lo que tu app recuerda, en palabras sencillas, normalmente puedes describir el esquema. “Recuerdo el nombre y el correo de cada cliente. Para cada cliente, recuerdo los pedidos que hizo. Para cada pedido, recuerdo qué panes y cuántos de cada uno.” Esa frase es, casi palabra por palabra, el esquema.

Auth: el portero en la puerta

“Auth” son dos palabras aplastadas juntas: autenticación (¿quién eres?) y autorización (¿qué tienes permitido hacer?). Ambas normalmente las maneja un pequeño conjunto de archivos en una carpeta llamada auth/, o un servicio cuyo nombre quizá reconozcas: Clerk, Auth0, Supabase Auth, NextAuth.

Las dos preguntas son distintas. La autenticación responde: “¿esta de verdad es Maya?” — normalmente con una contraseña, un inicio de sesión con Google o un enlace mágico enviado a su correo. La autorización responde: “¿Maya tiene permitido borrar los referidos de otras personas?” — y la respuesta honesta para la mayoría de las apps hechas con IA en su primera semana es “se nos olvidó verificar”.

Esta es la parte que más a menudo está rota en silencio. La pantalla de inicio de sesión funciona, así que se siente segura. Pero el backend no siempre está verificando que la persona con sesión iniciada sea la misma persona cuyos datos está tratando de leer. Si tu app tiene cualquier noción de “mis datos frente a tus datos”, pídele explícitamente al creador con IA: “Asegúrate de que los usuarios solo puedan ver y editar sus propios datos.” Te va a sorprender lo seguido que esa única frase revela una verificación faltante.

Integraciones: las cosas que no construiste pero que estás usando igual

Aquí es donde la mayoría de los no desarrolladores subestima lo que de verdad está pasando. La cosa que envía el correo de “tus croissants están listos” de Sam no es código — es una cuenta en SendGrid o Resend. La cosa que procesa el pago de la clase de Jordan no es código — es Stripe. La cosa que aloja las fotos en la tabla de posiciones de Maya no es código — es un servicio de almacenamiento como S3 o Cloudinary.

Cada integración aparece en dos lugares. Hay un pequeño trozo de código en el backend que dice “oye, Stripe, cóbrale a esta tarjeta”. Y hay una clave — una larga cadena secreta — guardada en algún lugar seguro (normalmente un archivo llamado .env que nadie debería nunca subir al repositorio) que le prueba a Stripe que la petición vino de la panadería de Sam y no de un desconocido.

Si alguna vez te preguntas por qué tu app de pronto deja de enviar correos o deja de aceptar pagos, la causa es casi siempre una de estas: una clave vencida, un límite de uso alcanzado o un cambio en las políticas de la integración. El código no se rompió. El apretón de manos sí.

El despliegue: cómo llega a internet

La pieza final es la parte que convierte la carpeta en tu disco en una cosa que tu cliente puede visitar en una URL. Esto normalmente significa tres cositas trabajando juntas:

• El host: un servicio como Vercel, Netlify, Fly o Render que corre tu backend y sirve tu frontend.
• El dominio: un nombre como tabla-de-maya.com que apunta a tu host.
• El build: la receta que toma tus archivos fuente desordenados y los convierte en la versión más esbelta y rápida que de verdad corre.

Cuando algo funciona localmente pero se rompe en producción, el problema suele estar aquí. Una clave que está configurada en tu laptop pero no en el host. Una librería instalada en desarrollo pero no en producción. Una base de datos que existe en tu navegador pero no en el sitio en vivo.

El hábito de cinco minutos que se paga solo

No necesitas leer cada archivo de tu proyecto. No necesitas saber qué hace la mayoría de ellos. Pero deberías, una vez por semana, hacer un recorrido de cinco minutos donde abras cada una de las carpetas de arriba y le preguntes al creador con IA, en palabras sencillas, qué cambió.

Maya hace esto cada viernes por la tarde. Teclea: “¿Qué cambió en el esquema esta semana, y por qué?” Y: “¿Hay alguna integración nueva en esta app que yo no haya pedido?” Las respuestas casi siempre son tranquilizadoras. Las pocas veces que no lo son, atrapa los problemas mientras todavía son pequeños.

Ese es el punto entero de entender las partes. No para volverte desarrolladora. Solo para poder hacer mejores preguntas.

A dónde ir después

Si este recorrido te ayudó, vale la pena dedicar tiempo a dos continuaciones. El bug que “se ve bien” cubre qué hacer cuando una de estas partes está rota en silencio, y listo para demo frente a listo para producción cubre cómo saber cuándo tu app pasó de la primera etapa a la segunda. El mismo mapa, distintos usos para él.