Fragments: 5月14日

先週、Mechanical Orchardが主催するThe Orchard Retreatで1日を過ごしました。そこで、ソフトウェア開発に携わる複数の人々が集まり、エージェント型プログラミングの台頭に伴うこの職業の未来について議論しました。イベントはChatham House Ruleのもとで開催されたため、私が耳にしたコメントやエピソードの出所を明かすことはできません。（もしご自身が該当すると思われる方がいて、帰属先の明記を希望される場合はご連絡ください。）以下は、私のノートに残ったいくつかの断片です。

 ❄                ❄

あるグループが、GNU Cobolコンパイラの動作クローンをRustで開発しました。結果は7万行のRustコードとなり、わずか3日間で構築されました。これは、LLMが既存のコードを新しいプラットフォームへ移植する能力を示す、もう一つの好例です。ここでは優れた回帰テストが極めて重要です（GNU Cobolのテストがどの程度優れているかはわかりません）。既存の実装にアクセスできる場合は、テストスイートを構築する可能性もあります。

 ❄                ❄

大規模な仕様書は人間がレビューするには複雑になりがちです。ある参加者は、LLMに人間の専門家へインタビューさせ、仕様の正しさを検証する質問をさせるというアイデアを共有しました。これはInterrogatory LLMの一形態です。

 ❄                ❄

AIに特有の話ではありませんが、ある参加者が、組織にコンサルティングする際に最初に行うのは、変更管理委員会のガイドラインを読むことだというコメントが印象的でした。これは過去に起きた問題の瘢痕組織です。私は以前から、「ある物事がなぜそのようになっているかを理解するには、そこに至った歴史を理解する必要がある」と述べてきました。これは、その歴史の重要な部分にアクセスするための優れた方法のように思えます。

 ❄                ❄

レガシーシステムの近代化に携わる私の同僚たちは、「リフトアンドシフト」——レガシーシステムを新プラットフォームへ移植しつつFeature Parityを維持する——に対して、長らく批判的でした。

私たちはこのパターンを、大きな機会損失と見なしています。古いシステムは時間の経過とともに肥大化し、ユーザーが使用しない機能が多数存在することが多く（2014年のStandish Groupの報告によると50%）、ビジネスプロセスも時間の経過とともに進化してきました。これらの機能を置き換えることは無駄です。代わりに一歩引いて、ユーザーが現在必要としているものを理解し、これらのニーズをビジネス成果や指標と照らし合わせて優先順位付けするエネルギーを集めるべきです。

しかし、この見解はLLMのコード移植能力が登場する以前に形成されたものです。この分野で多くの仕事をこなすある参加者は、レガシーマイグレーションの第一歩として、新プラットフォームへのリフトアンドシフトを今や常に最初に行うべきだと述べました。コストは以前ほど高くなく、より良い環境はさらなる進化をはるかに安価にします。ただ、そこで止まってはいけません。

 ❄                ❄

複数の参加者が金融業界出身で、複雑なレガシー環境と規制管理、金銭を扱うソフトウェアの誤りがもたらす重大なリスクという問題に深く関わっていました。彼らの課題の一つは、金融商品が複数の法域で提供される場合に生じる複雑さで、それぞれの法域に独自の規制を満たす必要があります。どの法域が適用されるかを判断し、ワークフローの適切な時点で正しいルールのセットを選択するソフトウェアの複雑さが多く存在します。

ここでの疑問は、エージェント型プログラミングの急速な進化により、各法域ごとに個別のよりシンプルなシステムを構築できるのではないかというものです。その後、LLMを用いてそれらの間の整合性を確保し、商品ルールが変更された際に、各システムがそれを自らの環境に反映させるというアプローチです。

ソフトウェア設計の大部分は、さまざまなビジネスコンテキスト間で何が同じで、何が異なるかを特定することです。同じであり、同じである必要がある部分では、更新コストの増加や不整合の危険性を理由に、コードの複製を避けるのが適切です。興味深いのは、LLMがこの問題に取り組むための新しいツールを提供できる役割です。

 ❄                ❄

このような集まりではいつものことですが、参加者はジュニア開発者のことを心配していました。私たちがThe Genieと協働する際、私たちの価値は優れた判断力にあります——それをどう教えるのでしょうか？ このグループには共通のツールがありました——Pair Programmingです。ペアリングの主な利点の一つは常にスキル移転であり、ここでは経験豊富なエージェント型プログラマーが、ソフトウェア設計やGenieを活用してそこに至る方法についての判断を伝えることができます。また、ジュニアはしばしば共有できるコツをいくつか持っており、特にエージェント型未来への移行においては、新鮮な目が非常に価値があります。

 ❄                ❄

歴史的に、私たちはコンピュータシステムを使って混沌とした人間のプロセスに秩序をもたらしてきました。AIはそれを逆転させているのでしょうか？

 ❄                ❄

