ソフトウェアの世界では、優れたエンジニアを管理職に昇進させて、ピーターの法則を加速させているよね。でも、必ずしもそうである必要はない。管理スキルは、管理される側のスキルから派生するものではなく、むしろそれとは直交しているんだ。これは、多くの博士課程の候補者が学ぶ教訓に似ている。自分の分野での専門知識は、教育の専門知識ではない。内部から昇進した企業は、新しい管理者のためにトレーニングを提供していたものだ。

私の経験とも一致する。問題を分解して、簡単に解決できるようにするのがプログラミングで一番楽しんでる部分なんだ。自分でコードを書く量が減るのは全然構わないけど、レビューする量が増えるのはちょっと嫌だな。さて、どうやって人々が悪いプロンプトに基づいてLLMが出したものを盲目的に受け入れる問題を解決するかだね。これは普遍的に当てはまるし、技術的な問題じゃない。

これに関して、あまり話されないことを付け加えたい。プログラミングをしているとき、私は集中力とフローを非常に重視しているんだ。コードアシスタンスは、微妙な方法でそれを壊したり妨げたりすることがある。だから、最近はもっと頻繁にオフにしているんだ。皮肉なことに、アシスタンスを使うことで、小さな非効率や気を散らす要因、悪い習慣、改善の可能性に気づくことができた。これは非常に広い意味で言っていて、マインドセットやツール、メモを取ること、運用化、コードナビゲーション、考える/デザインするからプログラミング/プロトタイピングに切り替えるタイミング、コードの整理など、改善できる小さなことがたくさんある。だから、私はこの発言には根本的に反対だ。> コードを書く技術はほとんど商品化されている (...) ある場合には、フローや高い集中状態に入るための環境を整えてからコードを書くのが非常に効果的だと感じる。プログラムとの結びつきが強くなり、より複雑にどう動くかを理解できるからね。今、私が学ぶべき2つの重要なことは、どのアプローチをいつ使うべきかを認識し、それぞれをより効果的に使うための準備をすることだ。

なんだこれ、コード生成は絶対にボトルネックだよ。実際のプログラミングスキルが不要になったって主張してる人がいたら、ぜひ一緒にバーチャルペアプログラミングセッションをやろうよ。すぐに彼らが中程度の複雑さのコーディングすらできないことを示してあげるから。これがこの論争を解決する唯一の方法だと思う。もし彼らがプロンプトに関する魔法のソースを持ってるなら、他の人が検証できるセッションやチャットを投稿すべきだよ（完全に再現可能でなくてもいいから）。昨日はほとんど一日が無駄になった。主にClaude 4 Sonnetを使って問題に取り組むことにしたから。すべてのステップで手を引いて、基本的なタイプミスや論理エラーを修正し続けて（同じセッション内で以前に修正したものも含めて）、結局、私が出した課題を解決できなかったんだ。皮肉を込めて言うけど、LLMが技術スキルを奪うって叫んでる人たちは、AI企業の株をたくさん持ってるに違いないと思う。

実際、シニアエンジニアがジュニアにタスクを委任して結果をレビューするために必要なスキルは、同じ2つのスキルなんだよね。

これはブログ記事で述べられている問題の狭い見方だね。君はソフトウェアエンジニアの視点から見ているけど、投稿しているウェブサイトを考えると理解できる。だけど、記事は実際にはもっと高いレベルのことに焦点を当てているんだ。つまり、君が分解している問題やレビューしているコードが「良い」か「価値がある」かを判断する能力についてなんだ。Claudeは「問題を分解」したり「コードをレビュー」するのが今より10倍上手くできるかもしれないけど、もしそれが無駄で不格好で、他の人が持っている特性が欠けているせいで悪いものだったら、意味がないんだよね。

「これには、ドメイン、コードベース、そして良いソフトウェアエンジニアリングの原則についての深い理解が必要だね。」ほとんどのAIは最終的にはこれを理解できるけど、ドメインだけは難しいかも。でも、数年後にはソフトウェアエンジニアリングはプロダクトマネジメントに似た感じになると思う。

これでコードを書くのを低賃金の労働に押し付けようとするのは、歴史上少なくとも三回目だね。今回は成功するかどうか見てみよう。問題は、小さな詳細が大きな詳細に影響を与え、それがまた小さな詳細に影響することだ。両方が得意じゃないと、どちらもダメになっちゃうことが多い。

