はじめに

ハッカソン盛り上がってますね🙌🏻

私も仕事ではAIフル活用していますしとっても便利なんですが、完走前のスクール生がやるなら注意しておいた方がいいと思うことがいくつかあるので注意喚起の意味も込めて書いておきます。

12章のレビュールール追加のお願いもその対策として追加してもらいました。

私の黒歴史、githubなので当然残っていて探してきましたので晒しながら書いていきますw
何が問題となるかも書いているのでShiftB受講生のハッカソン参加者には特に！ぜひしっかり読んでいただきたいです、、🥹

レビューの粒度

まずは差分の量を意識しましょう。

PRのページの右上の方にある緑の数字が変更で追加した行数、赤が削除した行数です。
基本的に緑を見てください。緑が1000行を目安でお願いします。

これ私の激ヤバ黒歴史です。
悪すぎる例です。1万行超えwブランチ名適当すぎw
絶対に真似しないでください！！

こんなPRを仕事でやったら見てもらえないと思いますし、私も絶対に「これは無理です、PR分割してください」って言います🙈

ルールとしては1000行以内となりましたが、私の現場では400行程度が目安です。

理由は差分が大きいとレビューの密度が落ちるからです。

人間は一度に理解できる情報量に限界がある
大きいPRは流し読みになりやすい
結果としてバグを見逃す確率が上がる

データもあるので参考に。。

Next.jsでAPIとフロント両方同時に1ブランチで開発しているケースが多いと思うので、400はちょっと厳しいだろうなって思うのですが、フロント/バック各400行で少し多めに見て1000行は全然妥当かなと思っています！！

コミットの粒度

一つ動いたと思ったらコミット&プッシュしてPR作成して今差分どれくらいかなって確認するようにしたら、この辺で一回レビューしてもらった方がいいかなと気をつけやすいかなと思います。

「ここまでやりたいけど大きくなる！」って時はコメントで

 // todo: API作ったら関数内の処理書く

とか書いておけば、このPRのスコープ外であることがレビュワーにも伝わります。

早めにPRあげてレビューこまめに受けるのが無難です。

スクール生のバイブコーディングで気を付けること

そもそもAIで生成されるコードは過剰な型フォールバック、無駄な型のアサーション、いらんロジックを出力、キモい型定義などなど結構めちゃくちゃやってきます。

指示の設計がちゃんとしていないほど、汚いコード出力されます。
既存のコンポーネントも言わないと使ってくれないです。
基本的に指示しない限りはコンポーネント切り出したり共通化とかもしてくれないです。
つまり設計して指示する能力とレビューする能力が試されるわけです、、

果たして自分でコード書いてアプリ作り切った経験のない人が読んでレビューできるでしょうか、、？
しかも大量に生成されて巨大になりがちですし、差分大きいとちゃんと処理を追って見れないのが正直なところです。

バイブコーディングするなら、決してページ単位にせずに！小さめを意識して！機能ごとに！！ブランチ切って開発することをお勧めします。

完走前のバイブコーディングを個人的には推奨はしません。

レビュワーの立場の本音

大きいPR(1000行超)きたら巨大PRきた!!!!!こんなデカイと負荷かかるなぁ、全部ちゃんと見れるかな。。。です。
小さめのPR(500未満)が毎日来るなら、いいサイズ感で最高！見れる自信ある！って感じで全然welcomeです🥳

回数多くて悪いなとか思う必要は全くないので、必要な機能を考えつつこまめにレビュー依頼出してください！！！

理解できないままレビュー提出

これは絶対やめてほしいです。
レビューを受ける効果が9割くらい減ると思います。
「あとで理解したらいいかな」って思うかもですが、多分できた気にはなるけど正しく理解できてない状態になるだけだと思います。

「この処理は何のためにしていますか？」「どういう意図でこれ書いてますか？」って聞かれて答えられない状態で提出はしないでくださいね🥹(質問されたけどわからないからAIに聞いて質問に答えるのはもう論外です。)

AIに対して「これいらんやろ、こうした方がいいやろ」って言って、AIが対抗してきても「あなたが間違ってる、hogehogeじゃないか。おかしいだろ」と言い切って「その通りです！」と言わせるくらいになっておきましょう。

その自信がないなら、まだバイブコーディングするのは早いかもしれないです。

「読んで流れは理解できるけど正しいのかはわからない」とかもあると思うので、わからないけどAIが出してるし動くからOKの状態は学習段階では避けておきましょう。

勘違いしないでほしいこと

「そういうお前も1万行のPR出してるじゃんw」と思いますよね、わかります。

私のこの黒歴史は、バイブコーディングなんて言葉もなかった時代に、約2ヶ月間、あぁ動かねぇなんでぇぇぇぇってのたうち回りながら1行1行自分で調べて書き殴った1万行です。

あの頃はスクール内の先輩もいるのかいないのかわからない、誰がどんな感じで進めてるかわからない、正解がわからない中で、必死に自走した結果の塊がデカかったって感じです。

対して、AIで生成した中身もよくわかってない1000行を丸投げするのは、ただの「思考停止」です。

PRがでかいのが問題であることは変わらないのですが、質は全然変わってくると思うので悪しからずw

セルフマージとレビュー依頼の壁

SNSや個人開発界隈で見かける爆速開発は、大抵が「セルフマージ（自分さえ良ければOK）」の世界だと思います。

でも、スクールや仕事で他人にレビューを求めるのは、他人の脳のリソースを借りるということですよね。
プロの世界で、理解していないAI生成コードを巨大PRで投げつけるのは、自分の責任を他人に押し付けているのと同じだと思います。

セルフマージ：自己責任
レビュー依頼：共同責任

動くからいいやろで巨大PRを出すのは、プロの現場ではNG行為です。
技術力以前のところで疑問を持たれかねないので気をつけてください、、！

おわりに

今回ルールが追加されたのは、レビューのしやすさのためだけではありません。

一番の目的は、学習効率を上げるためです。

AIで生成した巨大PRだと結果として成長が遅くなります。

逆に小さく分けて出せば、1つ1つの理解が深まる → レビューの質も上がる → 修正からの学習のサイクルが早く回る!! と思います。

遠慮せず、小さく出してどんどんレビューしてもらってください！(します！)