公開された魔法：生成されたコードはまだソースコードか？

1970年代、ある学者グループが、ソフトウェアがコンパイル済みアーティファクトとしてのみ配布されることに不満を唱え始めた。ソフトウェアを収益化しようとする企業には無視されたが、自由ソフトウェアを支持する小グループに取り上げられた。1980年代までに、彼らはその要求を成文化した。

その後1990年代、家庭用コンピュータの普及と安価な消費者インターネットの配信チャネルが「フリーソフトウェア」をより一般的な用語にしたが、「フリー」は同音異義語であり、ほとんどの人は金銭面に焦点を当てた。

平凡から有能なレベルのソフトウェアを開発するコストが月額20ドルのサブスクリプションコストに低下したことを考えると、自由の定義の別の側面を再検討する価値がある。

ソースコードをソフトウェアとともに配布することを求める背後にある原則は非常に合理的である。

ソースコード（およびその実行手順）は、ユーザーが欠陥を修復したい場合に必要である。また、ユーザーが原作者の限られた意図から目的を変更したい場合にも役立つ。最後に、初心者が例を通じて学ぶのに役立つ。

ここにいるなら、おそらくソースコードが何かを知っているだろうが、それが時間とともにどのように進化してきたかを見てみよう。

古代

コンピュータの核心はイエス/ノーマシンである。このイエス/ノー、真/偽、オン/オフ（脚注：技術的には正しいもの）の性質は、基数2の数体系としてエンコードすることに適している。CPUは命令をロードし、それを実行する。

問題は、「139」が加算命令だったか、「2736」だったかを覚えていることだ。待て、両方ともで、少し異なる。

ここでアセンブリ言語が登場する。覚えにくい数値を少し覚えやすい文字に置き換える。これらの文字はニーモニックであり、それらが表す数値はオペコードである。

したがって、「139」の代わりにADDと書き、「2736」の代わりにADDSと書く。どちらの場合も、マニュアルを開いて2番目の命令の副作用を思い出す。

ニーモニックとその引数（加算するもの）をオペコード/バイナリに変換するプログラムはアセンブラと呼ばれ、これがアセンブリ言語である。

70年代のコード

1970年代初頭にC言語が発明され、1970年代末までに広く使われるようになった。他の言語もあったが、この物語ではそれらは重要ではない。

C（および他のコンパイル言語）が行ったのは、プログラムを表現するためのよりコンパクトな方法を提供することだった。

// 私はゼロ個のライムで目覚める
int limeCounter = 0;

// 私は店に行く
limeCounter += 5;

printf("私は %d 個のライムを持っています\n", limeCounter);

これは労力の大幅な削減であり、「私は店に行く」セクションだけでもアセンブリでは次のようになる：

ldr  w1, [x0]       // limeCounterをロード
add  w1, w1, #5     // +5
str  w1, [x0]       // ストアバック

[完全なアセンブリはここをクリック...]

Cバージョンをアセンブリバージョンに変換する行為はコンパイルと呼ばれる。コンパイルとアセンブリのステップを不可視に結合することもできるが、それらは2つの別々のステージである。

一貫性は保証されない

コンパイラを活用することによって導入される微妙な変更の一つは、翻訳者にいくつかの自由度を残すことである。

この例では、コンパイラはADDニーモニックを選択したが、ADDSでも機能しただろう。

注意深い読者は、この単純なプログラムでは変数が決して使用されていないため、加算操作を削除し、ライムカウンタを5から開始できることにも気付くだろう。

コンパイラはこれらの自由度を利用でき、実際に利用する。それらがコンパイラ最適化である。それはまた、異なるバージョンやブランドのコンパイラが異なる結果の出力を生成することを意味する。

誰かがソースコードを期待するとき、彼らはCバージョンを意味する。それが著者の意図に最も近い。

解釈の余地

コンパイル言語の欠点の一つは、生成されたバイナリがアセンブルされた特定のCPUに結びついていることである。クロスプラットフォームなコンパイルコードを書くこともできるが、より注意と集中が必要である。

1990年代後半、スパイス・ガールズが友達と楽しんでいる間、Netscapeチームは懸命に働いていた。彼らのウェブブラウザ（Netscapeのものであり、スパイス・ガールズのものではない）内部には、ウェブページに隠された未コンパイルのコードを読み取り、ページ自体を変更できるエンジンがあった。

ブラウザはさまざまなCPU上で実行されるため、異なるパラダイム、つまりインタプリタも採用されていた。インタプリタは言語をアセンブリに変換してからアセンブルする代わりに、言語を独自の命令セットに変換し、それを独自のエンジンを介してCPUに中継する（またはそれに近い）。

