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. In die afgelope paar weke het ek my reisbou gedokumenteer , 'n AI-stelsel wat in staat is om vaag gebruikersintensies te vertaal in vlugbevestigde hardeware. OpenForge Die doel was om die redevaarding vermoëns van Google te toets Ek wou 'n spesifieke vraag beantwoord: Kan 'n LLM verder gaan as Python-skripte skryf en eintlik fisiese stelsels ontwerp waar verdraagsaamheid, spanning en verenigbaarheid saak maak? Gemini 3.0 Die antwoord, blyk dit, is 'n ingewikkelde "Ja, maar ..." Hier is die post-mortem oor wat gewerk het, wat misluk het, en die kritieke verskil tussen Kode en die stelsels. Generating Refactoring Die Wins: Drone_4 Werk Die drone_4 tak van die repository is 'n sukses. As jy die repo kloneer en 'n "Long Range Cinema Drone" vra, werk die stelsel van saad tot simulasie. Dit verstaan bedoeling: Dit weet dat "Cinema" beteken gladde vlug en "Long Range" beteken GPS en Crossfire protokolle. Dit gehoorsaam die fisika: Die Compatibility Engine verwerp suksesvol motor / battery kombinasie wat oorverhit of ontploff. Dit simuleer realiteit: Die USD-lêers wat vir NVIDIA Isaac Sim gegenereer is, vlieg eintlik. Ek moet erken, ek moes pragmaties wees. In make_fleet.py het ek 'n bietjie bedrieg. Ek het minder vertrou op die LLM om die vlootlogika dinamies uit te vind en meer op hardgekodeerde Python-orkestrasie. Ek moes myself herinner dat dit 'n toets was van Gemini 3.0 se rede, nie 'n kompetisie om te sien of ek 'n enkele lyn van kode kon vermy. As 'n bewys van die konsep van Waar die LLM die kreatiewe vertaling hanteer en Python die wette van fisika hanteer, is OpenForge 'n oorwinning. Neuro-Symbolic AI Die mislukking: die vierkantige pivot Die tweede helfte van die uitdaging was om hierdie werkende motor te neem en dit te draai. ek wou die Drone Designer in 'n Robot Dog Designer (die Ranch Dog) verander. Ek het Gemini 3.0 die hele kode-basis (88k tokens) gevoed en gevra om dit te refactor. I am officially shelving the Quadruped branch. Dit het duidelik geword dat die manier waarop ek hierdie pivot begin het, my 'n sirkulêre drain konynhole van probleemoplossing gelei het. Ek het myself in 'n loop gevind waar die fiksing van 'n koppelberekening die inventarisversorging sou breek, en die fiksing van die versorging sou die simulasie breek. As ek die Ranch Dog wil bou, moet ek 'n stap terug en bou dit van nul af, met behulp van die Drone-motor bloot as 'n verwysingsmodel, nie 'n basis om te oorskryf nie. Die les: die flattening effek Hoekom het die Drone-motor geslaag terwyl die Quadruped-refaktor misluk het? Dit kom neer op 'n spesifieke gedrag wat ek in Gemini 3.0 waargeneem het (en ander hoë konteksmodelle). Wanneer jy van die grond af bou, bou jy en die AI die argitektuur stap vir stap. Wanneer jy 'n LLM vra om 'n bestaande aansoek, dit sien nie die geskiedenis van die kode nie. pivot Die oorspronklike Drone kode is in verskillende, lineêre stappe gebreek. Daar was spesifieke foutbeheer poorte en wagtoestande wat afgelei is van vorige mislukkings. Gemini 3.0, in 'n poging om doeltreffend te wees, Dit het verskillende logiese stappe gekombineer in enkele, monoliete prosesse. Op die oppervlak, die kode lyk skoonder en meer Pythonic.Maar in werklikheid het dit die strukturele lasdraaiende mure wat die aansoek stabiel gehou het, verwyder. flattened the architecture Dit veronderstel dat die kode 'n stylgids was, nie 'n strukturele noodsaaklikheid nie. Die paradoks van vermoëns: Gemini 2.5 vs. 3.0 Hierdie projek het 'n kontra-intuïtiewe realiteit beklemtoon: Gemini 2.5 was safer because the code it confidently spit out was truncated pseudo-code. In vorige weergawes was die uitkomste gestruktureer om jou te wys hoe jy kon gaan oor die bou. Jy sou dan 'n plan moet bou om die buise binne die program te bou. Soms kon dit die hele lêer skryf. Soms moes jy funksie per funksie gaan. Gemini 2.5 het my gedwing om die Architect te wees. ek moes program-by-program gaan, maak presies uit wat ek wou hê. Gemini 3.0 het die spoed en rede om dit alles op 'n keer te doen. Gemini 3.0 skep kode wat onmiddellik werkbaar lyk, maar is struktuurlik verrot binne. Die finale oordeel As jy op soek is om 'n Generative Manufacturing Engine, of enige komplekse stelsel met LLMs, te bou, hier is my finale takeaways uit die OpenForge eksperiment: Greenfield is maklik, Brownfield is moeilik: LLMs uitsteek in die bou van nul af. Hulle is verskriklik in die herstel van komplekse, bestaande argitektuur sonder massiewe menslike handhawing. Do not Refactor with Prompts: As jy die doel van 'n app wil verander, moenie die AI vra om dit vir X te herschryf nie. Arhitektuur is nog steeds koning: Jy kan nie 'n kode-basis beskou as 'n vloeibare dokument wat deur 'n LLM geformuleer kan word nie. OpenForge het bewys dat ons die gaping tussen vaag gebruikersintensies en fisiese ingenieurswese kan oorbrug. Dit gesê, Gemini 3.0 is 'n massiewe sprong van 2.5. deel van wat ek hier ondersoek, is hoe om die beste uit 'n brandneue gereedskap te kry.
