おっしゃる通り、Anthropicの研究などで扱われてる定義とは違いますね。 新しい取り組みの上での新しいロールを便宜上バイブコーダーと読んでるだけなので、今後呼び方も変わっていくと思います。

今必要なバイブコーダーはドメイン知識、業務知識が高く、業務設計が出来る人ですね。 エンジニアがアーキテクチャの土台やハーネスを作るので、バイブコーダーには上に乗るものを作ってもらい、エンジニアがチェックする。 これのメリットは開発工程における要件定義や画面設計などにおけるコミュニケーション、認識齟齬が激減することなんですよね。 バイブコーダーとエンジニアって対立しがちですが、そうではなく協働の形に持っていけるとそれぞれの持ち味を最大限に出来る開発体制が組めるんですよ。

設計って漠然としちゃってるので、エンジニアがやってる設計並べてみます。 「設計できる人になりたい」って相談よく受けるんですが、設計って一枚岩じゃなくて、抽象度ごとに全然違う作業が積み重なってます。 上流（何を作るか決める） ・業務設計 ・サービス設計 ・UX設計 ・情報設計 ・ドメイン設計 システム化する範囲としない範囲の線引きをするところ。ここを間違えると、下流でどれだけ綺麗に書いても死にます。 アーキテクチャ領域（全体の骨格） ・システム方式設計 ・インフラ設計 ・ネットワーク設計 ・セキュリティ設計 ・可用性/信頼性設計 ・性能/キャパシティ設計 ・コスト設計 ・運用設計 ・移行設計 「作った後どう生き延びるか」を先に決める層。 外部設計（境界を決める） ・画面/UI設計 ・API設計 ・バッチ設計 ・イベント設計 ・データ設計（概念/論理） ・認証認可 ・権限設計 ・エラーメッセージ設計 自分と外側の約束事。一度公開すると変えづらいので、実は一番慎重にやるべきところ。 内部設計（実装の構造） ・モジュール/クラス設計 ・テーブル設計 ・状態遷移設計 ・トランザクション設計 ・例外設計 ・ログ設計 ・キャッシュ設計 ・命名規約 「動くコード」と「変更できるコード」を分けるのがこの層。 横断的な設計 ・テスト設計 ・CI/CD設計 ・デプロイ/リリース設計 ・組織設計 組織設計を入れてるのは、コンウェイの法則そのままで、チームの境界がそのままシステムの境界になるからです。 AI時代に増えたやつ ・コンテキスト設計 ・エージェント設計 ・人間の介在点設計（どこに承認ゲートを置くか） ここ2年で新しく生まれた設計領域。まだ誰も正解を持ってないので、みんな模索中。 で、全部並べて気づくのは、やってることは同じだということ。 制約の中で、両立しないもののどちらを取るか決めて、その理由を残す。 一貫性か可用性か。疎結合か単純さか。今の速度か後の変更容易性か。 だから設計書は成果物じゃなくて副産物で、本体は「捨てた選択肢とその理由」の方なんですよね。 逆に言うと、トレードオフが存在しない箇所は設計じゃなくてただの作業です。 AIが作業を持っていく時代に残るのは、こっち側です。