#プロダクト開発

AI がコードを書くのはもう珍しくありません。けれど、その変化を見て「人間の仕事は終わった」と受け取るのは早すぎる、というのが今回の話です。Simon Späti は、問題は AI が出すコードそのものではなく、チームから「なぜそうなっているのか」という理解が抜け落ちていくことだと書いています。速さだけを追う現場ほど、その空洞化は深刻になる。この記事は、AI コーディングの賛否というより、ソフトウェアを誰が理解し、誰が保守するのかを問う内容です。 元記事は、まず「コードを書くことはもう死んだのか」という問いに触れつつ、論点はそこではないと切り出します。著者の見方では、問題は AI がコードを書けることではなく、システム全体や設計の意図を誰も分かっていない状態が広がることです。ある議論のコメントでは、AI は平均的なコードを書ける、そして元のコードベースが平均以下なら、AI はそれを平均程度まで引き上げられるかもしれない、と述べています。ただし著者自身は、そこで終わらないと言います。みんなが Claude に聞くだけになり、計画がなくなっていくからです。 記事の中盤では、急成長するスター

ソフトウェア開発は、冷静に見ればただの業務改善や道具づくりにすぎません。ところが現場に入ると、議論は急に熱を帯び、判断は極端になり、関係者の振る舞いまで少しおかしく見えてくることがあります。今回の元記事は、その妙な変化を「ソフトウェアは人を狂わせる」というかなり強い言い方で説明しています。大げさな比喩に見えますが、開発に関わったことがある人なら、どこか身に覚えがある話ではないでしょうか。 元記事の著者は、ソフトウェアには人の感覚を狂わせる条件がそろっていると見ています。速さ、金、複雑さ、抽象度の高さ、そして方針をいくらでも変えられる自由。これらは単体なら扱えるのに、組み合わさると妙な副作用を生むというわけです。著者は、華やかな名称や図に隠れて見えにくいだけで、世の中の多くのソフトウェアは実際には「フォーム、API endpoint、権限、計算、workflow、database」が並んだ地味なもので、せいぜい queue が足される程度だと述べます。そして辛辣に、結局は「格好のいい spreadsheet にすぎない」と言い切ります。 ただ、つくる過程はそこまで素朴ではありません。ソフ

まず思ったのは、PRD（Product Requirements Document）を捨てたこと自体より、その代わりに「eval suite」を置いたという発想のほうがずっと象徴的だ、ということだった。PRDは人間向けの説明書だけれど、eval suite はモデルや機能を実際に測るためのものだ。AI の会社では、きれいに要件を書き下ろすより、まずどう動くかを定義して測れる形にするほうが、たしかに筋がいいのかもしれない。 ここで面白いのは、これは単なるドキュメント文化の話ではない点だと思う。Anthropic が coding を戦略的優先事項にした、という話も同じ文脈にある。AI のプロダクトは、見た目の機能一覧よりも、どの場面でどれだけ役に立つかが本体になる。そうなると、PRDで「こういう機能を作ります」と書くより、評価用の問題を並べて、期待値を継続的に確かめるほうが、現実に近い。人間の会議で合意したつもりでも、モデルは平気で外してくるからだ。 ただ、少し引っかかるのは、これがすべてのチームにそのまま当てはまる話ではないことだ。eval は強いが、何を測るかを決めるのがそもそも難し