AIにコードを任せても壊れない人がやっていること
AIに任せたコードが、回すたびにじわじわ壊れていく。
そんな経験はないだろうか。
仕様書を書いて、AIにコード化させて、問題が出たら仕様を直してまた回す。コードは見ない。そんな進め方を試したら、かえってコードがどんどん悪くなったという話だ。
その違和感を真正面から扱った講演がある。AI Engineer というカンファレンスで Matt Pocock が話した「ソフトウェアの基礎は、いまこそかつてないほど重要だ」というLTだ。
「specs to code」を試したら、コードが壊れていった
Matt Pocock は「Claude Code for real engineers」という、Anthropic の AI コーディングツール Claude Code を本職のエンジニア向けに教えるオンラインコースを運営している講師だ。
そのカリキュラムを組むなかで、Matt は最近の流行をひとつ試してみた。
specs to code（スペックスツーコード）と呼ばれる手法だ。
仕組みはシンプルで、まずアプリの仕様書をしっかり書く。その仕様書を AI に渡してコードに変換させる。問題が見つかったら、コードではなく仕様書のほうを直す。そしてもう一度コンパイラ（AIによるコード生成）を回す。コードそのものは、できるだけ見ない。
「これは新しいパラダイムだから、古いルールはぜんぶ捨てよう」というノリの運動だった。
ただ、Matt が実際に試したらこうなった。
「コードを見ないようにしようと思っていたけれど、結局見てしまった」
「最初は普通のコードが出てきて、もう一度回したらちょっと悪くなって、また回したらもっと悪くなって」
「気づいたら、ただのゴミができあがっていた」
会場で「同じ経験をした人」と挙手を求めると、たくさんの手が挙がった。
Matt の結論はこうだ。
コードを無視して、AI に丸ごと管理させるという発想は、結局のところ vibe coding（AI にフィーリングで書かせるやり方）の言い換えにすぎない。
仕様書だけを直し続けても、コードはむしろ劣化していく。
ここから Matt は逆方向に向かう。
「AI を信じてコードから手を引く」のではなく、「AI が真価を出せるコードベースとは何か」を、古い設計の本に立ち返って考え直していく。
古い本に書かれていた、「変えられないコード」の話
Matt がまず引っ張り出してきたのは、『A Philosophy of Software Design（ソフトウェア設計の哲学）』だった。
著者はジョン・オースターハウト。スタンフォード大学でコンピューターサイエンスを教える教授で、Tcl/Tk というプログラミング言語の生みの親としても知られている。長年スタンフォードで「ソフトウェア設計」の授業を担当してきた人物だ。
そこには「複雑さ」の定義が書いてある。
「ソフトウェアシステムの構造に関連する、システムを理解しづらく、変更しづらくしているもののすべて」
つまり、悪いコードベースとは何か、と聞かれたら、答えは「変えにくいコードベース」だということになる。
バグを生まずに変更できないコードは、悪いコードだ。
変更が容易なコードは、良いコードだ。
シンプルだが強い基準だ。
次に Matt が手に取ったのは『達人プログラマー』だった。
そこには「ソフトウェアエントロピー」という章がある。エントロピーというのは、放っておくとシステムは秩序を失ってバラバラになっていく、という物理の概念だ。
ソフトウェアもまったく同じ性質を持っている。
ひとつ変更を加えるたびに、その目の前の変更だけを考えて、システム全体の設計を考えないでいると、コードベースは少しずつ確実に劣化していく。
そして Matt は気づく。
specs to code でコンパイラ（AI）を何度も回していたとき、自分が見ていたのはまさにこのエントロピーそのものだった。
設計を考えずに、変更だけを積み上げていく。
その結果が、ゴミの山だった。
「コードは安い」は嘘だった
specs to code を支えるスローガンに「code is cheap」という言葉がある。
「もうコードは安い、いくらでも生成できる、だから人間がコードに注意を払う必要はない」という空気だ。
Matt はここに正面から異議を唱える。
「コードは安くなんかない。むしろ、悪いコードはこれまで以上に高くついている」
理由はシンプルだ。
AI は、良いコードベースのなかではきわめて優秀に働く。だが、変更しづらいコードベースのなかに放り込まれると、AI も人間と同じように壊し始める。
つまり、コードベースの質が低いほど、AI から得られる恩恵は小さくなる。
良いコードベースこそが AI の燃料だ。
良いコードベースを保つには、ソフトウェアの基礎が要る。
ここから Matt は、自分が遭遇した5つの失敗モードを順に潰していく構成に入る。
失敗1 ── AIが意図したものを作らないとき
最初の失敗は、誰でも一度は経験している。
「自分の頭のなかにはちゃんとしたイメージがあったのに、AI が出してきたものは、まったく違うものだった」
そういう体験だ。
Matt がここで持ち出すのは、フレデリック・ブルックスの『The Design of Design』に出てくる「設計コンセプト」という概念だ。
二人以上で何かを設計するとき、両者の間にはふわっとした「つくろうとしているものの理念」が漂っている。マークダウンに書ける形にはなっていない、目に見えないけれど確かに存在する共通理解。それが設計コンセプトだ。
AI と仕事がうまくいかないとき、何が起きているのか。
人間と AI のあいだで、設計コンセプトが共有できていない。
Matt の解決策は、たった数行の指示を AI に渡すことだった。
スキルの名前は grill me。「徹底的に問い詰めろ」という意味の名前だ。
中身はこんな短い指示だ。
「この計画のあらゆる側面について、共通理解に達するまで、容赦なく私にインタビューせよ」
「設計の枝分かれを一つひとつ歩き、決定どうしの依存関係を順に解いていけ」
これだけで、AI は40問、60問、ときには100問もの質問を投げ返してくる。
Matt が公開したスキルのリポジトリは、GitHub で 13,000 スターほど集めてバズった。それくらい刺さっている人が多いということだ。
このやり取りで生まれた会話は、そのまま PRD（プロダクト要件定義書）にも、Issue にも変換できる。
Matt はここで、Claude Code の標準機能である plan モードに小さな批判を加えている。
「plan モードはアセットを作りたがりすぎる」
つまり、すぐに「計画書」というドキュメントをアウトプットしようとしてしまう。
それよりも、共有された設計コンセプトに先にたどり着くほうが大事だ、という主張だ。
失敗2 ── AIが冗長になるとき
二つ目の失敗は、もう少し地味だが厄介だ。
「AI が出してくる文章やコードがやたらに長くて、自分との会話が噛み合わない感じがする」
Matt はこの感覚を、ベテランの開発者ならよく知っているはずだ、と話す。
ドメインエキスパート（業務知識を持っている依頼主）と仕事をするときの、あの「言葉の壁」と同じだ。
たとえば半導体まわりのアプリを依頼されたとして、開発者は専門用語をうまく咀嚼できない。専門家のほうも、開発者が書いたコードはわからない。両者のあいだで、言葉そのものがズレている。
ここで Matt が引っ張ってくるのが、DDD（ドメイン駆動設計）の「ユビキタス言語」という考え方だ。
ユビキタス言語とは、開発者の会話、コードのなかの表現、そして業務の専門家との会話、そのすべてが同じ用語で動く状態のことを指す。
それを AI とのやりとりに適用したらどうか。
Matt が作ったのは、コードベースを走査して、出てくる用語を集めてマークダウンの表にまとめてくれるスキルだった。
そうしてできた用語表を AI に渡し、自分でも開いておく。
AI の思考のログを読んでいると、こんな変化が見えた。
計画の質が上がる。
そして、AI 自身の思考が冗長でなくなり、計画と実装のズレも小さくなる。
人間と AI で、まず使う言葉を揃える。
そのうえで設計を話し合う。
これだけで、出力の精度はだいぶ変わる。
失敗3・4 ── 動かない、テストしづらい
三つ目の失敗は「ちゃんと作ったはずのものが、なぜか動かない」だ。
Matt の処方は王道だ。
TypeScript（型のある JavaScript）のような静的型を使う。
フロントエンドなら、AI にブラウザを触らせて挙動を確認できる環境を用意する。
自動テストを書く。
ただ、ここで Matt は LLM の悪い癖を指摘する。
AI はせっかくフィードバックループ（型エラーやテスト結果といった、即座に返ってくる確認の仕組み）があるのに、それをうまく使いきれない。
一気に大量のコードを書いてしまい、最後になって「あ、型チェックしていなかったな、テストも回しておくか」と思い出すような働き方をする。
『達人プログラマー』にぴったりの表現がある。
「ヘッドライトの先を走ってしまう」
夜道で、自分が照らせる範囲よりも速いスピードで走ってはいけない。フィードバックの速さが、そのままあなたの速度の上限なのだ。
四つ目の失敗は、その自然な続きだ。
「テストを書こうにも、テストすること自体が難しい」
テスト設計には、ユニットの大きさをどうするか、何をモックするか、どんな振る舞いを検証するか、たくさんの相互依存した判断がある。
Matt の経験則はシンプルだ。
良いコードベースは、テストしやすいコードベースだ。
ではテストしやすい構造とは何か。
ふたたびオースターハウトの本『A Philosophy of Software Design（ソフトウェア設計の哲学）』に戻る。「ディープモジュール」という考え方だ。
ディープモジュールとは、中身に多くの機能を抱えながら、外から見える窓口（インターフェイス）はとても小さい部品のことだ。逆に「シャローモジュール」は、中身がそれほどないわりに窓口だけがやたら複雑な部品を指す。
AI に任せると、放っておいてシャローモジュールだらけのコードが出来上がりやすい。小さな部品がたくさん散らばっていて、それぞれが互いに薄く絡みあっている。
そういうコードベースを AI に探索させると、目的のロジックにたどり着く前に迷子になる。依存関係を理解できず、勝手な変更を入れる。結果としてバグが増える。
ディープモジュールで構成されたコードベースは違う。
中身は太く、入り口は細い。
テストはその細い入り口に対して書けばいい。中身がどう変わっても、入り口が変わらないなら振る舞いは保証される。
Matt はここでも、シャローからディープにコードベースを整える専用のスキルを作っている。
失敗5 ── 脳が追いつかないとき
ここまでの失敗を片づけても、最後にもうひとつ、いちばん深い問題が残る。
人間の脳のほうが、追いつかなくなる。
「これまでで一番疲れている」と感じている人はいないだろうか、と Matt は会場に問いかける。
たくさんの手が挙がった。Matt 自身も同じだという。
書けるコードの量が増えれば、レビューしなければならない量も増える。AI と人間がいっしょに、コードベース全体を頭のなかに保持しようとしてしまう。
ディープモジュールが効くのは、ここでもだ。
中身が一定の太さでまとまっていると、人間はそれを「グレーボックス」として扱える。
グレーボックスとは、中身を完全に見るわけでもなく、完全に無視するわけでもなく、外側の振る舞いを確かめれば中身は AI に任せていい、という扱い方だ。
「私はインターフェイスを設計する。実装は AI に任せる」
これが Matt の五つ目の失敗への答えだ。
もちろん、金融処理のように壊せない領域はこの限りではない。だが、多くのモジュールではこの分業が成立する。
人間の脳を救うのは、設計の節度だ。
設計に毎日投資すること
最後のメッセージは、ケント・ベックの言葉だ。
ケント・ベックは TDD（テスト駆動開発）やエクストリームプログラミングを広めたことで知られるエンジニアで、現代のソフトウェア開発のスタイルに大きな影響を与えた人物だ。
「システムの設計に、毎日投資せよ」
Matt は specs to code の問題を、この言葉でひと言にまとめる。
specs to code は、設計から手を引いている。divest している。
それは投資の真逆だ。
Matt はこの講演を、ひとつの比喩で締めくくった。
AI を、現場で実際にコードを書いてくれる、戦術担当の有能な兵卒だと考えてほしい。
「兵卒の上には、戦略を考える人間が必要だ。そしてそれはあなただ」
戦略を担うために必要なのは、20年以上前から使われ続けてきたソフトウェアの基礎スキルだ。良いコードベースの定義、共通言語、TDD（テスト駆動開発）、ディープモジュール、毎日の設計投資。
どれも、新しい話ではない。
新しい話ではないからこそ、AI 時代でも揺るがない。
まとめ
ここまでの内容を振り返るとこうなる。
specs to code に違和感があるなら、その勘は正しい。コードを見ないという発想は、設計から手を引くことと同じだ
AI が壊さないコードベースをつくるための知恵は、すでに古典のなかにある。複雑さの定義、共通言語、ディープモジュール
「設計はあなたが、実装は AI が」という分業を意識すると、人間の脳の負荷も下がる
Matt 自身が公開しているスキル群は GitHub の Mac PCO skills、ニュースレターは aihero.dev で見られる
ソフトウェアの基礎は、AI 時代になって陳腐化したわけではない。むしろ、こうしたスキルを持っている人ほど AI を強く使いこなせる、という話だ。
元の動画も短くて熱量があるので、ぜひ見てみてほしい。
元動画: "Software Fundamentals Matter More Than Ever" — Matt Pocock