非常に多くのソフトウェアがデータ変換に関わっています。あちらのレコードをこちらのAPIで消費する必要がありますが、データ構造の違い（しばしば異なるBounded Contextsに起因する）があるため、ある程度の変換が必要です。エージェントは、この種の変換コードの記述に特に適しており、それはしばしば私たちが望むよりも退屈な作業です。

 ❄                ❄

Chaos Engineeringは、耐障害性を向上させるための価値ある手法となり、NetflixのChaos Monkeyが有名になりました。これはライブサービスをランダムに破壊し、エコシステムがどれだけうまく反応・回復するかを確認するものです。AI向けのChaos Monkeyとはどのようなものでしょうか？ パイプラインに意図的に幻覚を導入し、センサーがそれを検知できるかを確認するものでしょうか？

 ❄                ❄                ❄                ❄                ❄

デスクに戻って

Structured-Prompt-Driven Development (SPDD)に関する記事について、著者がQ&Aセクションで回答した質問がいくつか寄せられています。その中の一つが特に目にとまりました：

エージェントにプロンプト/仕様のレビュー自体を行わせることを検討したことはありますか——人間がCanvasをレビューするのではなく、エージェントがREASONS Canvasとコード差分を読み、整合性を検証する——？

返答では、これを行うためのコマンドが利用可能であるものの、欠点があると述べられています。特に、自動的に行わない理由の一つとして：

人間の学習を促すこと。レビューはまた、人間がAIの選択から学ぶ場でもあります——パターン、トレードオフ、考えもしなかった選択肢など。人間を排除すればスピードは上がりますが、SPDDが守ることを目指す長期的なスキル成長を阻害します。[…] 十分な判断ルールが蓄積され、本当の信頼が得られるようになったら、徐々にレビューの多くをエージェントのステップに移していくかもしれません——しかし、人間がAIから学ぶ部分は、私たちが維持する予定です。

AIツールの価値を判断する一つの方法は、それが私たち人間が住み、作り出す世界についてより多く学ぶのをどれだけ助けるかです。

 ❄                ❄                ❄                ❄                ❄

先週、何らかの奇妙な方法で肘を負傷しました。きっかけはなく、「しまった」と言うような出来事はありませんでした。ただ徐々に痛みと腫れが始まりました。スポーツ傷害を避けるための生涯にわたる戦略1が、私を裏切ったのです。氷とイブプロフェンを適用したところ、腫れは引きましたが、可動域は悪化しました。英国での幼少期にナイフとフォークの使い方を学んだおかげで、通常は左手で食事しています。

可動域の喪失は、家に帰って再び一日中コンピュータの前に座るようになってから起こったことに気づきました。肘を直接使わなくても、右手はタイピングとマウス操作をたくさん行います。私のデスク環境はかなり ergonomics で、良いキーボード、マウス用のリストレスト、椅子のアームレストがあります。それでも、コンピュータの使用が家に帰ってから肘の状態を悪化させたのでしょうか？ 私にとって執筆は止められない習慣となっているので、コンピュータを使わないことは想像できません。しかし、この機会に音声入力を試してみるべきかもしれません——結局のところ、ほとんどの人はタイピングよりも速く話すことができます。

何年も前に、同僚が音声認識が自分に合わせて訓練すれば非常に優れていると教えてくれたことがありました。試してみたところ、当時のAI以前の時代でも音声認識は確かに非常に良かったです。しかし、私には合いませんでした。執筆中はEmacsに素早く単語を入力しますが、ほぼ即座に編集に戻ります。2文を書いて編集し、もう1文を書いて段落を再編集する。自分の言葉を見て考えるという往復が非常に密接で、単に言葉を口述することはできません。

それでさらに考えさせられました。私は20代になってから執筆にコンピュータを使い始めました。学校では手書きをし、大学ではタイプライターで打っていました。しかし、それらのメディアは今私がしているような絶え間ない書き直しをサポートしていません。テキストエディタが発明されていなかったら、私は作家になっていたでしょうか？

 ❄                ❄                ❄                ❄                ❄

James Pritchardは、多くの開発者が製品の実行時にエージェントを過剰に使用していると考えていますが、LLMは関数として使用する方が優れていると述べています。

エージェントの問題は、機能しないことではありません。予測不能に機能することです。既知の実行パスを、「自律性」と引き換えにしますが、それは主に「何をするかわからない」という意味です。エージェント駆動の機能が本番で壊れた場合、デバッグするのはスタックトレースではなく、会話のトランスクリプトになります。

「エージェント」のユースケースのほとんどは実際にはワークフローであり、既知の一連のステップのうち1つか2つがLLMを含むものです。そのために自律性は必要ありません。関数呼び出しが必要です。

