問題は2つのことから来てる。1) 「LLMはジュニアと同じくらい賢い」と聞いた人たちが、ジュニアを雇う代わりにLLMのサブスクリプションを選んでしまうこと。2) シニアとジュニアのパフォーマンスの差が大きくなってきてること。シニア開発者たちは何年も手を汚して手動で作業してきたし、いろんな課題にも取り組んできたからね。この世代のジュニアからミッド開発者は、「手で打つ作業」の多くが省かれてるのに、まだそれが大丈夫だと思ってるのが問題だよ。

ここでの意見には賛成だけど、提案された解決策にはあまり希望を持ってない。人間が複雑さを管理する必要があるという私の主張は、モデルがその複雑さを自分で管理できるようになっていくからなんだ。これを裏付けるのは、過去3年間でモデルが進歩した速度（ChatGPTは3ヶ月前に3歳になった）だと思う。ソフトウェア業界全体が、この能力はここで止まらず、どんどん成長していくことを理解する必要があるよ。説明できることは、最終的にLLMができるようになるからね。

シニアはジュニアから生まれる。シニアが欲しいなら、ジュニアにコードを書かせるべきだ。エンジニアの平均在職期間が短すぎて、ほとんどの雇用主が個人を育てることを考えていないんだ。実際のアプローチは「シニアが欲しいなら、シニアを雇うべき」って感じ。今後どうなるかは分からないけど、前の世代のCOBOLプログラマーのようなシナリオは想像しやすいね。

以前は、すべてのエンジニアがCを書くことから始めるべきだって教えられてたけど、現代の開発者のほとんどはそうじゃなかった。シニアは、シニアの意味が変わることや、そこに至る道も違うことを覚悟しておくべきだよ。低レベルの言語から高レベルの言語へのシフトがあったようにね。

コードを書きたがるジュニアを見つけるのがどんどん難しくなってきてるし、誰が本当にやる気があるのか見極めるのも難しい。ジュニアにこの決断をさせて、自制心を持たせるのは、ちょっと危険な二面性があると思う。私が彼らにやってほしいと思っても（本当にそう思ってる！）、競争心が強いジュニアたちは、AIによるコード生成に頼る傾向があると思う。それが彼らをより良く見せて、生産的に見せるからね。シニアは、ジュニアにコードを書かせるだけじゃなくて、何らかの形でそれを促したり、要求したり、あるいは強制したりする方法を考える必要があると思う。

シニアはジュニアから生まれる。シニアが欲しいなら、ジュニアにコードを書かせなきゃ。企業もそれを知ってるけど、これは囚人のジレンマみたいな状況なんだ。企業はジュニアをスキップして、シニアを他の会社から引き抜くために少し高い給料を払うことができる。みんながこれを始めたら、当然みんなが損をする。新しいシニアが足りなくなるからね。これを避けるには、ほとんどの企業がルールを守る必要があるけど、簡単にはいかない。ジュニアのトレーニングにかかるコストが経済的な成果に対して高くなるほど、ルールを破るインセンティブが大きくなる。もう一つの選択肢は、厳しい競業避止契約を設けて、社員が会社を移るのを難しくすることかもしれない。でも、これは法的に難しいし、一般的に社員にとって良いことではないよね。

すべてのキャリアパスがソフトウェアファーストの会社から始まるわけじゃないし、すべてのソフトウェアファーストの会社が最も厳しいコードベースで働いてるわけでもない。だから、僕の経験では、すべてのシニアエンジニアがもっと厳しい会社でシニアエンジニアとしてやっていけるわけじゃない。これってソフトウェア特有の経験じゃないよ。これが人生なんだ。

本当の疑問は、ジュニアにコードを書かせてシニアになるためにお金を払う必要があるのかってことだよね。もしコーディングがアートなら、ジュニアたちは他の苦しんでるアーティストたちと同じ場所に行き着くことになるし、成功するアーティストだけが報酬のあるコーディングの仕事を得ることになる。今、週末に無給で情熱プロジェクトのコーディングをしてるから、ちょっと考えちゃうよ。

問題は、コストに敏感な企業がこれをサポートしてくれるかどうかだね。ジュニアはコストがかかるし、育ててもすぐに辞めちゃうから、根本的な問題だよ。リテンションは賢い企業でしか機能しないし、他の多くの企業では回転ドアみたいになっちゃう。いい面もあって、30年以上の経験を持つ開発者として、最近はかなり良い契約給をもらってるよ。プロセス地獄や製品の劣化にハマってる回転ドア企業は、新しい価値を提供できずに、高いコストの経験豊富な開発者を探し回ってる。今の給料は、キャリアの初めに比べたら全然マシだよ。

