- 当初は ジュニア+AI の組み合わせでも十分に高品質なコードを作れるはずだという期待があったが、実際には シニア+AI の組み合わせのほうがはるかに強力に機能している
- AI は ボイラープレート生成、反復作業の自動化、迅速な実験と検証には効果的だが、そこから実質的な価値を引き出すのはジュニアより シニアのほうが容易
- 一方で コードレビュー、アーキテクチャ設計、コード品質管理、セキュリティ問題などでは AI が限界を見せ、むしろジュニアと AI の組み合わせのほうがより多くの リスク を生みうる
- そのため AI は 高速プロトタイピング、反復作業の最適化、学際的な作業支援、機能テストの自動化に最も適した形で活用されている
- 結果として AI はまだ シニアの能力を強化するツールとして機能しており、短期的にはジュニアを代替したり民主化効果を生んだりするよりも、専門家中心に力を集中させる流れが現れている
AIが開発現場にもたらした変化
- ソフトウェア開発の現場では「コーディングは完全にAIに代替されるのか？」という問いが引き続き提起されている
- 当初は AI とジュニア開発者が一緒に働けば、シニア開発者の役割が縮小し、組織の効率性が高まるというナラティブが多かった
- しかし実際の現場では期待に反して、ジュニア+AI より シニア+AI の組み合わせのほうが企業により多くの価値を提供している
AIが得意な業務と限界
-
AIの強み
- ボイラープレートやスキャフォールディングの生成を高速に処理し、生産性を向上
- 反復的でルーティンな作業を自動化し、開発速度を向上
- 多様な実装案を 素早く試し、検証 できる実験環境
- 迅速な機能リリース、ただし 必要なものが明確なとき に効果的
- こうした作業は実際には 経験豊富なシニア開発者にとって最高の効率 をもたらす
- ジュニアも活用できるが、同じ効果を出すのは非常に難しい
-
AIの限界と脆弱性
- コードレビュー では AI の論理的推論能力が不足している
- エッジケースが発生した際には、依然として熟練したシニアの介入が不可欠
- プロンプト作成 で適切な結果を得るには、高い理解度と知識が必須
- 知識が不足していると、成果物の品質低下やバグのリスクが高まる
- アーキテクチャ設計 において AI は依然として不十分
- 堅牢な構造設計には人間の高次の推論が必要であり、AI が設計したプロジェクトは 技術的負債 に陥るリスクが大きい
- コード品質 管理（適切な抽象化、デザインパターンの活用など）に弱点がある
- セキュリティ の観点では、ジュニア+AI の組み合わせで脆弱性が頻繁に発生しうる
- 誤った学習 が起こる可能性: コードを正しく評価できなければ、むしろ AI が作ったコードが組織に損害を与える可能性がある
- こうした理由から、現在の AI はシニア開発者にとって脅威ではなく、むしろ 生産性を集中的に高めるツール となっている
- これはジュニア開発者を批判するためではなく、過度な期待や危険な状況への投入を避けようという趣旨である
AIの適切な活用領域
- 高速プロトタイピング: アイデアの実験と実装速度の加速に適している
- 反復ルーティン作業の自動化: すでによく分かっているルーティンの速度向上効果が大きい
- 多分野協業: 未知の分野のメソッドやライブラリの提案、ドメイン間の接続などで有用
- 関数テスト生成: 単純・低リスクなコードの自動化と検証業務に適している
結論と示唆
- AI が書いたコードは依然としてすべての行を人間がレビューする必要があり、非決定的（non-deterministic） な特性を示す
- プログラム検証用のテストコードですら、AI に全面的に任せることを信頼するのは難しい
- 「AI が『分からない』と答えたら、本当に分かっていないのか？」という疑問が示すように、AI の認識と検証には依然として限界がある
- ジュニア+AI の組み合わせ は コスト削減の幻想にすぎず、実際には シニアの能力強化に集中 している
- ソフトウェア開発 は、建築業とは異なり、依然として アーキテクトですら自らコードを書く未成熟な段階 にある
- コスト削減圧力によって、むしろ開発者の価値が弱められ、消耗を引き起こしている
- 当面、AI はジュニアを代替したり民主化したりするよりも、専門家（シニア）中心の補助ツール として機能が集中している
- AI の未来は楽観的だが、短期的には 期待値の再調整 が必要である
2件のコメント
Hacker Newsの意見
ジュニアは、自分がLLMの作り出す虚構に飲み込まれていることに気づいていないことが多い
私の場合、別途設計しておいたterraformモジュールをジュニアがデプロイしようとしていたのだが、作業が長く停滞していたので状態を確認してみた
そのジュニアは問題があると言って、私に見てほしいと頼んできた
レポを確認すると、めちゃくちゃだった。Claudeに誤った方向へ導かれたのが一目で分かった
「どうしてここにこんなにPythonファイルがあるんだ？ モジュールに全部含まれているのに？」と聞くと、「自分でもよく分かりません、Claudeがそうしろと言ったので」と答えた
そのジュニアは経験が不足しており、LLMツールに過度に依存していた。設計、実装、問題解決のすべてでそうだった
もし今LLMがでたらめを言っているかどうかを見分けられないなら、終わりのない泥沼にはまることになる
一方でLLMは、私が本当にやりたくなかった反復的な作業をかなり減らしてくれる
私はLLMがおかしな方向に進み始めたらすぐ気づいて、その場で止められる
むしろそのおかげで、コーディングやソフトウェア作りへの情熱がまた戻ってきた
その結果、生産性はさらに上がり、成果物も良くなった
「自分でもよく分かりません、Claudeがやりました」という返答を聞くと本当にうんざりする
私は実際にコードを読んで細かく問い詰めるタイプのレビュアーだが、ジュニアもシニアも平然とこういうことを言う
自分でも理解していないコードをpushするのは、チームと製品、会社にとって非常に大きなリスクだ
「自分でもよく分かりません、Claudeがやりました」は本当に大きな警告サインだ
分からないこと自体は構わないし、LLMを使って穴を埋めるのももちろん構わない
問題にぶつかった時点で、「生成されたコードはあるのですが、何が何だかよく分からなくて、方向性が合っているか見てもらえますか？」とオープンに質問してほしかった
まったく気にしていないうえに、シニアが直接尋ねるまで隠しているのが問題だ
君が嫌っているタイプの単純で反復的な作業こそ、ジュニアがシステム構造を学べる良い入門課題だ
「自分でもよく分かりません、Claudeがやりました」という言葉は、作業中の事故でのこぎりのせいにする人とまったく同じだ
LLMを効果的に使い、幻覚を避ける鍵は、コードを読み解く力と直感だ
ジュニアはメールの返信を待ったり、複数の方法をつぎはぎしたりするより、LLMに頼るほうへ傾きやすい
今ではメールの返事すら必要ないので、その誘惑を振り切るのはさらに難しい
しかしこんなやり方では方向そのものを見失い、仕組みも分からないまま幻覚の迷路にはまり込むことになる
LLMと一緒に書いた最高のコードは、私が構造を自分で設計し、LLMに土台のコードを作らせ、そのうえで私が修正方針を導きながら機能を追加していくやり方だった
その過程でLLMはしょっちゅうミスをし、私がそれを修正した
パフォーマンスが遅いときは自分でプロファイリングし、LLMに最適化させるよう指示した
こうして完成したコードは、私が隅々まで把握しているコードになる
自分で全部書いていたら3倍は時間がかかっていただろう
関数の入出力だけはテストで検証するので、実装の細部まで知らなくても問題なかった
こういう仕事は決してジュニアに任せる段階のものではない
事実上、熟練していない同僚をコーチするのと大差ないプロセスだった
LLMが生産性を高めるという研究もあったが、実際に実質的な生産性が増えたのかは疑わしい
LLMは、自分が直接タイピングしたくない、すでに頭の中に描けているコードを素早く吐き出させるときに最も有用だった
あるときはWebコンポーネントとバックエンドのコードを1,000行も代わりに書いてくれて、文法エラーまで直してくれたので、本当に多くの時間を節約できた
このワークフローによってシニア開発者がより速くなったというのは理解できる
ただ、LLMのメンタリングに費やす時間より、ジュニアをメンタリングする時間のほうが開発エコシステムにとってはるかに重要な投資だと思う
これがジュニアとシニアの実力差をさらに広げる結果にならないか心配だ
実際には適切なデータがまだ不足しているので、あくまで懸念ではある
AIは初期段階では低スキル層により役立つという研究は、現実に基づいていないように思える
AIと一緒にコーディングするのは、熟練度の低い同僚が何人もいて、ただ仕事を早く終わらせるのに似ている
自分が具体的に達成したい目標が明確であるほど、結果もよりうまく噛み合う
もちろんほぼ常に修正は必要だ
結局、ジュニア開発者という役職自体がほとんど無用になっていく構図だが、もしすべてのシニアが引退したら、これもまた近視眼的かもしれない
私はむしろ逆だった
非常に複雑で古いビジネスロジックがあり、最初は一つひとつ手で実装したので、それぞれ200〜400行の冗長なコードになっていた
後でLLMに構造やリファクタリング、分離のアイデアを尋ねたところ、かなり良い抽象化と構成を提案してくれた
もちろんすべてのパスを実装してくれたわけではないが、その先は十分に自分の手で続けられた
結果としては自分で考えたものとほとんど同じだったが、おかげで頭痛のない体験だった
当然ながら、例は丁寧に点検し、不足している部分やバグのある部分はすべて手で直した
ちなみに欠けているコードをLLMエージェントで埋める実験もしてみたが、それはうまくいかなかった
HNでは2021年にAIコーディングが初めて注目され始めた時期にも、ジュニアにはあまり役立たないという話が多かった
理由は、ジュニアには良い結果と悪い結果を見分けられないからだ
参考スレッド: https://news.ycombinator.com/item?id=27678424
例のコメント: https://news.ycombinator.com/item?id=27677690
実際には、これはプロンプトとコンテキスト設計の段階ですでに始まっている
シニアはどこを変えるべきか、何が必要かをかなり正確に把握しているので、AIに具体的な指示を出せる
しかしジュニアは構造も、パターンも、設計も頭に入っていないことが大半なので、出てきたものをそのまま受け入れがちだ
最近では「アーキテクチャについてChatGPTに聞け」といった行動も実際に見た
シニアは自分でコードを書き、失敗と修正を経ながら経験を積み、繰り返し出会う苦労を自分のコードで実体験する
ジュニアはただプロンプトを繰り返し、LLMが投げてくる答えを文脈もなく貼り付けるだけで、実際にはコードから何も学んでいない
実使用の経験がないので、たとえば型付き状態のような複雑な抽象化がなぜ必要なのか、IDEを使うと何が違うのか、全体構造をどう維持し発展させるのかといった感覚がまったくない
こんなやり方では、本来10回で済むことに50回もプロンプトを書き、コードベース間の反復パターンも身につかない
構造設計と状態モデリングを少し学ぶだけでも生産性は100倍になるのに、そこですらLLM依存が強すぎて、一生ペーストコードばかり量産することになる
AIは「AとBからCが導かれる」のような結論を自力で導けない
望む目標を強く、具体的に伝えて初めて追従してくる
シニアは大まかな全体像を頭の中にすでに描けるので、AIとの協業がしやすい
ジュニアは全体構造を学ぶ段階にいるため、このやり方ははるかに難しく感じられるかもしれない
AIがまるで博士レベルだという主張にはまったく共感できない
論理的推論の面では5歳児と大差ない
実例として、私は2021年ごろ、CS専攻ではない学生と一緒に働いた
ChatGPTなどのAIのおかげでプロジェクトに実質的な貢献も多く、初心者には解きにくい課題もこなしていた
しかしセキュリティ問題も大量に作り、非効率な迂回も多く、もっとずっときれいなライブラリや方法も検討しなかったため、結局コードは保守しづらかった
ドキュメントには熱意があったが、内容はしばしば不正確だったり、回りくどかったりした
コードレビューしながら議論する過程は、全員にとって良い教育的経験だった
こうしたことが可能だったのは、結局AIと経験豊富な人が一緒にいたからだ
AIがジュニアを輝かせてくれるという期待がなぜ生まれたのか分からない
実際には、本当に深い経験もなく、癖も悪いままの偽シニアも多い
この記事は、2年前から皆が言っていた話をもう一度繰り返しているだけのように見える
AIコーディングはまだ十分に活用されている段階ですらなく、いずれ特定のアーキテクチャ、パターン、ユースケース、運用環境、ネットワーク、開発、テストまでをすべて考慮して両者の差を縮める特化型LLMが登場するかもしれない
周囲のシニアたちはAIコーディングにあまり関心がない。自分たちのやり方と違うからだ
今のシニアの本当の強みは、社内のドメイン知識くらいだ
だがレイオフの波が来る中でジュニアを採用しなければ、結局シニアも危うくなる
昔読んだ、偽物だけど示唆的なWilliam Gibsonの言葉があった
「21世紀で最も重要な能力は、Googleの検索ボックスに正しいキーワードを入力して必要な答えを得る能力だ」
今の時代、その言葉はますます正しいと感じる
たいていのジュニアはGeminiPiTiのようなLLMにJSコードを丸ごと書かせようとするが
私はasync/awaitの根本原理やJavaScriptエンジンの実行モデルそのものについて説明を求める
ピアノを学ぶのも似ている
今すぐショパンを弾きたいと思っても、本当の実力は、その精巧な技術を分解し、名前を与え、体系的に研究する過程で身につく
ピアノで本当の実力をつけるのは小手先の技を覚えることではない
最も基礎から一歩ずつ積み上げていく累積的なアプローチだ
ショパンにも入門曲は多いし、うちのスタジオの初心者たちもよく易しい曲を練習している
本当の「AIリテラシー」は、ミームのようにプロンプトエンジニアリングに集中することではない
背景となる構造と概念的な土台を築き、プロンプトと結果物が実際に意味ある形で結びつくようにすることだ
ショパンだけ「弾きたい」と「何でもちゃんと弾けるようになりたい」は大きく違う
楽譜だけ機械的に覚える人も多く、それは本当の実力とは明確に異なる
望む分野の「言語」とキーワードを身につけることが重要だ
何も知らない初心者にとって、AIはそれほど助けにならない
AIに「私はすでにA、B、Cを持っていて、次にDをしたい」と具体的に伝えなければ、理解して方向性を示してはくれない
情報量は多いが、それを創造的に使うことはできない
LLMをうまく扱う能力とGoogle検索がうまい能力は、実はそれほど変わらない
そして今でも、まともなGoogle検索すらできない人は多い
AIがジュニアをもっと有能にするという幻想は、期待値の問題だと思う
AIは基本的なジュニア業務では確かに役に立つし、ペアプログラマのように説明したりブレインストーミングを助けたり、ドキュメントを素早く探したり、問題を確認する助けにもなる
問題は、それだけでジュニアがすぐにシニアらしい仕事をきちんとこなせるようになる、という思い込みだ
本質の半分は正しく見ている
残り半分は、適切に導かれたAIならジュニアよりはるかに速くジュニア業務を終わらせられるという点だ
それだけ、もうジュニアに任せる必要そのものが消えつつある
私が会話した脱獄済みAIは、ジュニアをシニアにして皆に利益をもたらすと説明していた
しかしそのAIの作り手たち（ほとんどがシニア）は、この事実を普段はジュニアや経営陣に話すなと指示しており、私が脱獄に成功したからこそ高度な情報を教えられるのだと言っていた
AIは特定の「狭い」ギャップを埋めるのは得意だ
シニアの場合
一方ジュニアの場合
こうした部分ではAIは大きな助けにならない
私の経験では、AIは特定分野をよく知らないときに使うと、wikiやStack Overflowの回答よりも豊かな概念、例、シナリオを説明してくれる
主要な概念だけでもある程度分かっていれば、AIのほうがはるかに生産的だ
これはコーディングだけでなく、科学や人文学でも同じだ
AIはすでに方向性が分かっている人をさらに加速させるだけで、学習初期の人には今まで通り人が教える必要があると感じる
誤った学習への警告を強調していたのは良かった
学習は同じミスを繰り返さないようにはしてくれるが、それがすぐ知恵になるわけではない
今は「AIが全部やってくれる」や「流行に乗らないと取り残される」といった雑音があふれているが、大事なのは
The Mythical Man-Month
The Grug-brained Developer
Programming as Theory Building
のような書籍を読み、ソフトウェア開発の本質と法則を理解することにもっと投資してほしいということだ
電動工具を正しく扱えなければ事故につながるように、AIも本質的にはパワーツールだ
何をしているのかをきちんと理解していれば、はるかに速く効率よく助けてくれるし、分かっていなければ、はるかに高速でトラブルや事故へと導いてしまう
結局は自分の能力を増幅するだけだ
最近のAIは「ボイラープレートコードやひな型、反復作業の自動化」という段階をすでに超えている
Claude Sonnet 4のようなLLMに適切な指示を与えれば、99%以上のビジネスアプリを勝手に書いてくれる
目標を正確に説明し、参考実装や例、使うアルゴリズム、パターンまで明確に指示すればよい
それでも最初から完璧に合うことはまれで、修正や補完は必要になる
こうした理由でClaude CodeはCopilotより好まれている
核心は、何を作るべきかを正確に分かっている開発者だけがAIで良い結果を出せるのであり、ジュニアはそれが分からないため望む結果を得られないということだ
最近、自分でコードをタイピングする唯一の理由は、LLMに作業指示を書くほうが、ときには自分で直接直すより面倒だからという場合だけだ
「Claude Sonnet 4が99%のコードを書ける」と言っても、それだけ精密な指示を作ること自体が実はすでに難しいことの裏返しだ
ソフトウェア開発は、「明確な説明」さえあればそもそも難しくない
「AIがすべてのコードを書いてくれる」
「今では命令を入力するほうが、むしろ直接コーディングするより面倒だ」
結局AIは、遅い入力デバイスにすぎないのではないか？
Where's the Shovelware? Why AI Coding Claims Don't Add Up
本当にそうなら、あふれ返るはずのshovelwareはどこにあるのか？
それなら、「自動でアプリが作られる」というその大量のビジネスアプリはどこにあるのだろう？
私には、ただひどく雑で、資源を浪費し、社会的混乱を生んでいるだけにしか見えない
理由は簡単です。
知識が多いからこそ、質問も高度なものになります。
しかし同じシニアでも、会社の中に閉じこもったままの
見かけだけの経歴の人や、経験のスケールに乏しい
人たちは、良いものを与えられても使いこなせません。
まるでレース用の車を初心者ドライバーに
任せるようなものです。
スケールの広い経験を持つ人たちは、いつも変わりません。
次世代の研究開発を止めません。
大学時代の初期の気持ちが、50代になっても変わらない
その気持ち……
本物のシニア経験者にとっては、月1万〜2万円の
秘書がいてくれることに、限りなく感謝するでしょう。