キャリア
永遠のジュニア:AIがあなたのために開発できないスキル
Forever Junior: The Skills AI Can't Develop for You (tech.criteo.com)
要約
AIの進化により、ソフトウェアエンジニアの仕事は変化しており、コードを書くことよりもコードをレビューすることの重要性が増しています。ジュニアエンジニアは、AIエージェントに作業を任せることで学習機会を失い、「永遠のジュニア」になるリスクに直面しています。この状況を乗り越えるためには、AIに質問を投げかけ、その回答を深く掘り下げる「問いかけ」のスキルや、AIが生成したコードをレビューする際に、既存のコードパターンやチームの慣習を理解し適用する「レビュー」のスキルを、人間自身が意識的に開発していくことが不可欠です。
全文翻訳
AI & 機械学習、キャリア & 成長、エンジニアリング
永遠のジュニア:AIがあなたのために開発できないスキル
2026年10月7日 エリーズ・バツロン
エージェント中心の世界です。
ソフトウェアエンジニアリングは、私たち全員がまだ理解しようとしているAI革命の渦中にあります。長年、ソフトウェアエンジニアは消滅の6ヶ月前だと言われてきました。一部の人々はまだ仕事が消えつつあると信じています。他の人々は、それは単に変化しているだけだと言います。
私の経験は後者を支持します。
AIに対する私の懸念
エンジニアの優先順位に real shift を見てきましたが、仕事自体は非常に必要とされています。Criteoでは、エンジニアは依然として採用され、依然として高く評価されており — 生産性を可能な限り向上させるためにAIエージェントに頼ることが増えています。しかし、それらのメッセージはすべて同じ補遺を伴います:ハンドルをしっかりと握ってください。ツールを使用してください、しかしあなたが何をしているのかを知ることをやめないでください。
学校を出たばかりのジュニアとして、「まだ何をしているのか学んでいる」というのは但し書きではありません — それが仕事の説明です。したがって、エージェントに作業をさせるだけでなく、代わりにそれを学ばせる誘惑に駆られるのは、少し危険です。結局のところ、それは私よりもはるかに多くのことを知っています!
学校では、この仕事でより良くなる方法はただコードを書くことだと教えられました。今では、できる限り直接コードを書かないように言われています。では — どうやって学ぶべきなのでしょうか?それが私が実際に恐れている消滅です:ソフトウェアエンジニアが消滅することではなく、シニアが消滅すること — 私たち全員が永遠のジュニアになり、別のエージェントの助けを借りて1つのエージェントの作業をレビューする資格しか持たなくなることです。
では、私はそれについてどうすべきだったのでしょうか?
私は2つの質問を研究することから始めました:
AIは私の仕事の説明で実際に何を変化させたのか?
シニアとは、具体的に何なのか?
最初の質問に答えるために、私はオンラインや職場の議論を聞くだけでよかったのです。多くの人が、コードを書くことよりもコードをレビューすることの方が今では重要だと言っています。コーディング構文や言語を学ぶことは時代遅れであるというのがコンセンサスです。そしてもちろん、企業は私たちにトークン管理のようなコスト最適化に焦点を当てることを望んでいます。
後の質問については、職場のシニア、特に私のチームのシニアを観察し、シニアシップが何を意味するかの鍵をいくつか拾い上げました。私のチームでは、シニアは出荷したコードを擁護できる人、単に持っているのではなく設計上の選択を議論できる人、エージェントが間違った方向に向かっているときにそれを伝えられる人、いつ委任し、いつ自分でやるべきかを知っている人 — そして残りの私たちを教える時間を取る人たちです。
これらのガイドラインに従って、私は成長する必要がある場所のマッピングを作成し、年末までに昇進候補にノミネートされることを最初のマイルストーンとしました。このマップをたどることで、いつかシニアシップに到達できることを願っています。
次の質問は、どうやってかでした。明らかに、私はスキルを開発する必要がありました。
私は、多くのエンジニアがそうしたように、skill.md を書くことから始めました:シニアの行動について私に教えるメンターのようにモデルが振る舞うようにするための指示とパターンをモデルにフィードしました。それは確かに役立ちます。しかし、そのプロセスのどこかで、本当のギャップは私のエージェントの行動にあるのではなく、私の行動にあることに気づきました。したがって、この記事の焦点は、私が書いたスキルについてではありません。それは、エージェントと一緒に開発しているスキルについていくために、私が自分自身で開発しなければならなかったスキルについてです。私がジュニアからシニアに進化することを実際に可能にすると信じているスキルです。
問いかけ
私は、計画やコード自体への理解をテストするために、エージェントにソクラテス的な質問を私に尋ねるように指示することから始めました。各決定やコード変更の終わりにちょっとしたポップクイズ。実際には、質問は半分しか関連性がなく、計画やコードを注意深く見たり、エージェントと話して理解を確認したりするのに役立つことがほとんどでした。
# 理解チェックと委任された作業
- 実装された作業の後、理解を促します — スタイルをローテーションします:例:自分の言葉で説明する、Xが変更された場合に何が壊れるかを予測する、1つの失敗モードを説明する、1文でトレードオフを擁護する。必要に応じて優しく修正し、再確認します。
- サブエージェントまたは委任されたタスクは、同じルールに従う必要があります:確認されていない変更はなく、確認されていない変更検証もありません(同じタスク検証ルールの対象となります)。
コード言語:Markdown (markdown)
その時、私は自分自身の人間的なスキルを構築していることに気づきました。5歳児なら誰でも、誰かが折れるまで繰り返し「でもなぜ?」と尋ねることでマスターしているスキルです。
好奇心。
LLMの最高のトリックは、あなたの言語であなたに話しかけ返すことです — だからそれを使用してください。あなたが従わない決定について、エージェントに説明を求めてください。馴染みのないものを名前で言及するときは、出典を引用するように求めてください。しっくりこない提案を正当化するように求めてください。最後のものが本当のトリックです:欠陥のある解決策をエージェントに声に出して説明させることは、しばしばそれが自身の間違いを捉える方法であり — あなたもそれを捉える方法です。
シニアは、本番環境にリリースしたコードを擁護できます。彼らは設計上の選択を議論できます。エージェントが間違った方向に向かっているときにそれを伝え、方向転換できます。エージェントに十分に疑問を投げかけると、あなたはまさにそれをリハーサルしていることになります。
はい — これにはトークンがかかります。公平です。しかし、私は、出荷する前にコードを完全に理解していると、本番環境でより頻繁に機能するため、ここで遅くすることが全体的により効率的であることを見つけました。そして、それが機能しない場合は、エージェントと再び往復するのではなく、自分で修正できます。AIを少し頻繁に使用するよりも、毎回十分に好奇心を持つ方が良いです。コードを半分理解したまま出荷して、後でその代償を払うよりも。
レビュー
エージェントと可能な限りコードを書いている場合、その作業をレビューすることにほとんどの時間を費やすことになります。レビューはそれ自体のスキルです — 特にこのAIの状況では、シニアシップに到達するために最も必要とされるスキルと言えるでしょう。良いニュースは、あなたはすでにそのためのトレーニングセットを持っているということです:シニアがあなたのコードに残したすべてのコメントです。
パターンに注意してください。名前付けについて常に注意を受けていますか?あなたのチームは明らかに命名規則を気にしています — エージェントのコード内のすべての名前を2回確認してください。それを十分に行うと、あなたの業界、あなたの会社、さらにはあなたのチームに固有のプラクティスに気づき始めます。そして、それを使ってエミュレーションを練習できます。
# 既存のコードとの類似性と再利用性
各実質的なタスクについて:
1. 発見 — コードベースを検索します(および/またはユーザーに尋ねます)最も近い既存の機能(同じ種類のエンティティ、リソース、テーブル、APIサーフェスなど)を探します。
2. 整列 — 候補を要約します;どちらのアナログが最良かを尋ねます。何も適合しない場合は、作業が完全に新規であることをユーザーに確認するように求めます。
3. アンカー — 選択した参照(パス、コンポーネント、パターン)を指定し、スレッド全体で保持します。
4. 計画と実装(確認後) — アウトラインまたは実装するときは、参照からの逸脱を指摘します。参照が一度きりの場合は、小さな共有抽象化が過剰なエンジニアリングなしで両方に役立つかどうかを尋ねます。
5. 情報ギャップ — ユーザーが参照が暗示する詳細(フィールド、所有権、API形状)を省略した場合、仮定する前に尋ねます。
コード言語:Markdown (markdown)
私のチームは製品カタログを所有しています。新しいエンティティタイプを追加するたびに、シニアは「これはすでに持っているものと非常によく似ています」というようなことを言いました。そこで、既存のエンティティをテンプレートとして使用し始めました — そして、レビューのためにコードをプッシュしたとき、テンプレートエンティティからのすべての逸脱を精査するのを見ました。パターンは明白でした:逸脱を正当化し、できる限りのものを再利用してください。それに気づくと、自分で適用できるようになり、同僚がそれをする前にエージェントの出力をレビューできるようになりました。
さらに一歩進んで、そのパターンを私のスキル(今回はmarkdownファイルの種類)に書き込み、直接エージェントにフィードしました。今では、レビューを開く前に、それはパターンを念頭に置いています。あなたはこれをさらに進めることができます:あなたのgit履歴やチームチャットにAIを向け、レビューパターンを自分で見つけ出させます。
面白いことに、それは2つの意味が中間で出会うところです:私はスキルを構築して、スキルでより良くなることができるようにしました。ファイルはエージェントの最初のドラフトを私のチームのコードにより似たものにします;それを何度もレビューすることが、私をゆっくりとより良いレビュアーに変えます。最終的には、良いスキルファイルを持つジュニアにはならないでしょう。私が書いたシニアになるでしょう。