Changes to resolver.py: - Improved PHI value tracking in _value_at_end_i64() (lines 268-285) - Added trace logging for snap hits with PHI detection - Fixed PHI placeholder reuse logic to preserve dominance - PHI values now returned directly from snapshots when valid Changes to llvm_builder.py: - Fixed externcall instruction parsing (line 522: 'func' instead of 'name') - Improved block snapshot tracing (line 439) - Added PHI incoming metadata tracking (lines 316-376) - Enhanced definition tracking for lifetime hints This should help debug the string carry=0 issue in esc_dirname_smoke where PHI values were being incorrectly coerced instead of preserved. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
138 lines
5.4 KiB
Markdown
138 lines
5.4 KiB
Markdown
# 実装駆動型学習:AIが見落とした基本原理の再発見
|
||
|
||
## 1. はじめに
|
||
|
||
ソフトウェア開発におけるAI活用が急速に進む中、AIの理論的完璧さと人間の実践的直感の相互作用について、興味深い現象が観察された。本稿では、プログラミング言語Nyashのコンパイラ開発において、3つの最先端AI(ChatGPT、Claude、Gemini)が中間表現(MIR)の設計時に型情報の必要性を見落とし、MIRの概念すら知らなかった開発者が実装の苦痛から直感的にその必要性を再発見した事例を詳細に分析する。
|
||
|
||
## 2. 背景:Everything is Box
|
||
|
||
Nyashは「Everything is Box」を哲学とする新しいプログラミング言語である。開発者(以下「にゃー」)はプログラミング初心者でありながら、AIとの協働により言語設計から実装まで進めてきた。特筆すべきは、にゃーがコンパイラ理論の知識を持たないまま、実装経験を通じて本質的な設計原理を発見していった点である。
|
||
|
||
## 3. AIが見落とした型情報
|
||
|
||
### 3.1 MIR設計プロセス
|
||
|
||
2024年11月、MIR(中間表現)の設計がAI主導で行われた:
|
||
|
||
```
|
||
ChatGPT: 「命令を27から13に削減しましょう」
|
||
Claude: 「BoxCall統一で美しい設計に」
|
||
Gemini: 「最適化戦略も考慮済みです」
|
||
```
|
||
|
||
全てのAIが「最小化」と「統一性」に注目し、型情報については誰も言及しなかった。
|
||
|
||
### 3.2 結果としての型情報欠落
|
||
|
||
```json
|
||
// 生成されたMIR
|
||
{"op": "binop", "kind": "+", "lhs": 10, "rhs": 20, "result": 30}
|
||
```
|
||
|
||
この`+`が文字列連結なのか数値加算なのか、MIRレベルでは判別不可能となった。
|
||
|
||
## 4. 実装での苦闘
|
||
|
||
### 4.1 症状の発現
|
||
|
||
2025年1月、LLVM バックエンド実装時に問題が顕在化:
|
||
|
||
```
|
||
期待: print("Hello" + " World") → "Hello World"
|
||
実際: print("Hello" + " World") → "0"
|
||
```
|
||
|
||
### 4.2 デバッグの迷走
|
||
|
||
ChatGPT5は50分もの長考に入り、300行に及ぶ複雑なResolver実装を提案:
|
||
|
||
```python
|
||
def resolve_value(self, value_id, context):
|
||
# 型推測の複雑なロジック
|
||
if self.is_stringish(value_id):
|
||
# 文字列の可能性を追跡
|
||
# さらに300行...
|
||
```
|
||
|
||
## 5. 人間による再発見
|
||
|
||
### 5.1 素朴な疑問
|
||
|
||
にゃーの疑問は単純だった:
|
||
|
||
> 「なんで+が文字列か数値か分からないの?」
|
||
> 「最初から書いとけばよくない?」
|
||
|
||
### 5.2 発見のプロセス
|
||
|
||
1. **痛みの体験**: 「文字列が0になる」バグとの格闘
|
||
2. **なぜの追求**: 「なぜ型が分からない?」
|
||
3. **常識の適用**: 「普通は型情報あるよね?」
|
||
4. **他言語調査**: LLVM IR、JVM bytecodeは全て型付き
|
||
5. **結論**: MIRに型情報が必要
|
||
|
||
### 5.3 AIへの逆提案
|
||
|
||
```
|
||
にゃー: 「MIRに型情報入れたら?」
|
||
ChatGPT5: 「...確かにその通りです」
|
||
```
|
||
|
||
## 6. なぜAIは見落としたか
|
||
|
||
### 6.1 部分最適化の罠
|
||
|
||
AIは与えられた目標「命令数最小化」に集中しすぎた:
|
||
- 13命令達成 ✓
|
||
- 型情報 ✗(考慮外)
|
||
|
||
### 6.2 実装経験の欠如
|
||
|
||
AIは理論は完璧だが、実装の苦痛を経験できない:
|
||
- デバッグの frustration
|
||
- 型推測の complexity
|
||
- 「動かない」の重み
|
||
|
||
### 6.3 文脈の断片化
|
||
|
||
3つのAIが別々に相談を受け、全体像を共有していなかった。
|
||
|
||
## 7. 新しい協働モデル
|
||
|
||
### 7.1 AIの強み
|
||
- 理論的正確性
|
||
- 大規模な知識
|
||
- 最適化能力
|
||
- 大規模リファクタリング
|
||
|
||
### 7.2 人間の強み
|
||
- 実装の痛みからの学習
|
||
- 直感的な問題発見
|
||
- 全体を俯瞰する力
|
||
- 複雑性への素朴な疑問
|
||
|
||
### 7.3 複雑性の段階的侵入への対処
|
||
|
||
本研究で新たに発見されたのは、「複雑性の段階的侵入」現象である。PHI生成が知らぬ間に2箇所で行われていた事例が示すように、システムは段階的に複雑化し、誰も全体像を把握できなくなる。
|
||
|
||
この問題に対し、人間の「なぜ2つあるの?」という素朴な疑問が、アーキテクチャの根本的な改善(Resolver統一)を促した。AIは部分最適化に優れるが、全体の複雑性増大に気づきにくい。人間の俯瞰的視点が不可欠である。
|
||
|
||
### 7.4 相補的協働
|
||
|
||
```
|
||
理論(AI) + 実践(人間) + 疑問(人間) = 持続可能な開発
|
||
```
|
||
|
||
## 8. Everything is Experience
|
||
|
||
本事例が示すのは、「Everything is Experience(すべては経験)」という新しい学習原理である。AIがいくら理論に精通していても、実装の苦痛を通じた学習には代替できない。逆に、理論を知らない人間でも、経験を通じて本質的な原理を再発見できる。
|
||
|
||
## 9. 結論
|
||
|
||
Nyashコンパイラ開発における型情報の再発見は、AI時代における人間の役割を再定義する。我々は理論をAIに委ね、実装を通じた学習に集中することで、AIが見落とす本質的な問題を発見できる。この「実装駆動型学習」は、今後のソフトウェア開発における重要なパラダイムとなるだろう。
|
||
|
||
最後に、にゃーの言葉を引用する:
|
||
|
||
> 「MIRなんて知らなかったけど、痛い思いしたら分かったにゃ」
|
||
|
||
これこそが、人間にしかできない学習の形である。 |