Japanese Translation:

2026 年までに、AI は受動的なアシスタントから、有用なコードを書ける実行志向の「ジュニアエンジニア」へと進化し、開発者がどのように働くべきかという根本的な変化をもたらしています。ジュニア開発者にとって、AI をデフォルトでの第一歩として利用することは、本質的な学習を迂回させ、低品質な出力への過信を招く恐れがあります。その代わりに、問題点を最初に書き下して「ゴムダック効果」を活かし、行き詰まった場合にのみ AI を利用すべきです。シニアエンジニアは、AI のドリフト（良きパターンからの逸脱）を発見し、「非常に優秀なジュニア」として振る舞うエージェントを統括するために依然として不可欠です。したがって、企業が次々と採用に注力するのはジュニアではなく、コードエントロピー（複雑性の過剰さや不適切な設計判断による静かなる劣化）を管理するシニアエンジニアであり、この劣化は能動的かつ小規模でテスト可能イテレーションでのリファクタリングが行われなければ発生します。

高価な技術的負債と脆弱なシステムを回避するためには、業界は堅牢なシステム設計スキル（何を構築し、部品どうしがどのように接続されるかを理解すること）と厳格な検証プラクティスを優先する必要があります。ベストプラクティスには、変更を小さく・漸進的に保ち、大きな飛躍ではなく純粋でテスト可能なメソッドを要求し、Playwright などのツールを用いてセーフティネットを構築し、AI がデバッグのためにログへのアクセスを持つように保証し、生成されたコードを能動的に簡素化して「静かに腐敗」することを防止することを含みます。究極的には、速度は理解力を代替することはできません。テリーンス・ Tao の知見に従うと、速く到着することは往々にして理解度が低いかを示すため、能動的な人間の監督と慎重なアーキテクチャ計画なしの迅速な開発は、管理不能なソフトウェアエコシステムにつながります。

AI 活用と開発者の進化：2026 年の実践的知見

私にとって、人工知能（AI）は最初級の**「ガムダック」でした。やがてそれは新しいクリップボード**へと代わり、スタック・オーバーフローからの断片コピーを代替する場所となりました。さらに、最高のスペルチェッカーかつコード補完ツールへと進化し、今では本物の価値あるコードを書く能力を備えています。

ゴムダック効果

AI に答えを求めつつも、まず自分の問題を文字に書き出すプロセスこそが重要です。

AI への質問前に文章化することで、頭の中で問題の整理と明確化が促進されます。
スタック・オーバーフロー同様の効果を、より自律的に得ることができます。

先延ばし習慣の克服

AI は**プロcrastination（先延ばし）**との戦いにおいて強力な対抗手段となります。

**「まずは動くシンプルなコード」**を作るアプローチで、情報の不足による立ち往生を防ぎます。
日常的なプログラミングタスクには以前の実績があるため、AI はそれを基に**「シンプルな共通解」**を容易に見出せます。
これにより、最初の一歩から動き出す契機となり、そこから先は本人の裁量で進めます。

ジュニアとシニアの視点

AI を使い始めるタイミングや、立場によってアプローチは異なります。

ジュニア開発者への助言

初期段階では AI に依存しすぎないべきです。「なぜ動くのか」を理解せずに動作するコードを受け取ることは危険です。
基盤が欠如しているため、良い出力と悪い出力を見分けることができず、単に信用してしまうリスクがあります。
AI は「最後の手段」として位置づけ、問題と格闘することは学びの本質です。その格闘をスキップすることは学習機会の損失となります。

シニア開発者への課題

何が「良いコード」か理解しているため、AI の逸脱を察知し修正できますが、過度な依存は避ける必要があります。
将来的には、企業においてシニアを採用し、ジュニアの役割を AI に代替するケースも出てくる可能性があります。

エントロピーとリファクタリング

人生やコード開発はエントロピー（秩序の乱れ）との戦いです。コードに手を加えるほどそれは劣化し、AI はその劣化プロセスを加速させることもあります。

クラスが過剰に大きくなるやモジュール間の過結合といった問題は、AI が自ら警告してくれないため注意が必要です。
対抗手段としてリファクタリングが不可欠です。大きな構成要素の連携を観察し、必要に応じて切り捨て続けましょう。
AI を適切に活用すれば、小さな段階での反復変化（インクリメンタルな変更）は検証が容易で、リファクタリング自体を低コストで行えます。
漫然と AI を使うと、コードはすぐにぐちゃぐちゃになり悪化します。

誤誘導される場面

AI は小さなステップで最も効果を発揮しますが、スコープが大きすぎたり文脈が不足したりすると推測に基づいて空白を埋めてしまいます。

過度なコード生成に注意：明らかな要素を見逃し、単純化する代わりに追加だけを続けてしまう傾向があります。
要求していない新たな抽象化（設定オプションや不必要なヘルパークラスなど）を返されることもあります。
戦略: 段階的に構築を進め、各ステップでコードを理解しやすい状態に保つことが重要です。大きな飛躍を期待するアプローチは避けましょう。
誤回答の活用: たとえ答えが間違っていたとしても、どのような解法になり得るかを示すだけで、正しい方向へのヒントになります。

システム設計に対する変化

コード生成自体は容易になったものの、「何を構築するか」および「各構成要素どうしがどのように統合されるか」を把握することは依然として自動化の対象外です。システム設計のスキルが以前よりも重要になっています。

AI にピースごとにコード生成を任せてしまうと、境界が曖昧になりやすくなります。
システムの全体像を頭の中で保ち、結合度と凝集度を自らが監視する必要があります。

学んだこと：実践的な 4 つの習慣

現在の AI 活用から得た実践的知見は以下の 4 つに集約されます。

変更は小さく、漸進的に行う
- AI に「不要な機能を追加せず、シンプルで純粋かつ検証可能なメソッドを選ぶこと」を明確に伝えます。
- 機能構築中は既存動作を改変せず、新規コードを追加するアプローチが推奨されます。
- 動作確認完了後、一度のリファクタリングを行うのが理想です。
適切なセーフティネットを築く
- Playwright などのテストツールの使い方は必須です。健全なテストにより、生成されたコードの検証を迅速に行えます。
- プロダクションシステムでは、AI がログにアクセスでき、直接デバッグできる環境を整える必要があります。
- 大きな変更とその理由を記録するマークダウンノートを維持します。
積極的に単純化する（後片付け）
- AI は後片付けを行わないため、動作させたら時間をかけてシステムを簡素化してください。
- そうしないとコードは静かに腐食していきます。
保持したコードを実際に理解しているか確認する
- 動作する出力を受け入れて進めば学習にはつながりません。丁寧に時間をかけて行うことで初めて真の経験、思考、アイデアが獲得できます。
- テルレンス・タオ氏の指摘通り、AI を純粋にスピード向上のために使うと**「到着は早まるが、理解は浅くなる」**という現象が起きます。

結論：スピードより「手間」を

現在はコード生成のスピードは安価になっていますが、優れたソフトウェアには依然として**「手間」**が必要です。

システム設計への投資を日々行いましょう。
構築するものについて時間をかけて理解するように心がけましょう。

私が持っていたガムダックスのすべて