Sistema de activos del motor v1 + pulido profundo del chat

Cuatro pistas en un día: el panorama del día

Este fue el día más denso hasta el momento, avanzando desde la medianoche hasta la mañana siguiente con cuatro pistas ejecutándose a la vez: el motor aterriza característica tras característica y se corrige bajo un estricto circuito cerrado de siete pasos, el panel de chat entra en un pulido de estado estable "nunca terminado", el backend clava la seguridad y los contratos de interfaz con pruebas una por una, además de una refactorización de cierre que sacó la recarga en caliente de la interfaz por sí sola. Reunir tanto en un día sin caos se redujo a dos cosas: cada pista tenía límites claros y criterios de aceptación, y cuanto más cerca estaba un cambio de la base, más tenía que ser verificable. A continuación está dividido por temas, pero recuerde que avanzaron juntos en un solo día.

Sistema de activos del motor v1: hacer referencia al contenido del juego mediante identificador

La entrega más importante del motor este día fue la primera versión de un sistema activo. Antes, el "contenido del juego", como modelos, texturas y escenas, no tenía una forma unificada de gestionarse; el sistema de activos les dio una identidad formal: cada activo es un objeto estructurado al que se hace referencia a través de un "identificador" liviano en lugar de pasar enormes datos sin procesar. Un asa es como el número de llamada de una biblioteca: manténgalo presionado y podrá ir a buscar el libro, sin tener que cargar con todo el libro. Se construyó una escena de sala de muestra para validar la cadena. La importancia: ahora se puede hacer referencia al contenido del juego, compartirlo y reutilizarlo de forma estructurada, con un punto de entrada para cargar modelos, texturas y escenas. Es el verdadero punto de partida para todas las funciones posteriores de "importar un modelo, colocar recursos en una escena".

Un punto de referencia de paridad de píxeles: la calidad de renderizado no puede retroceder silenciosamente

Lo que más teme un renderizador interno no es un solo cuadro incorrecto, sino "empeorar silenciosamente sin que nadie se dé cuenta": cambie una cosa y algunos cuadros difieren de la referencia en unos pocos píxeles, invisibles a la vista pero que se desvanecen con el tiempo. Este día se planteó un criterio de "paridad de píxeles": se comparan los cuadros renderizados del motor con una referencia píxel por píxel, y en el momento en que la diferencia excede un umbral, la integración continua se vuelve roja y bloquea el cambio para que no se fusione con el tronco. "La representación es correcta" de algo que se observa manualmente y se siente a una puerta automática y objetiva que se ejecuta en cada confirmación. Para un motor que evoluciona su calidad de imagen a largo plazo, esta puerta es la condición previa para que la calidad se mantenga estable; con ella, puede cambiar la representación con audacia y sin temor.

Verificación visual de Sandbox: permita que el agente "vea" si la imagen es correcta

Hacer que una IA edite juegos automáticamente se encuentra con un problema inevitable: después de cambiar las cosas, ¿cómo sabe que la imagen es realmente correcta? Verificar solo si el código tuvo un error conduce fácilmente a "el código no falló pero la pantalla está en negro" mientras se cree que tuvo éxito. Este día se construyó un mecanismo de verificación visual en el sandbox, separando deliberadamente dos roles: "producir la imagen" y "comprobar la imagen": un lado ejecuta el juego y captura los fotogramas, el otro juzga los fotogramas capturados. Separar los roles hace que la verificación sea más confiable: no hay trampa de autocertificación de "edito, hago capturas de pantalla, lo declaro bien". Este paso es clave para que el agente pase de "puede escribir código" a "es responsable de su salida": ya no simplemente arroja código por encima de la pared, sino que puede cerrar el ciclo y observar "cómo se ve realmente lo que hice".

Representación instanciada + muchos objetos: un juego de bloques como piedra de toque

Este día también explotó la capacidad del motor para muchos objetos con una demostración de minijuego de "eliminación de bloques que caen". Estos juegos presentan muchos bloques idénticos en la pantalla a la vez, y emitir un comando de extracción por separado para cada pila se acumula rápidamente. Para ello, el motor añadió "dibujo instanciado": un único envío dibuja un lote grande del mismo objeto, amortizando el costo repetido. La ruta de renderizado de muchos objetos se ordenó al mismo tiempo, por lo que "muchas entidades que aparecen juntas" se ejecutan de manera rápida y estable. Validar con un minijuego genuinamente jugable en lugar de una prueba abstracta es en sí misma una disciplina: hacer que un juego real funcione sin problemas es mucho más convincente que pasar un fragmento aislado.

