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. I de sidste par uger har jeg dokumenteret min rejsebygning , et AI-system, der er i stand til at oversætte vage brugerintentioner til flyveprøvet hardware. OpenForge Målet var at afprøve Googles evner. Jeg ønskede at besvare et specifikt spørgsmål: Kan en LLM gå ud over at skrive Python scripts og faktisk ingeniør fysiske systemer, hvor tolerance, spænding og kompatibilitet betyder noget? Gemini 3.0 Svaret, viser det sig, er et kompliceret "Ja, men..." Her er post-mortem om, hvad der fungerede, hvad der mislykkedes, og den kritiske forskel mellem Kode og af systemer. Generating Refactoring Anmeldelse af Drone_4 Works Den drone_4 gren af repository er en succes. Hvis du kloner repoen og beder om en "Long Range Cinema Drone", fungerer systemet fra frø til simulering. Det forstår hensigten: Det ved, at "Cinema" betyder glat flyvning og "Long Range" betyder GPS og Crossfire protokoller. Den adlyder fysik: Kompatibilitetsmotoren afviser med succes motor/batteriekombinationer, der ville overophedes eller eksplodere. Det simulerer virkeligheden: De USD-filer, der er genereret til NVIDIA Isaac Sim, flyver faktisk. Jeg vil indrømme, jeg var nødt til at være pragmatisk. I make_fleet.py, jeg "svindlede" lidt. jeg stolede mindre på LLM til dynamisk at opfinde flåde logik og mere på hard-coded Python orchestration. jeg var nødt til at minde mig selv om, at dette var en test af Gemini 3.0's ræsonnement, ikke en konkurrence for at se, om jeg kunne undgå at skrive en enkelt linje kode. Som et bevis på, at begrebet - hvor LLM håndterer kreativ oversættelse, og Python håndterer fysikkens love - OpenForge er en sejr. Neuro-Symbolic AI Anmeldelse af The Failure: Quadruped Pivot Den anden halvdel af udfordringen var at tage denne arbejdsmotor og dreje den. Jeg ønskede at forvandle Drone Designer til en Robot Dog Designer (den Ranch Dog). Jeg fodrede Gemini 3.0 hele kodebasen (88k tokens) og bad om det til refactor. I am officially shelving the Quadruped branch. Det er blevet indlysende, at den måde, jeg startede denne pivot, førte mig ned i et cirkulært dræningshul af fejlfinding. Jeg befandt mig i en løkke, hvor fastsættelse af et drejningsmoment beregning ville bryde inventar sourcing, og fastsættelse af sourcing ville bryde simuleringen. Hvis jeg vil bygge Ranch Dog, må jeg træde tilbage og bygge det fra bunden, ved at bruge Drone-motoren blot som en referencemodel, ikke en base at overskrive. Læs også: Flattening Effect Hvorfor lykkedes Drone-motoren, mens Quadruped-reaktoren mislykkedes? Det kommer ned til en specifik adfærd, jeg har observeret i Gemini 3.0 (og andre højkontekstmodeller). Når du bygger fra bunden op, bygger du og AI arkitekturen trin for trin. Men når du spørger en LLM til en eksisterende applikation, ser den ikke kodens historie. pivot Den oprindelige Drone-kode blev opdelt i forskellige, lineære trin. Der var specifikke fejlhåndteringsgater og ventetilstande, der stammer fra tidligere fejl. Gemini 3.0, i et forsøg på at være effektiv, På overfladen så koden renere og mere pythonisk ud. Men i virkeligheden havde den fjernet de strukturelle belastningsbærende vægge, der holdt applikationen stabil. flattened the architecture Den antog, at koden var en stilvejledning, ikke en strukturel nødvendighed. Kapacitetens paradoks: Gemini 2.5 vs. 3.0 Dette projekt fremhævede en kontraintuitiv virkelighed: Gemini 2.5 was safer because the code it confidently spit out was truncated pseudo-code. I tidligere versioner blev udgangene struktureret for at vise dig, hvordan du kunne gå om at bygge. Du skulle derefter opbygge en plan for at opbygge tarmene i programmet. Nogle gange kunne det skrive hele filen. Nogle gange måtte du gå funktion efter funktion. Gemini 2.5 tvang mig til at være arkitekten. Jeg måtte gå program for program, kortlægge præcis, hvad jeg ønskede. Gemini 3.0 har hastigheden og begrundelsen til at gøre det hele på én gang. Gemini 3.0 skaber kode, der ser praktisk ud med det samme, men er strukturelt rodet inde. Den endelige dom Hvis du er på udkig efter at opbygge en Generative Manufacturing Engine, eller ethvert komplekst system med LLMs, her er mine sidste takeaways fra OpenForge eksperimentet: Greenfield er let, Brownfield er hård: LLM'er udmærker sig ved at bygge fra bunden. Don't Refactor med Prompts: Hvis du vil ændre formålet med en app, skal du ikke bede AI om at omskrive dette for X. I stedet skal du kortlægge logikstrømmen i den gamle app og bede AI om at opbygge en ny app ved hjælp af det logiske kort. Arkitektur er stadig konge: Du kan ikke se en kodebase som et flydende dokument, der kan ændres af en LLM. OpenForge har bevist, at vi kan overbryde kløften mellem vage brugerintentioner og fysisk teknik. Når det er sagt, Gemini 3.0 er et massivt spring fra 2.5.
