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. Nas últimas semanas, estiven documentando a miña construción de viaxes , un sistema de IA capaz de traducir a vaga intención do usuario en hardware probado de voo. OpenForge O obxectivo era probar as capacidades de razoamento de Google Eu quería responder a unha pregunta específica: pode un LLM ir máis aló de escribir scripts de Python e realmente enxeñar sistemas físicos onde a tolerancia, a tensión e a compatibilidade importan? Gemini 3.0 A resposta, resulta, é un complicado "si, pero..." Aquí está o post-mortem sobre o que funcionou, o que fracasou e a diferenza crítica entre Código e Os sistemas. Generating Refactoring Descrición do xogo Drone_4 Works Primeiro, a boa noticia.A rama drone_4 do repositorio é un éxito. Se clona o repo e pide un "Long Range Cinema Drone", o sistema funciona de semente a simulación. Comprende a intención: sabe que "Cinema" significa voo suave e "Long Range" significa protocolos GPS e Crossfire. Obedece á física: O motor de compatibilidade rexeita con éxito as combinacións de motor/batería que poderían sobrecalentarse ou explotar. Simula a realidade: os arquivos USD xerados para NVIDIA Isaac Sim realmente voan. Recoñezo, tiven que ser pragmático. En make_fleet.py, "traizoei" un pouco. Confiaba menos no LLM para inventar dinámicamente a lóxica da flota e máis na orquestración de Python de código duro. tiven que lembrarme que isto era unha proba do razoamento de Gemini 3.0, non un concurso para ver se podía evitar escribir unha soa liña de código. como unha mostra do concepto de Onde o LLM xestiona a tradución creativa e Python xestiona as leis da física, OpenForge é unha vitoria. Neuro-Symbolic AI O fracaso: o pivote cuadruped A segunda metade do reto foi tomar este motor de traballo e pivotealo. quería converter o Deseñador de Drones nun Deseñador de cans robóticos (o can de granxa). Alimentou Gemini 3.0 toda a base de código (88k tokens) e pediulle ao refactor. I am officially shelving the Quadruped branch. Tornouse obvio que a forma en que comecei este pivote me levou a un burato de solucionamento de problemas de drenaxe circular.Atopeime nun loop onde fixar un cálculo de torque rompería a obtención de inventario e fixar a obtención rompería a simulación. Se quero construír o Ranch Dog, teño que dar un paso atrás e construílo desde cero, usando o motor Drone simplemente como un modelo de referencia, non unha base para sobreescribir. A lección: o efecto aplastante Por que o motor Drone logrou o éxito mentres o refactor Quadruped fracasou? Isto débese a un comportamento específico que observei en Gemini 3.0 (e outros modelos de alto contexto). Cando constrúes desde o principio, ti e a IA constrúen a arquitectura paso a paso. Porén, cando se solicita un LLM para unha aplicación existente, non ve a historia do código. Non ve as cicatrices de batalla. pivot O código orixinal do Drone foi dividido en pasos distintos e lineais. Houbo portas específicas de xestión de erros e estados de espera derivados de fallos anteriores. Gemini 3.0, nun intento de ser eficiente, Axuntou pasos lóxicos distintos en procesos singulares e monolíticos.Na superficie, o código parecía máis limpo e máis pitónico.Pero na realidade, eliminou as paredes estruturais de carga que mantiñan a aplicación estable. flattened the architecture Supuxo que o código era unha guía de estilo, non unha necesidade estrutural. O paradoxo da capacidade: Gemini 2.5 vs. 3.0 Este proxecto destacou unha realidade contraintuitiva: Gemini 2.5 was safer because the code it confidently spit out was truncated pseudo-code. Nas versións anteriores, as saídas foron estruturadas para mostrarche como poderías ir sobre a construción. Entón terías que construír un plan para construír os intestinos dentro do programa. Ás veces, podería escribir o ficheiro enteiro. Ás veces, terías que ir función por función. Gemini 2.5 forzoume a ser o Arquitecto. tiven que ir programa por programa, mapeando exactamente o que quería. tiven que manter a man da IA. Gemini 3.0 ten a velocidade e o razoamento para facelo todo dunha vez. Gemini 3.0 crea código que parece operable de inmediato, pero está estruturalmente podre por dentro. Xuízo final Se está a buscar construír un motor de fabricación xerativa, ou calquera sistema complexo con LLMs, aquí están as miñas conclusións finais do experimento OpenForge: Greenfield é Fácil, Brownfield é Duro: LLMs sobresaen na construción desde cero. Non refactor con Prompts: Se queres cambiar o propósito dunha aplicación, non pidas á IA que reescriba isto para X. En lugar diso, mapea o fluxo lóxico da vella aplicación e pídelle á IA que constrúa unha nova aplicación usando ese mapa lóxico. Arquitectura é aínda rei: Non podes ver unha base de código como un documento fluído que pode ser morfo por un LLM. OpenForge demostrou que podemos romper a brecha entre a vaga intención do usuario e a enxeñaría física. Dito isto, Gemini 3.0 é un salto masivo desde 2.5. parte do que estou explorando aquí é como sacar o mellor dunha nova ferramenta.
