AIで対応できない領域

Git管理。 AIが散らかしたコードを「人間が保守可能な美しい構造」に維持・整理する庭師（ソフトウェアアーキテクト）の需要は、これから爆発的に高まります。

ルール

SOLID原則 インデントルール HTML: インラインスタイルを使用しない。 バックエンド: ハードコーディング禁止。

課題

作業者の作業スピードが速くなる → 大量のレビューが来る → レビュアー過労死

レビュー: 1段階目をAI、2段階目を人間という手法が流行る（Lineヤフー等）

コード生成が高速化しても、レビュー・テスト・デバッグが追いつかなければ、デリバリー速度は上がりません。 生産性はパイプライン全体で決まります。

AIの提案が「正しそうに見える」ことが問題を悪化させます。 明らかに間違っていれば即座に却下できますが、「95%正しい」提案は検証に最も時間がかかります。

「約9割の開発者がAIツールで遅くなっている」は本当か ── AI開発ツールの生産性パラドックスを検証する https://qiita.com/nogataka/items/d0fd2f4a9aedd01eba5c

その他

Cursor・Windsurf・Claude Code — 「どれが最強か」より「いつ何を使うか」を考える【2026年春版】 https://qiita.com/AI-SKILL-LAB/items/e9ebe3e44e6d51935a21

【GitHub】GitHubは低品質なユーザによるContributeを拒否する仕様を検討・実装中 https://qiita.com/rana_kualu/items/78fdef38b201985cb0d9

■Claude codeは大規模開発に向かないの？ https://www.youtube.com/shorts/GQY7aJUSC5s

■プログラム
・関数名とロジックが正しい関係にあること
NG: getDataなのにgetして設定してみたいなのは最悪

■開発・レビュー
プルリク前にAIにレビューしてもらうことが必須
→ それ用のプロンプトを作成して共有するのが有用。

■コンテキスト
AIはSeederも確認する。
そのためSeederの内容が適当だった場合、プログラムもおかしくなる。

■DB
・カラム
カラム名はかならず小文字にすること。
適切なカラム名にすること。略語は禁止。
これに反論してくる意見は全て無視で良い。カラムのベストプラクティスでもあるし、AI駆動の観点でもこれが100点。

データ型がかなり重要になる
数値の文字列型とかふざけたことはNG

モデルクラスやマイグレーションファイルの適切さが強烈に効いてくる。
どんなAIでもここを基軸とするため。