バイブコーディングで「AIのコードを一行も読まない」現場のレビューは何を見ているのか
「コードも読まずに何がエンジニアだ」——AI駆動でSaaSを一人で作っていると、こう言われそうな働き方になる。
だが9ヶ月で一人開発を完走して確信した。レビューが要らなくなったのではない。レビューする対象が、コードから別のものに移ったのだ。
従来のコードレビュー観をアップデートしないと、AI時代のエンジニアは消耗するだけになる。
この記事は バイブコーディングで、AIのコードを読まない私が、レビューで見ている大事なポイント のダイジェスト版です。
少数精鋭時代の開発チーム像や、危ういエンジニア像の詳細は、上記の完全版をどうぞ。
コードは見ない。でも、穴があるのは知っている
最初に誤解されたくないことを書く。
「AIのコードは完璧だから読まない」とは一言も言っていない。むしろ逆。生成AIが吐くコードには穴がある。論理の抜け、考慮の漏れ、破壊的実行——1つのAIに任せれば、そのAIの癖をまるごと引き受けることになる。
ではその穴をどうするのか。答えは「自分の目で一行ずつ追う」ではない。
複数のAIで、レビューを循環させる。
あるAIが書いたものを別のAIが叩く。それをまた戻して直す。三すくみで穴を潰すのが基本だ。仕組みの詳細は要件定義が全て——AI駆動開発を三すくみレビューで回した話でも書いた。
穴を潰す仕組みがあるから、コードそのものを一切見ない。コードを見ないのは手抜きではなく「設計」の話だ。
やったのは「コードを書く」より「場を整える」こと
コードを見ない代わりに何をしていたか。プロダクトのオーナーとしてAIがスムーズに走れる場を整えていた。整えたのはざっと3つ。
| 整えるもの | 中身 |
|---|---|
| 任せ方の設計 | どのAIに何を任せるか。どこからは人が判断を握るか |
| 進め方のルール | どういう順番で開発を進めるか。どこで一度立ち止まって確認するか |
| 脱線を防ぐ枠組み | AIが暴走・脱線しないよう、先に道を作っておく |
バイブコーディング界隈ではこの枠組みを「ガードレール」や「Skill」と呼ぶ。呼び方はどうあれ、やっていることは同じだ。コードを書くより、AIが気持ちよく走れる場を整える。オーナーの仕事はいつのまにかそっちに移っていた。
レビューの対象が、根本から変わった
ここが一番伝えたい変化。昔と今で、レビューの中身はこう変わった。
| 昔のレビュー | 今のレビュー | |
|---|---|---|
| 見るもの | この実装は正しいか。バグはないか | AIが意図した仕組みやルールに沿っているか。脱線していないか |
| 対象 | コード一行ずつ | 開発の進み方そのもの |
| 喩え | 職人の手元を覗き込む | 工房全体が設計図どおりに回っているか見る |
個々の部品は信頼できる仕組みに任せる。自分は、全体が意図からズレていないかだけを見張る。
結局レビューで見ているのは、この大事なポイント1つだけだ。
無数のコードではなく、AIが意図どおりに走っているか。
それさえ外さなければ、一行ずつ追わなくても品質は守れる。
▶ 少数精鋭時代の開発チーム像や、危ういエンジニア像の詳細はこちら → バイブコーディングで、AIのコードを読まない私が、レビューで見ている大事なポイント
「一人開発の特殊な話」で終わらせないでほしい
「一人でSaaSを作るなんて、自分には関係ない」と感じた人もいるはず。だが、待ってほしい。持ち帰ってほしいのは規模の話じゃなく、向き合い方のマインドだ。
やっていることを小さくほぐすとこうなる。
- AIに何を任せ、何を任せないかを決めた
- 脱線しないようルールを敷いた
- 出てきたものに責任を持てる仕組みを作った
これは一人開発じゃなくてもできる。今いる現場でAIへの任せ方を整理してみる。チームのレビューにAI前提の一工夫を足してみる。小さな範囲でいい。
「AIを使う」から「AIを統制する」へ、立ち位置を半歩ずらす。
その半歩がAI時代の成長戦略になる。コードを速く書く競争で消耗するのではなく、AIをどう御すかに軸足を移す。この向き合い方の差が、数年後に大きな差になる。
危ういのは、どっちのエンジニアか
2人を思い浮かべてほしい。
| Aさん | Bさん | |
|---|---|---|
| 強み | 一行ずつ丁寧に読める | 行は追わない。仕組みとルールで品質を守る |
| 全体俯瞰 | できない | できる |
| AIとの関係 | AIに肩代わりされる側 | AIを統制する側 |
少し前ならAさんが信頼された。だがAIが実装を担う今、評価は逆転していく。
Aさんの仕事はAIが肩代わりできる領域に近い。一方、Bさんの仕組み作りやルール整備はAIには丸投げできない。何を作るか、何を作らないか、どう統制するか——ここは人が決めるしかない。
スキルシートに書くべきは「統制」だ
この変化はスキルシートの書き方にも直結する。
多くの人はこう書く。「Cursorを使用」「ChatGPTでコーディング」。だがツールを使ったことはもう差にならない。使うのが当たり前になってきているからだ。
差がつくのはAIをどう統制したかだ。
| Before（ツール名だけ） | After（統制を語る） | |
|---|---|---|
| 例文 | 生成AIを活用して開発を効率化 | 複数のAIでレビューを循環させ、コードの穴を潰す体制を設計。開発ルールを整備し、脱線を防ぎながら一人でSaaSを開発した |
| 読み手の印象 | ツールを触った | AIをどう統制して何を成したかが見える |
これからのスキルシートで強いのは、間違いなく後者だ。
統制した経験を継続的に記録するなら、フォーム入力で体裁が自動統一される Skillsheet-Port のようなツールが使える。AI活用欄を「ツール名の羅列」から「統制プロセスの記録」に格上げするための土台になる。
まとめ：レビューの解像度を、上げる
- AIのコードを読まないこと自体は手抜きじゃない。穴を潰す仕組みがあるかどうかが分かれ目
- レビューは消えていない。対象が「コード」から「仕組みへの忠実さ」に上がった
- やることの本質は3つ：①任せ方の設計 ②進め方のルール ③脱線を防ぐ枠組み
- 規模の話ではなくマインドの話。「AIを使う」から「AIを統制する」へ半歩ずらす
- スキルシートには「使った」ではなく**「どう統制したか」**を書く
次にスキルシートを開いた時、考えてみてほしい。「AIを使った」と書くのか、それとも「AIをどう統制したか」を書けるのか。まだ書けないなら、明日の現場でその半歩を踏み出すところから始めればいい。
▶ 完全版ガイドはこちら → バイブコーディングで、AIのコードを読まない私が、レビューで見ている大事なポイント
▶ 無料でスキルシートを作ってみる → https://www.skillsheet-port.com/