最初の1か月は、私はCopilotを意欲はあるけれどガードレールのない若手エンジニアのように扱いました。
私が頼んでいないコードを平気で書いてくるのです。関数の途中まで書き終えていると、Copilotが先回りして……新しいメソッドを作り、クラス全体を提案し、まるで自分を証明したい若手のように主導権を取ろうとしてくる。
決定的だったのはリファクタリングの最中でした。単にスタイルガイドを無視するだけではありません。R と T という変数名まで作ってきたのです。私がすでに抽象化していたロジックを重複していました。抽象化を認識することなく、同じパターンを3回も書いた。テストは壊れましたが、Copilotは気にしません。だって気にするように教えていなかったのだから。
正しく書くなら本来20分で済むはずの後始末に、私は2時間を費やしました。
私たちはエンジニアに主導権を持つことを教えます。ですがAIでは、それを手綱で引き戻す必要があります。
それがいつものパターンになりました。私は指示を出す。Copilotは踏み込みすぎる。私は削って整える。指示、踏み込み、削除。AIが出した内容を編集する時間のほうが、最初から自分で書く場合よりも長くなっていました。
AIが悪いからではありません。私がシステムを定義すべきときに、答えを求めていたからです。
マークダウンファイルの気づき
悪い出力から抜け出そうとして、指示を出し直すことで何とかしようとするのをやめたとき、転機が訪れました。代わりに、AIが参照する「頭脳」を変えたのです。
私は、私たちのエンジニアリング標準に基づいたマークダウンファイルを作成しました。要件の書き方。スコープを切る前に行うべき質問。ユーザーストーリーとタスクの違い。トレードオフの考え方。抽象化より重複を選ぶのはどんなときか。コードベースにおける「クリーン」とは何を意味するのか。
次に、あるエージェントがコードを生成したとき、即興で作ることはありませんでした。私たちがすでに定義していたパターンを実行したのです。
違いはそこでした。私はもう若手エンジニアに指示を出していませんでした。シニアエンジニアをオーケストレーションしていたのです。
シニアエンジニアが本当にやっていること
シニアエンジニアは、タイピングが速いから上手いコードを書くわけではありません。パターンを認識できるから、より良いコードを書くのです。抽象化すべきときと、重複すべきときを知っています。書かれていないけれど、コードベースの文化として存在する制約を理解しています。
それをAIにプロンプトで叩き込むことはできません。エンコードする必要があります。
私たちは、それをスキル、ルール、エージェント、フックに組み込みました。BAペルソナ向けのマークダウンファイルがあります。ソリューションアーキテクト向けのものもあります。コードレビューやQAの扱い方も含めて用意しています。エージェントが仕様書を生成したりコードを書いたりすると、これらのファイルを参照します。即興ではありません。すでに定義したパターンを実行しているだけです。
昔の制約は人員数でした。「十分な人がいない」。いまの制約はアルゴリズムの品質です。判断力をどれだけうまくエンコードできているか。何が「良い」のかをどれだけ明確に定義できているか。
なぜアーキテクトが勝っているのか
私が気づいたことをお伝えします。プリンシパルエンジニアやアーキテクトは、中堅開発者よりも速く、しかもより深くAIを取り込んでいます。利用数はずっと高い。
技術的に優れているからではありません。彼らはすでに「システム」として考えているからです。
中堅エンジニアはAIをペアプログラマーのように扱います。プロンプト、レビュー、受け入れ、繰り返す。アーキテクトはAIをインフラのように扱います。パターンを定義し、制約をエンコードし、あとはシステムに実行させる。
システムとして考えられて……その考え方を指数関数的にスケールできるのなら、なぜやらないのでしょう？
変えたスキル
私は、コストは「クラフト」だと思っていました。クリーンな関数を書く満足感。違いました。
コストは、まったく別のスキルを学ぶことでした。コーディングではありません。プロンプト出しでもありません。オーケストレーションです。
エージェントをどう連鎖させるか。人間の判断をどこに挿入するか。システムがそれを破れないほど硬直した標準を、でもあなたを驚かせる余地があるほどには柔軟に、どうエンコードするか。
AIで苦戦しているエンジニアは、ツールで苦戦しているわけではありません。別のスキルに何年も最適化してきたから苦戦しているのです……手作業でコードを書くことに……そして今、ゲームが変わった。
質問
そこで、私が今見ているのはこういうことです。
エンジニアがAIで壁にぶつかったとき、指示を出し直しますか……それとも再アーキテクトしますか？ AIをより良い言葉で誘導しようとするのか、それともAIが参照するもの自体を変えるのか？
最初のアプローチは線形にスケールします。プロンプト1回、出力1回、編集1回。次のアプローチは指数関数的にスケールします。システムを一度だけ定義し、あとは永遠に実行させる。
ほとんどの人がAIをGoogleのように使っています。介面がそう示しているからです。入力して、受け入れて、次へ。進歩している感じがします。
でも進歩とは検索の速さではありません。テコの効果です。
Googleは答えを返します。
シニアエンジニアはシステムを与えてくれます。
あなたはどちらを動かしていますか？
週1回のThe Builder's Leaderからのメール。枠組み、見落としがちな盲点、そして多くのリーダーが避ける会話。無料で購読する。