シニアが欲しいなら、ジュニアにコードを書かせなきゃダメだ。ジュニアは増やしたくないな、時間が経てば彼らが競争相手になるから。

同意する。でも、彼らが価値を膨らませているわけじゃなくて、「現代的」なソフトウェア制作組織の働き方に関わってると思う。プロダクトマネージャーやCレベルの人たちも、何をしてるのか分かってないんだ。ほとんどの人は「ソフトウェアエンジニアリング」の演劇の一部で、リクルーターはリクルートし、マネージャーは管理し、ソフトウェア開発者はソフトウェアを開発してる。みんなお金をもらったり、組織内での地位を得るためにやってるんだ。実際に成果を出せるのは、その少数の人たちだけなんだよね。

同意。私が関わった2つのソフトウェアチームでは、みんな「シニア」だった。新しいシニアもいれば、もっと経験豊富なスタッフもいた。私はいつもチームの中で一番若手だった。各チームの2人の開発者は、AIが登場する前は本当に10倍の実力を持ってた。15〜25年の経験があって、小さなチームで多くのことに秀でてる：コード、インフラ、Linuxの内部、ネットワーキング、素晴らしいデバッグスキル、良いプラクティスを守る、素晴らしいドキュメント、そして「正しい方法」で物事をやりたいという欲求、IQもパワーもある。その他の良いシニア開発者も、そのうちのいくつかはできるかもしれない。私の肩書きはシニアだけど、面接の時に昇給を交渉したからで、実際はせいぜいミッドレベル。今は解雇されちゃった。

同意する。今は資本が厳しいから、過剰採用は流行ってない。人々は90年代初頭やドットバストのことを忘れちゃってる。あの時も同じことが言われてたからね。確か、Kraftの1977年のプログラマーとマネージャーがこのことについて話してたと思う。今まで読んだ中で、業界についての最も良い別の見方だね。

じゃあ、彼らが良くなったらすぐに辞めちゃうかもしれないのに、貢献することを学ぶ重要性って何なの？人事部門は彼らを引き留めるために市場価格の昇給を与えないよ。給与圧縮や逆転の問題もあるし。ジュニア開発者は投資する価値がないんだ。僕は一度もマネージャーに「ジュニア開発者が何人かいるといいな。プロジェクトを時間通りに終わらせるのに本当に助かるんだけど」と言ったことはない。彼らは「ネガティブワーク」をしてる。確かに、ジュニアがシニアにならないのは業界の問題だけど、僕の目標は会社の四半期や年間の目標を達成することだから、10年後のことなんて考えてられないよ。

そうだね。だから多くの会社には「上がるか出て行くか」というルールのある終末レベルがあるんだ。それ以前のレベルでは完全に独立してないし、監視が必要すぎる。10年の経験があるジュニアエンジニアなんて誰も欲しくないよ。シニアエンジニアがジュニアエンジニアを助けるのにどれだけの時間を費やさなきゃいけないかに、すごくイライラしてるのをよく見る。でも、それが仕事なんだよね。少なくとも大きな部分はそうだった。

ジュニア開発者にはかなり助けられてるよ。重要なのは、誰が有能な働き手になるかってこと。献身的で細かいところに気を使える人は、投資する価値があるって感じ。もちろん、スキルの幅は広いし、誰にでもタスクを任せてうまくいくとは限らないけど、新卒の大学生の中には5年の経験を持つ人よりも優れた能力を持ってる人もいるよ。逆に、彼らが実際にできることに焦点を当てる必要があるね。週40時間以上働けば、たとえ狭いスキルでも、努力次第で広がっていくから。

ジュニア開発者はいつも役に立たない。タスクを与えるのは [...] 彼らに貢献してほしいからじゃなくて、貢献する方法を学んでほしいからだ。君の説明によれば、ジュニア開発者は役に立たないわけじゃないよ。彼らは君のプロジェクトにおける最も重要な人材投資だ。

これには全然同意できないな。悪いジュニア開発者は役に立たないかもしれないけど、優秀なジュニア開発者は機能をバンバン作り上げるのを見たことがある。学校を出たばかりのジュニア開発者はエネルギーがたっぷりあって、 burnout もしてないし、仕事をちゃんとやりたいって真剣に思ってるんだよね。

