はじめに
ここ1年、自分の実装業務はほぼすべてAIコーディングエージェント経由でやっています。
手を入れ続けたハーネスと、繰り返し使えるループとして運用している形です。
その一方で、新卒メンバーの支援には以前から関わっており、今年からは教育トレーナーを担当しています。そこで避けて通れないのが、「では1年目にも同じことをさせていいのか」という問いでした。
以下は現時点で自分がどう考え、何をルールにしているかの記録です。正解ではありません。
AIは制限しない
禁止という手段
「基礎が身につかないから、まずは自分で書かせるべきだ」という考えは真っ当だと思います。自分もその懸念自体は否定しません。
ただ、手段として制限を選ぶのは現実的ではありません。禁止したところで隠れて使います。そして見えないところで使われるほうが危険度は高い。どう使っているか把握できず、間違った使い方が定着していても気づけません。
何より今はAIがあることを前提にしてITエンジニア業界は回り始めてます。
使わせた上で、使い方に介入する。今のところ、これがよいと考えています。
書ける力と判断する力
現場ではすでに、コードを自分で書く場面より、出てきたものを評価して採否を決める場面のほうが多くなっています。この状況で価値を持つのは、ゼロから書ける能力よりも、目の前の成果物が妥当かどうかを判断できる能力です。
だから、書く経験を積ませること自体を目的にする必要はないと考えています。
判断の材料
問題はここからです。
AIを使うと、若手が触れるコードの量は増えるように思えます。実際は放っておくと減ります。動くものが返ってくるので、読まずに通してしまうからです。
判断できることが重要だと言いながら、判断の材料に触れる機会は自動的には増えません。意識的に取りに行かないと減っていきます。
これは若手に限った話ではありません。自分がPMとして関わったプロジェクトでも、出てくる量にレビューが追いつかず、後から読んでも説明できないドキュメントが残りました。動くけれど客が求めていたものではない、という成果物も出ました。読まずに通すというのは、規模が大きくなるとこういう形で表に出てきます。
だから、読ませる仕組みを別途入れる必要があります。1年目に課しているルールは、結局すべてここに帰着します。
1年目に課しているルール
調べた後、公式ドキュメントを斜め読みする
AIに聞けば答えは返ってきます。ただしAIは、聞かれたことにしか答えません。
フレームワークを使う仕事では、その独自機能をどれだけ知っているかで書けるものが変わってきます。そして独自機能は、存在を知らないと検索できません。目的を伝えれば動くコードは出てきますが、それがフレームワークの用意した仕組みに沿ったものかどうかは、聞いていない限り教えてくれない。結果として、素朴な実装で通ってしまうことがあります。
たとえばRailsであれば、複数のモデルに共通する処理をどこに置くかという場面があります。目の前の要件だけを伝えれば、各モデルに同じメソッドを書いたコードが返ってくることもある。それでも動きます。Concernという仕組みがあることを知っていて初めて、「これはそちらに寄せるべきではないか」という問いが立ちます。
そんな仕組みがあるのかという発見は、ドキュメントを開いて視界に入って初めて起きます。目的の項目を読みに行ったついでに、隣に並んでいる項目が目に入る。
この偶然の遭遇が、AIに聞くだけの経路では起きません。
辞書を読まなくなったことによって語彙力が落ちたという話を聞きますが同じだと思います。
経験者はこの部分を無自覚に補っていますが、1年目はそうではない。だから、理解した後に一次情報を斜め読みする手順を挟ませています。
確認質問は理解してから答える
エージェントは作業中に確認を求めてきます。ここを読まずに承認すると、何を選んだのか本人が把握しないまま作業が進みます。分からない点はその場で聞き返させ、理解してから決めさせています。
セッションは目的ごとに切る
話が長くなりそうならセッションを分けます。先頭で与えた前提が効かなくなるからです。
長いセッションで語尾の指定が消える現象は、誰でも一度は見たことがあると思います。あれは、最初に渡した指示が薄まっているということです。同じことがコーディング規約でも起きます。実際、仕様駆動で進めていたときに見ました。planモードで方針を決め、そのまま同じセッションで実装まで走らせたら、規約が守られていませんでした。
厄介なのは、語尾なら崩れたことが目で分かるのに、規約違反は見ても分かりにくいところです。指示は出したのだから守られているはず、という前提でレビューに入ってしまう。1年目であればそもそも規約を覚えていないので、逸脱に気づく手立てがありません。
セッションを切るのは、前提を渡し直す機会を強制的に作るためでもあります。そして目的ごとに切っておくと、後から「何を渡した上での結論なのか」を自分で追えます。1セッションに複数の目的が混ざると、判断の根拠が残りません。
gitは自分で確認する
取り返しのつかない操作は、提案をそのまま実行させません。
gitは1年目が最初に触れる不可逆な操作です。ここで「AIが言ったから実行する」という動き方が身についてしまうと、後により危険な領域に進んだときに同じことをします。
まだ答えが出ていないこと
危険度と教える順序
1年目が最初に触れる不可逆操作はgitですが、本番環境での作業やDB操作はもっと後になります。ところが事故の深刻度は明らかに後者のほうが大きい。
最も危険な領域を、最も経験の浅い時期には教えられません。到達してから教えるのでは遅い気もしますが、到達前に教えても実感が伴わない。ここはまだ整理できていません。
副作用
AIを前提に育った世代がどうなるかは、まだ誰も知りません。黎明期ですらないと思います。
そして仮に何かが抜け落ちるとしても、それをAIがカバーしてしまう可能性があります。かつて手計算ができないと困ると言われましたが、実際にはそれほど困らなかった。同じことが起きるかもしれません。
今課しているルールも、数年後には不要だったと分かるかもしれない。それでも今は必要だと判断しています。
受容度の個人差
同じ研修を受けても、AIへの向き合い方には差が出ます。差が出るのは、「ここまで任せられる」「こうすればもっと置き換えられる」と発想できるかどうかです。
低く見積もる側に寄れば、任せられる作業をいつまでも手で続けることになります。高く見積もりすぎれば事故る。ちょうどいい線は、失敗しながら調整していくしかないと思っています。
この見積もりは今も動き続けています。半年前に無理だったことが今はできる。経験の長さがそのまま有利に働くとは限らず、古い見積もりを持ち続けているほうが不利になる場面すらあります。
経験の浅い1年目にこの感覚をどう持たせるかは、まだ手がありません。
判断力の循環
「規約違反に気づけない」と書いた通り、1年目には判断の土台がありません。にもかかわらず判断する力が重要だと言っています。
ルールを課して読ませてはいますが、それが実際に判断力の育成につながっているかは検証できていません。
現時点の結論
原則として制限せず、読まずに通す動きだけを止める。
どれも派手なルールではありませんし、効いているかどうかも体感の域を出ていません。AIの性能も現場の使い方も動き続けている中での暫定解です。半年後には別のことを書いているかもしれません。
同じ問題を抱えている人がどう対処しているのか、聞いてみたいと思っています。