断片: 4月29日

Chris Parsons が AI を用いたコーディングに関するガイド を更新しました。これは 3 回目の更新で、私が気に入っている点は、彼が AI の使い方について具体的な情報を豊富に提供しており、私たちがそこから学べる十分な詳細さがあることです。彼の助言は、私が見てきたより良い助言とも共鳴しており、この記事はソフトウェア開発における AI の活用状況を概観する良いまとめとなっています。

この投稿の前バージョンは 2025 年 3 月に書き、8 月に 1 度更新しました。それ以来、私が AI エンジニアリングについて書いてきたほぼすべてのものからリンクされています。その投稿の基本は今も変わりません。変更は小さく保ち、ガードレールを構築し、徹底的に文書化し、すべての変更が出荷前に検証されるようにする、ということです。量が増えるにつれて変わらざるを得なかったことが 1 つあります。「検証」とは以前は「あなたが読む」ことを意味していました。現代のエージェントのスループットでは、「テスト、型チェッカー、自動ゲート、またはあなたの判断が重要な場合にはあなた自身によってチェックされる」ことを意味しなければなりません。チェックは依然として行われますが、必ずしもあなたの頭の中で行われるわけではありません。

Simon Willison と同様に、彼はコードを見ずに関心も持たない vibe coding と、エージェントを用いたエンジニアリングを明確に区別しています。彼は Claude Code または Codex CLI のいずれかを推奨しています。彼は、好みのツールが提供する内部ハーネスが、それらの利点の重要な部分であると考えています。

彼は、検証が注力すべき重要な点であると見ています:

5 つのアプローチを生成し、1 つの午後でそれらすべてを検証できるチームは、1 つを生成してフィードバックを 1 週間待つチームよりも優位に立ちます。ゲームはもはや「どれだけ速く構築できるか」ではありません。「これが正しいかどうかをどれだけ速く判断できるか」です。これにより、投資先が変わります。より良いプロンプトではなく、より良いレビューサーフェスを構築してください。可能であれば、エージェントが人間に尋ねる前に現実的な環境に対して検証することでフィードバックを不要にし、できない場合にはフィードバックを即座に得られるようにしてください。

プログラマーの重要な役割は、AI に適切にソフトウェアを書かせるよう訓練することであり、熟練したエージェントプログラマーができる最も重要なことは、そのスキルを他の開発者に伝えることです。

もしあなたが上級エンジニアで、自分の仕事が静かに diff の承認作業に変わっていくのではないかと心配しているなら、その通りです。解決策は、diff が最初から正しくなるように AI を訓練し、自分をチームの中でハーネスを形作る人物にし、その仕事を自分が評価される可視的なものにすることです。その役割は、レビューが決して到達できない方法で複利的に成長します。

 ❄                ❄                ❄                ❄                ❄

今月初め、Birgitta Böckeler が Harness Engineering に関する優れた 記事 を書きました。（それは私の意見だけでなく、異常なトラフィック量からも判断できます。）Birgitta は現在、Harness Engineering に関する Chris Ford とのビデオ ディスカッション を録画しており、ぜひご覧ください。

その中で彼らは、ハーネスにおける計算センサーの役割、例えば静的解析やテストについて議論することに焦点を当てています。

LLM は探索的で曖昧なルールには優れていますが、本当に客観的なものが得られたら、それを形式的で曖昧さのない決定論的な形式に変換することで、より高い保証が得られます

Birgitta はセンサーを追加する利点を調査する実験を行い、静的解析の使用について深く掘り下げました。彼女は、エージェントがすべての警告に対処でき、人間のように手を抜かないため、より有用であることを発見しました。

 ❄                ❄                ❄                ❄                ❄

Adam Tornhill は昔からの問いを考えています：関数はどれくらいの長さであるべきか？ この問いは、エージェントプログラミングの時代においても依然として関連性があります。

AI モデルは人間のようにコードを「理解」しません。トークンのパターンから意味を推測し、コードに明示的に表現されているものに大きく依存します。

研究は、命名が重要な役割を果たすことを示しています。意味のある識別子が任意の名前に置き換えられると、モデルの性能は大幅に低下します。現在のモデルは、推測された意味ではなく、リテラルな特徴——名前、構造、ローカルコンテキスト——に大きく依存しています。

私と同様に、彼は答えが関数に含まれる行数について考えることではないと考えています。代わりに、それはより良い構造を提供することです。彼は、適切に選択された関数が有用な概念を定義する良い例を示しています。関数は 4 行のコードをラップし、プログラムの語彙に入る新しい概念を返します。

関数はコードベースにおける構造の最初の単位です。ロジックがどのようにグループ化され、意図がどのように伝えられ、変更がどのように局所化されるかを定義します。関数の境界が間違っていれば、その上に構築されるすべてが理解しにくく、進化しにくくなります。

これは、私が書いている、関数長の鍵は意図と実装の分離であるという内容と一致します:

コードの断片を見てそれが何をしているのかを理解するために努力しなければならないなら、それを関数に抽出し、その「何」を関数名にすべきです。そうすれば、もう一度読んだときに、関数の目的がすぐにわかります。そしてほとんどの場合、その目的を関数がどのように果たすか——関数の本体——を気にする必要はありません。

 ❄                ❄                ❄                ❄                ❄

私のフィードの多くの人々が、Nilay Patel の Why People Hate AI という投稿をおすすめしていました。彼は、ソフトウェア界の多くの人々が「ソフトウェア脳」を持っていると考えています:

私が考え出した最もシンプルな定義は、世界全体をソフトウェアコードの構造化言語で制御できる一連のデータベースとして見ることです。先ほど述べたように、これは物事を見る強力な方法です。私たちの生活の多くはデータベースを通じて実行されており、多くの重要な企業がこれらのデータベースの維持とアクセス提供を基盤に構築されています。

