- コードを書くコストが急激に下がった現実が、エンジニアリングの習慣全体を揺さぶっている
- かつてはコード生産が高コストだったため、設計・見積もり・企画を中心とした効率的な開発文化が形成されていた
- コーディングエージェントの登場により、1人の開発者が同時に複数の作業（実装、リファクタリング、テスト、文書化）をこなせるようになった
- しかし、**「良いコード」**を作ることには、依然として高い品質基準と開発者の判断が求められる
- その結果、新しい個人・組織的な開発習慣を築く必要性が浮上している
コード作成コストの変化
- 以前は、数百行のクリーンでテスト済みのコードを書くのに1日以上かかっていた
- そのため開発者は、限られた時間とコストを基準に、機能の価値と優先順位を評価していた
- プロジェクト設計、スケジュール見積もり、機能企画などはすべて、**「コーディング時間の効率的な利用」**を中心に行われていた
- コーディングエージェントの導入により、コード入力のコストが急激に下がり、従来の判断基準が揺らいでいる
- 1人のエンジニアが複数のエージェントを並列実行し、同時多発的な開発作業を進められる
- この変化は、従来の時間対価値の判断構造を見直させるものとなっている
依然として高価な「良いコード」
- 新しいコードを生み出すことは、ほぼ無料に近くなったが、**「良いコード」**を作ることには依然として大きなコストがかかる
- 良いコードの条件は次のとおり
- 正確に動作し、バグなく目的を達成する
- 検証プロセスを経て、そのコードが信頼できることを証明する
- 適切な問題解決に焦点を当て、エラー状況を予測可能な形で処理する
- 単純で最小限の構造を保ち、保守性と理解しやすさを高める
- テストとドキュメントが最新の状態に保たれていること
- 将来の変更可能性を考慮しつつ、不必要な複雑さを追加しない
- アクセシビリティ、セキュリティ、拡張性、保守性などの非機能品質特性を満たす
- コーディングエージェントはこのプロセスの一部を支援できるが、最終的な品質保証の責任は開発者にある
新しい開発習慣の必要性
- **エージェントベースのエンジニアリング（agentic engineering）**環境では、従来の開発習慣はもはや有効ではない
- 個人も組織も、新しい業務の進め方と判断基準を形作る必要がある
- 現在、業界全体でこうしたベストプラクティスが整備されつつある
- 提案されているアプローチは、「時間がもったいない」と感じる瞬間でも、非同期のエージェントセッションを動かして実験してみること
- 最悪の場合でも、10分後に確認してトークンの無駄遣いで終わるだけである
Agentic Engineering Patternsガイドにおける位置づけ
1件のコメント
Hacker Newsの意見
「コードは常に高価だった」という表現が正しいのかはわからない
実際に高価だったのは コードそのものではなく、その周辺のあらゆるプロセス だった — 正確性の確保、保守、チーム間の調整、長期サポートなどが本当のコスト要因だった
テストや承認手続きを過剰に通すと、むしろプロセスがコストの大半を占めるようになる
LLMは短期的には 動くコードを生成するコスト を大きく下げたが、長期的には保守・セキュリティ・テストの負担が増えるかもしれない
結局、本当に変化が起きたのかは長期データを見ないとわからない
以前は数百行のコードですら作成コストが大きかった
2000年代式のSLOCountツール（WebAssembly版）に256行のJavaScriptを入れてみたら、当時基準で約 $6,461 のコスト見積もりが出た
もちろんその数字はネタ程度に見るべきだが
今は自分で仕事をするというより、自分の仕事を管理する 自分自身のマネージャー に近い
生産性は以前よりおよそ2.5倍になった感覚がある
要件収集、設計、テスト、デプロイ、保守は依然として必要で、コストの大半は 保守段階 で発生する
Amdahlの法則のように、コーディングのコストが0に近づいても他段階のコストが限界になる
問題は、それが人間の本性上難しいという点だ
正確性・保守性・性能 のような品質要素は、経験を通じてのみ身につく隠れたコストだ
「コードは常に高価だった」という主張には同意しない
実際には、「良いコード」を書こうとしていたから高価だったのだ
基準を下げれば生成されたコードは速くて安いが、良いコードに戻すための努力 は依然として同じだ
エージェントコーディングを擁護するなら、別の論理でアプローチすべきだ
自分で書くときは各行の理由を理解しているが、AIが作ったコードは各構文を検証しなければならない
この1か月、大半の作業をエージェントで行ったが、人間なら作らないような エッジケースのバグ が出続けている
結局、レビューコストが大きくなり、短期的な利益が消える
ただ、コーディングエージェントのおかげでそのコストは はるかに下がっている
細かな修正はエージェントが代行するので、より高品質なコードを素早く作れる
複雑性は蓄積するので、最初に書くときに丁寧に扱うのが最も安い
今は短期的な利益が大きいが、長期的にはノイズが10倍に増えるかもしれない
LLMは戦術的プログラミング、つまり素早い機能実装に特化している
だからこそ、システム全体の複雑性管理がより重要になる
コード生成は言われるほど安いが、価値ある結果に変える技術 こそが本当の実力だ
Agentic engineeringは結局、安価な入力を価値ある出力へ導く技術だ
Agentic engineeringは単にソフトウェアを書くことではなく、特定の問題を素早く解決するためのツール作り だ
だが問題解決が終われば、AIそのものは面白くない
多くの人はAI自体を目的にしているが、本当の価値は 問題解決 にある
Alan Wattsの言葉のように、メッセージを受け取ったら電話は切るべきだ
ツールが安くなったからといって価値が自動的に生まれるわけではない
設計と構造化の能力 が本当の価値だ
結局、意思決定の質が核心だ
資金調達は価値の証拠ではない
「コードは常に高価だった」という主張には疑問がある
クリーンでテストされたコードの定義からして曖昧だ
テストをやりすぎるとコストは爆発し、組織的な承認手続き も大きなコスト要因になる
LLMは短期コストを下げるが、長期の保守コストは増やしうる
私がインターン時代にスタートアップで安く働いたことはあるが、障害・データ破損・技術的負債 が積み上がった
見た目は安く見えても、隠れたコストは大きかった
LLMのおかげで今は高品質なコードを安く得られるようにも見えるが、まだ適応中だ
今はv1を作るのは安いが、成熟した製品の複雑な意思決定 は依然として高価だ
ソフトウェアの経済的価値は コードに込められた情報 にある
コードを書くことはその情報をマッピングする過程にすぎず、情報の質が本当の価値を決める
速くコードを書いても情報の質が上がるわけではない
コンサルティングでスライドを素早く作っても価値が生まれないのと同じだ
実装速度が速くなりすぎると、開発者の メンタルモデルがコードとずれていく
関連記事: Cognitive Debt by Simon Willison
リファクタリングを高速に繰り返せたからだ
AIはますます文脈を理解するようになるだろうが、そのぶん人間の判断を手放さなければならない
いつか機械が意図を完全に把握するようになれば、人間はループの外へ追いやられるだろう
あらゆる開発方法論の核心は、要件は常に変わる という事実だ
だから良いコードとは「変更しやすいコード」だ
今のLLMエージェントがそうしたコードを作れるのかは疑わしい
完全に信頼できるようになるまでは、プロトタイプ水準にとどまる気がする
仕様が曖昧なら、テストも価値検証も難しくなる
テストがあっても せいぜい70%くらいの確信 しかない
直接コーディングするより速く、結果も 保守可能なコード として出てくる
クリーンなコードと良い慣行を明示すれば、十分に保守可能な結果になる
結局は Garbage in, garbage out だ
私が書いた記事（The Final Bottleneck）で述べたように、
コードを書く速度は上がったが、その後の段階が追いついていない
単なる習慣の問題ではなく、責任構造・言語設計・システム構造全体 が変わらなければならない
本当に生産性が10倍になっているなら、すでに スタートアップが市場をひっくり返しているはず だ
できるからといって、必ずやるべきとは限らない
AI evals（measure-first-optimize-last, ai-evals.io）のようなアプローチがその方向だ
機能の暴走 は誰も望んでいない
コードの1行1行が 負債（liability） だ
LLMがコードを吐き出す時代には、その負債が爆発的に増える
ツール自体は悪くないが、責任を持たないプログラムがコードベースを書き換える 構造は危険だ
「コードが安い」とは生成が安くなったという意味であって、配布承認コスト は依然として大きい
判断の段階を省けば、生産性向上ではなく 統制の空白（control gap） が生まれる
速いからといってマスターキーを渡すのは危険だ
どちらも安くはなっていない
私もこの意見にはほぼ全面的に同意する
コード作成は安くなったが、レビューと検証のコスト は依然として大きい
特に数百万行規模のモノレポでは、テストしやすさを高めることが核心だ
こうした議論が、Twitterの過熱した空気の中でバランスを取ってくれてありがたく感じる
コード churn は簡単になったが、品質検証 が新たな課題になっている
LLMが作る大量の変更は微妙な失敗を生み、その流れは止まらない
コードは安くない
トークンコスト もあるし、実際のコスト構造はまだ不透明だ
収益のないスタートアップがGPUサプライチェーンを独占している状況なので、データが不足している
LOCが増えるほど負債も増える
思考から実行までの距離は短くなったが、それでもコード自体は責任であることに変わりはない
今は補助金のおかげで安いが、ハードウェア・電力・人件費が下がればさらに安くなるかもしれない