最近のHEPで見かけた「ユーザー」と「専門家」の間の概念を思い出させる。あの区別は本当に馬鹿げていて、理解できない。最初はコードに出会って、慣れていないけど、すぐに問題を解決するために専門家になって進めることになる。どのコードベースから始めようが関係なく、実際のスタックが何をするのか、そこに何が関与しているのかを理解することが大事なんだ。人々は自分が何をしているのかを深く理解するべきだからね。でも、これはすべてのエンティティの「企業化」から来ていて、パフォーマンスを評価するためにランダムな指標が使われている。単純な質問「これが動くのか」「修正が必要なのか」「このものは壊れるのか」を聞く代わりにね。仕事から離れた管理者タイプの人々と、実際に仕事をしている管理者との間には明確な断絶がある。ストレス要因を理解し、システムの深い理解や追加の文脈化が必要なところを把握することが求められるのに、全体を台無しにしないためにはね。とはいえ、これは非常に特異な視点から来ていて、業界標準ではない技術スタックを持っている。

教育って、単に知識や方法を教えるだけじゃなくて、学ぶ力を教えるべきだと思うんだよね。ハードな知識は、結局のところ副産物みたいなもんだから。何もないところからは学べないし、何かを使って学ぶことになる。その何かが最終的にはハードな知識を形成するんだよね。一般的には、広い範囲だけど浅いハードな知識になっちゃう。皮肉なことに、今の共同開発ではその学ぶ力が削られている気がする。組織の短期的な利益のために、特定の技術知識を持った人が求められて、簡単に代替可能なようにされてるんだ。人に依存しないように、プラグアンドプレイの部品みたいにね。組織内では学ぶ能力が価値を持たない。入る前に十分に練習して、入った後は集中的に応用するべきなんだ。進化する組織を主張するために、教育は外部の企業に限られた時間で委託されて、実際の組織の文脈でやるんじゃなくて、作り上げた例や一般的な（人工的な）適用性でお金を稼ぐんだよね。組織の一部になって、日々新しいハードな知識を特定の文脈で応用するのは、ランダムな熱心な人によってカジュアルに行われる。もし彼らが会社の方針や確立された管理方法を打破できればね。最終的には、方針や実践も厳格にしなきゃいけないよね。そうしないと、管理に関わる人たちもコードの兵士のように簡単に代替可能になっちゃうから。組織のためにね。このアプローチを「組織指向の開発」と呼ぼう。

比較的敵対的な設定で、ローカル管理者権限すらないこれについてちょっと脱線するけど、仮想VMやサンドボックス化されたマシンへのローカル管理者権限はどう？それがあれば、開発者は生産的になれると思うし、ITが守りたいものも守れるんじゃないかな。そうなると、実際の問題はローカル管理者権限じゃなくて、内部ネットワークに接続されていて、社内リソースにアクセスできるマシンへの管理者権限を持つことになると思う。つまり、ITは一度ローカルネットワークに入ったら、たくさんの貴重なものにアクセスできるという戦略を取っているかもしれない。これはちょっと怖い戦略だね。

誰も初心者にこれを教えてくれないんだよね、誰かが教えてくれたらよかったのに。クリエイティブな仕事をしている私たちは、良いセンスがあるから始めるんだ。でも、その間にギャップがある。最初の数年は作るものがあまり良くないんだ。良くなろうとしているし、可能性はあるけど、実際にはそうじゃない。でも、あなたのセンス、つまりゲームに引き込んだものはまだ素晴らしい。それが、あなたの作品に失望する理由なんだ。多くの人はこの段階を乗り越えられずに辞めちゃう。私が知っている面白いクリエイティブな仕事をしている人たちは、みんなこの時期を経験している。自分の作品には、欲しい特別なものがないってわかってる。みんなこれを通過するんだ。そして、もしあなたが始めたばかりか、まだこの段階にいるなら、それは普通のことだって知っておくべき。最も大事なのは、たくさんの作品を作ること。毎週一つのストーリーを完成させるために、自分に締め切りを設けること。たくさんの作品を作ることで、そのギャップを埋められるし、あなたの作品はあなたの野望と同じくらい良くなる。私はこれを理解するのに、今まで会った誰よりも時間がかかった。時間がかかるのは普通だよ。頑張って乗り越えていこう。（アイラ・グラス）

簡単に言うと、「自分にとって簡単なタスクでうまくいくのは簡単だ」ということ。これが、良い作品を生み出しながら、自分のスキルの成長を止める方法なんだ。