子供の育成に関しても同じようなダイナミクスが大きなスケールで起きてるのは面白いね。子供はジュニアエンジニアよりずっと無力だし、少なくともジュニアエンジニアは自分で食べ物を取ったり、トイレを済ませたり、部屋を壊さないようにしたり、自分の命を保つことができる。みんな、子供を育てるコストを親に押し付けたいと思ってるけど、経済的な利益は25年以上先にしか実現しないのに、コストはかなり大きい（たいていは、少なくとも一人の親がフルタイムで注意を向ける必要があって、その分収入が減る）。将来の親たちは「そんなの無理だわ」って言って、子供を持たない選択をしてる。長期的な影響は、ソフトウェア業界がジュニアを避けるのと同じような感じで、完全な崩壊になるだろうね。労働力がなければ、仕事もできないし、ただ何もない、存在しない、消費者もいないってことになる。でも、少子化はもっと長いスパンで進行する（ソフトウェア業界は5年くらいでジュニア不足を感じ始めると思うけど、経済全体は子供不足を感じるのにもっと時間がかかる）、しかももっと根本的な問題だ。特定の業界が消えるのではなく、すべての業界が消えて、全然違うものに再構築される可能性が高い。生態系の捕食者/獲物/バッタモデルを思い出すな。多くの種の個体群動態は環境の収容能力を超えてしまう傾向がある。個々の個体は自分の繁殖や生存の決定をするけど、その合計が個体群の崩壊やほぼ完全な絶滅を引き起こし、サバイバーが資源を再発見したときに回復するんだ。

ジュニア開発者はいつも役に立たない > その同じ考え方はAIにも当てはまるけど、どの会社もそのトレーニングコストを払いたくないんだよね。前回、ジュニア開発者が私のチームに加わったとき、似たようなことを考えた。でも、マネジメントと話してみたら、トレーニングだけじゃなくてもっといろんなことが関わってるって教えてもらった。会社には地域の教育機関との社会的責任の約束があって、毎年インターンシップや採用活動に参加することを誓わなきゃいけなかった。会社は都合のいいときだけ人をリクルートするようなフェアウェザーフレンドにはなれなかったんだ。もう一つの側面はコストだ。シニアエンジニアだけのチームは高くつく。最後の側面はレベルアップ。会社にたくさんのレベルがないと、チームには同じレベルのエンジニアがたくさんいることになっちゃう。そして、昇進の逆ピラミッド的な性質から、昇進を待つエンジニアが何年も待たされることになる。だから、ジュニア、中堅、経験豊富なエンジニアが混ざったチームの方がいいんだ。そうすれば、コストと昇進の流れがコントロールできる。今、AIがあることで、影響はジュニア開発者だけにとどまらないかもしれない。中堅開発者にも影響が出ると思う。企業は「ジュニア1人と中堅1人をAIで1人のジュニア開発者に置き換えられる」と考える可能性が高いんだ。

学校を出たばかりの人の中には、役に立つ人もいたよ。チケットの数は常に増えてるし、「落ち着いたらこれに取り組むから」と言ってるチケットを誰かが拾ってくれるのは助かる。もし彼らがコードベースで何もできないなら、かなり難しくなると思う。あと、何年も前に始めたときの文脈を完全に忘れてしまった人もいるから、メンタリングがあまりうまくいかないこともあるね。

ジュニア開発者は昔から無能だった。彼らには、シニアエンジニアが数時間でできるタスクを1週間や2週間かけてやらせていた。貢献させたかったわけじゃなくて、貢献することを学ばせたかったから。知らないけど、知識やコーディングの腕、直感で多くのシニアを凌駕する子たちもいるよ。新人が2時間でできるタスクを1週間かけるのは、シニアがクソみたいなソフトウェアのプロセスをすでに学んでいるからだよ（大体、壊れかけのビルドやコードレビュー、チケットシステムを扱ってるし）。

僕の悪夢のシナリオ（現実になりそうな気もする）は、業界での最後の年が、ほとんど理解できないコードベースで働くプロンプトモンキーやエージェント「マネージャー」になることだ。理解できるコードベースで働く方が常に好ましいから、AIの能力も最大限に活かせるしね。AIが物事を説明してくれるし、熟練した人間は自分の特定のニッチに関するしっかりした知識を持っているから、一般的なAIにはない部分がある。だから人間はまだまだ重要な役割を果たすことになるよ。

