「コードを書くことは今や安い」は、コーディングエージェントがコンピュータにコードを打ち込むコストを劇的に下げたという観察と、その帰結に慣れることこそがエージェント型エンジニアリングのプラクティスを取り入れるうえで最大の課題だという主張を指す。その論旨は、コードは常に高価だった（きれいでテスト済みのコードを数百行生み出すのに、ほとんどの開発者は丸 1 日かそれ以上を要する）というものであり、マクロとミクロの両方のレベルで、非常に多くのエンジニアリング上の習慣がその単一の制約を中心に築かれてきたというものである。
その説明によれば、マクロのレベルでは、組織は高価なコーディング時間を効率的に使えるよう設計、見積もり、計画にかなりの時間を費やし、機能のアイデアを、それがもたらす価値がその時間に見合うかどうかで評価する。ミクロのレベルでは、開発者は同じ基準で日々何百もの判断を下している。リファクタリングに追加の 1 時間をかける価値があるか、ドキュメントを書くべきか、あるエッジケースにテストを書くべきか、デバッグ用インターフェースを正当化できるか、といった判断である。コードを生み出すコストが下がると、どのトレードオフが理にかなっているかについてのこうした直観は揺らぐ。さらに、並列エージェントを動かせるようになったことでその計算はいっそう難しくなる。1 人のエンジニアが、複数の場所で同時に実装、リファクタリング、テスト、ドキュメント作成を進めているかもしれないからである。
用法
この原則には意図的な但し書きが対になっている。新しいコードを届けることはほぼ無料にまで値下がりしたが、良いコードを届けることは依然としてかなり高価だ、というものである。情報源は、良いコードが何を意味するかを列挙している。動くこと。動くことをわかっていること、つまり自分自身と他者に対してそれを確かめる手順を踏んでいること。正しい問題を解決していること。エラーケースを穏当かつ予測可能に扱い、将来の保守担当者にとって十分に情報のあるエラーを出すこと。シンプルかつ最小限で、現在も将来も人間と機械の双方にとって理解しやすいこと。回帰テストスイートとして機能するテストによって守られていること。適切なレベルでドキュメント化され、振る舞いが変わったときにはそのドキュメントも更新されること。設計が将来の変更を受け入れられるようになっていて、YAGNI と、将来の変更を必要以上に難しくしないこととのバランスが取れていること。そして、そのソフトウェアにふさわしい非機能的な品質（アクセシビリティ、テスト容易性、信頼性、セキュリティ、保守性、可観測性、スケーラビリティ、ユーザビリティ）を満たしていること。
コーディングエージェントのツールはこのほとんどに役立つとされるが、プロジェクトが実際に必要とする「良さ」の部分集合について出力が良いものであることを保証するという大きな負担は、それを操る開発者に残される。
適用される場面
この原則は、エージェント型のツールによってコードが安く生み出せるようになった場面すべてに当てはまり、その実践上の帰結は規則ではなく習慣として示されている。「それを作るのはやめておけ、時間をかける価値はない」と直感が告げるたびに、とにかくプロンプトを投げてみること。それも非同期のエージェントセッションで行い、最悪の結果でも、10 分後にトークンを費やす価値がなかったとわかるだけで済むようにすること。
この原則は、試行がほぼ無料になるほど有能なエージェントと、捨てた試行のコストが小さいワークフローを前提としている。明示されている限界は、この安さが当てはまるのは生産であって保証ではないということである。したがって、安いコードを完成した仕事として扱うことは、上記の但し書きが防ごうとしている誤用である。
どの程度確立しているか：情報源はこれを、まだ模索中の原則として提示している。これらのベストプラクティスは業界全体でまだ模索されている最中であり、著者自身もまだ模索中だと述べ、「自分を疑ってみる」という習慣を、確立した助言としてではなく、現時点で得られる最善のものとして示している。これは、その著者自身によるエージェント型エンジニアリングのパターンに関するガイドの 1 章として掲載されている。
関連用語
- エージェント型エンジニアリング — これがその基礎となる原則として示されているプラクティス
- 検証負債 — 生産が保証を上回ることで生じる、レビューされていない作業の蓄積
- レビューのボトルネック — コードを書くことが安くなった後に、残るコストが集中する場所
- 70% 問題 — エージェントが生み出すコードがどこでほぼ無料ではなくなるかについての関連する説明