メッチャ長くなりそう。。。
ちょっと書くことをまとめていたら読み物として超絶長くなったため、何回かに分けて投稿します。
一応、各記事には全体のリンクも用意するので、順番に読んでいってもらえれば幸いです。
前セツ
第1話では人間向けのアーキってAIにはどうなの？と言うことをAIと確認していき、Feature FirstはAIと相性が良いみたいということが分かってきたところで「共通Utilとかってどうなんや？」と言う疑問が。。。
今回はそこら辺をAIに聞いてみたよ！
DRYはAI時代でも正義なのか？
共通Utilの話になると、AIは意外なことを言い始めました。
🤔 え～すけさん
「じゃあ、共通Utilってどうなるの？」
🤖 AI
「AIだけで開発するなら、人間ほど積極的には共通化しないかもしれません。」
……え？
DRYを否定するの？
DRYは人間のための考え方？
改めて聞いてみました。
🤔 え～すけさん
「でもDRYって良い設計の基本じゃないの？」
🤖 AI
「もちろん、人間だけで開発するなら今でも非常に有効です。」
🤖 AI
「しかし、AIはコードを書くコストがほぼゼロなので、評価軸が少し変わります。」
なるほど。
じゃあ、その評価軸って何なんでしょう？
AIは「書く」のではなく「読む」のが高コスト
例えば人間なら、
String formatMoney(int value) {
...
}
という処理を10か所で使うなら、
「共通Utilにしよう」
と考えます。
その方が修正箇所も1か所になりますし、保守もしやすいです。
でもAIは違います。
AIはこの程度のコードなら数秒で生成できます。
逆に、
MoneyUtil
DateUtil
StringUtil
NumberUtil
CollectionUtil
のようにUtilが大量にあると、
- どれを使う？
- 同じような関数は他にもある？
- このUtilは画面用？DB用？
- 他に影響しない？
という確認作業が発生します。
つまり、
AIにとって一番高いコストは「書くこと」ではなく、「理解すること」なのです。
「2回使ったら共通化」は本当に必要？
自分は普段、
「同じ処理が2回出てきたら共通化」
くらいの感覚で実装しています。
そこで聞いてみました。
🤔 え～すけさん
「じゃあ、2回使ったくらいじゃ共通化しない方がいい？」
🤖 AI
「AI主体なら、その判断基準は見直しても良いと思います。」
例えば、
String trimKana(String value)
という関数が2か所で使われていたとします。
人間なら
KanaUtil.dart
を作るかもしれません。
でもAIは、
同じ処理をそれぞれのFeatureに持っていた方が、
読むファイルが少なくて済む可能性があります。
これは結構意外でした。
じゃあ、Utilは全部なくなる？
もちろん、そんなことはありません。
そこで今度は逆の質問をしてみました。
🤔 え～すけさん
「じゃあUtilって要らなくなるの？」
🤖 AI
「いいえ。仕様が統一されるべきものは共通化した方が良いです。」
この回答には妙に納得しました。
例えば、
- 金額表示
- 和暦変換
- 郵便番号
- 電話番号
- 消費税計算
これらは会社全体で同じ仕様になるべきです。
画面によって
￥1,200
1,200円
¥1200
のようにバラバラだったら困ります。
つまり、
仕様を統一したいものは、今までどおり共通化する価値があります。
ここで新しい疑問が湧いた
AIの話を聞いているうちに、
あることに気付きました。
AIは毎回
Utilities.moneyFormat()
を呼び出しているだけです。
じゃあ……
🤔 え～すけさん
「AIって、中の実装まで毎回読んでるの？」
🤖 AI
「必ずしも読む必要はありません。」
ここから話が急展開します。
AIは実装より「使い方」を知りたい
例えば、
Utilities.moneyFormat(1200)
という関数があるとします。
AIが知りたいのは、
実装よりも、
- いつ使うのか
- 何を渡すのか
- 何が返るのか
- どういう場面では使ってはいけないのか
という情報です。
つまり、
AIはコードではなく、
「仕様書」を読んでいる
と言った方が近いのかもしれません。
じゃあ、仕様書をもっと充実させたら？
ここで、ふと思いました。
🤔 え～すけさん
「もしかして、AI向けFrameworkってコードより仕様書の方が重要なんじゃない？」
AIは少し考えてから、こう答えました。
🤖 AI
「その考え方には可能性があります。」
ここから、「AI向けFrameworkはMarkdownが主役になるのでは？」という、さらに面白い話へ進んでいきます。