はじめに
私はいわゆるエンジニアではありません。
コードが書けるかと言われると、正直 Hello Worldが限界です。
そんな自分が、生成AIの登場によって「アプリやツールを作れる側」に立てるようになりました。
いわゆる バイブコーディング です。
バイブコーディングは、間違いなく革命だった
最初は感動でした。
- 「こんなツールを作りたい」と日本語で書く
- 生成AIがコードを吐く
- 動く
正直、「もうプログラミング学習いらないのでは？」とすら思いました。
実際、小さなツールや簡単なWebアプリなら 驚くほどのスピードで形になります。
ある規模を超えた瞬間に壊れる
問題はここからです。
機能が増え、
- 画面が増え
- 状態が増え
- 分岐が増え
…ていくと、地獄が始まりました。
- 修正すると別の場所が壊れる
- 生成AIに直させると、さらに別の場所が壊れる
- なぜ壊れたのか、自分でも分からない
コードを見ても理解できません。
今思えば当然で、 自分は「何を作るか」を言葉にしていなかった からです。
プロが見たら卒倒するコードになる理由
今なら分かります。
バイブコーディングでは、
- 目的
- 仕様
- 制約
を頭の中のふんわりしたイメージのまま進めがちです。
生成AIはそれを補完してくれますが、 曖昧さまで含めてコード化してしまう。
結果、
- 一貫性のない設計
- その場しのぎの修正
- 文脈を失ったコード
が積み上がります。
これはスキルの問題というより、 開発の進め方の問題 でした。
じゃあどうするか？ → 仕様駆動開発
私が行き着いた答えはシンプルでした。
コードを書く前に、仕様を書く
いきなり実装を投げない。
まず生成AIに投げるのは、
- このツールは何を解決するのか
- 何ができて、何ができないのか
- どんな操作フローなのか
という 文章の仕様です。
ド素人なりの仕様駆動開発
私はプロの設計書なんて書けません。
なので、やっているのはこれだけです。
- 機能を箇条書きにする
- ユーザー操作を順番に書く
- 例外ケースを日本語で書く
それをそのまま生成AIに渡します。
すると、
- コードが安定する
- 修正指示が明確になる
- 生成AIとの会話が「会話」になる
バイブコーディングはやめていません。
使い方を変えただけです。
おわりに
これは、
- プロのエンジニアになる話ではありません
- 生成AIを否定する話でもありません
むしろ逆で、
生成AIを本当に活かすために、人間側がやるべき仕事が見えた
という話です。
バイブコーディングは入口として最高です。
でも、ずっとそこに居続けると必ず詰まる。
その一歩先にあるのが、 仕様駆動開発 なのだと思っています。