I spent a few weeks building a Neuro-Symbolic Manufacturing Engine. I proved that AI can design drones that obey physics. I also proved that asking AI to pivot that code to robotics is a one-way ticket to a circular drain. En las últimas semanas, he estado documentando mi construcción de viajes , un sistema de IA capaz de traducir la intención vaga del usuario en hardware probado en el vuelo. OpenForge El objetivo era probar las capacidades de razonamiento de Google. Quería responder a una pregunta específica: ¿Puede un LLM ir más allá de escribir scripts de Python y realmente ingeniería de sistemas físicos donde la tolerancia, la tensión y la compatibilidad importan? Gemini 3.0 La respuesta, resulta, es un complicado “Sí, pero...” Aquí está el post-mortem sobre lo que funcionó, lo que fracasó, y la diferencia crítica entre Código y Los Sistemas. Generating Refactoring La victoria: Drone_4 Works Primero, la buena noticia.La rama de drone_4 del repositorio es un éxito. Si clona el repo y pide un "Drone de cine de largo alcance", el sistema funciona de semilla a simulación. Comprende la intención: Sabe que "Cinema" significa vuelo suave y "Long Range" significa protocolos GPS y Crossfire. Obedece a la física: El motor de compatibilidad rechaza con éxito las combinaciones de motor y batería que podrían sobrecalentarse o explotar. Simula la realidad: los archivos USD generados para NVIDIA Isaac Sim realmente vuelan. Admito, tuve que ser pragmático. En make_fleet.py, yo "engano" un poco. me basé menos en el LLM para inventar dinámicamente la lógica de la flota y más en la orquestación de Python de código duro. tuve que recordarme que esto era una prueba del razonamiento de Gemini 3.0, no un concurso para ver si podía evitar escribir una sola línea de código. Como prueba del concepto de —donde el LLM maneja la traducción creativa, y Python maneja las leyes de la física—OpenForge es una victoria. Neuro-Symbolic AI El fracaso: el pivote cuadruped La segunda mitad del reto fue tomar este motor de trabajo y pivotarlo. quería convertir al diseñador de drones en un diseñador de perros robóticos (el perro de rancho). Alimenté a Gemini 3.0 toda la base de código (88k tokens) y lo pedí al refactor. I am officially shelving the Quadruped branch. Se ha vuelto obvio que la forma en que empecé este pivote me llevó a un agujero de rescate de drenaje circular.Me encontré en un loop donde fijar un cálculo de torque rompería el suministro de inventario, y fijar el suministro rompería la simulación. Si quiero construir el Ranch Dog, tengo que dar un paso atrás y construirlo desde cero, usando el motor Drone simplemente como un modelo de referencia, no una base para sobreescribir. La lección: el efecto aplastante ¿Por qué el motor del Drone tuvo éxito mientras que el refactor cuadruped fracasó? Se reduce a un comportamiento específico que he observado en Gemini 3.0 (y otros modelos de alto contexto). Cuando construyes desde el fondo, tú y la IA construyes la arquitectura paso a paso. Sin embargo, cuando usted solicita un LLM para una aplicación existente, no ve el historial del código. No ve las cicatrices de batalla. pivot El código original del Drone se rompió en pasos distintos y lineales. Había puertas específicas de gestión de errores y estados de espera derivados de fallos anteriores. Gemini 3.0, en un intento de ser eficiente, Aglomeró distintos pasos lógicos en procesos singulares, monolíticos.En la superficie, el código parecía más limpio y más pitónico.Pero en realidad, había eliminado las paredes estructurales de carga que mantenían la aplicación estable. flattened the architecture Supuso que el código era una guía de estilo, no una necesidad estructural. El paradojo de la capacidad: Gemini 2.5 vs. 3.0 Este proyecto destacó una realidad contraria a la intuición: Gemini 2.5 was safer because the code it confidently spit out was truncated pseudo-code. En versiones anteriores, las salidas fueron estructuradas para mostrarle cómo podría ir sobre la construcción. Después tendría que construir un plan para construir los intestinos dentro del programa. A veces, podría escribir el archivo entero. A veces, tuvo que ir función por función. Gemini 2.5 me obligó a ser el arquitecto. tuve que ir programa por programa, mapeando exactamente lo que quería. tuve que mantener la mano de la IA. Gemini 3.0 tiene la velocidad y el razonamiento para hacer todo de una vez. crea una ilusión creíble de un One-Shot Pivot. Gemini 3.0 creates code that looks workable immediately but is structurally rotten inside. It skips the scaffolding phase. La sentencia final Si está buscando construir un motor de fabricación generativa, o cualquier sistema complejo con LLMs, aquí están mis conclusiones finales del experimento OpenForge: Greenfield es fácil, Brownfield es difícil: LLMs sobresalen en la construcción desde cero. No Refactor con Prompts: Si desea cambiar el propósito de una aplicación, no pida a la IA que reescriba esto para X. En su lugar, mapee el flujo lógico de la aplicación antigua y pida a la IA que construya una nueva aplicación usando ese mapa lógico. La arquitectura sigue siendo el rey: No puedes ver una base de código como un documento fluido que puede ser morfemado por un LLM. OpenForge demostró que podemos cerrar la brecha entre la vaga intención del usuario y la ingeniería física. Dicho esto, Gemini 3.0 es un salto masivo desde 2.5.Parte de lo que estoy explorando aquí es cómo sacar el mejor de una nueva herramienta.
