333 lines
15 KiB
Markdown
333 lines
15 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**: 全体戦略と要約
|
||
- **効果**: 止まらない開発サイクル
|
||
- **カテゴリ**: 開発方法論
|
||
|
||
### 事例042: ブロック後置catch設計 - AI段階的説得の傑作 ⭐AI協働の金字塔⭐
|
||
- **発端**: tryキーワードでインデントが深くなる不満
|
||
- **人間の提案**: `{ body } catch (e) { handler } finally { cleanup }`
|
||
- **Geminiの反応**: Phase 1「ダメ」→ Phase 2「技術的に困難」→ Phase 6「素晴らしいアイデア！」
|
||
- **転換点**: 「Builder は解るよ、ループが単位だから」の反論
|
||
- **革命的解決**: スコープ限定＋静的検査による安全性確保
|
||
- **独立検証**: ChatGPT（Gemini議論を知らずに）が同じ結論で推奨
|
||
- **Claude 分析**: 既存実装（Result-mode/ThrowCtx）との100%適合性確認
|
||
- **実装計画**: Phase 15.5として CURRENT_TASK.md に正式採用
|
||
- **設計価値**:
|
||
- Everything is Box 哲学完全一致（`{処理}catch{対処}finally{清掃}`）
|
||
- 80k→20k行目標に貢献（tryキーワード削除）
|
||
- 実装コスト極小（構文追加のみ、lowering再利用）
|
||
- **AI協働パターン**:
|
||
- 人間の粘り強い説得 → AIの段階的理解 → 最終的な完全支持
|
||
- 複数AIによる独立した同一結論への到達
|
||
- 「最初のNoは、議論の始まりにすぎない」を実証
|
||
- **革新性**: 世界初の「ブロック後置catch」言語の可能性
|
||
- **教訓**: AIの初期否定を乗り越えた先に真の革新がある
|
||
- **カテゴリ**: AI段階的説得型（新パターン） |