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. ここ数週間、私は私の旅の建物をドキュメンタリー化してきました。 AIシステムは、曖昧なユーザーの意図を飛行実証のハードウェアに翻訳する能力がある。 OpenForge 目標は、Googleの推論能力をテストすることでした。 私は具体的な質問に答えたいと思いました: LLM は Python スクリプトの書き込みを超え、実際には寛容性、電圧、互換性が重要な物理システムをエンジニアリングできますか? Gemini 3.0 答えは、複雑な「はい、しかし・・・」です。 私は今日このプロジェクトを包み込んでいます. ここでは、何がうまくいくのか、何が失敗したのか、そして重要な違いについてのポストモルテムです。 コード& システム Generating Refactoring タイトル: Drone_4 Works まず、良いニュースです. リポジトリの drone_4 支店は成功です。 レポをクローンして「Long Range Cinema Drone」を要求すると、システムはシミュレーションからシミュレーションまで機能します。 「Cinema」はスムーズなフライトを意味し、「Long Range」はGPSとCrossfireのプロトコルを意味する。 それは物理に従う: 互換性エンジンは、過熱または爆発する可能性のあるモーター/バッテリーの組み合わせを成功させます。 それは現実をシミュレートする: NVIDIA Isaac Sim のために生成された USD ファイルは実際に飛ぶ。 私は、私は実践的でなければならなかったことを認めます。 make_fleet.pyでは、私は少し「詐欺」しました。私は、フロートロジックをダイナミックに発明するためにLLMを少なく、ハードコードのPythonオーケストラをより多く信頼していました。 という概念の証拠として、 LLMがクリエイティブな翻訳を扱い、Pythonが物理の法則を扱う場合、OpenForgeは勝利です。 Neuro-Symbolic AI THE FAILURE: THE QUADRUPED PIVOT 課題の2番目の半分は、この動作エンジンを取り、ドローンデザイナーをロボット・ドッグ・デザイナー(ランチ・ドッグ)に変えたいと思いました。 私はジェミニー 3.0 にコードベース全体 (88k トークン) を供給し、それを refactor に依頼しました. それは自信を持って新しい物理学、新しいソーシングエージェント、新しいキネマティクスソーセーバーを吐き出しました. I am officially shelving the Quadruped branch. 私がこのパイオニーを始めた方法が私をトラブルシューティングの円滑な排水ウサギホールに導いたことが明らかになりました. I found myself in a loop where fixing a torque calculation would break the inventory sourcing, and fixing the sourcing would break the simulation. 私は、トークの計算を修正すると、在庫のソーシングを破るだろう。 もし私がランチ・ドッグを建設したいのなら、私は後退し、ドローンエンジンを単なる参考モデルとして、書くためのベースではなく、ゼロから作らなければならない。 レッスン:Flattening Effect なぜドローンエンジンは成功したが、クアンドラップド・ファクターは失敗したのか。 これは、ジェミニ 3.0 (および他のハイコンテキストモデル) で観察した特定の行動に由来します。 あなたが地上から建てるとき、あなたとAIは段階的にアーキテクチャを構築します. You lay the foundation, then the frame, then the roof. しかし、あなたがLLMを求めるときは、 既存のアプリケーションでは、コードの歴史は見えず、戦闘の傷跡は見えません。 pivot 元のドローンコードは、異なる線形の段階に分割された。 以前の失敗から生じた特定のエラー処理ゲートと待機状態があります。 Gemini 3.0は、効率化しようとして、 それは異なる論理的ステップを単一の単一のプロセスにまとめた。表面上では、コードはよりクリーンでよりピトニックに見えたが、実際には、アプリケーションを安定させた構造的な負荷を担う壁を削除した。 flattened the architecture コードはスタイルガイドであり、構造的必要性ではないと仮定した。 能力のパラドックス: Gemini 2.5 vs. 3.0 このプロジェクトは、直感的な現実を強調した: Gemini 2.5 was safer because the code it confidently spit out was truncated pseudo-code. 以前のバージョンでは、出力の構造は、あなたがどのようにして構築を進めるかを示すために構成されていました. あなたはその後、プログラムの内部を構築するための計画を構築する必要があります. 時には、それはすべてのファイルを書くことができます. 時には、あなたは機能によって機能に行う必要があります. ジェミニ2.5は私をアーキテクターに強制しました。私はプログラムごとに行き、私が望むものを正確にマッピングし、AIの手を握らなければなりませんでした。 Gemini 3.0は、すべてを一度に実行するためのスピードと理屈を持っており、信じられないほどのワンショットピボットの幻想を生み出します。 Gemini 3.0 は、すぐに実行可能に見えるコードを作成しますが、内部は構造的に腐ります。 最終判決 生成製造エンジン、またはLLMで複雑なシステムを構築したい場合は、OpenForge実験からの最後の取り組みを以下に示します。 グリーンフィールドは簡単で、ブラウンフィールドはハードです:LLMsはゼロからの構築に優れています。 Don't Refactor with Prompts: If you want to change the purpose of an app, don't ask the AI to rewrite this for X. 代わりに、古いアプリの論理フローをマッピングし、AIにその論理マップを使用して新しいアプリを作成するように頼む。 アーキテクチャはまだキング:あなたはLLMによって変形することができる流動的な文書としてコードベースを見ることはできません。 OpenForgeは、我々が曖昧なユーザー意図と物理エンジニアリングの間のギャップを打ち破ることができることを証明しました。 それによると、Gemini 3.0 は 2.5 からの巨大な飛躍です。ここで探求している部分は、まったく新しいツールから最大限の利益を得る方法です。
