Error uno: escribir una especificación en lugar de una frase
Las personas que ya se han visto perjudicadas por software de mala calidad tienden a abrir el generador y escribir un párrafo. Sistema de calificación, preferencias de unidades, modo sin conexión, esquema de colores, todo anticipado antes incluso de que llegue la primera respuesta. Se siente responsable. No lo es. El generador lee tu única frase, infiere lo que probablemente quieres decir y regresa con un plan en unos quince segundos —"un registro de entrenamiento para escaladores" se convierte en un registro de sesiones, una vista de seguimiento de grados y un panel, con la escala V de boulder y las rutas YDS elegidas por defecto porque eso es lo que usa la mayoría de los escaladores. Te dice qué eligió, ahí mismo en el plan, para que puedas corregirlo en una línea si eres la excepción. Escribir el párrafo por adelantado no te ahorra ese paso. Igual obtienes un plan, igual tienes que leerlo, y ahora has pasado tres minutos escribiendo restricciones que el plan te habría mostrado de todos modos, en el orden que realmente importa para tu proyecto.
El plan no es un formulario con espacios para rellenar. Es texto en prosa, y respondes en prosa. "En realidad, cámbialo a grados de escalada estilo europeo, estoy en Europa" es una edición completa. También lo es "añade un campo de compañero/registro de aseguramiento, escalo con distintas personas". Cada edición regenera el plan, no la construcción — estás ajustando el rumbo antes de que empiece la parte costosa, no reiniciándola. Aprobar ese plan es la última decisión que debes tomar. Todo lo que viene después es generación y verificación.
Error dos: observar el feed como si fuera una terminal bloqueada
La construcción se ejecuta del lado del servidor, y el desastre aquí casi siempre es una falsa alarma: alguien mira un feed de actividad silencioso durante dos minutos y asume que se ha quedado colgado. No es así: está en una fase que no produce salida visible a cada segundo, y el feed indica en qué fase estás precisamente por esta razón. Puedes cerrar la pestaña por completo. La ejecución no vive en tu navegador.
Lo que realmente debes esperar varía mucho según el tipo de proyecto. El registro de escalada — unas pocas páginas, un modelo de datos local, sin llamadas a una API externa — se completa en menos de tres minutos, lo cual es típico para cualquier cosa que básicamente sea "registra esto, grafica aquello, muéstrame una lista". En el momento en que una construcción necesita un backend real, autenticación, una base de datos con relaciones, tareas en segundo plano, estás ante ocho a doce minutos, porque ahora hay generación y migración de esquemas, y la verificación se ejecuta una segunda vez contra código de servidor en lugar de solo marcado. Los juegos son aún más lentos, porque necesitan generación de recursos: sprites, efectos de sonido, a veces una segunda pasada visual si el primer intento no se ve bien en el tamaño en el que se mostrará. Y el empaquetado nativo, un APK realmente instalable, no una vista web envuelta en un shell, se delega a una cadena de herramientas real. Gradle, firma, todo eso. Solo ese paso puede añadir de cinco a diez minutos por encima de todo lo demás, y es la fase en la que un feed silencioso significa que la cadena de herramientas está haciendo su trabajo, no que algo se haya roto.
El costo honesto de este modelo es que pierdes la retroalimentación instantánea, carácter por carácter, de ver el código fluir hacia un editor. Lo que lo reemplaza es un sistema que sobrevive a que tu portátil se ponga en reposo y a que tu wifi se caiga, que puedes revisar desde tu teléfono, que sigue funcionando estés o no observándolo. Para una construcción de noventa segundos, esa compensación apenas se nota. Para la construcción de backend de doce minutos, es la diferencia entre vigilar una terminal y salir por un café.
Error tres: confundir generado con terminado
Esta es la parte cara. Una compilación que termina rápido y no ha sido revisada no es una compilación terminada, es un borrador que resulta funcionar — y en la brecha entre esas dos cosas es donde la mayoría de los generadores de sitios rápidos se ganan su mala reputación, publicando formularios sin sanitización y botones que nadie puede alcanzar con el teclado. Antes de que esta plataforma dé algo por terminado, agentes verificadores independientes lo revisan: código, seguridad, enlaces, SEO, accesibilidad y conformidad con el plan que aprobaste. Esa es una revisión genuinamente separada, no el mismo agente releyendo su propio resultado y asintiendo.
La verificación de seguridad busca los errores comunes que realmente causan problemas en producción: una clave de API subida al código del lado del cliente, un formulario que acepta entradas sin sanitización, un endpoint que confía en un ID de usuario proporcionado por el cliente en lugar de derivarlo de la sesión. La verificación de accesibilidad no es un linter que puedas silenciar con un comentario — comprueba relaciones de contraste reales y si los elementos interactivos son accesibles con el teclado.
La conformidad es la que más se subestima. Es fácil que una pasada de generación omita silenciosamente algo que pediste — ese campo de compañero/registro de descenso de tu edición del plan, por ejemplo — a tres archivos de distancia dentro de la compilación, despriorizado sin que nadie decidiera eliminarlo. La conformidad relee tu plan aprobado frente al resultado real y detecta la brecha. Cuando encuentra una, la corrección se aplica y se vuelve a verificar automáticamente; no recibes una lista de tareas pendientes, recibes o bien una corrección que nunca ves, o bien nada que corregir en absoluto. Los detalles de lo que verifica cada agente verificador, y qué ocurre cuando algo falla dos veces seguidas, están en Cómo se verifican las compilaciones. Lo único que vale la pena llevarse de esta sección: terminado significa aprobado, no generado. Trata esas dos cosas como lo mismo y tarde o temprano publicarás la clave expuesta o el botón inalcanzable.
Lo que obtienes si evitas los tres errores
- Un producto funcional en una vista previa real que puedes explorar — una instancia realmente en ejecución con tus datos conectados, no una captura de pantalla de cómo se verá.
- Un hilo de chat vinculado a él, donde "oscurece el encabezado y añade una página de estadísticas" produce una versión dos junto a la versión uno. La versión anterior no desaparece; queda como respaldo mientras la nueva ocupa la vista previa en vivo.
- Botones que hacen cosas: publicar en vivo, descargar el código, generar instaladores nativos, enviar a una tienda. No modales de venta adicional disfrazados de botones.
Ese botón de descargar el código merece una segunda mirada, porque es lo que distingue a una herramienta en la que confiarías para algo real de una que solo usarías para prototipos desechables. Si el código es realmente tuyo para llevarte, con una estructura de archivos legible y sin bloqueos exóticos más allá de lo que realmente pediste, entonces la plataforma tiene que seguir ganándose tu próxima sesión en lugar de vivir de la comodidad de que ya estás atrapado dentro de ella.