~100 pases de chat polaco: costo, duración, múltiples proveedores

El panel de chat entró en un estado estable "nunca terminado" este día, con más de cien pequeñas iteraciones centradas en algunas cosas prácticas. Uno: muestra el costo y la duración reales de cada turno, con un formato de cantidad adaptable (céntimos, diez y dólares, cada uno con la precisión adecuada) para que puedas ver de un vistazo cuánto costó. Dos: un selector conmutable para "qué backend de codificación usar": puede anclar una conversación a una, la elección se recuerda, se sincroniza entre pestañas, admite la selección de teclado arriba/abajo y advierte cuando la que eligió no está disponible. Tres: manejo reflexivo del estado "el modelo está pensando en silencio durante mucho tiempo", que induce ansiedad: muestra los segundos transcurridos, sugiere un cambio más allá de un umbral y una nota de marcador de posición para "terminado pero sin salida visible". Cada pase tocó una cosa, se autoprobó y registró una nota. Esta pista gana cien pases porque es la superficie que el usuario mira más tiempo cada día: por muy fuerte que sea la capacidad, si lee laboriosamente y se siente inseguro, no hay confianza.

Seguridad backend y endurecimiento de contratos: listas blancas, defensa transversal, muchas pruebas

Dado que el agente realmente lee y escribe archivos en su máquina, el backend debe hacer que "sólo pueda tocar lo que debería" sea hermético. Este día se establecieron una gran cantidad de defensas y pruebas en torno a la seguridad de archivos y rutas: restringir las rutas accesibles con una lista blanca, agregar defensa contra el exceso de "recorrido de directorio", negarse a sobrescribir un directorio existente al escribir un archivo y redactar la ruta de inicio del usuario en las respuestas externas (para que las rutas reales de su máquina no se filtren). Mientras tanto, los contratos de interfaz del backend fueron determinados prueba por prueba: qué entrada debería devolver qué, cómo se manejan los casos extremos, todo protegido por pruebas, y el recuento de pruebas unitarias superó un hito ese día. Nada de esto es una "nueva característica visible", pero decide si te atreves a permitir que una IA de edición de archivos entre en tu propio proyecto: sólo con límites claros, comportamiento predecible y regresiones detectadas por pruebas se puede tener una verdadera tranquilidad.

Una refactorización final: hacer que la recarga en caliente de la interfaz sea independiente

Al llegar la madrugada, el día cerró con una refactorización estructural: hacer que el mecanismo de recarga en caliente de la interfaz sea independiente y colocar cada parte en su lugar a lo largo del camino: los datos del juego del usuario se movieron al propio directorio de la instancia, la fuente del motor se extrajo a una ubicación de compilación unificada, la configuración del entorno se elevó a la raíz del repositorio y se enderezó el diseño del directorio anidado propenso a errores. Una refactorización de este tipo casi no muestra cambios por parte del usuario, pero hace que la experiencia de "editar el código, la interfaz se recarga instantáneamente" sea más limpia y menos propensa a interferencias cruzadas. Cuanto más claros sean los cimientos, más rápido se construirá más adelante; hacer esto al final del día es precisamente porque, después de que aterrizaron tantas cosas nuevas, todo el árbol necesitó una consolidación para realinearse.

que significa este dia

Si los días anteriores demostraron que "la conversación puede construir algo ejecutable", este día sentó las bases para "se puede hacer de manera confiable y a largo plazo". El sistema de activos permite gestionar el contenido de forma estructural; el punto de referencia de paridad de píxeles y la verificación visual del espacio aislado dan un criterio objetivo sobre si la imagen es correcta; la seguridad y las pruebas del backend hacen que "dejar que la IA actúe" sea confiable; el pulido del chat hace que la gente quiera usarlo a diario; y la refactorización de cierre lo mantiene todo limpio en términos de ingeniería. Juntos revelan una postura: avanzar rápidamente, pero dejar a cada paso un rastro sólido que puede verificarse, retroceder y retrospectarse. Ese es exactamente el modelo que este registro quiere dejar para el desarrollo futuro: la velocidad y el rigor no son una cosa o la otra, sino dos cosas que se pueden lograr en el mismo día.