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

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