エージェント型エンジニアリングは、単に私たちがこれまでやってこなかったことのすべてである

いつものように、ここでの見解は私の個人的なものです。この記事では、エージェント型エンジニアリングを採用することを推奨しているわけではありません。あなたがそれを試すことを選んだか、あるいは誰かがあなたのためにそれを決定したと仮定します。マット・レバインはしばしば、仮想通貨が第一原理から現代金融を再発見していることについて書いています[1]。同様に、人々がエージェント型エンジニアリングを改善するアプローチに興奮しているとき、私は彼らが単に私たちがすでにソフトウェアエンジニアとして持っているべき実践について話しているに過ぎないと考えずにはいられません。私たちが時間的圧力のために通常カットしてしまう仕事の種類です。典型的な例は、変更に関する詳細を整理し、要件を記述するために課題追跡ツールを使用することです。そうすれば、その作業をエージェントに引き継ぐことができます。そのようにして、エージェントは質問とともに課題にコメントし、作業中にステータスを更新できます。これは単なる通常のソフトウェアエンジニアリングです。 さらにいくつかの例を挙げます。 メソッドのドキュメンテーション文字列。 説明的なプルリクエスト。 ドキュメントを最新の状態に保つ、あるいはそもそもドキュメントを書くこと。 意味のあるテストを書く、あるいは単にテストを持つこと。 一貫性を確保するための自動リンティング、あるいは単に合意されたコード規約を持つこと。 実装前に設計の計画、アーキテクチャ設計、フィードバックの受け取り。 会議の議事録を記録し、決定されたことについて全員が合意したことを確認すること。 DMのみを送信するのではなく、オープンで検索可能なチャネルで会話を行うこと。 繰り返しになりますが、これらはすべて通常のソフトウェアエンジニアリングの実践です。人々が今、それらを行うことに興奮しているのを見て安心しています。エージェント型エンジニアリングがその変化を促すために必要だったことに、ただ落胆しているだけです。なぜ私たちは、私たち自身よりもボットに高い基準を課しているのでしょうか？ 同僚が最近こう言いました。「プリンシプルの指針に関するコンテキストの欠落に気づいたPRをレビューしました。将来、他のエンジニアのエージェントがそれらを尊重するように、それらの原則をエンコードするためにドキュメントに変更を加えています。このような場合、以前にもドキュメントを更新できたはずですが、現実的にはあまり効果がなかったでしょう。チーム全体と話し合い、全員がそれを記憶していることを確認する必要があったでしょう。今では、適切なドキュメント構造により、すべてのエンジニアのエージェントがドキュメントを読み、それに従うでしょう。」 ソフトウェアエンジニアは、古くから自分たちの作業を自動化してきました。CIでコードフォーマットチェックがあることに腹を立てているわけではありません。自動化の線引きをしたいのであれば、ジェームズ・C・スコットの「Stateのように見る」にあるmētis（メティス）に目を向けたいと思います。「mētisは、類似しているがめったに同じではないタスクで長年の実践を通じてのみ獲得できる知識の一種として理解されるべきであり、変化する状況への絶え間ない適応を必要とします…具体的な状況で経験則をいつ、どのように適用するかを知ることが、mētisの本質です。」mētisは常に特定の状況にローカルです。コード構文は、よく記述された人間の構築物です[2]。他のエンジニアリング原則は自由形式であり、処方して読解可能にするのが難しくなります。これらのルールの書面形式は、特定の課題のニュアンスを扱う際には常に柔軟性が低くなります。書面によるルールは判断ではありません。確かに、凍結された読解可能なシステムは、何もないよりは良いです。 そもそも、プログラミングは一般的に sucks[3]（ sucks はここでは「 sucks 」とカタカナ表記または原語のまま残すのが適切ですが、文脈から「 sucks 」は「 sucks 」と訳すのが適切です。ここでは「 sucks 」と訳します）ということを忘れないでください。AIツールを適用するのに苦労している会社にいる友人から、エージェントの出力の多くを捨てなければならなかったと聞きました。「依存関係の1つに変更が加えられ、スプリントの途中でコミュニケーションなしに行われたため、小さなリファクタリングを行う必要がありました。」もし「エージェント型エンジニアリングが単なるロボットを使った通常のエンジニアリングである」ならば、私も同様の推論があります。エンジニアリングをより困難にするものは、エージェント型エンジニアリングをはるかに困難にします。エージェントは、人間のように状況をナビゲートするmētisを持っていません。もしエージェント型エンジニアリングで苦労しているなら、立ち止まって、あなたの会社では通常のソフトウェアエンジニアリングも同様に難しいかどうか考えてみてください。機能不全のシステムにAIを貼り付けても、それが人であれソフトウェアであれ、あなたの問題を解決することはありません。1975年以来、私たちは遅れているプロジェクトに人を追加しても、さらに遅れることを知っています。偽の人間を追加しても、何も変わりません。同じ間違いを繰り返すだけでなく。 ↩︎ 言語によって異なりますが、組織としてスタイル規約のセットに合意できることが重要です。 ↩︎ 大学3年生の時にこの文章を読んで、「まあ、私の残りの人生はこんな感じになるのだろうな」と思ったのを覚えています。12年経った今でも正確です。 ↩︎ YouTubeの新しいプログラムは、一気見を促進します YouTubeは、テレビで視聴するあらゆるものになろうとしています。幸いなことに、まだ選択する方法があります。少なくとも今のところは。07 Aug Thundermail、Tuta、そしてLavabitを思い出す あなたのメールプロバイダーの選択はどれほど重要ですか？ある意味では、個人としてはあまり重要ではありません。しかし、私たちの選択が一緒になれば、それは重要になります。そこで、Lavabitの使用と、TutaやThundermailのような今日の選択肢を回想します。10 Jul 終わらせるつもりのなかったプロジェクトを復活させるためにコーディング支援ツールを使用しても大丈夫です YouTube Musicとopensubsonicの間のコネクタを実装するために、Claude CodeとOpus 4.6を使用してみました。結果として、比較的短時間で動作するプロジェクトを得ることができました。23 Apr Claudeのコーディングの雰囲気は悪化しています 過去2ヶ月間、Claude CodeのUXが継続的に低下しているのを見てきました。Opus 4.7のリリースにより、それは本当に明白になりました。16 Apr Googleで良いサポート体験をするところでした Googleのサポートは健全ではありません。実際、決して良くはありませんでした。ボストンにある実店舗のスタッフは素晴らしかったですが、Pixel 9 Pro Foldが壊れたとき、他のサポートは本当に失敗しました。23 Feb