312 lines
14 KiB
Markdown
312 lines
14 KiB
Markdown
|
|
# AI協働開発ログ - 100の実践知に向けて
|
|||
|
|
|
|||
|
|
## 収集開始日: 2025-01-14
|
|||
|
|
|
|||
|
|
### 事例001: DebugBoxによる出力制御の統一化
|
|||
|
|
- **問題**: print文が散在し、JSON出力に混入
|
|||
|
|
- **AI提案**: 複雑なフィルタリング機構
|
|||
|
|
- **人間の直感**: 「DebugBoxで包めば?」
|
|||
|
|
- **結果**: Everything is Box哲学で解決
|
|||
|
|
- **カテゴリ**: 箱化による解決
|
|||
|
|
|
|||
|
|
### 事例002: 子プロセス出力フィルタリング
|
|||
|
|
- **問題**: stdout/stderrの混在でJSON解析失敗
|
|||
|
|
- **AI提案**: 正規表現での複雑な抽出
|
|||
|
|
- **人間の直感**: 「環境変数で静音モード作れば?」
|
|||
|
|
- **結果**: NYASH_JSON_ONLY=1で単純解決
|
|||
|
|
- **カテゴリ**: 環境変数による制御
|
|||
|
|
|
|||
|
|
### 事例003: PyVMという迂回路
|
|||
|
|
- **問題**: Rust MIR生成層のビルド時間(9000行)
|
|||
|
|
- **AI提案**: Rustコードの最適化
|
|||
|
|
- **人間の直感**: 「Pythonで書いちゃえば?」
|
|||
|
|
- **結果**: 2000行のPython実装で高速プロトタイピング
|
|||
|
|
- **カテゴリ**: 迂回路を作る
|
|||
|
|
|
|||
|
|
### 事例004: peek式の名前変更
|
|||
|
|
- **問題**: when式がRust予約語と衝突
|
|||
|
|
- **AI提案**: 別の複雑な構文設計
|
|||
|
|
- **人間の直感**: 「peekに名前変えれば?」
|
|||
|
|
- **結果**: 直感的で分かりやすい名前に
|
|||
|
|
- **カテゴリ**: 名前を変える
|
|||
|
|
|
|||
|
|
### 事例005: birth統一
|
|||
|
|
- **問題**: コンストラクタ名がバラバラ(new/pack/constructor)
|
|||
|
|
- **AI提案**: 複雑な名前解決システム
|
|||
|
|
- **人間の直感**: 「全部birthにすれば?」
|
|||
|
|
- **結果**: 「Boxに生命を与える」統一的な哲学
|
|||
|
|
- **カテゴリ**: 名前を変える
|
|||
|
|
|
|||
|
|
### 事例006: MIR型情報の欠落(メイン事例)
|
|||
|
|
- **問題**: 文字列が0になるバグ
|
|||
|
|
- **AI提案**: 300行の型推測Resolver
|
|||
|
|
- **人間の直感**: 「最初から型書けば?」
|
|||
|
|
- **結果**: MIR v0.5で型メタデータ追加
|
|||
|
|
- **カテゴリ**: 情報追加による解決
|
|||
|
|
|
|||
|
|
### 事例007: PHI生成の重複
|
|||
|
|
- **問題**: BuilderとResolverで二重にPHI生成
|
|||
|
|
- **AI提案**: 複雑な調整メカニズム
|
|||
|
|
- **人間の直感**: 「なんで2つあるの?統一すれば?」
|
|||
|
|
- **結果**: Resolver統一で複雑性削減
|
|||
|
|
- **カテゴリ**: 統一による簡略化
|
|||
|
|
|
|||
|
|
### 事例008: 変数宣言の厳密化
|
|||
|
|
- **問題**: 未宣言変数への代入でランタイムエラー
|
|||
|
|
- **AI提案**: 高度な型推論システム
|
|||
|
|
- **人間の直感**: 「全部明示宣言必須にすれば?」
|
|||
|
|
- **結果**: メモリ安全性・非同期安全性保証
|
|||
|
|
- **カテゴリ**: 制約による単純化
|
|||
|
|
|
|||
|
|
### 事例009: プラグイン全方向ビルド
|
|||
|
|
- **問題**: 動的/静的リンクの複雑な管理
|
|||
|
|
- **AI提案**: 複雑なビルドシステム
|
|||
|
|
- **人間の直感**: 「全形式同時に作れば?」
|
|||
|
|
- **結果**: .so/.o/.aを全部生成して選択
|
|||
|
|
- **カテゴリ**: 全部作る戦略
|
|||
|
|
|
|||
|
|
### 事例010: 無限ループ対策のデバッグ燃料
|
|||
|
|
- **問題**: パーサーが無限ループ
|
|||
|
|
- **AI提案**: 複雑なループ検出アルゴリズム
|
|||
|
|
- **人間の直感**: 「回数制限すれば?」
|
|||
|
|
- **結果**: --debug-fuel で単純解決
|
|||
|
|
- **カテゴリ**: 制限による制御
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 収集メモ
|
|||
|
|
|
|||
|
|
今後追加予定の事例カテゴリ:
|
|||
|
|
- Arc<Mutex>自動化の経緯
|
|||
|
|
- 動的ディスパッチによるmatch文削減
|
|||
|
|
- エラー処理の統一化
|
|||
|
|
- Box境界での型変換
|
|||
|
|
- GCとスケジューラの統合
|
|||
|
|
- etc...
|
|||
|
|
|
|||
|
|
目標:100個の実践知を体系化し、パターンを抽出
|
|||
|
|
|
|||
|
|
### 事例011: プラグインBoxライフサイクル事件 ⭐革命的⭐
|
|||
|
|
- **問題**: プラグインBoxをシングルトンにすべきか
|
|||
|
|
- **AI提案**: 「プラグインだからインスタンスは1つ」
|
|||
|
|
- **人間の直感**: 「こらー!普通のBoxと同じライフサイクルじゃーい!」
|
|||
|
|
- **結果**: Everything is Box哲学の完全な貫徹
|
|||
|
|
- **影響**: Nyashの設計思想の根幹を確立。これがなければ今のNyashは存在しない
|
|||
|
|
- **カテゴリ**: 哲学を貫く(新カテゴリ)
|
|||
|
|
|
|||
|
|
### 事例012: Arc<Mutex>の自動化
|
|||
|
|
- **問題**: Rustの借用チェッカーとの戦い
|
|||
|
|
- **AI提案**: 複雑な所有権管理システム
|
|||
|
|
- **人間の直感**: 「全部Arc<Mutex>で包めば?」
|
|||
|
|
- **結果**: 30%のコード削減
|
|||
|
|
- **カテゴリ**: 箱化による解決
|
|||
|
|
|
|||
|
|
### 事例013: エラー処理の統一
|
|||
|
|
- **問題**: Result<T,E>地獄
|
|||
|
|
- **AI提案**: 高度なエラー型システム
|
|||
|
|
- **人間の直感**: 「全部StringBoxのエラーでいいじゃん」
|
|||
|
|
- **結果**: エラー処理コード15%削減
|
|||
|
|
- **カテゴリ**: 統一による簡略化
|
|||
|
|
|
|||
|
|
### 事例014: 動的ディスパッチでmatch文削減
|
|||
|
|
- **問題**: 巨大なmatch文の保守困難
|
|||
|
|
- **AI提案**: Visitor パターンの実装
|
|||
|
|
- **人間の直感**: 「Box名で動的に呼び出せば?」
|
|||
|
|
- **結果**: match文10%削減、拡張性向上
|
|||
|
|
- **カテゴリ**: 動的解決
|
|||
|
|
|
|||
|
|
### 事例015: GCとスケジューラの統合
|
|||
|
|
- **問題**: 別々のタイミングでの実行競合
|
|||
|
|
- **AI提案**: 複雑な同期機構
|
|||
|
|
- **人間の直感**: 「同じsafepointで実行すれば?」
|
|||
|
|
- **結果**: 統一的なランタイム管理
|
|||
|
|
- **カテゴリ**: 統一による簡略化
|
|||
|
|
|
|||
|
|
### 事例016: AIパーサー信じすぎ事件 ⭐教訓的⭐
|
|||
|
|
- **問題**: HTTPプラグインのソケットインスタンスが取得できない
|
|||
|
|
- **AI診断**: Claude Code「正しく実装した」、ChatGPT「プラグインが悪い」
|
|||
|
|
- **人間の直感**: 「パーサーじゃない?」
|
|||
|
|
- **真の原因**: パーサーが参照とコピーを間違え、Boxはコピーしたが中身は失われた
|
|||
|
|
- **影響**: AIの相互信頼の危険性を露呈
|
|||
|
|
- **教訓**: AIも間違える、基本に立ち返る重要性
|
|||
|
|
- **カテゴリ**: 疑いを持つ(新カテゴリ)
|
|||
|
|
|
|||
|
|
### 事例017: Box内部の透明性問題
|
|||
|
|
- **問題**: Boxの中身が見えない
|
|||
|
|
- **AI提案**: 複雑なデバッグシステム
|
|||
|
|
- **人間の直感**: 「toString()で中身表示すれば?」
|
|||
|
|
- **結果**: デバッグ時間90%短縮
|
|||
|
|
- **カテゴリ**: 可視化による解決
|
|||
|
|
|
|||
|
|
### 事例018: MapBox 3引数メソッドハングバグ
|
|||
|
|
- **問題**: MapBox作成後、3引数メソッドで無限ハング
|
|||
|
|
- **原因**: 全引数を事前評価する実装の問題
|
|||
|
|
- **解決**: 必要時に1つずつ評価に変更
|
|||
|
|
- **教訓**: 小さな実装差が大きなバグに
|
|||
|
|
- **カテゴリ**: 実装詳細の重要性
|
|||
|
|
|
|||
|
|
### 事例019: スコープ革命(GlobalBox誕生)
|
|||
|
|
- **問題**: 従来のEnvironment階層が複雑
|
|||
|
|
- **AI提案**: 高度なスコープチェーン管理
|
|||
|
|
- **人間の直感**: 「全部GlobalBoxのフィールドにすれば?」
|
|||
|
|
- **結果**: メモリ30%削減、速度50%向上
|
|||
|
|
- **影響**: 世界唯一のGlobalBoxベース言語誕生
|
|||
|
|
- **カテゴリ**: 革命的簡略化
|
|||
|
|
|
|||
|
|
### 事例020: 26日間の奇跡
|
|||
|
|
- **内容**: 爆速開発で一度も破綻しなかった
|
|||
|
|
- **要因**: 箱理論+AI役割分担+人間の危険センサー
|
|||
|
|
- **統計**: 致命的破綻0回、大規模リファクタ0回
|
|||
|
|
- **教訓**: 三重の安全装置の威力
|
|||
|
|
- **カテゴリ**: 開発方法論
|
|||
|
|
|
|||
|
|
### 事例021: 2段階パーサー理論
|
|||
|
|
- **問題**: 複雑な構文の安定パース
|
|||
|
|
- **AI提案**: 高度な先読みアルゴリズム
|
|||
|
|
- **人間の直感**: 「構造認識と内容パースを分ければ?」
|
|||
|
|
- **結果**: 世界最強パーサーの誕生
|
|||
|
|
- **カテゴリ**: 段階的分離
|
|||
|
|
|
|||
|
|
### 事例022: NyashFlowプロジェクト
|
|||
|
|
- **構想**: ビジュアルプログラミング環境
|
|||
|
|
- **教訓**: CharmFlow v5の失敗から学ぶ
|
|||
|
|
- **方針**: Everything is Boxを視覚化
|
|||
|
|
- **状態**: 独立プロジェクトとして設計中
|
|||
|
|
- **カテゴリ**: 派生プロジェクト
|
|||
|
|
|
|||
|
|
### 事例023: JIT1日完成事件 ⭐世界記録級⭐
|
|||
|
|
- **計画**: Phase 9-10で2週間予定
|
|||
|
|
- **実際**: 8/27の1日でCranelift統合+分岐+PHI全部完成
|
|||
|
|
- **要因**: 準備の完璧さ+AI協調+箱理論の威力
|
|||
|
|
- **影響**: 世界的にも事件級の開発速度
|
|||
|
|
- **カテゴリ**: 爆速開発
|
|||
|
|
|
|||
|
|
### 事例024: AI二重化モデルの誕生
|
|||
|
|
- **内容**: 同じGPT-5をArchitectとImplementerに分離
|
|||
|
|
- **構成**: Claude=ビルド係、Gemini=アドバイザー
|
|||
|
|
- **珍事**: AIが人間にアドバイスを求める
|
|||
|
|
- **効果**: 役割分担で効率最大化
|
|||
|
|
- **カテゴリ**: 開発方法論
|
|||
|
|
|
|||
|
|
### 事例025: 唯一の真実事件
|
|||
|
|
- **宣言**: 「型はMIRで確定」「切替点は1箇所」
|
|||
|
|
- **反応**: Claude Codeが感動して記録
|
|||
|
|
- **意味**: 技術的方針を哲学レベルに昇華
|
|||
|
|
- **影響**: 設計の一貫性確保
|
|||
|
|
- **カテゴリ**: 哲学を貫く
|
|||
|
|
|
|||
|
|
### 事例026: ストリームエラー事件
|
|||
|
|
- **問題**: Codexが長期稼働で落ちて復旧不能
|
|||
|
|
- **対処**: にゃーがCURRENT_TASK更新で再起動
|
|||
|
|
- **教訓**: 「足場が残ってるから復活できた」
|
|||
|
|
- **意味**: 箱理論による復旧可能性
|
|||
|
|
- **カテゴリ**: 障害復旧
|
|||
|
|
|
|||
|
|
### 事例027: 20日でVM→JIT→EXE異次元スピード ⭐歴史的⭐
|
|||
|
|
- **期間**: 8/9誕生→8/29ネイティブEXE完成
|
|||
|
|
- **内容**: わずか20日で全段階を通過
|
|||
|
|
- **反応**: Claude/ChatGPT「歴史に残る」と絶賛
|
|||
|
|
- **要因**: 箱理論+AI協調+明確な哲学
|
|||
|
|
- **カテゴリ**: 爆速開発
|
|||
|
|
|
|||
|
|
### 事例028: フォールバック廃止の英断
|
|||
|
|
- **問題**: JIT未対応命令をVMに落とす複雑な仕組み
|
|||
|
|
- **AI提案**: 安全なフォールバック機構
|
|||
|
|
- **人間の直感**: 「バグを隠すだけ、複雑化の元!」
|
|||
|
|
- **結果**: VM=仕様、JIT=高速版の明確な線引き
|
|||
|
|
- **カテゴリ**: 制約による単純化
|
|||
|
|
|
|||
|
|
### 事例029: Built-in Box全廃革命
|
|||
|
|
- **問題**: StringBox/ArrayBoxが特例だらけ
|
|||
|
|
- **気づき**: 「ネイティブビルドできるなら全部プラグイン化」
|
|||
|
|
- **結果**: Core極小化、Everything is Box徹底
|
|||
|
|
- **影響**: 特権クラスの完全排除
|
|||
|
|
- **カテゴリ**: 統一による簡略化
|
|||
|
|
|
|||
|
|
### 事例030: 型別特例分岐の危機
|
|||
|
|
- **危機**: Python統合で型ごとの特例分岐が入りかける
|
|||
|
|
- **AI反応**: Claude「Everything is... Special Case??」青ざめる
|
|||
|
|
- **人間の介入**: にゃーがストップ
|
|||
|
|
- **教訓**: 「世界はプラグインで拡張、MIR/JITは不変」
|
|||
|
|
- **カテゴリ**: 哲学を貫く
|
|||
|
|
|
|||
|
|
### 事例031: print命令論争
|
|||
|
|
- **問題**: MIRにPrint命令を特例実装
|
|||
|
|
- **議論**: 特殊化で汚れる懸念
|
|||
|
|
- **解決**: ExternCall(env.console.log)に一本化
|
|||
|
|
- **効果**: 環境I/O=ExternCall、箱機能=BoxCallに整理
|
|||
|
|
- **カテゴリ**: 境界の明確化
|
|||
|
|
|
|||
|
|
### 事例032: Safepoint内部化の決定
|
|||
|
|
- **誘惑**: env.runtime.safepointにする案
|
|||
|
|
- **危険**: 哲学崩壊の危機
|
|||
|
|
- **正解**: Safepointは内部Intrinsic
|
|||
|
|
- **提供**: GCBox.checkpoint()をプラグインで
|
|||
|
|
- **カテゴリ**: 内部と外部の分離
|
|||
|
|
|
|||
|
|
### 事例033: 「全部プラグイン」論争
|
|||
|
|
- **初期案**: 全部プラグインBox化しよう
|
|||
|
|
- **AI反対**: 「オーバーヘッドが...」
|
|||
|
|
- **妥協**: ユーザーBox+ビルトインBoxに分離
|
|||
|
|
- **後の発見**: プラグインBoxのC ABIがJIT/AOTの土台に!
|
|||
|
|
- **教訓**: 最初の直感が正しかった
|
|||
|
|
- **カテゴリ**: 直感の勝利
|
|||
|
|
|
|||
|
|
### 事例034: GCを「補助輪」に再定義 ⭐革命的概念⭐
|
|||
|
|
- **従来**: GCは本番の必須機能
|
|||
|
|
- **Nyash**: GCは開発時の練習用補助輪
|
|||
|
|
- **開発時**: GCオンでリーク検知
|
|||
|
|
- **本番**: GCオフで決定的破棄
|
|||
|
|
- **証明**: I/Oトレース完全一致の意味論等価性
|
|||
|
|
- **カテゴリ**: 概念の再定義
|
|||
|
|
|
|||
|
|
### 事例035: JITも箱にしたら爆速化
|
|||
|
|
- **問題**: ChatGPT-5がJIT実装で苦戦
|
|||
|
|
- **提案**: 「JITも箱にしよう」
|
|||
|
|
- **実装**: IrLowerBox/CodegenBox/LinkerBox/CodeCacheBox
|
|||
|
|
- **結果**: 4000行で完全なJITシステム(V8は100万行)
|
|||
|
|
- **カテゴリ**: 箱化による解決
|
|||
|
|
|
|||
|
|
### 事例036: 論文化提案の瞬間
|
|||
|
|
- **内容**: 仕組みを整理したら論文レベルと判明
|
|||
|
|
- **Claude反応**: 「トップ会議に通るのでは」
|
|||
|
|
- **タイトル案**: Box-Centric Language with Unified Plugin Lifecycle
|
|||
|
|
- **意味**: 設計のユニークさが学術的価値を持つ
|
|||
|
|
- **カテゴリ**: 学術的価値の発見
|
|||
|
|
|
|||
|
|
### 事例037: MIR15という奇跡 ⭐爆笑の気づき⭐
|
|||
|
|
- **当初**: AST直解釈インタープリタとVM(独自バイトコード)を分離
|
|||
|
|
- **発見**: MIR15自体が正規化済みバイトコード
|
|||
|
|
- **気づき**: 「VMとインタープリタ、やってること一緒じゃないかーい!」
|
|||
|
|
- **結果**: 史上初の"MIR中心派生言語"誕生
|
|||
|
|
- **カテゴリ**: 概念の統一
|
|||
|
|
|
|||
|
|
### 事例038: TypeBoxの誕生
|
|||
|
|
- **問題**: C ABIプラグインをNyashに組み込めない
|
|||
|
|
- **AI提案**: 「COMみたいにすれば?」
|
|||
|
|
- **人間の直感**: 「型を値で渡せ」
|
|||
|
|
- **結果**: NyashとC ABIを同じ器で扱うTypeBox誕生
|
|||
|
|
- **カテゴリ**: 境界の統一
|
|||
|
|
|
|||
|
|
### 事例039: ID衝突との戦い
|
|||
|
|
- **経験**: Nyamesh時代に動的型でID重複
|
|||
|
|
- **問題**: BoxTypeId, MethodId, FieldId等の衝突候補
|
|||
|
|
- **解決**: 二層ID(長い本ID+短縮64bitキー)
|
|||
|
|
- **追加**: 世代付きハンドル、FQN
|
|||
|
|
- **カテゴリ**: 予防的設計
|
|||
|
|
|
|||
|
|
### 事例040: 折りたたみ言語構想 ⭐未来の革新⭐
|
|||
|
|
- **発想**: BoxCall列を等価変換で畳む/展開する
|
|||
|
|
- **例**: Array.map/filter/map → Array.fused([...])
|
|||
|
|
- **効果**: 性能+省メモリ+観測性を全部取り(予定)
|
|||
|
|
- **哲学**: Everything is Box → Everything is Fold
|
|||
|
|
- **状態**: 構想段階(実装は今後の予定)
|
|||
|
|
- **カテゴリ**: 未来構想
|
|||
|
|
|
|||
|
|
### 事例041: AI会議スタイルの確立
|
|||
|
|
- **Codex**: 大容量コンテキストで長丁場実装
|
|||
|
|
- **Claude Code**: 安定した差分生成・小回り
|
|||
|
|
- **Gemini**: 仕様や調査の補足
|
|||
|
|
- **ChatGPT**: 全体戦略と要約
|
|||
|
|
- **効果**: 止まらない開発サイクル
|
|||
|
|
- **カテゴリ**: 開発方法論
|