JavaScriptは最初のインタプリタ言語ではなかったが、おそらく最も普及している。それ以来、反復され、ブラウザから抽出され、LLMが好むデフォルト言語の一つとなった。おそらく、それがどれほど一般的に使われているかによる。

インタプリタが進化するにつれて、一部は独自の独立したバイトコードを作成したが、一般的な形式ではなかった。

配布可能なアーティファクトがないため、インタプリタ言語はソースを出荷することを意味していた。ソースを難読化して知的財産を制御しようとする努力があったが、それは問題の診断と修正を困難にするというトレードオフを伴う。本質的に、難読化されたコードは依然としてJavaScriptであり、読みにくい変種にすぎない。これは後で重要になる。

ソースコードがウェブページに直接あったため、学習を志す人々の参入障壁が大幅に低下した。そして人々は学んだ。おそらく史上最高の学習の機会の一つだった。

私たちの子供たちも私たちを嘲笑うだろう

パラダイムはシフトし進化し続ける。パラダイムシフトの奇妙な点は、それが着地して安定するまで評価するのが難しいことである。

オープンソース運動の背後にある原則に戻ろう。その精神は、一般の実践者が以下のことを望むことに集約される：

• 配布されたソフトウェアの欠陥を修復する
• 原作者から学ぶ
• 原作者に依存せずに機能を拡張する

しかし、私たちがより頻繁に見ているのは、インターフェースの変化である。開発者は一連の命令を作成し、コンピュータは書かれたとおりに実行する。

プロンプト駆動開発は、再実行可能な永続的なアーティファクトを生成するか、エージェントハーネス自体をインタプリタとして扱う。永続的なアーティファクトが検査されない場合、それは機械語や中間アセンブリと実質的に変わらない。

したがって、ソースはそのプロンプト、または一連のプロンプトになる。ほとんどの人は、出力が十分に良くなった時点でプロンプトの改良をやめる。なぜなら、彼らはプロセスを共有するつもりがなかったからである。

プロンプトの出力はJavaScript（またはRust、Kotlin）になるが、すべての意図が剥ぎ取られている。学ぶものは何もなく、難読化されたJavaScriptやアセンブリ言語のバージョンを出荷し、それをソースコードと偽ることに近い。作者自身も中間表現を理解していないかもしれない。しかし「プロンプトを出荷する」という用語は、ほとんど嘲笑的に使われる。なぜなら、それは非常に信頼性が低いからである。

プログラミング言語がサポートしないことの一つは曖昧さである。英語が圧縮の一形態であるならば、それは非可逆的である。英語は曖昧さの中で繁栄し、「べき」という単語はすべての要求文書の災いである。したがって、プロンプトだけでは到底十分ではない。

だから私は、単独で「プロンプトを出荷する」ことを主張しているわけではないが、6ヶ月前のソースコードは価値を失いつつある。私たちは何か新しいものを発明する必要があるのだろうか？

Knuthは知っていた

留意すべきことは、それぞれの啓示について、それは最先端技術ではなく、時代を先取りしたものであり、より広い業界が追いつくのを辛抱強く待っていたということである。

私たちのコンパイラの例は1975年に起こったが、概念は1957年から存在していた。インタプリタはわずか1年後（1958年）に考案されたが、主流が追いついたのは1995年だった。

私が説明してきた問題の形状を見ると、それはDonald Knuthが1984年に導入した文芸プログラミングと奇妙な類似性を持っている。プログラマはコードが埋め込まれたエッセイを作成し、一対のツールを活用する。一つのツール（tangle）はコンパイラの出力を最適化し、もう一つのツール（weave）は読者の出力を最適化する。コンピュータは命令を消費し、私たちは意図を消費する。コードベースにコメントを散りばめる代わりに、エッセイを出荷し、コードで曖昧さを解決する。文芸プログラミングでは、散文がプログラムである。今日の世界では、プロンプト、またはその派生形を保持することが重要であるように思われる。特にオープンソースにとっては。意図が失われれば、「ソース」コードはアセンブリや難読化されたJavaScriptを出荷するのと大差ない。

それは一部の学術サークルでは好奇心の対象のままであった。Jupyterノートブックはいくぶん近づいたが、実際には連鎖するセルの連なりになる傾向がある。Knuthの解決策は広く採用されなかったかもしれないが、彼は確かに問題の到来を見越しており、40年以上も私たち残りの者が追いつくのを待っていた。

ここでの正しい手順は何か確信はないが、この曲は非常に聞き覚えがある。すべての歌詞を知っているわけではないが、少なくともメロディーはハミングできると思う。