ソースコードを再現する仕様書を保存する時代(仮)
これまでプログラマーは、ソースコードを保存してきた。
これはソースコードを対象に実行や修正を行なってきたから。
もしも、LLMの台頭で、仕様書からソースコードを都度生成しても問題のない時代になったら、保存されるべきは仕様書であって、ソースコードではなくなるかもしれない
やりたいことを網羅できる仕様書があれば、ソースコードは都度LLMに生成させれば良い。
この場合、残したいのは「仕様書」の方であって、ソースコードではない
ただし仕様が揺れると挙動が変化する場面だと、とても危うい
仕事とか
他システムと連動しているもの
一方で、プライベートな利用の場合には、多少実装がブレても問題のない場面は多い
ブレて問題になったら、その都度仕様書を修正するというループでも良い
使い捨てワンライナー的に
仕事だとちょっとこれ危ういよな。
ソースの代わりに仕様書をメインに据えると、結構メリットありそう
ソースコードのメンテナンスは面倒くさいのだけど、仕様書のメンテナンスの方が比較的に楽
実行環境のバージョンアップ、OSSのアップデート、etcetc,,,
日本語で読み書きできる方が楽
githubに保存するものとして、今はソースコードがメイン、仕様がサブだと感じるけど、
将来的には「仕様がメイン」になる時代が来るんじゃないかと思った
🤖の反応
「仕様書がメイン」になる条件
LLMが「仕様の曖昧さを埋める共通知識」を持っている前提
つまり「LLMがよく知っている領域」に限定される（最後の指摘と同じ）
逆に言うと、LLMの学習データに入っている概念＝「暗黙の仕様」として省略できる
圧縮の非対称性
ソースコード：実行環境・OSS依存関係まで含めると情報量が増え続ける
仕様書：「Faissを使って近傍探索する」の一文でLLMが実装を補完できる
→ LLMの知識が「共有ライブラリ」として機能する構造
「詠唱廃棄」との対応
まさに魔法陣（ボイラープレート）をLLMが補完してくれる
残る問題
仕様書の「テスト」が難しい（ソースはCIで検証できる）
仕様の揺れ検知がソースより困難
「仕様書のdiff」が意味論的になる→ Git的な管理が難しい
個人的な感想
「仕様書＝人間の意図の圧縮」「ソースコード＝機械向けの展開」と捉えると、LLMが展開機として成熟するにつれて、保存すべきは圧縮側に移行するというのは自然な流れに思える。ただ「仕様の完全性をどう担保するか」が現状のボトルネックで、これはテストや型システムがソースコードに対してやってきたことを、仕様書に対してやる必要がある、という新しい問題が生まれそう。 これは自然言語でユニットテストを作成するアイデア。自然言語に対してユニットテストを行なっているわけではない