彼は、関数は予測可能に合成されるため、ワークフローがわかっているなら、プログラムテキストで合成する方が、エージェントが自分で調整する方法を考え出すよりも優れていると指摘します。より速く、トークンも少なくて済みます。通常、失敗への対応も容易です。インタラクションの範囲がより小さいためです。

 ❄                ❄                ❄                ❄                ❄

Pritchardはまた、人々がスキルを必要以上に使用していると考えています。彼は、人々がマークダウンのスキルファイルをフォルダに蓄積するが、LLMはそれらを一貫して使用せず、必要なときに見逃したり、必要ないときにコンテキストを肥大化させたりすると述べています。スキルに入れるべき多くのものは、ハーネスの他の部分、できれば計算的なものでなければなりません。スキルは意図的で頻度の低いワークフローでのみ使用されるべきです。

スキルへの執着は、より深いパターンの症状です。人々がアーキテクチャに手を伸ばすべきときに、設定に手を伸ばしていることです。

「LLMは良いテストを書かない。」テストのスキルを書いてはいけません。既存のテストは一貫性がありませんか？ テストのセットアップは複雑ですか？ それらの問題を修正すれば、指示されなくても良いテストを書くでしょう。自分が誇りに思うテストファイルにポイントしてください。コードは英語よりも明確です。

[…]

最善のセットアップは、LLMの設定がほとんど必要ないものです。明確なパターンを持つクリーンなコードベース、非自明なことのための短いプロジェクト設定、オートメーションのためのフック、そして意図的に実行する特定のワークフローのための1つか2つのスキル。それだけです。

 ❄                ❄                ❄                ❄                ❄

エージェント型プログラミングの台頭についてよく言われるのは、私たちの仕事で非決定性を扱い始めなければならないということです。もちろん、これはやや単純化です。ソフトウェア開発のいくつかの側面は、以前から非決定性に直面してきました。その顕著な例が分散システムであり、真に不快な分散システムの水域を探る上で著名な人物がKyle Kingsbury（Aphyr）です。

先月、彼はLLM対応の未来についてどのように見ているかに関する長い記事（PDFは32ページ）を公開しました。タイトル「The Future of Everything is Lies, I Guess」は、この未来に対する彼の熱意の欠如を表しています。

一部の読者は、私が機械学習の驚異——コード生成におけるLLMの優れた能力、Sunoがハミングしたメロディを洗練された曲に変える驚異——により多くの紙面を割かなかったことに不満を抱くでしょう。しかし、これは車を運転することがいかに速く便利かについての記事ではありません。私たちは皆、車が速いことを知っています。私は、都市の形に何が起こるのかを問うています。

あまり楽観的ではありませんが、長い読み物に値します。Kingsburyは、AIの能力について明らかに十分な情報を持っている人物の視点から、AIの成長に関する多くの懸念を提起しています。

彼の見解では、これらすべてに対する最善の対応は「止める」ことです。彼は自分の執筆、ソフトウェア、個人生活でAIを使用することを避けたいと考えています。AI企業で働く人々は辞めるべきだと考えています。それでも、これらのツールは有用であることを知っており、使用したいとも思っています。

私はAIの未来について、希望派であり悲観派でもあります。根本的に、私はあらゆる強力な技術を大きなバスと見なしています。私たちはそのバスに乗るか、轢かれるかのどちらかです。私は、障壁を設けてもその車輪に轢かれるのを止められないと思うので、バスに乗っています。バスに乗っていれば、運転手に少し影響を与えるために誰かと合流できるかもしれません。また、私は何事についても、特にこれほど強力なものについては、将来の結果を推測することを非常に嫌がります。18世紀後半の初期の産業資本家たちは、自分たちが解き放った産業革命が何をもたらすか、どんな手がかりを持っていたでしょうか？ 多くの害を生み出した一方で、少なくともバスに乗っていた国々の何百万人もの人々の生活水準を大幅に向上させました。AIは、私が本当に夢見ることのできない利益を生み出すかもしれませんが、友人がパーキンソン病を食い止めるのを助けるときに、その片鱗を垣間見ることができます。

そのような希望はありますが、Kingsburyの記事は、現在のより暗い側面に光を当て、責任に関する深刻な問いを投げかけています。

Mastodonインスタンスのモデレーターとしての仕事の一部は、ユーザーレポートに対応することであり、時折CSAMに関するレポートがあります。私は法的にそのコンテンツをレビューしてNCMECに提出する義務があります。私はこれらの画像を見たくありませんし、本当に見なかったことにしたいと思います。暗い朝、コンピュータの前に座ってAI生成の性的暴行画像に関するモデレーションレポートを見つけると、OpenAIなどのエンジニアがこれらの画像も見ることを望むことがあります。おそらくそれが、彼らが世界にもたらしている技術と、「アライメント」が実際にどのように機能しているかについて反省させるでしょう。