Every
エージェントが作ったソフトウェアを「磨く」という仕事
要点
- エージェントが一晩でコードを書き、朝には緑のPRが積まれている時代。残る人間の仕事は「これは本当に良いか」を判断し、さらに押し上げることだと著者は主張する
- Polish（磨き上げ）とは、動いているアプリを自分で使い、「なんか違う」という感覚をエージェントに伝えるループ。コードレビューではなく使用体験のレビュー
- `/ce-polish` コマンドでブランチをチェックアウト→開発サーバー起動→エディタ内でアプリ表示の3ステップを自動化。会話の流れを切らさない環境が質のポイント
- Polishで得た感覚的フィードバックを `/ce-compound` でルール化すると、次のフィーチャーからエージェントがデフォルトでその美意識を適用するようになる（複利構造）
- 「再実装コストがほぼゼロになった今、守るべきものは時間ではなく品質」という役割の転換を明示
編集部の考察
著者が `/ce-compound` と呼ぶ仕組みが核心だ。「なんか違う」という感覚的フィードバックをコマンド1つでルール化し、以降のフィーチャーにエージェントがそのルールをデフォルト適用する——これは「1回の判断が永続的に複利で効く」という構造を意味する。自社の開発チームに置き換えると、AIが大量にPRを積み上げる環境では、ルールベースの質と更新頻度がそのままプロダクト品質の上限になる。問題は、このルールベースを誰が持つかだ。著者の場合は個人の taste だが、10人・100人のチームで同じことをやると、ルールが属人化してキーパーソン依存になるか、逆に形骸化した共有ドキュメントに埋もれる。「compound が効く状態を組織的に維持する」には、polishing で得た判断を誰が・どのタイミングで・どんな形式でルール化するかのプロセス設計が必要になる。エンジニアの評価軸もここで揺らぐ：コード生産量ではなく「質的判断をどれだけルールに昇華したか」を問う評価フレームを持っていないなら、今期中に設計し直す価値がある。
原文より
“Without that final human judgment, everything the agent produces is functional, but forgettable.”
本記事は原文ニュースレターの独自キュレーション・考察であり、翻訳ではありません。引用部分の著作権は原著者に帰属します。