la respuesta honesta a "¿cómo usás la ia para construir interfaces y escenas?" es: no escribiendo una especificación enorme y recibiendo de vuelta algo terminado. ese camino produce algo seguro de sí mismo y equivocado. lo que de verdad funciona es un ciclo tan ajustado que casi no tiene pasos.
el ciclo
- soltá un solo activo. una pieza de arte, una capa, un único elemento. no el plan — una sola cosa.
- "intégralo." la ia conecta esa única cosa con lo que ya existe.
- editá por capa. movés este elemento. no "rehacé la escena" — "este, acá."
- mostrá. mirá el resultado renderizado de verdad, no una descripción de él.
- ajustá. corto y direccional — "más naranja", "subilo 50px", "engreído, no sorprendido" — y de vuelta al 3.
el diseño no se decide de entrada y se ejecuta. emerge del ciclo. en una construcción, la tarjeta de resultado fue del centro → al costado → al centro otra vez sin que nadie lo decidiera por adelantado — cada movimiento solo era obvio una vez que el anterior estaba en pantalla.
╭──────────────────────────╮ │ scene │░ ├──────────────────────────┤░ │ ▣ layer 3 + new art │░ ◂ edit one │ ▣ layer 2 ~ moved │░ │ ▣ layer 1 · base │░ ╰──────────────────────────╯░ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░ small diff · always shippable
dónde se rompió
dos trampas con dientes.
la primera: la trampa de que localStorage le gana al archivo. el editor de escenas guardaba las posiciones en localStorage para que los ajustes se sintieran instantáneos. pero eso significaba que el estado guardado pisaba en silencio al archivo fuente. entonces cambiabas el archivo, recargabas, y tu cambio no aparecía — ganaba el valor viejo de localStorage. esto quemó varias idas y vueltas de "lo cambié, no se muestra". la lección: cuando un cambio no aparece, sospechá de una capa de caché o de sobreescritura antes de sospechar del cambio. el arreglo fue enrutar las ediciones por propiedades que la sobreescritura no escribía, o sacar cualquier cosa estructural de la capa de sobreescritura y hornearla en el fuente como algo real, de primera clase.
la segunda: el susto del trabajo perdido. una vez un paso de verificación escribió en estado persistente de una página que se estaba editando activamente — técnicamente inofensivo, totalmente aislado. coincidió con un momento de "se me borró el trabajo" y se leyó como que la herramienta destruía el trabajo. el daño real fue cero; el daño a la confianza no. la regla que salió de ahí: nunca verifiques escribiendo en estado vivo de algo en lo que la persona está trabajando activamente. verificá solo de lectura. revisá la sintaxis, cargalo sin tocar nada. el trabajo perdido — incluso el miedo a perderlo — no es un bug chico. es toda la relación.
él posiciona, yo construyo
el humano arrastra elementos en un editor en vivo donde la respuesta es instantánea — esa es la parte rápida, intuitiva, guiada por el ojo, y un humano simplemente es mejor en eso. la ia toma la lógica, la animación, el estilo, el arte nuevo — las partes lentas de afinar a mano y rápidas de especificar. no hagás que la ia adivine posiciones de píxeles; no hagás que el humano escriba a mano el código de las transiciones. jugá con el camino rápido de cada lado.
y las ediciones por capa le ganan a un solo prompt grande por una razón concreta: un prompt grande obliga a la ia a regenerar todo, incluido el 90% que ya estaba bien, y va a "mejorar" en silencio cosas que no le pediste que tocara. una edición por capa es un diff chico, legible y reversible. una línea por cambio. podés ver exactamente qué se movió.
la acumulación no es más que control de versiones para el diseño en sí — commits chicos, siempre listos para enviar, nunca una reescritura de golpe que no podés deshacer.
el punto
cuando el medio es visual, la acumulación le gana a especificarlo-todo-de-entrada. no como preferencia de estilo — por una razón estructural: no podés especificar con precisión lo que todavía no viste. la especificación es una conjetura sobre un resultado visual, y los resultados visuales te sorprenden. cada ciclo de "soltá una cosa → mirá → ajustá" reemplaza una conjetura por una observación. la especificación de entrada amontona todas las conjeturas en el momento en que menos sabés.
la única excepción: confirmá la forma antes de una reconstrucción desde cero. ¿un ajuste chico? hacelo y mostrámelo. pero si estás por reconstruir todo un componente de otra manera, revisá primero la estructura — adivinar la arquitectura desperdicia una reconstrucción entera, y ese es el único lugar donde el ciclo rápido sale demasiado caro de correr sobre una conjetura equivocada.