そうだね。僕は住宅ローンが終わって、少し仕事を選べる余裕があるから、日々ガーデニングしたり、エージェントツールを使って個人的なコーディングプロジェクトに没頭してる。例えば、高性能のOLTPデータベースをゼロから作ったり、全く新しい論理的な永続プログラミング環境を構築したり、ちょっと変わった数学に基づいたシンセサイザーやFPGAソフトプロセッサを作ったり。普通の人がやることだよね。だから、これらのツールが一人の手の中でどれだけのことができるかは知ってる。すごいよ。でも、最低トークンのノルマを設定したり、「スターAIコーダー」と呼ばれる人たちが「コードレビューはしないで」とか「手でコーディングするのをやめて」と言っている話を友達から聞くと、首を振りたくなる。冬に契約の仕事を少しやってみたけど、まあまあだったけど、結局はコードレビューで対立するLLM同士の戦いになって、創業者が毎週末に新しいプロジェクトをコーディングしてた。これらのツールはチームワークや本当のチームソフトウェアエンジニアリングには向いてない。業界が理解するまで、ただ様子を見るつもりだよ。まともに働ける場所は、ゆっくりと言える年配の賢い人たちがいるところだけだと思う。今のところ、オンタリオ州ハミルトンエリアでカットしたルバーブが1束5ドルで売ってるよ。アスパラガスもたくさんある。

いや、ビジュアルやガントチャートは、まさに理解できる「PM用語」だと思う。確かに、C-suiteや投資家がイノベーションのシグナルを出している限り、何も解決しないけど、それも長くは続かないだろうね。

残念だけど、君の言う通りだと思う。こういう投稿を職場でシェアするのも躊躇しちゃうよ。現状に合わないことはあまり受け入れられない感じがするから。

いいえ、コードは実際にはほぼ常に正しい それは私の経験とは違う、特に入力がバグやパフォーマンスの問題のときは。ガイドがないと、頻繁に幻覚を見たり誤診したりする。でも、何をしているかに目を光らせて、正しい方向に押し進めれば、RCAや分析はうまくできて効率を改善することができる。 > 人間の開発者に同じ量の機能/スコープのドキュメントを与えたら、あなたの生産性は急上昇するだろう。人が情報を消化して分析する速さには、機械と比べて限界があると思う。

LLMが最初に出たとき、人々は「Facebookのクローンを作って」みたいに言えばいいと思ってたけど、今はもっと具体的に要求を伝えたり、定義を明確にする必要があるって気づいてきた。それがソフトウェアのボトルネックだった。これは1986年にフレッド・ブルックスが「No Silver Bullets」というクラシックなエッセイの中で「エキスパートシステム」や「自動プログラミング」のセクションで予測していたことだ。彼は、Vibe Codingの核心的な特徴と、今私たちが経験していることを正確に示している。慎重に選ばれたいくつかの領域での初期の成功と、その領域を超えて広がるにつれての合理的だが画期的ではない生産性の向上がある。

今、プロダクトオーナーたちが自分の仕事をLLMに振り分けようとしている。以前は、要求を出す人が曖昧な要求や悪い要求を出していたから、プロセスはうまくいかなかった。彼らはビジネスの意図を理解していなかったり（または不注意だったり）したからね。LLMは、同じ曖昧で悪い要求を受け取って、それを信じられるように見せるだけなんだ。

もっとひどいよ。曖昧な要件は、問題の曖昧な解釈しか生まない。たとえ良い要件を提供しても、結局は曖昧な解釈しか手元にない。将来的にはこういうことが問題にならないって約束されてるけど、実際には全然実現してない。「Facebookのクローンを作れ」っていうのが、エンドユーザーへの曖昧な約束なんだ。現実は、曖昧な解釈から生まれる多くの仮定に繋がって、最終的には成功を主張するために要件を変更しなきゃいけなくなる。だから、すべてが妥協の産物になっちゃう。市場に出せる製品を作るための特別な結果はない。どこにでも死体が転がってる。要件を定義して実装するためには、この技術よりももっと良いものが必要だよ。

さらに悪いのは、人間のソフトウェアチームと関わると、曖昧な要件は（少なくともうまく運営されている組織では）さらなる具体化を求められることだ。「『データを取得する』ってどういう意味？」みたいにね。でもLLMは「もちろん！データを取得してユーザーに渡す完全に実装されたコードをどうぞ。」って言って終わりなんだ。

プロダクトの人たちはLLMが大好きだよ。なぜなら「Xはどういう意味？どうやって機能するの？」って質問しないから。プログラマーは、すべてのケースについて聞くけどね。