¿Por qué falló mi build con IA? Causas y cómo arreglarlo

¿Por qué falló mi build con IA y cómo se arregla?

Casi siempre porque el prompt pedía más de lo que cabe en una sola pasada, o porque pedía algo que necesita un conector que aún no has enlazado. Un fallo reportado es la caja de pruebas haciendo su trabajo: cada construcción se arranca antes de entregarse, y la que no carga se reporta como fallo en lugar de entregarse como una página en blanco.

Leer esa frase de la manera correcta cambia lo que haces después. El fallo es información sobre la petición, no un veredicto sobre la herramienta ni sobre ti, y la mayoría se resuelven haciendo el siguiente prompt más pequeño y más concreto.

¿Qué significa exactamente que una construcción falle?

Que el proyecto no arrancó ni dibujó nada en la caja de pruebas, así que no se entregó. Esa comprobación está entre la generación y la entrega precisamente para que una página que no abre sea nuestro problema y no el tuyo.

Conviene tener claro qué es y qué no es esa comprobación. Confirma que la construcción cargó y pintó algo. No confirma que la aplicación se comporte como querías, no revisa el código y no juzga si el contenido es bueno. Baja el riesgo de recibir una página rota. No lo elimina.

De ahí salen dos decepciones distintas con dos arreglos distintos. Una construcción que falló no llegó a existir, y se arregla con otro prompt. Una construcción que llegó y está mal es un proyecto que funciona con el que no estás de acuerdo, y se arregla con una edición. Confundir las dos es lo que más tiempo hace perder.

¿Cuáles son las causas habituales?

Cinco, y las dos primeras cubren la mayor parte de lo que se encuentra la gente.

La fila del alcance es la interesante porque en realidad no es un error. Una pasada de generación tiene un presupuesto, y un prompt que describe una plataforma entera con once pantallas, tres roles y un modelo de facturación pide más razonamiento del que cabe en una pasada. Dividirlo no es un apaño: es el flujo previsto.

Las filas de conectores comparten una misma forma: describiste una capacidad que vive en un servicio externo y el servicio no estaba enlazado. Nada dentro de una página puede crear tu proyecto de Supabase por ti, así que la construcción no tiene dónde poner los datos que le pediste guardar. La secuencia correcta está en cómo poner un inicio de sesión.

¿Cómo se reescribe un prompt que falla una y otra vez?

Recortándolo hasta lo que tiene que funcionar y haciéndolo crecer después. Tres pasadas suelen ganarle a un intento heroico, y en total salen más baratas que una racha de fallos.

Empieza solo por estructura y contenido. Qué páginas hay, qué dice cada una y qué se espera que haga el visitante. Sin cuentas, sin cobros, sin datos. Eso es una construcción que el generador completa con holgura y que te deja algo delante para mirar.

Después añade una capacidad por edición. El inicio de sesión en una pasada. El panel que ve la persona identificada en la siguiente. Los pagos después. Cada edición es un cambio pequeño y verificable, y cuando una sale mal sabes exactamente qué frase la causó, cosa que nunca sabes tras un prompt enorme.

Sé concreto sobre comportamiento en vez de sobre adjetivos. "Quien abra la página de pedidos sin haber iniciado sesión va a la pantalla de acceso" se puede construir. "Hazlo seguro" no describe nada. El tratamiento completo está en cómo escribir un buen prompt.

¿Y si la construcción abre pero está mal?

Entonces no ha fallado nada, y la herramienta correcta es una edición y no una reconstrucción. Vale la pena interiorizar esta distinción, porque empezar de cero tira las partes que ya estaban bien.

La fila central es la única en la que empezar de nuevo es lo correcto, y la señal es que estás describiendo otro producto y no otra versión de este. Qué hacer cuando el resultado sencillamente no es lo que esperabas está en qué hacer si no te gusta el resultado.

¿Cuánto cuesta otro intento?

Los precios por acción están publicados, así que puedes planificar un enfoque por pasadas en lugar de apostarlo todo a un prompt.

Pro cuesta $25 al mes con 200 créditos, aproximadamente 16 plataformas o 33 construcciones rápidas, o 66 ediciones si solo gastas en editar. El plan Free trae 5 créditos una vez, menos de lo que cuesta una construcción nueva. Business cuesta $99 al mes con 800 créditos.

Lee esos números como un argumento a favor de la ruta incremental. Una construcción más cinco ediciones son veintiún créditos y producen un proyecto que entendiste en cada paso. Cuatro intentos de un prompt gigante son veinticuatro y producen o nada o algo que no sabes depurar. Qué ocurre cuando el saldo se agota está en qué pasa cuando se acaban los créditos.

¿Cuándo el problema no es el prompt?

Cuando lo que pides está fuera de lo que el producto fabrica, y ninguna reformulación cambia eso. Tenerlo claro evita que te culpes por una frontera.

Aplicaciones móviles nativas. La salida corre en un navegador. Se puede abrir en un teléfono y añadir a la pantalla de inicio, y eso no es una ficha en una tienda de aplicaciones.

Juegos en 3D. Los juegos son 2D y de navegador. Eso es un rango real y también un borde real.

Lógica de negocio muy específica. Prorrateos, matrices de permisos e integraciones con un sistema que no tiene conector llegan mediante una secuencia de ediciones, no con un solo prompt, y a veces mediante alguien trabajando sobre el código exportado. Zugo no sustituye a un equipo de desarrollo en un producto complejo.

Cualquier cosa que exija criterio sobre tu negocio. Un generador escribe lo que describes. Decidir qué debería construirse sigue siendo tuyo.

¿Cómo evitarlo la próxima vez?

Cinco hábitos, y salen baratos.

Conecta los servicios antes de describir funciones que los necesitan, porque el conector es la condición previa y no el remate. Construye la versión más pequeña que ya resulte interesante y trata todo lo demás como ediciones. Nombra comportamientos, no adjetivos. Cambia una cosa por edición para poder saber qué provocó qué. Y mira la dirección publicada en un dispositivo real después de cada pasada, en lugar de acumular cinco cambios sin verificar. El paso de publicar está en cómo publicar el proyecto.

Juntos convierten la construcción en un bucle difícil de estropear del todo: describe algo pequeño, míralo, describe lo siguiente pequeño. La mayoría de los fallos son un único prompt heroico que se saltó el bucle entero.

Cuando quieras probar la versión incremental, describe la página útil más pequeña que se te ocurra en Zugo, publícala y añade la segunda cosa solo después de haber mirado la primera.