最近入った会社でもこれを見てるよ：コードの80〜90%が生成またはプロンプトで作られてる。大きなプルリクエストがあって、レビューや監視はほとんどなし。長期的なアーキテクチャを考えてる人なんて全然いないし（正直、できる人もいない）。全体的に、どの段階でも批判的な思考がほとんどなくて、エラーメッセージをLLMに戻して、また繰り返すだけ。スキルを持った人がこれらのプロジェクトを軌道に戻すのに役立つ世界があればいいけど、もしかしたら社会全体がこの質の低下を受け入れつつあるのかもね。

仕事では、Kotlin+Springや複数のNextJSアプリ、マイクロサービス、RustのCADエンジンを使ってエンタープライズソフトウェアを作ってる。ここ3、4ヶ月は、ちょっとした調整以外でコードを書いてないな。前は何年も毎日手でコードを書いてたけど、新しいワークフローには楽しめる部分がたくさんある。ファイルの中で問題に没頭していた頃が懐かしいし、Claudeからの実装サマリーをたくさん読むのは時々宿題みたいに感じる。機能が4つのリポジトリにまたがってて、読むには多すぎるから。でも、AIネイティブなワークフローならではの方法で、コードをいろんな解決策に形作るのは楽しいし、エージェントスキルやフレームワークを作って、それを会社や生活の他の側面に広げていくのも好きだ。深い作業があって、まだまだトレンチでハッキングしてる感覚がある。いろんな方法で同じ満足感を得られるし、時間やエネルギーの制約で手が届かなかった新しいことを探求できるのはワクワクする。あと、バックエンドスタックが好きじゃないし、ReactやNextJSには狂気じみた嫌悪感を抱いてる。でも、もうそれを書く必要がないから嬉しいし、UXに集中して、顧客を幸せにしたり、生活を楽にしたり、ソフトウェアをどんどん良くしていくのができるのが最高だ。転換点の前に良いソフトウェアエンジニアリングを学んだ人は、今とてもラッキーだよ。存在的な不安や悲しみの段階も旅の一部だったけど、正しい態度であれば祝うべきことや探求すべきことがたくさんある。

もう起こったことだよ。古参の人たちは、現代のアプリケーションが重たいフレームワークや過剰な抽象化レイヤー、「レフトパッド文化」で膨れ上がって非効率になっていることを正しく指摘している。外部依存関係を引き込んで最も些細なことをやらせるけど、そういうことができる開発者が業界の需要を満たすためにソフトウェアを効果的に作れるようになったんだ。LLMだけのコーダーは、進化の次のステップに過ぎない。

これはまさに https://news.ycombinator.com/item?id=47157039 のことだと思うし、私もあなたと同じ反応だった。

そう思うよ。ホームページに行ってみて、サムネイルは全部AI生成で、クリックベイトなタイトルばかりだよ。

「LLMがあなたのスキルを奪う；同じ不安を抱える賢いシニアエンジニアの私の話を聞いて」みたいな記事が増えてるみたいだね。 https://www.ivanturkovic.com/2026/02/25/ai-made-writing-code... これと同じスタイルだね。でも、そこではうまくいってるみたい。エージェントが書いても。

誰かが「このパターンを認識できるようになると、どこにでも見えるようになる」と言ってた。正直、そんなことにならなければいいなと思ってたけど、今はもう見えてしまったから、2023年以降に生成されたウェブコンテンツを読むのが悲しくなりそう。はぁ。これが人類が素晴らしいものを持てない理由だよね。Xじゃなくて（無頓着な子供みたいに壊しちゃうから）、Yなんだ（良いものや本物を押し出す安っぽいコピーを作っちゃうから）。でも、実は他に何もないんだ。これが今の私たちの未来。正直言うと、高校時代のあの人に話しかけて、新しい溶接工を育ててくれるか聞いてみようかな。

問題は、彼らが以前は非常に遅いペースで進歩していて、教えられる瞬間がたくさんあったことだと思う。今は誰でもコードを適当に書いて、見た目は動いてるけど、実際には地雷だらけのものができちゃう。彼らは、自分が知らないことを知らない状態で、どうやってその直感を育てられるんだろう？どうやってそれをレビューして、彼らを助けられるんだろう？もしかしたら解決策が見つかるかもしれないけど、簡単かどうかは分からないな。

