Cómo editar una web hecha con IA después de crearla

Se edita escribiendo lo que quieres cambiar. En Zugo le dices al chat "sube el formulario por encima del mapa" o "pon la cabecera más oscura", la IA modifica el proyecto real, lo arranca en un sandbox para comprobar que sigue abriendo y te devuelve la versión nueva. Cada edición cuesta 3 créditos. No hace falta abrir ningún archivo.

La primera versión es un borrador, no un resultado. Prácticamente todo el valor de estas herramientas está en el bucle de ajuste, y hacerlo bien es una habilidad concreta que se aprende en una tarde.

¿Qué se puede cambiar por chat y qué no?

Casi todo lo que se ve y buena parte de lo que hace. Texto, colores, tipografía, orden de las secciones, añadir o quitar bloques, cambiar campos de un formulario, conectar un servicio o ajustar el comportamiento en móvil.

Lo que cuesta más son los cambios que en realidad son varios cambios disfrazados de uno. "Hazlo más profesional" no es una instrucción: es una valoración, y la IA tiene que adivinar qué significa para ti. "Quita la sombra de las tarjetas, usa una sola tipografía y reduce el titular a dos líneas" sí lo es.

También cuesta más la lógica de negocio muy específica. Descuentos por volumen con reglas propias, permisos por tipo de usuario o flujos con muchas condiciones se consiguen, pero a base de ediciones sucesivas, cada una pequeña y comprobable, no de un solo prompt largo.

Y hay una categoría que no depende de la herramienta: lo que requiere una decisión tuya. Qué precio poner, qué prometes, qué foto usar. La IA escribe cualquier cosa que le pidas y ninguna de esas decisiones es suya.

¿Cómo se pide un cambio para que salga a la primera?

Nombrando el sitio, el elemento y el resultado. La diferencia entre una edición que acierta y tres que se acercan está casi siempre en la precisión de la frase, no en la potencia del modelo.

La fila del menú enseña el patrón más útil de todos: describir el síntoma exacto, con el dispositivo y la acción, en vez de la valoración. Es la misma diferencia que hay entre decirle a un mecánico "el coche va mal" y "suena al frenar en curva".

Cambia una cosa cada vez cuando estés afinando. Cinco peticiones juntas se resuelven en una sola edición y son más baratas, y si el resultado no te gusta no sabrás cuál de las cinco lo estropeó. Cómo se escribe el encargo inicial está en la guía de prompts.

¿Cuánto cuesta editar y cuánto tarda?

Una edición cuesta 3 créditos, la mitad que una construcción nueva. Ese número es el que conviene tener en la cabeza cuando decides si pides un cambio o rehaces la página entera.

El plan gratuito da 5 créditos, así que da para una edición y poco más. Pro son 25 dólares al mes con 200 créditos, que dan margen para un ciclo largo de ajustes, y Business son 99 dólares al mes.

Aquí hay una cuenta práctica que ahorra dinero: si vas a cambiar el 80% de la página, sale más barato agrupar los cambios en una sola edición que pedir seis. Y si lo que quieres es otra cosa distinta, reconstruir desde cero cuesta 6 y a veces es la decisión correcta.

¿Y si una edición empeora la web?

Vuelves a la versión anterior. Es la razón por la que editar conversando no da miedo: el estado anterior no se pierde cuando pides un cambio, así que probar algo agresivo tiene un coste acotado.

Esa red de seguridad cambia la forma de trabajar. En vez de razonar mucho antes de pedir, conviene pedir, mirar y decidir, porque mirar el resultado real es más informativo que imaginarlo. La guía de qué hacer si el resultado no te gusta desarrolla esa vuelta atrás.

Además, cada edición vuelve a arrancarse en un sandbox antes de llegar a ti, y una construcción que no abre no se entrega. Eso no garantiza que el cambio te guste; garantiza que la web no se queda en blanco por un cambio de texto.

Un hábito que ahorra disgustos: cuando la página esté en un punto que te sirve, publícala. Tener una versión buena en vivo hace que experimentar después sea cómodo, porque lo que ven los visitantes no cambia hasta que vuelves a publicar.

¿Se puede editar el código directamente?

Sí, y no hace falta para casi nada. El proyecto es código real y se exporta a GitHub como un repositorio normal, así que un programador puede abrirlo, cambiarlo y trabajar como lo haría con cualquier otro proyecto.

Eso importa por una razón concreta: la ruta de salida existe desde el primer día. Si el proyecto crece y llega a un punto en el que el chat ya no es el instrumento adecuado, no hay que reconstruirlo en otro sitio. La guía de exportación de código explica cómo funciona.

La frontera honesta es esta: Zugo no sustituye a un equipo de desarrollo en un producto complejo. Para una web, una tienda pequeña, un panel interno o un primer producto, el bucle de chat basta y sobra. Para un sistema con integraciones profundas y muchos casos raros, el chat te lleva lejos y luego el trabajo es de programación.

Los juegos tienen su propia frontera: se construyen en 2D y corren en el navegador. Dentro de eso se editan igual que cualquier otra cosa, y lo que casi siempre hace falta ajustar es la dificultad, que solo se juzga jugando.

¿Cuál es el orden que menos tiempo pierde?

Estructura, contenido, estilo. En ese orden, porque cambiar la estructura después de haber pulido los colores obliga a pulirlos otra vez.

Primero coloca las secciones que tienen que estar y quita las que sobran. Después escribe los textos de verdad, con tus precios y tus datos, porque un texto real cambia el aspecto de la página más que cualquier ajuste visual. Solo entonces toca el color, la tipografía y el espaciado.

Al final, dos comprobaciones que valen más que diez ediciones: ábrela en un móvil de verdad y haz clic en todos los enlaces. La mayoría de los fallos vergonzosos de un lanzamiento se cazan ahí, en menos de cinco minutos.

Empieza por una construcción y dedica las tres primeras ediciones a la estructura en zugo.dev.