2026年に、なぜコードを書くのか
(softwaredoug.com)- ソフトウェアエンジニアの役割は、コードを書くことを超えてソフトウェアファクトリーを構築・維持することへと広がったが、システムを理解し改善するには、今なお自分でコードを扱う必要がある
- プロンプト、
AGENTS.md、ナレッジベースでエージェントを導き、テスト、リンティング、型システム、評価で成果を守れば、性能の低いモデルでも十分に実用的な変更を生み出せる - 自分でコーディングすると、英語を介さずに実行環境で考えることができ、受け身のコードレビューだけでは見落としやすい脆弱性・弱いテスト・不要な例外を実感できる
- エージェントはコンパイラよりも新しく加わったインターンに近く、既存コードや不正確な要求に保守的に従い、人間の一度きりのミスまでラッピングや間接層として増幅しかねない
- 人間がまずアプローチを自分で試してパターンを確立し、エージェントにそれを繰り返させることで、当事者意識と判断力を保ちながら自動化の生産性を活用できる
エージェントが働くソフトウェアファクトリー
- ソフトウェアエンジニアはソフトウェアそのものだけでなく、誰でも変更をプロンプトで依頼し、すぐにデプロイできるようにする組立ラインも維持する
- プロンプト、スキル、
AGENTS.md、ナレッジベースを通じて、エージェントが成功できるインフラを先回りして整える - テスト、リンティング、型システム、評価、他のAIを活用した自動評価によって、結果を事後的に保護する
- プロンプト、スキル、
- 十分な制約と最新のコンテキストを与えれば、知能の低いモデルでも逸脱せずに実用的な変更を作れるため、人間がコードを読んだり直接書いたりする必要はないようにも見える
- しかし、Fableレベルの知能を持つエージェントがいたとしても、直接コーディングすることは、英語という中間層なしに実行環境で直接考えることを可能にする
- エージェントが作ったdiffやパッチを受け身で読むだけでは、システムアーキテクチャと深く結びつくのは難しい
- コードを自分で扱えば、その上に機能を追加したとき何が壊れるのかを実感できる
- コードを整理し、例外が継ぎ足されない一貫したアーキテクチャ原則を文書化すれば、ソフトウェアファクトリーもより安定して動作する
- デバッグの過程でテスト戦略の弱点を見つけて直せば、新しい種類のバグ全体を防げる
- 直接コーディングすることだけがソフトウェアを理解する唯一の方法ではなく、磁化された針とぶれない手のように極端な手作業に固執する必要もない
- 実際のコードの大半をAIが生成するとしても、直接コーディングは依然として有用な手段であり続ける
直接コーディングで守る思考力と当事者意識
- コードを読んで承認するだけの逆向きケンタウロスの役割にとどまると、集中力と当事者意識が落ち、低品質なコードがレビューを通りやすくなり、細かな調整も難しくなる
- 細部に注意を払わなければ脆弱性が蓄積し、長期的には低品質コードがエージェントにも悪影響を与える
- 人間がまずアプローチを自分で試したうえで、エージェントに確立されたパターンを繰り返させれば、結果に継続的に関与し、所有できる
- 英語は計算を精密に表すには仕様性の足りない言語である
- アルゴリズム作業では、実行可能なステップとして構想し、考える必要がある
- 状況に応じて、設計空間の大きい低水準言語や、計算環境がより制約された高水準言語を選び、必要な精度を調整できる
- コーディングエージェントをコンパイラのように扱うと、ひどく書かれたコードでもデプロイしてよいという態度につながりかねない
- エージェントはコンパイラよりも新しく入ったインターンに近い
- 不完全で品質の低い可能性がある既存コードを読み、不正確な変更説明をもとに新しい変更を生成する
- 人間はインターン集団に思考や嗜好をそのまま委ねることはできないので、消費者にとどまらず自ら関与すべきだ
- エージェントは、見つけたときより良い状態でコードを残すボーイスカウト・ルールを自発的に守るのが難しく、それを任せるのも気が重い
- 現在の変更をできるだけ安全にする方向に偏り、既存の判断を保守的に温存する
- あるコードベースで、人間が何気なく一部の状態にブラウザのローカルストレージを使ったところ、他の状態はバックエンドのデータベースに保存しているにもかかわらず、エージェントがその判断を維持しようとしてラッピングや間接層を追加し、コード行数が約3倍に増えた
- こうした保守性は、人間が一度だけ下した誤った判断を増幅しうる
- コードを自分で削除し、探索する過程は、英語だけで指示するよりも、より良いアーキテクチャに到達する助けになる
- コードに注意を払うほど、思考力、作者としての感覚、ソフトウェアファクトリーを導く能力が強まる
- ソフトウェアファクトリーでは、アーキテクチャパターンからアルゴリズムや性能まで、細部が重要である
- エージェントは評価・計測・保護装置の必要性を高め、個人プロジェクトでもCIを後回しではなく初期から追加するよう促した
- その結果、ソフトウェア開発の状態は大きく改善したが、どんな組立ラインにも依然として弱点は残る
- 自動車工場でも、組立ラインを分解したり、内燃機関の細部を掘り下げて10%改善したり、現場の問題を早期に発見できなかった理由を探るために一日中ブレーキパッドのテストを観察したりしなければならないことがある
- ソフトウェアでも、細部と全体構造を結びつけるには、何を自分で扱えるかに恣意的な境界を引くべきではない
4件のコメント
私がコードを書く瞬間は、何か問題が起きたときだが
そのときも自分で直接やるというよりは
今後そうした問題が起きないようにハーネスを修正するので
コードを書く機会がだんだん減っている
思考力とオーナーシップに共感します…
トークンの値がないからです…
Hacker Newsの意見
コードを書けなければレビューもできないのは自明に思えるが、Claudeが書いてCodexがレビューすればよいという人や会社がある。それでもアセンブリやコンパイル済みバイナリではなく、PythonやJavaのような高級言語で成果物を求める理由は、結局のところ 人間がコードを読める必要があるから
開発者にコードを読んでデバッグし推論することを期待しながら、その能力を育てる訓練は与えたくないという態度は矛盾している
あらゆる創作をLLMに任せながら業界が発展し続けられるのかは疑問
どちらが優れているという意味ではなく、細部をあまり重視しない人が世界を動かすこともあるし、問題ごとに必要な精密さの度合いが違うのかもしれない
コンパイラは、LLMが実際にコンパイル・実行されるコードを書くのを助けるが、機械語を直接出力するとそもそも実行不能である可能性が高い。もちろん、コードをまったく書けないならレビューははるかに難しい
「プログラムを生成できるほど包括的で正確なプロジェクト仕様を業界では何と呼ぶか？ コード と呼ぶ」 — CommitStrip
きちんと書かれていれば、コードの核心は基盤となるビジネスロジックをもっとも単純に表現しているはず。支援レイヤーまですべてレビューする必要はないかもしれないが、コードを読んでいないならビジネスロジックを完全に理解したとは言いにくい
https://softwaredoug.com/blog/2026/07/04/write-code-not-specs
重要な問いは、誰が手書きコードに金を払うのかということ。顧客はコードを書くことや生成すること自体ではなく 問題解決 に金を払うので、もっとも低コストで騒ぎも少なく解決する側が仕事を取るし、AIツールが日程を圧縮してくれる利点は無視しがたい
1990年代からこの業界にいるが、優れていない開発者が平凡な成果物を作ることは昔から多かった。手作業のコードを過度にロマン化しがちだが、実際のコードベースは時間とともに保守しにくくなり、バグだらけになりやすかったし、雑に進められたプロジェクトもまったく新しい現象ではない
今は両手を縛られたままソフトウェア工場を建てようとしているようなもの
集中して理解するには、エージェントを遠くから見守りながらコードを受動的に読むだけでは足りず、自分でコードを体験する必要がある。結局のところ 自分のメンタルモデルを鍛えなければならない ということ
コーディングしているとき、無意識は「これは正しい感じがする」といった判断を数多く下しているが、これは反復と深い集中によってしか養われず、コードレビューや文書を読むだけでは限界がある。こうして形成されたメンタルモデルがあれば、運用障害のエラーメッセージを見るだけで原因を即座に突き止められるが、生成されたコードでは遅い意識的思考で長く探すことになる
LLMが本当に有用であるためには、コード保守全体を引き受けて外部ライブラリのように振る舞うと仮定できなければならず、そうでなければ問題は起き続けるしかない
まだどちらが正しいのかは分からず、さらに調べているところ
2026年になっても AI生成コードは依然としてひどい。Fableであれ、カスタムのPi/opencode LeetCodeハーネスであれ、成果物はひどいもので、自分のコードとAIコードの品質差を見分けられないならよくない知らせがある
エージェントがボーイスカウト・ルールに従うよう、プロファイル実行、コードカバレッジ確認、批判的レビュー、レポートと後続作業の作成をルールに明記しておいた。一緒に働いてきた人の90%よりも、今日の最先端LLMのほうがこうしたルールをはるかによく守るのに、これを悪いことだと言うべきなのか疑問
エージェントは保守的なので、人間の一度きりのミスを増幅しかねない。これを解決する方法は多く、人によって考え方も違うため、コードを読まないやり方も直接読んで書くやり方もあり得るが、LLMを介さないコードの精密さから得られる利点も大きい
自分がコードを直接書かなければならない理由は、そうしないとLLMがコードを作りすぎるから。問題を完全に理解して一般化しないと、「Hello World」に1万行と抽象化レイヤー5つがぶら下がるのを防げない
LLMはトークン予測器なので、解くべき問題が多いほど出力するコードトークンも増える傾向がある
解くべき問題を抱えている当事者は人間なので、問題を理解しなければLLMが実際の要求と無関係な問題を解くX/Y問題が起こりうる。LLMはライブラリや高級言語のような本質ではない要素をよりよく抽象化するが、問題の核心は依然として形式的に表現しなければならない
制約を一つずつ追加して望む結果に到達するバイブコーディングも、結局は緩く非形式的なプログラミングである。LLMには問題の周辺部を任せ、核心は自分で書いて理解するほうがよい
表面上は要求を完璧に満たしていたが、不必要で雑なコードだった。従量課金のトークンを売る会社には、問題を雑に解きつつできるだけ多くのトークンを消費するルーブ・ゴールドバーグ的な解法を作る経済的インセンティブがあり、生成時だけでなく、新たなバグが混ざった巨大なコードを後で扱うときにもさらに多くのトークンを使うことになる
コピペコードを嘲笑していた人たちが、今では雑に継ぎはぎしたコードには熱狂しているのが滑稽
2022年11月のChatGPT 3.5から現在までの進歩を見ると、4年後もコードレビューをしているのか疑わしい。AI極論者でなくても、現在の速度が維持されるなら5〜10年後には、今日の形のソフトウェアエンジニアリングと開発が消える可能性は高い
人間にはUI設計くらいしか残らず、残りはすべて抽象化されてAIが実作業を処理するようになるかもしれない
Webはすでに十分ひどいのだから、せめて今くらいは無能な人間を責められる状況でいてほしい
KPIの圧力とは無関係に、機会があるたび自分でコードを書き、AIにはより賢いコード自動補完くらいしか期待していない
コーディングが好きで、本当に幸せになれるから自分でコードを書く。好きなことを手放す理由がない