「バイブコーディングはスパゲッティコードになる」らしいので、パスタを折るアプリを作った
「バイブコーディングはスパゲッティコードになる」らしいので、パスタを折るアプリを作った
こんにちは、黒パグです🐾
Xを眺めていたら、また見事な図が流れてきた。
左側には配線がぐちゃぐちゃに絡まった建物。右側には、ケーブルがまっすぐ通った美しい建物。
左がバイブコーディング。右がソフトウェアエンジニアリング。
別の版では、左が従来のエンジニアリングで、右が「エンジニアリング＋AI」になっていた。建物がロケットになっている版まである。何パターンあるんだこれ。
ただし、どの版でも左側の地下だけは元気よくスパゲッティである。
見た瞬間に思った。
は？ 人間が書いた大規模コードも、普通にもっと絡まってるだろ。
一部の天才エンジニアが、十分な時間と予算と権限を与えられ、組織まできれいに整えた理想例を、世の中の「ソフトウェアエンジニアリング」全体と混ぜてはいけない。
現実には、昨日まで別部署だった機能が今日から同じ画面に入り、三年前に退職した人のコメントが唯一の仕様書になり、誰も消せない条件分岐が静かに本番を支えている。
人間は歴史を作る。
コードにも歴史を作る。
そして歴史は、だいたいきれいに整列しない。
スパゲッティコードは、下手な人が書く長いコードではない
スパゲッティコードという言葉は、処理やデータが麺のように絡まり、どこか一つを直すと別の場所まで壊れるコードを指す。
初心者向けの説明では「一つのファイルへ全部書くとスパゲッティになります」と言われることが多い。
半分は合っている。
ただ、ファイルを細かく分ければ解決するわけでもない。十個のファイルが同じデータを勝手に書き換え、一個の仕様変更で十個すべてを修正するなら、皿を十枚に分けただけで麺はまだつながっている。
本当に困るのは、次のような状態だ。
どこを直せばよいか分からない
直した影響がどこへ届くか分からない
失敗したとき、どこで失敗したか分からない
何を確認すれば完成なのか分からない
分からないが、動いているので誰も触らない
最後のやつが一番強い。
AIを使えば右側になるのか
ならばAIにコードを書かせれば、最初からきれいな右側の建物になるのか。
ならない。
AIは、こちらが渡した要求をものすごい速度で形にする。要求の境界が見えていれば、実装も速い。テストも作る。人間が見落とした条件を指摘することもある。
一方で、要求が曖昧なら、その曖昧さも高速で増幅する。
たとえば、こう頼む。
> ログインできて、売上が見られるアプリをいい感じに作って。今日中。
短くて気持ちのよい指示だが、決まっていないことだらけである。
誰がログインするのか。誰の売上を見るのか。閲覧だけなのか。金額は税込みか。日付の境界は日本時間か。データが取れなかったときにゼロ円と出してよいのか。
AIは空白を埋めるのが得意なので、止まらずに作れる。
そこが便利で、そこが怖い。
人間が一週間かけて作っていた暗黙仕様を、AIなら午後のおやつまでに大量生産できる。
AIはスパゲッティを片づける機械ではない。製麺速度を上げる機械にもなる。
じゃあ、パスタを折ればいい
ここまで考えたところで、普通の人なら設計論の記事を書く。
黒パグは違った。
スパゲッティコードが問題なら、パスタを先に折ればいい。
あ。
アプリができた。
名前は「PASTA BREAKER」。
雑な開発指示を入力して、危険度や設計方針を選び、「パスタを折って生成」を押す。すると、曖昧な要求を、実装担当へ渡せる指示へ分解してくれる。
もちろん、パスタを折る以上、イタリアへの配慮は欠かせない。
リセットボタンを押すと、こう怒られる。
> Spezzare la pasta?! Vuoi morire?
>
> パスタを折るだと？ お前、死にたいのか？
画面の下では、カルボナーラの作り方がイタリア語で延々と流れる。生クリームは禁止である。
何のために実装したのかは分からない。
必要だった。
パスタを折る前に、要求を折る
このアプリが実際にしているのは、コードの自動修正ではない。
実装を始める前に、雑な要求を小さく折っている。
難しく見えるが、初心者が最初に確認することは三つでいい。
1．誰が、何をするのか
「ログイン機能」ではなく、「一般利用者がメールアドレスでログインする」のように書く。
管理者もいるなら分ける。他人のデータを見られるのかも決める。
2．失敗したら、どうなるのか
通信に失敗したとき、成功したふりをしない。保存できていないなら「保存しました」と出さない。
エラーをゼロにするのではなく、失敗したときに戻れる道を作る。
3．何を見たら完成なのか
「いい感じに動く」は確認できない。
ボタンを押したら画面が変わる。未ログインなら入れない。データがなければ空の表示になる。ここまで具体的なら、人間もAIも同じ場所を確認できる。
全部を完璧に決める必要はない。
分からないところを、分からないまま隠さない。それだけでも麺はかなり短くなる。
そして、パスタが押せなかった
完成したPASTA BREAKERを「無駄なもの研究所」の本館へ展示した。
動作確認もした。公開もした。
ところがiPadから本館を開くと、パスタを押しても何も起きない。
スパゲッティコード防止アプリの入口が動かない。
ネタとしては百点である。
製品としては零点である。
原因はPASTA BREAKER本体ではなかった。本館から別の展示へ移動するリンクの扱いが、iPadのアプリ内表示と合っていなかった。
ここで大事なのは、「ボタンが押せない」という症状だけを見て、パスタ側のコードをいじらなかったことだ。
玄関の鍵が開かないからといって、台所を解体してはいけない。
本館の内部展示と外部展示を分け、外へ移動するものだけ新しい画面で開くように修正した。もう一度iPadで確認する。今度は開いた。
テストも一件落ちたが、こちらは製品コードではなく、テスト用に作った簡易ブラウザが古かった。そこも分けて直し、全件通した。
「エラーが出た。AI、全部直せ」は速い。
速いが、無関係な場所まで直すことがある。
症状が出た場所と、原因がある場所は同じとは限らない。これはAI以前から変わらない。
右側の建物は完成しない
最初に見た図へ戻る。
左側はぐちゃぐちゃ。右側は整然。比較図としては分かりやすい。
でも現実のコードは、右側へ完成して終わるものではない。
機能が増える。担当者が替わる。外部サービスの仕様が変わる。昨日の正解が、来年の邪魔になる。
人間が書いても絡まる。AIが書いても絡まる。
大事なのは、絶対に絡ませないことではなく、絡まったときに一本ずつ追えることだと思う。
どこから入ったデータなのか。誰が変更できるのか。失敗はどこへ残るのか。何を確認して「終わった」と言ったのか。
そこが見えれば、全部を建て直さずに済む。
見えなければ、右側に見える建物の壁を開けた瞬間、たぶんパスタが出てくる。
まとめっす
Xでスパゲッティコードの図を見た。
「人間のコードも普通に絡まるだろ」と思った。
パスタを折ればよいと気づいた。
アプリができた。
そして、そのアプリへのボタンが押せなかった。
何を言っているのか分からないと思うが、開発とはだいたいこういうものである。
AIを使うと、コードを書く速度は上がる。
同じ速度で、勘違いを実装する速度も上がる。
だから、いきなりコードへ投げる前に、要求を少しだけ折る。
誰が使うのか。
失敗したらどうなるのか。
何を見たら完成なのか。
その三つだけでも、AIとの開発はかなり変わる。
なお、黒パグはスパゲッティを折ることには反対です。
念のためイタリア語でも書いておく。
> Agli italiani: mi dispiace. E sia chiaro: io, Kuro Pug, sono contrario a spezzare gli spaghetti.
パスタは鍋へ。
コードは追跡できる場所へ。
それではまた🐾
関連リンク
• PASTA BREAKER
• 無駄なもの研究所
• Zenn技術解説「パスタを折ったらスパゲッティコードが減った――ネタアプリを本気で設計した話」
#生成AI #バイブコーディング #スパゲッティコード #プログラミング #プログラミング初心者 #アプリ開発 #Webアプリ開発 #ソフトウェア開発 #ソフトウェア設計 #デバッグ #JavaScript #フロントエンド #GitHub #デプロイ #プロンプトエンジニアリング #AI活用 #エンジニア #技術記事 #パスタ #無駄なもの研究所
おまけ
元ポストはこれ↑
それよりもトレンドのケンタが黒パグの食欲を直撃。
ものすごい勢いで買いに行ったら混んでた。数年振りのケンタはマジで美味かった😆