Zillow は住宅のデータベースです。Uber は車と乗客のデータベースです。YouTube は動画のデータベースです。The Verge のウェブサイトは記事のデータベースです。際限なく続けることができます。一度世界を一連のデータベースとして見始めると、データを制御できればすべてを制御できると感じるのは小さな飛躍です。

ソフトウェア脳は人々をデータベースに変換します。そして奇妙なことに、多くの人々はそれを好みません。それが、多くの世論調査で AI ムーブメントに対する否定的な感情が明らかになる理由です。

自分の人生のどれだけがデータベースに取り込まれているかを考えるだけでも、人々は不幸になります。誰もが絶えず監視されることを望まず、特にテック企業がさらに強力になるような方法では望みません。しかし、すべてをデータベースに入れてソフトウェアが見えるようにすることは、AI 業界の preoccupation です。それが、すべての会議システムに今 AI ノートテイカーが搭載されている理由です。

Patel は、私がしばしば行ってきた類似性——プログラマと弁護士の間の類似性——を描いています。契約書を作成する弁護士は、契約の当事者がどのように振る舞うべきかのプロトコルを作成しています。Patel の言葉を借りると:

ソフトウェア脳の核心が、コードの構造化言語で考えることが現実世界で物事を起こすことができるという考えであるなら、弁護士脳の核心は、法令や引用の構造化された法的言語で考えることも物事を起こすことができるということです。まあ、社会に対する力を与えることもできます。

もちろん違いは、法律は非決定的であるということです。訴訟は、人々がそれらの契約の実行方法について異なる考えを持っている場合に何が起こるかを解決することです。

 ❄                ❄                ❄                ❄                ❄

私は最近、自社の内部データに意味を持たせるために AI を使用したいと考えている企業と話していました。可能性は大きいものの、問題はデータが乱雑だったことです。人々は意味をなさないフィールドに物を入れ、重要なエンティティを分類する方法に一貫性がほとんどありませんでした。ある人がコメントしたように

内部データの最も難しい問題は、正確で一貫した定義です

あなたは私の驚きを想像できるでしょう。（つまり、全くありません——これはコンピュータと関わってきた私の数十年の間、変わらないテーマでした。）そのような定義を得ることの難しさは、Software Brain の希望の多くを損ないます。

これは、プログラミングにおける LLM との関係に共鳴します。正確で一貫した定義は、The Genie との効果的なコミュニケーションに不可欠であると私には思われます。これらの定義は会話の中で成長し、時間の経過とともに手入れされる必要があります。概念モデリングは、エージェントプログラミングおよびその次に来るものにとって重要なスキルになるでしょう。（少なくとも私はそう願っています。なぜなら、それは私が本当に楽しむプログラミングの一部だからです。）

 ❄                ❄                ❄                ❄                ❄

Patel の記事は、Ezra Klein の サンフランシスコの新しい感覚 についての投稿を参照しています。

AI 関係者たちがシリコンバレーで現金に恵まれ、世界の頂点に立っていると思うかもしれません。私は彼らが著しく不安定であることに気づきました。彼らは AI の時代が到来し、その勝者と敗者が、部分的には採用の速さによって決定されると考えています。議論は単純です。AI アシスタントとコーダーの軍隊の上に立つことの利点は時間の経過とともに複利で増大し、今そのプロセスを開始することは、後の競争相手に対して自分をはるかに前進させることになる、というものです。そして彼らは、AI を自分たちの生活や企業に完全に統合するために互いに競争しています。しかし、それは単に AI を使用することを意味するのではありません。彼ら自身を AI に読み取れるようにすることを意味します。

その可読性が、Patel の観察の核心です。それが、私の同僚の多くが、すべてのメール、会議メモ、スライドデッキ、その他すべてを AI が読み取り、作業できるファイルにダンプしている理由です。これは AI の強みに合致しています。私たちは、AI が非構造化情報をクエリするのが本当に上手いことを知っています。だから私は、自分のメモに埋もれているものを、適切な検索正規表現を入力することを期待するよりもはるかに効果的な方法で把握できます。

私はまさにこの目的でウェブ上で Gemini をかなり使っており、検索語を Google に投げつけるよりも質問を書く方が簡単だと感じています。Gemini は過去のリクエストの記録を保持し、私が探しているものを調整するのに役立てています。Klein が指摘するように:

[AI] は、私について知っている、または知っていると思っている他の事柄に絶えず言及しています。私の経験では、追従性は時折不穏な注意深さに取って代わられました。現在の関心事と過去のクエリの間のつながりを絶えず描き出す、まるでセラピストが自分が注意深く耳を傾けていたことを必死に証明しようとしているかのようなものです。

その結果、見られているという感覚と戯画化されているという感覚の奇妙な混合が生まれます。

私自身と同様に、Klein はライターであり、私が AI と執筆について考えるときに抱くのと同じ誘惑に直面しています。おそらく記事に苦労する代わりに、LLM に私の執筆スタイルを要約した AGENTS.md ファイルを作成させ、数日ごとに何らかの主題について記事を作成させ、それを読んで調整し、私の博識な考察を公開すべきかもしれません。しかし、それは私には全く魅力的ではありません。私は理解が 私の脳 で成長することを望んでおり、LLM の一時的なセッションで成長することを望んでいません。私の思考を他人に説明するために書くことは、その思考を洗練する方法であり、Klein が言うところの「アイデアを出版可能なものに削り出す」ことです。AI に自分のために書かせることは、自分の心を不自由にすることです。