ほとんどの人は狩りをしたり、火を起こしたり、食べ物を育てたりする方法を知らないよね。もし全てのスーパーやレストランが長期間食べ物を売り切れたら、人々は飢え死にするだろう。でも、実際にはそんなことは起こらない。なぜなら、スーパーやレストランがたくさんあって、供給チェーンもいろんな場所から調達しているから、冗長で分散型の性質があるから問題にならないんだ。だから、自分で食べ物を作るのも同じこと。結局、ロボットやフードレプリケーターが十分にあれば、食べ物を作る方法を知っていることは関係なくなるよ。壊れても、どこかに必ず見つけられるからね。（注：まだそこには至っていないけど）

どの時点で「大丈夫」と「心配」の境界線が引かれるの？君が言ったのは君の視点からのものだと思うけど、みんなが同意するわけじゃないし、主観的だよね。

それは全然違う無知で、もっと危険だよ。なんで？テフロンパンで卵を焼く方法を知らない方が危険なの？それとも石の上で薪の火で焼く方法を知らない方が危険なの？前者を知っていて後者を知らないのは許されるの？テフロン業者に依存しないために、材料科学を理解する必要があるの？

開発者の平均在職期間は長い間2.5年だったし、チームを変える開発者も多かった。AIが登場する前から、多くの開発者は自分がメンテナンスするために呼ばれたコードがどう動くかを理解していなかった。 > 私の英語の指示は、何の成長も残さない。私は何も学ばず、下に何があるのかも知らない。私はなぜ存在するべきなのか？Claudeコードを使うときは、何をどうするかを更新するマークダウンファイルを維持するように言ってみて。単に「$yをやれ」じゃなくて、「$xのために$yをやる必要がある」とかね。マークダウンファイルが更新されれば、それが記録されて、エージェントが正しいコードを出して変更を加えることがあるよ。考えてもみなかったユースケースもね。そしたら「なぜ$yをしたの？」って聞けるし、予想外でも、ああ、正しかったんだなってなる。 > 私はなぜ存在するべきなのか？それは間違った質問で、正しい質問は「なぜ私の雇用主は私に給料を払っているのか？」だよ。雇用主は、明確に定義された要件を働くコードに変えるために給料を払っている。お金を稼ぐためか、あるいはお金を節約するためにね。もしあなたが中堅のチケットテイカーなら、それがあなたの役割だよ。タイトルに関係なく、誰もあなたがforループを使うかwhileループを使うかなんて気にしない。高いレベルでは、あなたは自分の$n年の経験を使って、より曖昧で影響力のある大規模なプロジェクトを、期限通りに、予算内で、要件を満たす実装に変える責任がある。LLMが登場する前は、自分のコーディング、チームを組むこと、そしてディレクターやCTOに「これは社内でやるべきことじゃない」と伝えることが求められた。今は、そのリソースの間にコーディングエージェントが加わっている。いずれにせよ、チケットテイカー以上の立場の私は、まずコードの行を見ていないだろう。機能要件と非機能要件を満たしているかをテストして、主にホットスポット、つまり同時実行の問題、セキュリティの問題、そして明らかなスケーラビリティの問題を見て、実際のトラフィック、ウェブリクエストやETLジョブのトランザクションで叩く前に確認するんだ。パールを握りしめる前に言っておくけど、私は80年代にアセンブリを趣味で始めて、キャリアの最初の15年はC言語で複数のメインフレームやPC、後にはWindows CEデバイスでビットをいじってたんだ。

もっと「ハンズオフ」じゃなくて、小さな編集を最適化するClaudeコードが欲しいな。例えば、IDEに座って、いくつかの行を選択して、（例えば）Caps Lockを押して音声をアクティブにして、何を調整すべきかを短く言うと、それが次の調整のためにステージされる感じ。例えば「ここに新しいユースケースが必要だから、yをする関数を作ろう」とか。 [関数が現れる] いいね、オブジェクトをそれに接続する必要があるね [クラスを指さす] [LLMが言語サーバーを通じてコードパスを遡って見つけて、情報を渡す] そのUXの主な障害は、応答の速度だと思う。音声認識はほぼ瞬時だけど、その後のコーディングプロンプトは良くなるまでに少し時間がかかるからね。そんなインタラクティブなアプローチは、スピードがあればもっと良く感じるだろうな。残念ながら、誰もLLMのためにマウスと音声の組み合わせをターゲットにしていないみたいだ。これは、さまざまなタイピング関連の問題を抱える人々にとっても素晴らしいアクセシビリティツールになるだろう。

理想的なシナリオでは、従業員が交換可能であることが望ましい。組織全体を人質に取るような、代替不可能な個人は必要ないからね。そういう個人から自分を守る方法の一つは、全てのメンバーが他の人の役割を取れるだけの知識を持つことを確保することだ。少しのトレーニングの後でもね。問題は、高いレベルの能力と透明性を維持するのは非常にコストがかかることだ。もう一つの解決策は、組織が完全に混乱していて、誰も何をしているのかわからない状態になることだ。そうすると、組織は非効率的になるけど、その非効率は全体の観点から見ると安く済むかもしれない。

皮肉なことに、「オーナーシップ」はよくある管理の話題だけど、実際にオーナーシップを取ろうとすると、アクセスの壁や情報不足、一般的な「君はここで何をしているの？」というメンタリティにぶつかる。確かに、一人の人間が全てを知っているわけではないけど、大企業は特に、あなたに何の可視性も与えたがらないように見える。締切を与えられて、残業して必死に間に合わせようとしているのに、その締切があなたが招待されていない会議で延長されたことを発見するのは特にイライラする。さらに悪いことに、「彼は今すごく頑張っているから、元の締切に間に合えば予定よりも早く進むし、間に合わなければ余裕がある」というような暗い管理手法を使っていることもある。もし私が管理の道具として使われることが期待されているなら、私は自分の職務をその通りにこなすだけで、さらに何かをするつもりはない。もしオーナーシップが期待されているなら、少なくともクールな子たちのテーブルに座って、何か関連することを言う機会が必要だよね。

なんか不思議なんだけど、Claudeを使うことで、実際にやろうとしてることにもっと集中できる気がする。プログラミングの30年間、ずっと「ヤクシェービング」に時間を費やしてたんだ… ボイラープレートの設定とか、いつもやらなきゃいけない基本機能の追加、サポートシステムの設定とかね。Claudeを使うと、そういうことがすごく早く終わるから、実際にやりたいことに集中できるし、だからこそ、自分が大事にしてるコア機能を頭の中に保てるんだ。他のプロジェクトで共通する部分をやるために、コアで新しい部分を脇に置く必要がなくなる。