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. Dalam beberapa minggu terakhir, saya telah mendokumentasikan bangunan perjalanan saya , sistem AI yang mampu menterjemahkan niat pengguna yang tidak jelas kepada perkakasan yang terbukti terbang. OpenForge Tujuannya ialah untuk menguji keupayaan pemikiran Google. Saya mahu menjawab soalan tertentu: Bolehkah LLM melampaui penulisan skrip Python dan sebenarnya kejuruteraan sistem fizikal di mana toleransi, voltan, dan keserasian penting? Gemini 3.0 Jawapan, ternyata, adalah “Ya, tetapi...” yang rumit. Berikut ialah post-mortem tentang apa yang berjaya, apa yang gagal, dan perbezaan kritikal antara kod dan sistem yang Generating Refactoring Kemenangan: Drone_4 Works Pertama, berita baik. cawangan drone_4 repository adalah kejayaan. Jika anda mengkloning repo dan meminta "Long Range Cinema Drone," sistem berfungsi dari benih kepada simulasi. Ia memahami maksud: Ia tahu bahawa "Cinema" bermaksud penerbangan yang lancar dan "Long Range" bermaksud protokol GPS dan Crossfire. Ia mematuhi fisika: Enjin Kompatibiliti berjaya menolak kombinasi motor / bateri yang akan terlalu panas atau meletup. Ia mensimulasikan realiti: fail USD yang dihasilkan untuk NVIDIA Isaac Sim sebenarnya terbang. Saya akan mengakui, saya terpaksa menjadi pragmatik. dalam make_fleet.py, saya "menipu" sedikit. saya bergantung kurang kepada LLM untuk secara dinamik mencipta logik armada dan lebih kepada pengoreksian Python yang dikodekan keras. saya terpaksa mengingatkan diri saya bahawa ini adalah ujian penilaian Gemini 3.0, bukan pertandingan untuk melihat sama ada saya boleh mengelakkan menulis satu baris kod. Sebagai bukti konsep untuk —di mana LLM menangani terjemahan kreatif, dan Python menangani undang-undang fizik—OpenForge adalah kemenangan. Neuro-Symbolic AI Kegagalan: Pivot Quadruped Separuh kedua cabaran ialah mengambil enjin kerja ini dan memutarnya.Saya mahu mengubah Designer Drone menjadi Designer Anjing Robot (Ranch Dog). Saya memberi makan Gemini 3.0 keseluruhan kod basis (88k token) dan memintanya kepada refactor. ia dengan percaya diri mengeluarkan fisika baru, agensi sumber baru, dan penyelesai kinematika baru. I am officially shelving the Quadruped branch. Ia telah menjadi jelas bahawa cara saya memulakan pivot ini membawa saya ke bawah lubang kelinci penyelesaian masalah.Saya mendapati diri saya dalam loop di mana memperbaiki pengiraan torsi akan memecahkan sumber inventaris, dan memperbaiki sumber akan memecahkan simulasi. Jika saya mahu membina Anjing Ranch, saya mesti mundur dan membina dari asalnya, menggunakan enjin Drone semata-mata sebagai model rujukan, bukan asas untuk ditulis semula. Pelajaran: Kesan Flattening Mengapa enjin Drone berjaya manakala refactor Quadruped gagal? Ia datang kepada tingkah laku tertentu yang saya amati dalam Gemini 3.0 (dan model konteks tinggi lain). Apabila anda membina dari atas, anda dan AI membina seni bina langkah demi langkah. anda meletakkan asas, kemudian bingkai, kemudian bumbung. Walau bagaimanapun, apabila anda meminta LLM untuk sebuah aplikasi yang sedia ada, ia tidak melihat sejarah kod. pivot Kod Drone asal dibahagikan kepada langkah-langkah yang berasingan dan linear. Terdapat gerbang penanganan ralat tertentu dan keadaan menunggu yang dihasilkan daripada kegagalan terdahulu. Gemini 3.0, dalam usaha untuk menjadi berkesan, Ia mengumpulkan langkah-langkah logik yang berbeza ke dalam proses-proses monolitik yang unik.Pada permukaan, kod kelihatan lebih bersih dan lebih Pythonic.Tetapi dalam realiti, ia telah menghapuskan dinding struktur yang membawa beban yang mengekalkan aplikasi yang stabil. flattened the architecture Ia menganggap bahawa kod adalah panduan gaya, bukan keperluan struktural. Paradoks Kemampuan: Gemini 2.5 vs. 3.0 Projek ini menyoroti kenyataan yang bertentangan: Gemini 2.5 was safer because the code it confidently spit out was truncated pseudo-code. Dalam versi terdahulu, outputs telah disusun untuk menunjukkan kepada anda bagaimana anda boleh pergi tentang pembinaan.Selepas itu, anda perlu membina rancangan untuk membina bahagian-bahagian dalam program.Kadang-kadang, ia boleh menulis keseluruhan fail.Kadang-kadang, anda perlu pergi fungsi oleh fungsi. Gemini 2.5 memaksa saya untuk menjadi Arsitek. saya terpaksa pergi program demi program, memaparkan apa yang saya mahu. Gemini 3.0 mempunyai kelajuan dan alasan untuk melakukannya semua pada satu masa. ia mewujudkan ilusi yang boleh dipercayai daripada One-Shot Pivot. Gemini 3.0 mencipta kod yang kelihatan boleh digunakan dengan segera tetapi strukturnya kotor di dalam. Penghakiman Akhir Jika anda sedang mencari untuk membina Mesin Pengeluaran Generatif, atau mana-mana sistem yang kompleks dengan LLMs, di sini adalah amalan terakhir saya daripada eksperimen OpenForge: Greenfield adalah mudah, Brownfield adalah sukar: LLM cemerlang dalam membina dari awal.Mereka mengerikan dalam memulihkan kompleks, seni bina sedia ada tanpa tangan manusia yang besar. Jangan Refactor dengan Prompts: Jika anda ingin mengubah matlamat aplikasi, jangan meminta AI untuk menulis semula ini untuk X. Sebaliknya, memaparkan aliran logik aplikasi lama, dan meminta AI untuk membina aplikasi baru menggunakan peta logik itu. Arsitektur masih Raja: Anda tidak boleh melihat pangkalan kod sebagai dokumen cecair yang boleh diubahsuai oleh LLM. OpenForge membuktikan bahawa kita boleh menampung jurang antara niat pengguna yang tidak jelas dan kejuruteraan fizikal. Yang dikatakan, Gemini 3.0 adalah lompatan besar daripada 2.5. sebahagian daripada apa yang saya meneroka di sini adalah bagaimana untuk mendapatkan yang terbaik daripada alat baru.
