コードを書くことは今や安価になった
エージェント工学の実践における最大の課題は、コード作成が低コスト化した結果に適応することである。
キーポイント
AIコーディングエージェントにより、コードを書く（生成する）コストが劇的に低下し、従来のソフトウェア開発の前提（コード作成は高コスト）が崩れつつある。
コスト低下の一方で、「良いコード」（動作保証、テスト、ドキュメント、保守性などを含む）を納品するコストは依然として相対的に高く、開発者の意思決定の基準が変容を迫られている。
並列エージェントの活用により、一人のエンジニアが同時に複数の作業（実装、リファクタリング、テスト、ドキュメント作成）を進めることが可能になり、生産性の評価や組織の慣行への影響が大きい。
影響分析・編集コメントを表示
影響分析
この記事は、AIエージェントがもたらす「コード生成の民主化」が、単なる生産性向上ツールではなく、ソフトウェア開発の経済性、プロセス、組織文化の根本的な再考を迫るパラダイムシフトであることを指摘している。開発者個人の意思決定からプロジェクト管理、ビジネス判断に至るまで、従来の「コストが高い」ことを前提に築かれた慣行全体の見直しが必要となる。
編集コメント
「コードを書くこと」の価値定義が変わる転換点。技術者だけでなく、マネージャーやプロダクトオーナーも必読の視点。
コードを書くことは今や安価になった - エージェント型エンジニアリングのパターン - Simon Willison's Weblog Simon Willison’s Weblog
ガイド > エージェント型エンジニアリングのパターン
コードを書くことは今や安価になった
エージェント型エンジニアリングの実践を採用する上で最大の課題は、コードを書くことが今や安価になったという事実の帰結に慣れることです。
コードは常に高価なものでした。数百行のクリーンでテストされたコードを生み出すには、ほとんどのソフトウェア開発者に丸一日以上かかります。私たちのエンジニアリング習慣の多くは、マクロレベルでもミクロレベルでも、この核心的な制約を前提として築かれてきました。
マクロレベルでは、私たちは膨大な時間をプロジェクトの設計、見積もり、計画立案に費やし、高価なコーディング時間を可能な限り効率的に使うことを保証します。製品機能のアイデアは、その時間と引き換えにどれだけの価値を提供できるかという観点で評価されます。機能は、その開発コストを何倍も回収できて初めて価値があるとみなされるのです。
ミクロレベルでは、私たちは一日に数百もの決断を、利用可能な時間と予想されるトレードオフを前提に行っています。もし余分に1時間コーディング時間がかかるなら、あの関数をもう少しエレガントにリファクタリングすべきか？ドキュメントを書くのはどうか？このエッジケースのテストを追加する価値はあるか？これのデバッグインターフェースを構築する正当性はあるか？
コーディングエージェントは、コンピューターにコードを打ち込むコストを劇的に下げます。これは、どのトレードオフが理にかなっているかについての、私たちの既存の個人的・組織的な直感の多くを覆すものです。
並列エージェントを実行する能力は、これをさらに評価しにくくします。なぜなら、一人の人間のエンジニアが、今や同時に複数の場所でコードの実装、リファクタリング、テスト、ドキュメント化を行えるからです。
良いコードには依然としてコストがかかる
新しいコードを届けることの価格は、ほぼ無料まで下がりました...しかし、良いコードを届けることは、それよりも依然としてかなり高価なままです。
私が「良いコード」と言うとき、それは以下のことを意味します：
コードは動作する。バグなく、意図したことを行う。
私たちはコードが動作することを知っている。私たちは、自分自身と他者に対して、コードが目的に適っていることを確認するための手順を踏んでいる。
それは正しい問題を解決する。
エラーケースを適切かつ予測可能に処理する：単なるハッピーパスだけを考慮しない。エラーは、将来のメンテナーが何が間違っていたかを理解するのに十分な情報を提供すべきである。
それはシンプルで最小限である。必要なことだけを、人間と機械の両方が今理解し、将来メンテナンスできる方法で行う。
テストによって保護されている。テストは、それが今動作することを示し、将来静かに壊れることを防ぐための回帰テストスイートとして機能する。
適切なレベルでドキュメント化されており、そのドキュメントはシステムの現在の状態を反映している。コードが既存の動作を変更する場合、既存のドキュメントはそれに合わせて更新される必要がある。
設計は将来の変更を可能にする。YAGNI（必要になるまで作るな）を維持することは重要です。来るかもしれない将来の変更を予期して追加の複雑さを伴うコードは、往々にして悪いコードです。しかし同時に、将来の変更を必要以上に難しくするようなコードを書かないことも重要です。
その他すべての関連する「〜性」、すなわち、アクセシビリティ、テスト容易性、信頼性、セキュリティ、保守性、観測性、拡張性、ユーザビリティ。これらは、開発中の特定のソフトウェアクラスに適した非機能的な品質指標です。
コーディングエージェントツールは、この大部分に役立ちます。しかし、生成されたコードが、現在のプロジェクトに必要な「良さ」のサブセットにおいて良いコードであることを保証するために、それらのツールを駆動する開発者には依然として相当な負担がかかります。
私たちは新しい習慣を築く必要がある
課題は、エージェント型エンジニアリングが提供する可能性と機会に対応する、新しい個人的・組織的な習慣を開発することです。
これらのベストプラクティスは、私たちの業界全体でまだ模索されているところです。私自身もまだそれを模索しています。
今のところ、私たちにできる最善のことは、自分自身を再考することだと思います：私たちの直感が「それは作る価値がない、時間の無駄だ」と言うときはいつでも、とにかくプロンプトを発行してみることです。非同期のエージェントセッションで行えば、最悪でも10分後に確認して、それがトークンの無駄だったとわかるだけのことですから。
原文を表示
Writing code is cheap now - Agentic Engineering Patterns - Simon Willison's Weblog Simon Willison’s Weblog
Guides > Agentic Engineering Patterns
Writing code is cheap now
The biggest challenge in adopting agentic engineering practices is getting comfortable with the consequences of the fact that writing code is cheap now.
Code has always been expensive. Producing a few hundred lines of clean, tested code takes most software developers a full day or more. Many of our engineering habits, at both the macro and micro level, are built around this core constraint.
At the macro level we spend a great deal of time designing, estimating and planning out projects, to ensure that our expensive coding time is spent as efficiently as possible. Product feature ideas are evaluated in terms of how much value they can provide in exchange for that time - a feature needs to earn its development costs many times over to be worthwhile!
At the micro level we make hundreds of decisions a day predicated on available time and anticipated tradeoffs. Should I refactor that function to be slightly more elegant if it adds an extra hour of coding time? How about writing documentation? Is it worth adding a test for this edge case? Can I justify building a debug interface for this?
Coding agents dramatically drop the cost of typing code into the computer, which disrupts so many of our existing personal and organizational intuitions about which trade-offs make sense.
The ability to run parallel agents makes this even harder to evaluate, since one human engineer can now be implementing, refactoring, testing and documenting code in multiple places at the same time.
Good code still has a cost
Delivering new code has dropped in price to almost free... but delivering good code remains significantly more expensive than that.
Here's what I mean by "good code":
The code works. It does what it's meant to do, without bugs.
We know the code works. We've taken steps to confirm to ourselves and to others that the code is fit for purpose.
It solves the right problem.
It handles error cases gracefully and predictably: it doesn't just consider the happy path. Errors should provide enough information to help future maintainers understand what went wrong.
It’s simple and minimal - it does only what’s needed, in a way that both humans and machines can understand now and maintain in the future.
It's protected by tests. The tests show that it works now and act as a regression suite to avoid it quietly breaking in the future.
It's documented at an appropriate level, and that documentation reflects the current state of the system - if the code changes an existing behavior the existing documentation needs to be updated to match.
The design affords future changes. It's important to maintain YAGNI - code with added complexity to anticipate future changes that may never come is often bad code - but it's also important not to write code that makes future changes much harder than they should be.
All of the other relevant "ilities" - accessibility, testability, reliability, security, maintainability, observability, scalability, usability - the non-functional quality measures that are appropriate for the particular class of software being developed.
Coding agent tools can help with most of this, but there is still a substantial burden on the developer driving those tools to ensure that the produced code is good code for the subset of good that's needed for the current project.
We need to build new habits
The challenge is to develop new personal and organizational habits that respond to the affordances and opportunities of agentic engineering.
These best practices are still being figured out across our industry. I'm still figuring them out myself.
For now I think the best we can do is to second guess ourselves: any time our instinct says "don't build that, it's not worth the time" fire off a prompt anyway, in an asynchronous agent session where the worst that can happen is you check ten minutes later and find that it wasn't worth the tokens.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み