モンスター出現：エージェントが作業を行う際に、私たちは何をまだ知っておく必要があるのか？

モンスター出現：エージェントが作業を行う際に、私たちは何をまだ知っておく必要があるのか？

CIが失敗していました。これは予期せぬことでした。私はエージェントワークフローを、エージェントがテストが失敗するブランチをコミットするとは考えられないほど洗練させてきました。CIの不安定さや環境の問題でしょうか？ いや、SonarQubeがApp.tsxについて文句を言っています。npmから新しい疑わしい依存関係をプルしたのでしょうか？ いいえ。SonarQubeは、このファイルを循環的複雑度でフラグしています。しばらく見ていませんでした。

ええ、App.tsxは約30行のコードで構成されていますが、そのうち15行はCodexが1行ずつ書いたコンポーネント全体です。それ自体は問題ありません。prettierを通せば終わりです。しかし、それだけでは循環的複雑度の説明にはなりません。これらのそれぞれは、かなりの表示ロジックとビジネスロジックを持つ、かなり複雑なコンポーネントでした。以前の私なら、慎重にリファクタリングし、コードが読みやすいことを確認したでしょう。一方、Codexはコンポーネント全体が1行にあることを気にしませんでしたし、それ以上に複雑さを気にしませんでした。それは、いくつかの機能にわたって、幸せに、そして確実にそのファイルを反復処理していました。

CIツールが問題をフラグしていましたが、それは正しい場合も、間違っている場合もありました。しかし、これは実際のシステムなので、調査する必要がありました。ファイルをフォーマットした後、コンポーネントとロジックを検査しました。Codexは、典型的な開発者がエッジケースをカバーする範囲を超えて、それをわずかに過剰に設計したのでしょうか？ はい、しかしそれはすべて正しかったです。私に不満はありませんでした。すべての複雑さはビジネス要件によって正当化されていました。そこで、CodexにSonarQubeを満足させるように指示しました。それは、リファクタリングして10個のファイルに分割することで実現しました。CIはパスし、物は出荷されました。この特定のインシデントは迅速に解決しましたが、もっとひどいことになった可能性を想像できるでしょう。結局のところ、これは私がこれまで見たことのないコードでした。

これが私たちの業界の進むべき道です。ソフトウェアシステムを所有することは、それを（または同様のシステムを）手作業で書いたことよりも、はるかに重要でなくなります。むしろ、最も重要になるのは、間違っているといつ気づくかを知るのに十分な知識を持ち、必要に応じて深く飛び込む意思と能力を持つことです。

ダイブボットと黄金の塊

あなたが船に乗っている（どんな船かはあなたが決めます）と想像してください。あなたの仕事は、海底から小さな金の塊を集めることです。ごく最近まで、金の袋を手に入れるには、水に飛び込み、底まで泳ぎ、あたりを見回し、袋に詰め込む必要がありました。澄んだ浅い水域なら簡単ですが、これがどれほど早く困難になるかは想像できるでしょう。浅い海の鉱山が枯渇し始めたので、あなたと仲間のエンジニアは、ますます深く危険な海から金を抽出するためのあらゆる種類の機械とツールを構築しました。これはほとんどの場合うまくいきました。あなたとあなたのチームは、機械を注意深く組み立て、維持し、ローテーションし、海底の採掘 opérationsを稼働させ続けるために常に潜っていました。時折、採掘 opérationsの崩壊について耳にしました。それは、海底の圧力のためであったり、事故やオペレーターの無能さのためであったりしました。課題は、これが非常に地質学的に活発な世界であるため、海底は常に変化しており、一部の鉱山は枯渇し、新しい鉱山が別の場所に現れることです。

しかし、良いニュースです！ここ数年で、潜水して自分で採掘 opérationsを構築できる、ますます洗練されたダイブボットが開発されています。あなたは彼らにどこに構築するかを指示するだけで、彼らは潜り、更新と金の塊を持って浮上するだけです。素晴らしいです。あなたはダイブボットが仕事をしている間、船でリラックスできます。心配するのは、船にどれだけの金を詰め込めるかだけです。これが楽観主義者の陣営です。

...まで...

