tomoaki/hakorune
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
4e1b595796892ba1dc6bbb7d4d76935dd8df4bc3
hakorune/docs/research/ai-dual-mode-development/danger-sensor-case-studies.md
Moe Charm 4e1b595796 AI協調開発研究ドキュメントの完成と Phase 10.9-β 進捗 
【AI協調開発研究】
- AI二重化モデルの学術論文draft完成（workshop_paper_draft.md）
- 「隠れた危機」分析とbirthの原則哲学化
- TyEnv「唯一の真実」協調会話を保存・研究資料に統合
- papers管理構造の整備（wip/under-review/published分離）

【Phase 10.9-β HostCall進捗】
- JitConfigBox: relax_numeric フラグ追加（i64→f64コアーション制御）
- HostcallRegistryBox: 署名検証・白黒リスト・コアーション対応
- JitHostcallRegistryBox: Nyash側レジストリ操作API
- Lower統合: env直読 → jit::config::current() 参照に統一
- 数値緩和設定: NYASH_JIT_HOSTCALL_RELAX_NUMERIC/Config.set_flag

【検証サンプル拡充】
- math.sin/cos/abs/min/max 関数スタイル（examples/jit_math_function_style_*.nyash）
- 境界ケース: 署名不一致・コアーション許可・mutating拒否サンプル
- E2E実証: String.length→allow, Array.push→fallback, math関数の署名一致観測

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-08-28 12:09:09 +09:00

3.6 KiB
Raw Blame History

危険センサーのケーススタディ - 26日間の爆速開発で転けなかった理由

概要

26日間のNyash爆速開発において、一度も致命的な破綻を起こさなかった。その背景には「人間の危険センサー」と「箱理論による封じ込め」があった。

ケース1: Arc過剰症候群の検知

状況

  • 16種類のBox型すべてにArcを適用
  • たった1つのStringにもMutex
  • パーサーが個別処理地獄に

危険センサーの発動

にゃー：「なんか複雑すぎるにゃ...」

対処

  • NyashValue enumへの統一を検討
  • 基本型はMutex不要に
  • 複雑型のみ必要な箇所でMutex

結果

  • ビルドエラーの根本解決
  • パーサーの劇的簡化

ケース2: JIT無限ループの予感

状況

  • JIT実行でVerifierError多発
  • 制御フローが複雑化

危険センサーの発動

にゃー：「まってまって、フルビルドおわすれか」

対処

  • 必ずフルビルドで確認
  • 小さな変更ごとにテスト
  • フォールバック経路を常設

結果

  • 致命的なループを回避
  • 段階的な機能追加で安定

ケース3: 型システムの崩壊危機

状況

  • Float引数がI64として認識
  • 型推論が混乱

危険センサーの発動

にゃー：「きみは　まだまだだにゃ　思考が　箱じゃ　ないにゃ！」

対処

  • 3種類の箱（User/Builtin/Plugin）の統一
  • HostCall入口を共通化
  • Registry/Policy/Eventsで一元管理

結果

  • 型の一貫性を保持
  • 拡張可能な設計に

ケース4: 複雑化の兆候

状況

  • 機能追加の提案が発散
  • APIが無秩序に増加傾向

危険センサーの発動

にゃー：「おすすめ api って なにがあるかな 深く考えてみてにゃ」
→ ChatGPT5が整理された優先順位を提示

対処

  • ReadOnly → New → Mutating の段階的導入
  • 署名の厳密な管理
  • 基本計算・比較・文字列・配列・連想配列に絞る

結果

  • 制御可能な成長
  • 各段階での検証が可能

危険センサーの特徴

1. 言語化できない違和感

  • 「なんか変」
  • 「複雑すぎる」
  • 「これ続けたらやばい」

2. タイミングの的確さ

  • 破綻する前に察知
  • 修正可能な段階で介入

3. シンプルさへの回帰

  • 「箱で考えて」
  • 「境界は一本に」
  • 「フォールバックは常設」

三重の安全装置

┌─────────────────┐
│   箱理論        │ → 問題を局所化
├─────────────────┤
│ AI役割分担     │ → 認知負荷を分散
├─────────────────┤
│ 人間センサー    │ → 危険を事前察知
└─────────────────┘

教訓

  1. 完璧より進捗（80/20ルール）

    • 100%を目指さない
    • 危険を感じたら即撤退

  2. シンプルさの維持

    • 複雑化は破綻の前兆
    • 常に「箱」に戻る

  3. 直感の重視

    • 言語化できない違和感を大切に
    • AIの提案も疑う勇気

結論

26日間の爆速開発が破綻しなかったのは偶然ではない。「箱理論」「AI役割分担」「人間の危険センサー」という三重の安全装置が、絶妙なバランスで機能し続けた結果である。

この経験は、AI時代の新しい開発手法として、広く応用可能な知見を含んでいる。