MathematicaやTI-89/92/CX-CAS、WolframAlphaにアクセスできたのに、微積分を学びました。数百の導関数や積分、分離可能な微分方程式の手動操作を全部手でやらなきゃいけなかった。でも、これらのツールのおかげで、何が間違っていたのかを理解しやすくなった。だから、あなたに同意するけど、他のツールでも何十年も前からそうだったよね。

「今のところ、自己規律をAIを避けるための手段としてしか見れないんだけど、これがどれだけ難しいか分かる？ソーシャルメディアの消費に自己規律が全くない人が何百万もいるんだ。」

「息子が何も言わずにそれをやってるのが誇らしい（バダンプ・ティッシュ）。クロードにパスを提案したら、『そんなやり方じゃ何も学べない』って言われた。」

「結局、何かを学びたいのか、何かを手に入れたいのかってことだと思う。数時間でアプリを作れるのと同じように、Spotifyで曲を聴くこともできるし、コードを書くことを学ぶのも、ピアノを弾くことを学ぶのも同じだよ。」

「文献は明確で、繰り返しの実践がスキルを身につける唯一の方法だと言っている。何世紀にもわたる文献は、実践と理論を対比させている。実際にやることではなく、他の人がどうやっているかを学ぶことで、実践に役立つ知識を得ることだ。これは違う：これは奴隷にやらせているようなものだ。歴史から分かるように、奴隷所有者はその仕事をどうやるか知らなかった。例えば、王や封建領主は動物を飼ったり、穀物を育てたりする方法を知らなかった。」

「徒弟制度は、AIが決して触れられない理由で素晴らしいけど、もし本当に学びたいことを理解してやりたいというモチベーションがないなら、AIを放棄する必要はないと思う。もしそうなら、AIは素晴らしいツールだよ。」

「学生がAIを悪用するのを防ぐための完璧なプランはこちら：すべての電子機器を禁止した上で、対面での鉛筆と紙の試験。」

「筋肉を鍛えた」 手で畑を掘ることで筋肉を鍛えることはできるけど、ほとんどの人は商業的にトラクターを使うよね。トラクターを操作するのもスキルだけど、また別のスキルなんだ。AIもそんな感じになると思う。人々はそれを使って、AIを使うスキルを学ぶようになるんじゃないかな。機械がやることを学ぶこともできるけど、コンパイラを使う代わりに機械語を書くことを学ぶようなものだけど、そうする人は限られてるかもしれないね。

私も同意するけど、シンプルで機能するソフトウェアを作る「アート」が急速に消えつつある。私のキャリアで最も影響を受けたことの一つは、リッチ・ヒッキーの「Simple Made Easy」を見たことだ。私たちの業界はエンジニアリングとアートの一部で構成されてる（つまり、センスを持つこと）。AIにはセンスがないから、バイブコーディングがうまくいかないんだ。エンジニアリングのアートは、書かなければならないコードの量を減らすことにある。すべての機能に「はい」と言うことじゃなくて、「いいえ」と言って、最も影響力のある機能を最小限の時間で出荷することなんだ。時には、正しい方法で物事を行うために、後退して再学習することも必要なんだ。一方で、AIはできるだけ多くのコードを生産することに焦点を当てていて、これはソフトウェアエンジニアリングの真逆なんだよね。

これは大惨事だ。覚えておいてほしいのは、使わなければ失うというシンプルな事実だ。このツールがもたらす認知的ダメージは、マクロスケールでは数年後まで大きくは見えないだろう。でも、最終的には人々が気づくはずだ。すべての作業（LLMにオフロードする前）は、脳を特定の方法で働かせるようにして、発明のアイデアを生み出す結果につながっていた。個人的には、LLMウイルスにさらされていない人や、その使い方に非常に規律がある人だけを厳選して雇っている（これは判断が難しいけど）。

「これも見たことあるけど、主に『チームリーダー』のシニアたち、つまりマネジメントコースに興味がある人たちね。一方で、SE2の子が全然関係ないことを手伝ってほしいって言ってきたんだ。新しいSE2じゃなくて、もうSE2として限界に達してるっぽい人なんだけど。とにかく、彼らが指摘したことを全く理解してなかったから、イライラして、AIに入力するための正確なプロンプトをそのまま教えてあげた。そしたらAIが解決してくれたんだ。結果に驚いてたけど、自分の無能さに恐怖を感じるべきだったのに。」