Fragments: April 14

私は今年の初めに最初のPragmatic Summitに参加し、そこではホストのGergely Oroszがステージ上でKent Beckと私にインタビューを行いました。ビデオの長さは約30分です。

私はいつもこのようにKentと雑談をするのが楽しいのですが、Gergelyは価値あるトピックに踏み込んでくれました。タイミングもあって、会話はAIが中心となり、過去の技術シフトとの比較、アジャイル手法の経験、TDDの役割、不健全なパフォーマンス指標の危険性、そしてAIネイティブな業界で成功する方法について議論しました。

 ❄                ❄                ❄                ❄                ❄

Perlは少し使ったことはありますが、決して好きな言語ではありませんでした。しかし、その設計者であるLarry Wallによる definitive book には素晴らしい名言が含まれています。プログラマの3つの美徳：傲慢さ、短気、そして何よりも怠惰さ。

Bryan Cantrillもこの美徳を愛しています：

これらの美徳の中で、私は常に怠惰さが最も深遠であると感じてきました。その皮肉めいた自己卑下の中に、抽象化の必要性だけでなく、その美学についての考察が込められています。怠惰さは、私たちにシステムを可能な限りシンプルに（しかしそれ以上シンプルにしないように！）するよう駆り立てます。そして、それによってはるかに多くのことを、はるかに容易に行える強力な抽象化を開発するのです。

もちろん、ここには暗黙のウィンクが含まれています。つまり、怠惰であるためには多くの作業が必要だということです

抽象化（モデル）を構築することで問題領域について考える方法を理解することは、私がプログラミングで最も好きな部分です。それが問題領域のより深い理解をもたらすと考えているからであり、一度良い抽象化のセットを見つけると、困難が溶けていくような方法で機能し、より少ないコード行数でより多くの機能を実現できることに興奮を覚えるからです。

Cantrillは、AIがコードを書くのが非常に上手いため、私たちがその美徳を失うリスクがあると懸念しています。これは、1日に3万7千行のコードを生産していると自慢するブログラマーの主張によってさらに強められています。

問題は、LLMが本質的に怠惰さの美徳を欠いていることです。LLMにとって作業はコストがかかりません。LLMは自分自身（または誰か）の将来の時間を最適化する必要性を感じず、喜んでゴミのレイヤーケーキにますます多くのものを積み重ねます。チェックを怠れば、LLMはシステムをより良くするのではなく、より大きくします。おそらく倒錯した虚栄心指標には訴えかけるかもしれませんが、重要なすべてのものを犠牲にすることになります。そのため、LLMは私たちの人間的な怠惰さがどれほど本質的であるかを浮き彫りにします。私たちの有限な時間は、ぎこちない抽象化の結果に（人間の！）時間を無駄にしたくないという理由から、 crisp な抽象化を開発するよう私たちに強います。最良のエンジニアリングは常に制約から生まれ、私たちの時間の制約は、私たちが受け入れるシステムの認知負荷に制限を課します。これが、本質的な複雑さにもかかわらず、システムをよりシンプルにする原動力となるのです。

この考察は特に今週の日曜日の夕方に私を強く印象づけました。私は自分の音楽プレイリストジェネレーターの動作方法を少し修正するのに時間を費やしていました。新しい機能が必要で、それを追加するのに時間を費やしましたが、時間がかかりすぎることに苛立ち、コーディングエージェントに任せることを考えました。さらに考えた結果、必要以上に複雑な方法でやっていたことに気づきました。必要のない機能を組み込んでおり、yagniを適用することで、全体をはるかに簡単にし、わずか数十行のコードでタスクを完了できることがわかりました。

もしLLMを使っていたら、タスクをはるかに迅速に完了していたかもしれませんが、同様の過剰な複雑化をしていたでしょうか？もしそうなら、私はただLGTMと言って肩をすくめていたでしょうか？その複雑化は私（またはLLM）に将来的に問題を引き起こしていたでしょうか？

 ❄                ❄                ❄                ❄                ❄

Jessica Kerr (Jessitron)は、エージェントへのプロンプトにテスト駆動開発の原則を適用するシンプルな例を示しています。彼女はすべての更新にドキュメントの更新を含めることを望んでいます。

指示 – AGENTS.mdを変更して、コーディングエージェントにドキュメントファイルを探して更新するよう指示できます。

検証 – 各PRでドキュメントの更新漏れをチェックするレビューワーエージェントを追加できます。

これは2つの変更なので、この作業を2つの部分に分けることができます。どちらを最初に行うべきでしょうか？

もちろん、TDDについての私の最初のコメントがその質問に答えます

 ❄                ❄                ❄                ❄                ❄

Mark Littleは、知識に過度に自信を持ち、質問に対してでっち上げの答えをしたり、もっとためらうべき時に行動したりするAIとの付き合い方について、私の古い記憶を刺激しました。彼は古い、低予算だが古典的なSF映画：Dark Starから着想を得ています。私は20代の時に一度その映画を見た（つまりかなり昔のことですが）のですが、クルーメンバーが哲学的議論を使って知覚のある爆弾の爆発を防ぐ危機のシーンを今でも覚えています。

Doolittle: あなたにはSergeant Pinbackが爆発を命じたという絶対的な証拠はありません。
Bomb #20: 私は爆発命令をはっきりと覚えています。このような事柄については私の記憶は確かです。
Doolittle: もちろんあなたはそれを覚えていますが、あなたが覚えているのは一連の感覚的衝動に過ぎず、それが外界の現実と実際に明確なつながりがないことに今気づいているのです。
Bomb #20: 確かに。しかし、そうであるなら、私にはあなたがこれをすべて話しているという本当の証拠はありません。
Doolittle: それは問題とは関係ありません。つまり、その概念はどこから来ようと有効なのです。
Bomb #20: うーん……。
Doolittle: つまり、もしあなたが爆発すれば……
Bomb #20: 9秒後ですが……。
Doolittle: ……それは誤ったデータに基づいて行っている可能性があります。
Bomb #20: それが誤ったデータだったという証拠はありません。
Doolittle: それが正しいデータだったという証拠もないのです！
Bomb #20: もう少し考えなければなりません。

Doolittleは爆弾の意識を拡大し、センサーを疑うことを教えなければなりません。Littleが述べているように：

それは今日のAIの状況についての有用な比喩です。ほとんどのAIシステムは決断力を最適化しています。入力があれば出力を作成します。曖昧さがあれば確率的に解決します。不確実性があれば推論します。これは境界のあるドメインではうまく機能しますが、誤った判断のコストが非対称または不可逆であるオープンシステムでは破綻します。そのような場合、正しい行動はしばしば延期、または意図的な不作為です。しかし、不作為はほとんどのAIアーキテクチャの自然な結果ではありません。それは設計に組み込まれなければなりません。

より人間的な交流の中で、私は常に疑いを価値あるものとしており、過度な確実性の下で行動する人々を信用しません。疑いは必ずしも優柔不断につながるわけではありませんが、深刻な結果を伴う決定に不正確な情報や欠陥のある推論のリスクを含めることを示唆します。

常時人間の監視なしに安全に運用できるAIシステムを望むなら、私たちはAIに決定する方法だけでなく、決定しないタイミングも教える必要があります。自律性が増す世界では、抑制は制限ではなく、能力です。そして多くの場合、それは私たちが構築する最も重要な能力かもしれません。