「ダイブボットが深すぎて迷子になるまで待て」。「ハハ、君のダイブボットは金のように見えるが、実際は光るタコの糞を持ってきた」。ダイブボットが普及するにつれて、ますます多くのホラーストーリーを目にするようになります。ダイブボットが迷子になり、何を構築すべきだったのかを忘れる。ダイブボットが非常に複雑でグロテスクなものを構築し、それを維持するのが困難になり、次の世代のダイブボットによって破棄される。水中採掘 opérationsはすべて、注意深く設計およびエンジニアリングされた大聖堂から、隠し通路と潜む恐怖を持つ、より無計画な邸宅のようになりました。 opérationsから離れれば離れるほど、失敗はより壮観になります。これが懐疑論者の陣営です。

ここにはモンスターがいる

ソフトウェアエンジニアリング業界（そしておそらく他の多くの業界もすぐに）は、上記のシナリオのバージョンを経験しています。あなたはすでに、楽観主義者と懐疑論者のどちらが自分をよりよく表しているかを知っているでしょう。まだどちらの陣営にコミットしたいか確信が持てなくてもです。

従来の知恵では、非自明なシステムを開発・維持するためには、そのシステムを適切に機能するモデルを持っている必要があるとされています。これに異議を唱える人はほとんどいないでしょう。そしてソフトウェアエンジニアリングでは、コードを直接扱うことでその作業モデルを取得します。長年のコーディングの練習と読書は、あなたが責任を負うシステムを理解するために必要な知識とツールを与えてくれます。すべての本番インシデント、すべての深夜のデバッグセッション、すべての成功したリリース。これらのすべての経験が、システムを所有するために必要な視点を与えてくれます。この投稿の文脈では、所有権とは、何かが壊れたときに呼び出されるのがあなたであることを意味します。

エージェント（ダイブボット）は、これらすべてをひっくり返しています。ダイブボットは、誰かが吸収できるよりも速く出力を生成し、過去の複雑なシステムでは、コードが少なくとも一度は人間の手を経由したと仮定できましたが、それはもはや真実ではありません。経験豊富な実務家がダイブボットのフリートを管理し、過去にはチームが必要だったであろう規模でソフトウェアを作成することが可能になりました。しかし、それはおそらく私たちの業界が直面している最大の課題を露呈しています。次世代のエンジニアをどのように育成するのでしょうか？

極端な場合、楽観主義者と懐疑論者は、この質問に対して全く異なる答えを持っています。一方では、これらのシステムを制御下に置く唯一の方法は、ダイブボットが生成するコードのすべての行を読むことだと言う信頼できる声があります。手でコーディングできること。コードの各部分が何をするのか、そしてそれがアプリケーションのコンテキストにどのように適合するかを説明できること。もう一方の陣営では、コードを見るのは無駄だと言う同様に信頼できる声があります。あなたのエネルギーを何を構築するかを理解することに集中し、どのように構築されているかは忘れてください。モデルがそれを処理します。どちらも正しいとは思いません。

今日のシニアエンジニアが学んだ方法、つまり手作業でのコーディング、終わりのないデバッグ時間、本番インシデントなどを通して学ぶ方法は、ジュニアにとって実行可能な道ではありません。はっきり言っておきますが、経済的に実行可能ではありません。つまり、企業がジュニアに「手作業でやる方法を学ぶ」ために何年もスポンサーになることを望む可能性は非常に低いということです。それは空想です。しばしば提示される代替案は、「エージェントが書いたすべての行を理解するようにする」というアドバイス、または「シニアとペアを組む」、または「慎重なコードレビューを行う」です。再び、数少ないショップを除いて、すべて空想です。業界全体がこれらのプラクティスを採用すると考えるなら、私はあなたに橋を売るつもりです。私に連絡してください。

ある程度の習熟度を達成するための実行可能な道を見つけるために、非自明なソフトウェアシステムを所有することが何を意味するかを見る必要があります。典型的なアーキテクト/リード/CTOがどのように操作するかを考えると、成功するためには、彼らはシステムのマインドマップ、海のチャートを持っている必要があることが明らかになります。本当の質問は、どのレベルの粒度でですか？ 100万行のレガシーコードベースを想像してください。それは長年にわたって多くの人々によって書かれ、拡張されてきました。CTOでさえ一部を書いたかもしれません。そして、本番の問題が発生し、あなたは午前2時に異なるタイムゾーンの人々から怒りのテキストメッセージを受け取りながら、それを理解しようとしている不運なSREだと想像してください。どのようなシステムのチャートが必要ですか？ あなたはシステム全体の高レベルで遠い地図を必要とし、どこに飛び込む必要があるか、モンスターがどこに住んでいるかを知るのに十分な知識を持っている必要があります。そして、未知のコードベースに飛び込み、何が起こっているかを理解し、ホットフィックスをプッシュし、インシデントレポートで何が起こったかを明確に説明できる必要があります。

