開発者にワークフローについて尋ねると、最新モデルがどれほど速くなったか、コーディングエージェントが今では何をこなせるのか、どの新しいツールで仕事の進め方が改善したかを語れます。Kunal Kushwahaには、その先に聞きたいことがあります。
「あなた自身はどうですか？」
最近、CodeRabbitのサンフランシスコオフィスで、WeMakeDevsの創設者KunalとThe Mergeのエピソード収録のために対談しました。AIが実装をより多く担うようになる中で、ソフトウェアエンジニアは何を学ぶべきなのか、そして使うツールとともにどう成長し続けられるのかについて話しました。
Kunalの答えは、今もエンジニアが担う仕事から始まります。アプローチを選び、その判断の理由を説明できるほど、問題を深く理解する必要があります。どのようなツールを使っても、リリースするものへの責任はエンジニアに残ります。さらに、エンジニアが技術的な深さを身につける実践的な方法として、LLMをローカルで動かすことも挙げました。
図1. エンジニアリングの判断には、システムの各部分がどう組み合わさっているかの理解が必要です。
12歳が8時間でプロダクトを作れる時代
最近のハッカソンで、Kunalは登録を済ませたものの、まだ参加待ちだった12歳の少年に出会いました。父親はすでに彼を会場に送り届けており、Kunalはイベントへの参加を認めました。
その若い開発者が作ったプロジェクトは、Kunalが過去10回のハッカソンで見た中でも特に気に入ったものの一つになりました。ユーザーのアイデアを調査し、それをもとにWebサイトを生成し、ユーザーが連絡できる相手を見つけるものでした。Kunalは、インターフェースやドキュメント、複数のツールを組み合わせた仕組みに感心しました。LinkedInのデモ動画には、短い寸劇も含まれています。
Kunalによると、それがすべて8時間でできたといいます。言語やフレームワーク、ソフトウェアとハードウェアの関係を何年もかけて学んできたエンジニアにとって、12歳の子どもが半日で本格的なアプリケーションを作る姿は、不安を感じさせるものかもしれません。この話から、実装を中心とする役割を担うエンジニアにとって、この変化が何を意味するのかという、より居心地の悪い話題へと進みました。
Kunalは、こうしたツールが可能にすることに期待していますが、この移行が一部のエンジニアにとって、ほかの人より難しいものになることも認識しています。狭く定義された実装作業を担当し、別の役割に移る機会が少ない人は、選択肢の多い人とはまったく異なる影響を受ける可能性があります。
彼の助言は、実装の自動化が進む中で、自分が仕事にどんな価値を持ち込めるのかを見つめ直すことです。
基礎があればハイプの先を見通せる
技術の基礎は、AIツールが生成したものや、それらについて語られる主張を評価する手がかりになるため、今も重要です。低レベルの仕組みを学ぶことに今も意味があるのかとKunalに尋ねると、その利点を端的にこう表現しました。「ハイプサイクルから抜け出す方法を学べます。」
基礎を理解していれば、ツールが実際に何を変えるのか、システムのどの部分に役立つのか、どこで限界が問題になるのかを問いやすくなります。その土台がなければ、見栄えのよいデモを、目の前の問題に適した解決策と取り違えやすくなります。
だからといって、エンジニアがすべてを知る必要があるわけではありません。KunalはKubernetesに深く携わってきましたが、今もKubernetesやLinux、ネットワークの知らない部分に出会います。実際に手を動かしてきた経験があるからこそ、知らないことを調べ、十分な情報に基づいて判断するための文脈を持てるのです。
AIを使った学習にも、彼は同じ考え方を当てはめています。学生がエージェントを使ってWebサイト全体を作っても、学びをそこで終わらせるべきではありません。生成されたものを読み、関数がどう動くのかを問い、実装を使って理解を深める必要があります。大切なのは、プロジェクトを一つ終えるたびに、次のプロジェクトを説明し、変更し、デバッグする力が伸びているかどうかです。
実装が容易になるほどプロダクトの判断力が重要になる
Kunalは、面接でプロダクトの判断力を見極めるためのシンプルな方法を提案しています。候補者にURLを渡し、「このWebサイトについて話してください」と伝えるのです。
候補者がプロダクトをどう分解して捉えるのか、自由に変更できるなら何を変えるのか、その判断が事業にどう影響するのかを聞きたいと考えています。その回答から、何に注意を向けるべきかを見極め、提案する変更がなぜ重要なのかを説明できるかが分かります。
これは、「最後のソフトウェアエンジニア」の仕事がどうなるかについてKent C. Doddsと交わした会話とも重なります。Kentは、エージェントが実装をより多く担うようになるにつれ、エンジニアは何を作るかを決め、システムを形作り、結果を判断することに多くの時間を使うようになると論じました。Kunalも、学生やエンジニア、ハッカソンのチームとの仕事を通じて、同じような結論に達しています。また、協力する力や共感、ソフトウェアを使う人への理解も、この仕事に欠かせないと考えています。
ハッカソンは、実行についての実践的な視点も与えてくれます。そうした環境でKunalは、チームが何を作るかを決め、成果をどう見せるかにも同じ判断力を求めます。最も優れたチームは、まず中心となる機能を一つ動かし、使える初期版を保存して、そこから作り込みます。また、成果を簡単に試せるようにします。
実行を重視するKunalの考えから、アイデアにどれほど重きを置くべきかという議論が生まれました。彼はアイデアより実行の方が重要だと述べましたが、私は実装が容易になるほど、価値ある問題を選ぶことがさらに重要になると主張しました。Kunalは自分の主張を補足しました。大きなアイデアにも、動く実装が必要です。小さくてもよくできたプロダクトが、実際には作られない大きなアイデアに勝つことはあります。
図2. 小さくても動くプロダクトがあれば、人に試してもらい、反応を得られます。
自動コードレビューはどこまで進むのか
私たちの意見が最も分かれたのは、自動レビューがどこまで進むかという点でした。Kunalは、エージェントがレビューをより多く担うようになり、いずれ人間がコードをレビューしなくなる可能性もあると考えています。同時に、変更にどれだけ注意を払うべきかは、その影響の大きさによって決まるとも考えています。Kunalは、大企業でブラックフライデーに障害が起きたという仮定を使い、どのような場合に人間のレビューが必要だと考えるかを説明しました。大規模なセール中にエージェントが修正を作ったとしても、やはり人に確認してほしいと考えています。
エージェントが最終的にどこまでレビューを担うかについて意見は分かれましたが、結果に対する責任がエージェントに移るわけではないという点では一致しました。
「何か問題が起きたら、責任を負うのはあなたです」とKunalは言いました。
話題は、エージェントが生成した変更がシステムに積み重なっていくとどうなるのかに移りました。私は、コーディングエージェントを使って約1年間作ってきたプロジェクトについて話しました。初めのうちは、エージェントが何を組み立てているのかを理解できていました。しかし、関わるエージェントが増えるにつれて、自動チェックが通り続けていても、その理解を保つことが難しくなりました。変更がテストに合格して本番環境に達した後に初めて表面化する可能性のある、保守、性能、セキュリティの問題についても話しました。
そこから、変更の影響範囲について話が進みました。レビュアーは、エージェントが触ると予想していなかった領域も含め、変更がアプリケーション全体にどう影響するのかを見る必要があります。CodeRabbitでは、その広い視点を提供するためにChange Stackを構築しました。プルリクエストを論理的なグループと階層に整理し、レビュアーが変更全体の依存関係をたどれるようにします。
LLMをローカルで動かす方法を学ぶ
エンジニアが次に学ぶべき具体的な技術を尋ねると、Kunalは、新しいコーディングエージェントのワークフローとは少し違うものを勧めました。
「LLMをローカルで動かす方法を学んでください」
彼が勧めるのは、モデルをローカルで動かし、次にファインチューニングや、それを大規模に実行するには何が必要かを探ることです。Kunalによると、この実践を通じて、モデルがどう動くのか、コンポーネント同士がどう通信するのか、どのようなデプロイ方法を選べるのかなど、インターフェースの背後にあるインフラに触れられます。
彼はこの経験を、Kubernetesの学習になぞらえました。本番ではマネージドサービスを使うエンジニアでも、自分で小さなクラスターを構築し、運用した経験は役に立ちます。その経験によって、マネージドサービスが自分たちに代わって何をしているのかを理解できるからです。
チームがモデルの提供方法を選ぶときにも、同じ考え方が当てはまります。API、自社所有のハードウェア、マネージドプラットフォームには、それぞれ異なるトレードオフがあります。ローカル環境の構築を経験すれば、さまざまな選択肢についてよりよい問いを立てるための文脈が得られます。
図3. モデルをローカルで動かすと、大規模なデプロイを検討する前に、AIサービスの背後にある構成要素に触れられます。
オープンソースへの貢献と発信で経験を積む
キャリアの初期に、オープンソースはKunalがよくある壁を乗り越える道になりました。インターンへの応募には経験が求められるのに、その経験を得るにはインターンに参加する必要があるように見える、という問題です。機会を待つのではなく、彼はKubernetesに貢献し、Google Summer of Codeに参加し、やがてメンターを務めることで、実績を公開の場で築きました。
AIツールが広く普及した今でも、彼はこれから始めるエンジニアに同じ道を勧めます。Kunalは、プロジェクト、オープンソースへの貢献、ハッカソンを、開発者がスキルを身につけ、学んだことを共有する機会だと捉えています。チュートリアルを終えたと投稿すれば進捗を示せますが、そこで学んだ概念を説明すれば、理解を試し、深めるフィードバックを得られます。
次の仕事に備えるエンジニアには、その仕事がどのような作業を含み、人々がどのようなAIツールやシステムを使っているのかを調べ、その知識をプロジェクトで実践するようKunalは勧めています。成果を共有すれば、ほかの人が試し、フィードバックを寄せる機会が生まれます。プロジェクトを説明し、フィードバックに応じて改善し、その結果に責任を持てるほど深く理解している開発者には、Kunalが冒頭で投げかけた「あなた自身はどうですか？」という問いへの具体的な答えがあります。
