はじめに
大AIエージェント時代が訪れて1年くらい経ちましたでしょうか。
100周くらい遅れてる感ありますが、AIエントリ書いてみようと思います。
1日かけていた実装が10分ぐらいでできることもあるので、コードを書くところだけなら本当に早くなりました。
そのわりに暇になった感じはあまりなくて、レビューの時間は増えましたし設計にも前より時間を使っています。
設計はむしろ前より時間がかかっている気もします。
この1年で仕事の進め方がどう変わったかというのと、認知負債、認知負荷について書いていきたいと思います。
AIで変わったこと
知らない技術に対する壁がなくなった
以前はわからないものを調べてから実装していたんですが、今はAIが自分にない引き出しを普通に出してくるので、わからなくても作れてしまう状態になっています。
知らない言語でもとりあえず動くところまでサクッと持っていけるようになりました。
自分なら選ばなかった実装方法も出てくるので、動いたあとにこれ何やってるんだとなって、そこから調べることが増えています。
個人の開発サイクルが爆速になった
自分はもともと作ってみないとわからないタイプなので、とりあえず書き始めるということが多いです。
頭にあるものを短時間で形にしてくれるのでフィードバックループが爆速になりました。
個人と書いたのは、事前にしっかり設計を固めて一発で決めるタイプの人だとこのサイクルは体感しづらいのかなと思ってるから。
認知負荷と認知負債
本題です。
AI導入以後気にしていることを書いていきます。
ここでは自分の中で以下のように定義しています。
- 認知負荷: コードを理解、判断するときにその場で頭へかかる負荷
- 認知負債: 理解していない部分を抱えたまま進み、変更や障害対応のときに後から支払うコスト
勉強している時間が爆増した
技術者としてどうなんだというところではありますが、自分は勉強が嫌いです。
ですが、前述の通りAIは既存の設計技法を使った、一見綺麗でそれっぽいコードを書いてきます。
その設計技法を知らないと、自分にとっては認知負荷が高いコードになります。
「これはどんな設計手法なんだ？」みたいなことが去年の末から今年の初め辺りまで頻発していました。
その都度体系的に勉強して〜と繰り返していました。（今もたまにある）
自分の引き出しが線形に増えていっている感があり良いのはいいんですが、勉強は嫌いです。
ですがここを疎かにするとクリティカルに認知負債に繋がるので日々格闘しています。
レビューが追いつかない
これも最近は慣れてきているんですが、当初はとても大変でした。
極論を言うとPR数が2年前と比べて10倍とかになっている気がします。
単純に目が追いつかないです。
レビューする筋肉が最近ついてきたようであんまり苦には感じなくなってきましたが、観点漏れがないか以前より気をつけるようになってしまいました。
あと、弊社に入社してからの試みとしてレビューするために左手デバイスを導入してみました。
VIAでノブにスクロールを割り当てて、PRをグリグリ見れるようにしています。
右手がとても楽になりました。
あと、1ファイル単位で見る癖が付くので認知負荷の軽減に役に立ってくれています。
みんな買おう。
コードの責任が増した（気がする）
アウトプットが増大したからといって結局それを保守するのは人間で、責任を持つのも人間です。
コード量が増大したことで、その分保守する範囲が物理的に増えた感があります。
また、保守するにもコードを理解していなければならないので、認知負荷が極力かからないコードを書くことを意識しています。
ですが、認知負荷を下げれば認知負債がなくなるというものでもないと思っています。
複雑でも理解できていれば負債ではなく、単純でもなぜこうしたか誰も説明できなければ負債になると思っています。
コードだけではなく意図も残す
AIが実装したコードを読んで処理を理解できても、なぜその設計を選んだのかまではコードだけでわからないことがあります。
設計や実装の別案を出してもらったときは、採用しなかった案と理由もPRなどに残すようにしています。
最近はこういった設計意図が残っていない状態を、認知負債とは別に意図の負債として扱う考え方もあるようです。
チームで保守するならこっちもかなり大事そう。
全部理解するのも無理
すべてを完全に理解するのも現実的ではないです。
特に業務の本筋ではなく、社内向けツールはそもそも最初から全部理解しないと割り切っています。
インとアウトに焦点を絞って見るようにして、認知負荷を感じないようにしています。
SNSを拝見していると、スピードを重視して顧客へのサービスまで理解不要としている方が結構な数いらっしゃるので心臓強いなと思います。
ほんとかな？
認知負荷を下げるコーディング
個人的に認知負荷を下げるためにやっているコーディング方法を書いていきます。
最近クラス設計を主にやっているのでその視点で。
最初にインターフェースとクラスを書く
最初にインターフェースとクラスだけ作っています。
ここが大まかな設計になる0から10の部分です。
あくまで大枠は自分で作るために箱と箱の名前は自分で決めるといった感じです。
メソッドの中身までは書かず、必要なinterface型とクラスを作っておきます。
クラスの責務、境界、入出力、依存関係がざっくり見える状態にする感じです。
まず自分の引き出しからインターフェースとクラスを作って、AIにレビューを依頼できるところまで形にしてあげます。
作ったインターフェースとクラスをAIにレビューさせて、抜けている部分や別案があれば自分で直します。
この段階で期待する入力と出力、エラー時の動きも簡単に決めておきます。
実装が早くなった分、ここで設計に使う時間は以前より増えました。
実装
インターフェースとクラスのレビューが終わったら、そこからの実装をAIに任せています。
だいたい10から90の部分です。
このときに自分の知らない実装方法が出てくるので、その認知負荷は受け入れて勉強しています。
設計や実装の別案も出してもらって、知らなかった方法はそこから拾っています。
最後は自分で見て手直しする
AIが実装したものをレビューして、最後の仕上げは自分で行います。90から100の部分。
ここで入力と出力だけでなく、境界値やエラー時の動きもテストで確認します。
深く理解する必要がある部分はコードを読んでいきます。
また、AIが作ったコードは見た目がそれっぽくても意図と合っていないことがあります。
テストや静的解析だけでなく、増えた依存ライブラリ、セキュリティ、既存の設計方針と合っているかも見る必要があります。
すべてAIに任せるとこの最後の確認が非常に重くなったので、最初にインターフェースとクラスの箱を作っておくようになりました。（できてないときもあります）
クイズを作らせる
時間があるときは実装完了後にAIにクイズも作らせています。今のコードを渡して、以下のように頼みます。
この実装を理解しているか確認したいのでクイズを出してください。
一問ずつ出して、私が答えたあとに解説してください。
以下の観点も含めてください。
- この処理が失敗するのはどんなときか
- このクラスを消すとどこが壊れるか
- なぜこの設計になっているか
- 別案と比べた問題点は何か
- 障害が起きたらどこから調べるか
人間サボっちゃいますからね。
AIに問題を出してもらって客観的な理解度チェックをしています。
最後の手直しでわかった気になっていても、実際に聞かれると答えられないことがあります。
間違えたところはコードに戻って読むようにしています。
AIが書いたコードを受け入れる前に、自分の言葉で処理を説明させる方法を試した研究もありました。
対象が初心者かつ一つの課題での実験なのでそのまま業務に当てはめられるものではないですが、やっていることはかなり近そうです。
まとめ
AIを使うと勉強が不要になるという感じではありませんでした。
コードを書く速度より、コードを理解する速度のほうが新しいボトルネックになっています。
何をどこまで理解するかはまだよくわからないですが、影響範囲と戻せるかどうかで決めるようになりました。
弊社もまだAIの実験段階なので、もう少し使っていきます。
勉強はまだ嫌いです。
参考