これはシステム全体の詳細な知識ではないことに注意してください。複雑なシステムを管理できる唯一の方法は、抽象化を構築することです。各レイヤーはさらに構築することを可能にしますが、どのような地図を持っていても、それはすべて下まで抽象化であり、誰もすべてのレイヤーを本当に理解していないことを覚えておくことが重要です。「モジュールXを書いたことがあり、それを隅々まで知っている」と「システムの抽象化の適切なモデルを持っており、どのモジュールにも飛び込んで壊れたときに修正できる」の間には大きな違いがあります。手作業でのコーディングは前者を与えてくれますが、システムの所有者、つまり呼び出される人は後者が必要です。

では、この絵はどうやって描かれるのでしょうか？ そして、ダイブボットが台無しにしたものを修正するために、未知の海に飛び込むことが誰かに期待できるでしょうか？彼らが金の塊を一度も手作業で採掘したことがないなら？

基礎、幅、およびジャストインタイムな深さ

複雑なシステムにおける最も陰湿な障害のいくつかは、静かな障害です。物事がほとんど機能するが、システムに何かがおかしいという種類のもの。おそらく、突然遅くなった、エラー率が上昇した、またはほとんどの場合完璧に機能するが19回の試行のうち1回だけ失敗する。あなたが午前2時にページングされるほどではありませんが、何かがおかしいという感覚を得る程度には。システムの所有者として、あなたはシステムの障害モードを理解する必要があります。業界として、私たちは人々がこれらの障害を検出し、推論する方法を教えるツールを持っています：基礎知識。そして良いニュースは、私たちが何十年もの間、無意識のうちにCS専攻に教えてきたということです。データ構造とアルゴリズム、ネットワーク、並行性、分散システムなどを指しています。正式な教育から来る必要もありません。これらは自分で読んだり学んだりできるトピックです。

簡単な絵を描くために（あなたがシニアエンジニアなら、ここで我慢してください）、ダイブボットにミッションを送ると想像してください。あなたは浅い水域にいて、金の塊を集めるために水深2mに送ります。4秒で戻ってきて、すべて順調です。次に、4mに送ります。しかし、今回は16秒かかります。それは奇妙です。次のミッションは水深16mで、256秒かかります。あなたは絵を理解しました。何かが明らかに間違っています。コンピュータサイエンスでは、これは二次的複雑性と呼ばれるでしょう。そして、それを認識する最良の方法はおそらく、理論を理解し、そのようなものが存在することを知っていることです。

これにより、所有権の次の柱である幅に到達します。私が仕事をしてきた中で最も成功したエンジニアやエンジニアリングリーダーのほとんどは、技術的なものかどうかにかかわらず、ほとんどすべてのトピックについて議論を続けることができました。彼らは特定の分野の専門家であったかもしれませんが、最も印象的だったのは、異なる分野の一見無関係な概念を引き出し、織り交ぜて問題解決に使用する能力でした。これは海の地図の高レベルなものです。これは、特定の海域が他の海域よりも危険であることを教えてくれます。知識の幅は、「ここに飛び込もう」と言うことを可能にします。そして、はっきりさせておきますが、私は想像できるすべてのドメインでの専門家レベルの知識について話しているのではありません。しかし、何かがおかしいときに何を調べるべきかを知るのに十分なだけです。あなたの海の探検を導くブイです。

