AI × Engineering
AIが書いたコードを、人間はレビューできない
速く書けるようになるほど、誰も読めなくなる。生産性のパラドックスの話。
スクロール
この記事の学習ループを notaps で試す反復接触を、音声と意味の小さな反復接触に変える。20言語 / オフライン / 広告なし / 買い切り。
App Storeで試すこの記事の要点
Xの文脈から来た人へ
AIに任せるほどコードは書ける、でも書けたコードを誰も理解できない。生産性のパラドックスについて。
なぜ起きるか
学習の問題は、才能より接触回数と開始摩擦で説明できることが多い。
何を変えるか
完璧な長時間学習より、言葉が生活の中に戻ってくる設計を作る。
notapsの役割
反復接触 を音と意味で何度も通し、次の学習を軽くする。
AIが書いたコードを人間がレビューできない問題
🤖
症状 01
PRが大きくなった
AIに「このバグ直して」と言うと、500行のdiffが返ってくる。動く。テストも通る。だが何が起きているのか、レビュアーには追えない。
症状 02
「LGTM」が増えた
読まずに承認する文化が定着する。コードは書けるが、コードベース全体を理解している人はチームに一人もいない、という状態が生まれる。
症状 03
1ヶ月後の自分も読めない
「AIが書いた」コードを、後で改修するときに自分でも読めない。結局AIに「これ説明して」と聞くことになる。理解の所有権を手放している。
73%
生産性 vs 理解度
AIアシストで「書く速度」は劇的に上がる。だが「コードベースの理解度」を自己評価で測ると、6ヶ月前より下がっているチームが73%。
— 社内調査・サンプル少 / 仮の数字
“
コードは書かれる回数より、読まれる回数の方が10倍多い。書き手の効率化を読み手の負担で支払っている。
— どこかで読んだ言葉
🪞
鏡を見る、というメタファー
ワークフロー
AIをどう使うか、で結果が分かれる
Anti-pattern
「全部書いて」ワークフロー
プロンプト一発で大きなdiffを生成し、動いたら承認。AIに考えてもらっている時間が長く、自分の理解が育たない。
推奨
「一緒に書く」ワークフロー
AIには小さな塊（数十行）を出してもらい、毎回読んで理解してから次へ。書く速度は犠牲になるが、理解度の所有権を保てる。
1/3
現実的な落としどころ
速度を1/3落とすかわりに、理解度の所有権を保つ。これが今のところ私が見つけているバランス。