AI時代のPrincipal Engineer
AmazonのPrincipal Applied ScientistのEugene Yanさんの記事に触発されたので書いてみる。
Advice for New Principal Tech ICs (i.e., Notes to Myself)
AI時代にPrincipal EngineerがAIとどう向き合い、どう生き残るかを書こうと思う。
なお、上記の記事にもある通り “1. Different principals will have different flavors.” なので、Principalと一言で言っても企業・チームによって千差万別であることに注意していただきたい。
1. AIは “frenemy”
2025年のソフトウェアエンジニアリングにおいて、AIの存在を無視することは難しくなってきている。特にコード生成においては、AIを使わないでコードを書くことが企業で働くうえで許されなくなりつつあるように感じている。企業によっては、AI生成されたコードの行数や使用token数をKPIとしてトラックしているという話も聞く。また、AI Native企業になろうと各社躍起である。
コードを自分で書いていく上で生成AIを使ったagentic codingは非常に助けになる。結構まとまった量のコードが生成されるので、生成しては捨て、という試行錯誤が速くなる、という話もある。また、隙間時間を使ったコーディングがしやすくなったので、ミーティングの合間にコードを生成する、なんてことも前より格段にしやすくなった。
ただしこれは、ICとして実装することだけに集中するならば、という前書きがつく。「何か」を生成するスピードは速いのだ。
なんだけど、過去にこの記事でも書いたように、コードレビューが業務の大きな割合を占めるであろうPrincipalにとっては、自分の背中を打ち抜く何かに代わる。自分ひとりだったり、似たような技術レベルの集団においてagentic codingはかなり有利に働くだろう。が、それはコードをちゃんと読めてレビューができてというのを暗黙のうちに仮定していることになる。このレベル感やコードの質に関する期待値がメンバー間ずれると、 “it works” と “but it’s broken"の間でのせめぎあいが発生する。
言い換えると、AIを使う人間の特性が増幅される傾向にあると言ってもよいかもしれない。人間が手で書いていたころは、およそ同じ方向を向いていたように感じていても、AIが人の営みを加速させずれを増幅させると、コントロールしてすり合わせるのがかなり難しくなる。
そういう意味では、AIは friend でもあるし enemy となりえるのである。
2. 必要なのは英語力、コミュ力。次に技術力とキャッチアップできる力
英語力と言っているのは、筆者がカナダに住みアメリカ企業で働いているからであるが、言語化能力と言い換えてもいいかもしれない。
コードを書く作業がagentに委譲されると、次第に業務の割合として増えてくるのが、部署間調整だったりメンバーのモチベーションマネジメントだったりといったソフトスキル側になってくる。日々誰かを説得し、何をするべきか、これはやるべきことなのかを言語で表現し、ありとあらゆることをunblockするのが仕事になる。
例えば、一緒に働いているプロダクトマネージャーに色々と決めてもらいたい、そうしたときに技術的なお膳立てをする必要があるだろう。あるいは、コードレビューをしていて設計的な問題を指摘したときに、自転車小屋の議論かと相手がやる気を失ってるのが伝わってくることもあるだろう。
そうしたときに、テキストコミュニケーションならば、AIに英語の下書きをしてよい表現に改善してもらうということはできる。
だが、生成された英語のレビューが迅速に自分でできないと、間違いや怪しい表現などに気づくことができないのである。人間がボトルネックになってしまう。素早く行動に移すためにも、英語力を上げより意図した表現をすぐに出せるようになる必要がある。そして、口頭での会話ではAIなんかに聞いてる暇なんてない。
コミュニケーション能力の重要性も上がっている。メンバーが非常にフラストレーションを感じているような反応があったときに、なぜそのような反応になったのかを考え想像することが、モチベーションを管理する上でも非常に重要である。例えば、おなかが痛いのかもしれないし、あるいは家族とけんかをしたのかもしれない。あるいは、子供が学校でトラブルに巻き込まれて、担任をすっとばして校長果ては教育委員会にエスカレーションをしているのかもしれない。
なぜ、このようなことを言っているのか、その真の理由は何なのか。そう、「筆者気持ちを答えなさい」問題である。これを考える作業はPrincipalになって格段に増えたし、その検討をAIを使ってサポートしてもらうことはできても、結局人間の機微は自分で考えないといけないのである。
何度となく、AIの遺電子の「新世界」のようにAIがコミュニケーションの文面を全部代わりに作ってくれるようになればいいのに、と思ったことか。
なお、Principal Engineerになっているのであれば、技術力的には何かしらの専門領域に一家言ある人だと思うので、AIを取り入れて新しいことをキャッチアップし続ける力さえあれば大丈夫だと思う。無論、AIのいうことだけを真に受けていてはハルシネーションの海に溺れてしまうので、論文や書籍、オープンソースのコードを読んだり書いたりするという素振りはとても大事である。
キャッチアップに対するスピード感は以前よりも求められる速度がぐっと上がっている。
3. AIを自分で使い倒し、AI slop detectorを身に着ける
おそらくChatGPTやGeminiなどを使って質問したり議論をするということは、日常的にやっていることだと思う。それに加えて、Claude Codeなどのcoding agentを使ったコード生成もやって日々の業務のコードを書いたり、スクリプトを作ったりなどもしているだろう。
AIを使い倒して業務活用するのは、今後の生き残りのためにもどんどんした方がいい。そして使い倒しておくと、AIが生成した AI slop を見分ける嗅覚が備わってくる。ここが非常に重要で、ドキュメントやスライド、コードもレビューするときにこの嗅覚があると「あ、これは真面目に読まなくていいな」など早期にフィードバックをすることができる。
人間の時間は有限であり、ノーレビューでAI生成物を渡されたら突き返すべきである。
4. Principalは孤独、AIは良い壁打ち相手。でも気をつけろ
アメリカ企業ではネガティブフィードバックや改善の提案をするときにお作法がある。最初の9割誉めて最後の1文2文で重要な改善事項を提示する、といった具合だ。あるいは、英語として主語を無生物主語にして遠回しに言う、みたいなやり方もある。
英語が第一言語ではない筆者にとってこのお作法は、非常にしんどい。文化の違いも大きいし、シュガーコーティングしすぎると相手に伝わらないこともまあまあある。
そこで活躍するのがGeminiなんかのAIだ。Gemini 3 Proなんかだと、かなりコーチングめいた事も言ってくれ、こういう流れで整理をした方がいいと提案してくれるし、何なら「うまくいきますように」なんてお祈りまでしてくれる。
でもね、今のLLMはしょせんRLHFなので、人間の都合の良い出力ばかり出しがちなのを忘れてはいけない。どこまで行っても、十分なコンテキストをLLMに渡すことは困難なわけで、再利用できる「前回までのあらすじ」みたいなのを用意して工夫はしているけど、会話を重ねると過去のコンテキストを忘却してしまうものである。
あと、人間にすっと歩み寄った物言いを言われ続けていると、解消しないといけない衝突が発生したときにLLMが一緒になって「相手が悪いです！その理由を徹底解説します！」なんて言ってくる。
LLMがいうことは、ある種のフィルターバブルみたいなものである、そのバイアスを補正するのは人間なのである、という強い覚悟が必要である。
5. AIは996に追い込もうとしてくる
coding agentのおかげでコードを書き始めるまでの静止摩擦係数が激減した。これはミーティングなどで忙しいPrincipalにはありがたい側面ではある。このおかげで何が起こるかと言うと、ちょっと晩御飯を食べる前にプロンプトでコードを生成開始する。すると、ご飯を食べてる時にも結果が気になってソワソワし始めて、見に行ってしまう。通知が出ている。次の指示を出す。
別の同僚は、飲み会に移動する前のエレベータ待ちの時にプロンプトで指示を出していた。
コードを書き始める静止摩擦係数がほぼ0になったおかげで、AIが深夜まで残業をするのを誘発するのである。
Werner Vogelsが言うように、(レビューのない)vibe codingはギャンブルであり、ある種の依存性があるのだ。
Staff+と呼ばれるラダーになってくると、皆が皆やっていることがちょっとずつ違うため道を見失いがちである。他の人の本やブログなどの言葉を読むことで、自分が正気を保てて来たところはあるので、この文章が誰かの助けになればうれしい。
もちろん、何か他にいい話があれば何かしらの方法で教えてほしい。