誰かが私に「幅をどうやって教えるのですか？すべてを網羅する概論クラスですか？」と尋ねました。私はその時良い答えを持っていませんでした。しかし、もっと考えてみると、これは教えられるものではないようです。「すべて101」というクラスはありません。私たちができる最善のことは、人々が読んだり、探求したり、好奇心を持ったりすることを奨励することです。できるだけ多くの情報を吸収してください。奇妙なインシデント、そして「しまった」と思った瞬間を覚えておいてください。それらがあなたの仕事とどのように関連しているかを考えてください。そして経験を積むにつれて、あなたの日常の経験とあなたの仕事を意識的に結びつける努力をしてください。数年前にランダムなプロジェクトで学んだ知識の断片が、日を救うために現れたことが何度あったか、私は数えきれなくなりました。この経験と幅は積み重なりますが、維持されなければなりません。

所有権の最後の柱は、私がジャストインタイムな深さと呼ぶものです。これは、どんな問題にも飛び込み、それを理解する能力と意欲です。未知の海にいても。檻に入ってサメと泳がなければならないとしても。巨大なイカを通り過ぎてシステムに何が間違っているのかを理解するために、チームを集め、大きくて適切な潜水艦に積み込まなければならないとしても。これは、仕事を完了するために必要なことを何でも学ぶ意欲です。また、ダイブが自分の能力を超えていることを知り、助けを求める必要があるという謙虚さでもあります。すべてのダイブがソロでできるわけではありません。すべてのダイブに価値があるわけではありません。

数ヶ月前、私のエージェントオーケストレーターに取り組んでいたとき、エージェントとサブエージェントの安定性の問題とライフサイクルバグに遭遇していました。私はそれらに何をさせたいかは知っていましたが、それらを構築したダイブボットはかなり無計画にそれを行っており、すべてのバグが一度に帰ってきました。1時間に何度もエージェントがクラッシュするのを画面を見つめながら座っていて、ダイブボット自身がその混乱を修正するのを数回試みた後、私は数年前にKubernetesの本を読んだことを思い出しました（はい、私はオタクです）そして「レベルトリガー状態機械」という言葉が突然私の目の前に現れました。そこで私は、当初意図していたよりも深く、電気工学における「レベルトリガー」の起源にまでダイブしました。私はダイブボットを連れて行き、コアアーキテクチャをゼロから再設計しました。それ以来、非常に安定しています。この成功した書き直しは、私が数年前に読んだ何かを偶然覚えており、仕事を完了するために必要なことを学ぶために飛び込む意欲があったために主に可能になりました。

したがって、あなたは海の高レベルな地図（システム）から始め、それがすべて下まで抽象化の層であることを理解します。そして、それらの抽象化のすべてが漏洩するので、システム所有者としてのあなたの仕事は、どこに飛び込み、どれだけ深く潜るかを知ることです。もはやジェネラリスト対スペシャリスト、あるいは神話上のT字型人材でもありません。

［画像: ［画像: Four skill shapes: specialist (one deep bar), generalist (one wide shallow bar), T-shaped (a wide bar with one deep stem), and owner (a wide bar with many narrow dives of varying depth, the deepest in orange ending in a small submarine).］］

新しい構築方法は、未知の領域に深く潜り込むことができるジェネラリスト、履歴書の詰め込み方ではなく、プレッシャー下で素早く学ぶ人を必要とします。あなたは実際に海のモンスターと戦いながら素早く学ぶ必要があります。私は長年多くの人と面接してきましたが、人々が履歴書に「素早く学ぶ」と書いているとき、私は彼らに複雑なシステムを素早く学ぶ必要があった時のことを話してもらうように尋ねます。どのようにしましたか？ あなたの答えは何でしょうか？

未来の所有者

したがって、基礎知識は学び、幅は集められます。しかし、ジャストインタイムな深さは練習できます。これら3つの柱は、誰かがシステムにおける所有権のシェアを成長させることを可能にします。あなたは浅い水域から始め、ダイブボットを潜らせるかもしれません。あなたはしっかりした基礎知識とまともな幅を持っているので、何かを構築してください。しかし、何かが壊れたときにスーツを着てモンスターと泳ぐ準備をしてください。

将来、広大な水中採掘 opérationsの責任者は誰になるのでしょうか？ 誰も知りませんが、私は上記の3つの柱を使いこなせる個人になると賭けます。それは、ラジオの仕組みを全く知らず、ただ音楽を聴きたいという願望だけで、古いラジオを分解して修理した子供でしょう。たとえすべてを元に戻した後、いくつかの余分なネジが残ったとしてもです。

---