「バイブコーディングはスパゲッティコードになる」らしいので、パスタを折るアプリを作った

「バイブコーディングはスパゲッティコードになる」らしいので、パスタを折るアプリを作った

こんにちは、黒パグです🐾

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活用 #エンジニア #技術記事 #パスタ #無駄なもの研究所

おまけ

元ポストはこれ↑

それよりもトレンドのケンタが黒パグの食欲を直撃。
ものすごい勢いで買いに行ったら混んでた。数年振りのケンタはマジで美味かった😆