なぜ2026年にコードを書くのか

私たちの仕事は、ソフトウェアだけでなく、ソフトウェア工場を構築することです。 ソフトウェアエンジニアは、誰でも変更をプロンプトで指示し、すぐにデプロイできるアセンブリラインを維持します。 私たちは、エージェントを成功させるインフラストラクチャをセットアップします。 プロンプト（スキル、AGENTS.md、ナレッジベースなど）を通じて積極的に行動します。 自動化された評価（テスト、リンティング、型システム、評価、その他のAIなど）を通じてソフトウェアを防御的に保護します。 これらすべてがエージェントを軌道に乗せます。 新鮮なコンテキストを持つ、たとえ愚かなモデルであっても、これらの制約の中で機能し、十分に良い変更を生成できます。 コードを見ることは、もはやばかげているようにさえ思えます。そして、コードを書きたいと思うことは、間違いなく笑い話です。 私は同意しません。コードを書くことは依然として有用です。 Fableのような知能があっても、人間はコードを書くことから価値を得ます。 エージェントが人間よりもコーディングが劣っているからではありません。 しかし、英語を介してプロキシされるのではなく、実行環境で直接考えるためです。 それは注意と理解に関するものです。 私の注意を維持するために、遠くからエージェントの受動的な観察者のように「コードを読む」を超えなければなりません。 システムのアーキテクチャと真に接続するには、コードを実際に体験することが役立ちます。 私はあなたの平坦な2次元の差分とパッチのシステムを望んでいません。 時折、私は下腹部にペインセンサーを取り付けた、完全な4DXバーチャルリアリティ体験を必要とします。何が起こっているのかを体験するために。 そしていいえ、これは「コードがきれいではない」からではありません。それは脆弱性を体験することです。 このコードの上に何かを壊さずに構築するのが難しい場合、エージェントがそれを理解するのはさらに難しくなります。 きれいにし、アーキテクチャに関する一貫した原則を文書化できれば、例外が半ダースもなく、ソフトウェア工場はよりうまく機能します。 デバッグし、テスト戦略が弱い場所を見つけ、修正を見つけることができれば、まったく新しいクラスのバグを潰すことができます。 ええ、あなたはコードを書かずにそれを行うことができます。 私はあなたに説教したり、「スロップキティ」と呼んだり、ソフトウェアを真に体験する唯一の方法は、磁化された針と安定した手にあると言ったりしません。 私もAI精神病に感染しています。 私のコードの大部分はAIによって生成されています。 それにもかかわらず、私はコードを書くことを有用なツールだと考えています。 私は他の人にもそうすることをお勧めします。 私は逆ケンタウロスであるだけのとき、注意を払うのに苦労します。 コードを読み、承認するとき、私は観察します。 遠くからエージェントを眺めているのと同じ所有感覚はありません。 スロップはレーダーの下を通り抜けます。 マイクロ調整が難しくなります。 そして長期的には、スロップはエージェントにも害を及ぼします。 私たちが細部に注意を払っていないために、脆弱性はまさに蓄積します。 一方で、人間がいくつかの作業を行い、アプローチをスパイクし、その後エージェントがパターンを刻印すると、私は参加し、結果を所有します。 コードを書くことは、私が考えるのを助けます。 英語は過度に指定されていない言語です。 計算を表現する正確な方法ではありません。 真にアルゴリズム的な作業のために、私は実行可能なステップでスケッチして考えたいです。 私は調整された精度の度合いを望んでいます。 時には、巨大な設計空間を持つ低レベル言語で。 時には、より限定された計算環境を持つ高レベル言語で。 代わりに、コーディングエージェントがコンパイラのようなものであるという間違った考え方に切り替えています。 その考え方は、ひどく書かれたコードをデプロイすることを許可します。 エージェントはコンパイラではありません。彼らは新しくオンボーディングされたインターンに似ています。 彼らは部分的で、おそらくスロップ化されたコードを読み、変更の不正確な説明を取り、変更を生成しなければなりません。 人間は、インターンの軍隊に思考と味覚を委ねることはできません。 そして、消費者の代わりにハンズオンであることは役立ちます。 例えば、エージェントがボーイスカウトルールに従うのを見たことがありますか？ コードを見つけたときよりも良く残すというルールです。 そして、彼らにそれを試してほしいと思いますか？ エージェントは、現在の変更を可能な限り安全に行うようにバイアスがかかっています。 以前のコードベースで、ある朝、カフェインを摂取する前に、私の肉脳がブラウザのローカルストレージの使用を言及した状況がありました。 そのため、一部のランダムな状態がローカルストレージで管理されていました。 それ以外はすべてバックエンドデータベースを介していました。 コードを見たとき、この愚かな人間の間違いを維持するためのラップと間接的な処理の量は、おそらく行数を3倍にしました。 エージェントは、非常に保守的であることによって、私たちの一度きりの悪い決定を増幅することができます。 コードを削除し、探索することによって、英語を介してこれをプロキシしようとするよりも、より良いアーキテクチャに到達することができました。 私の思考、私の著作権、私のファクターを導く能力は、コードを気にかけることによって大幅に増幅されました。 ソフトウェア工場を構築している場合、細部は重要です。 アーキテクチャパターンを確立する詳細。 アルゴリズムとパフォーマンスまで。 エージェントは、私たちに評価、測定、保護を促します。 彼らは、CIをサイドプロジェクトに早期に、後からではなく追加することをクールにしました。 それはソフトウェアの状態に対する巨大な改善です。 しかし、どんなアセンブリラインにも弱点があります。 時折、自動車工場で、アセンブリラインを分解する必要がある場合があります。 または、内燃エンジンの詳細を掘り下げて10％の改善を行う場合。 または、フィールドの特定の問題が早期に検出されない理由を理解するために、ブレーキパッドのテストを1日観察する場合。 私たちは、工場の全体像を頭に入れながら、それを行う必要はありません。 私たちは、微細な詳細と大きな絵をつなぎます。 ソフトウェアで触れることができるものに任意の境界を描くことは、その取り組みの妨げになります。 5月18日からトレーニングコース形式でsoftwaredougをお楽しみください！ こちらからサインアップしてください - http://maven.com/softwaredoug/cheat-at-search エージェントで検索を使用する方法、より良いRAGを構築する方法、クエリ理解でLLMを使用する方法を学ぶために、Cheat at Search with Agentsにぜひご参加ください。 Doug Turnbull Dougからのその他の情報 Twitter | LinkedIn | Newsletter | Bsky