最近、AIでコードを書くのがかなり普通になってきた。
Cursor や Claude Code みたいなツールを使えば、数分で数百行〜数千行のコードが出てくる。
実際かなり便利だし、自分も日常的に使っている。
ただ最近、OSS や会社の現場を見ていて感じるのは、
「コードを書く速度」より
「コードベースを維持する能力」のほうが重要になってきている
ということ。
AI が怖いのは「バグ」ではない
AI のコードって、意外と普通に動く。
テストも通るし、型も合うし、一見ちゃんとして見える。
でも本当に怖いのはそこではなくて、
-
よく分からない abstraction が増える
-
微妙に似た utility が乱立する
-
設計思想がバラバラになる
-
誰も全体像を理解できなくなる
-
「なぜこうなってるか」が失われる
みたいな「コードベースの崩壊」が起きること。
AI は「局所的に正しいコード」を作るのは得意。
でも「システム全体として自然か」はあまり見ていない。
OSS で起きていること
最近の OSS maintainers、かなり大変そう。
AI生成っぽい PR が大量に来るけど、
-
動く
-
一見まとも
-
でもプロジェクトの思想に合ってない
みたいなケースが増えている。
結果として、
-
PR サイズを小さくしてほしい
-
なぜこの変更が必要か説明してほしい
-
issue で先に議論してほしい
みたいな流れがかなり強くなっている。
コードそのものより、
「この人は理解して変更してるか？」
を見る方向に寄っている感じがある。
Big Tech も「レビュー側」に重心が移っている
「AI がコードの 80% 書いてる」みたいな話は最近よく出る。
でも実際に重要なのはそこではなくて、
最終的な merge の責任は人間が持っている
という部分だと思う。
結局、
-
architecture
-
dependency
-
abstraction
-
将来の保守性
みたいな判断は、まだかなり人間依存。
なので今後エンジニアに求められるのも、
-
実装速度
-
タイピング速度
より、
-
レビュー能力
-
設計力
-
「変な匂い」を感じる力
-
システム理解
になっていきそう。
小さい組織こそ、今ルールを作ったほうがいい
大企業は process で守れるけど、小さい組織は壊れると速い。
なので個人的には、AI導入より先に
「どうレビューするか」
を決めたほうがいいと思っている。
自分が今かなり重要だと思っているルール
1. 説明できないコードは merge しない
これが一番大事かもしれない。
-
なぜこの abstraction が必要か
-
なぜこの dependency を追加したか
-
なぜこの設計にしたか
を説明できないなら、たぶん理解していない。
AI生成コードでも、自分の言葉で説明できる状態までは持っていく。
2. 「賢そうなコード」より「普通のコード」を優先する
AI はすぐ abstraction を増やす。
でも実際には、
-
少し重複していても分かりやすい
-
flow が追いやすい
-
junior が読める
コードのほうが、長期的にはかなり強い。
最近はむしろ「どれだけ abstraction を減らせるか」のほうが重要になってきた気がする。
3. PR を小さくする
AI で巨大 PR を作るのは簡単。
でもレビュー品質は確実に落ちる。
なので、
-
小さく出す
-
段階的に出す
-
refactor と feature を分ける
はかなり大事。
4. 暗黙知を減らす
AI は「空気を読む」のが苦手。
だから、
-
この repository の思想
-
naming
-
dependency rule
-
folder 構成
-
など
みたいなのを明文化したほうがいい。
人間向けというより、AI 向け documentation に近い感覚。
AIに対しては、最近こういう見方
AI を「爆速な junior engineer」として扱う
感覚がかなりしっくり来ている。
実装は速いし、それっぽいコードも大量に出してくれる。
ただ、
-
repository の文脈は完全には理解していない
-
長期保守の責任は持たない
-
自信満々に間違える
みたいな特徴もある。
なので、
理解していない巨大変更を core に merge しない
みたいな、普段 junior 相手に自然にやっていることを、AI 相手にもそのまま適用するのが大事なんだと思う。
AI はかなり便利だけど、ownership まで代わりに持ってくれるわけではないので。
Discussion