AIは動くプロダクトまでは作ってくれない。それは今もあなたの仕事だ

• AIは数分でUIとデータベースを備えたプロトタイプを作れるが、最初に動くバージョンから本番品質のプロダクトまでの距離を縮めてはくれない
• 実際のプロダクトには、スケーラビリティ、エラー処理、オブザーバビリティ、セキュリティ、認証、データ構造のように、構文を書くことよりも工学的判断を必要とする問題が残る
• コンピュータサイエンスの価値は、コードの生産よりもシステムの挙動と失敗の原因を理解するメンタルモデルにあり、それを知っていてこそ非効率なクエリや競合状態を見つけられる
• 要件を機械的にコードへ移す需要は減っていくが、熟練したエンジニアは反復作業をAIに任せ、専門性が必要な問題に集中することで、はるかに速く作業できる
• AIを理解の代替として使うと、壊れたシステムの修正・拡張・引き継ぎが難しくなるため、基礎知識を先に身につけてからAIツールを活用すべき

---

プロトタイプとプロダクトの間にある隔たり

• 自然言語でアイデアを説明すれば、数分以内にUIとデータベースを備え、意図した機能を実行する動作可能なプロトタイプを得られる
• しかし、ノートPC上で動くプロトタイプは、実環境ではさまざまな問題を露呈しうる
  • 負荷に耐えられず、エラー処理も備えていない
  • APIトークンが漏えいする可能性がある
  • デモ用のデータモデルは、2人目のユーザーを追加した瞬間に破綻する可能性がある
  • 認証が検証されていない前提に依存しており、安全かどうかも不確か
• デプロイ段階に至ると、「動く」と「準備できている」の間にある大きな本番環境ギャップが明らかになる

難しい仕事はコードを書いた後にあった

• ソフトウェアエンジニアは以前から、何かを素早く動かすことはできた。実際に時間がかかる部分はその後だった
  • 規模が大きくなっても耐えられるシステム設計
  • ユーザーが想定外の経路で入ってきたときの例外処理
  • 障害発生を確認できるオブザーバビリティの構築
  • 3年後の後悔を減らすデータアーキテクチャの意思決定
• AIは最初に動くバージョンまでの時間を大幅に短縮したが、そのバージョンから本番品質のシステムまでの距離は縮めていない
• 速いリクエスト、レスポンス、結果確認の流れは、開発プロセスの残りも圧縮されたような印象を与えるが、ソフトウェアの難しい問題はそもそも構文を書くことではなかった
• 何を作り、どう構造化するか、何を先送りし、いつ断るかを決める判断力が、プロトタイプと本番システムを分ける

コンピュータサイエンスが今も必要な理由

• AI生成コードに簡単にアクセスできるようになったことで、アルゴリズム、データ構造、オペレーティングシステム、理論を何年も学ぶ必要があるのか疑問を持つ新規参入者が増えている
• コンピュータサイエンス教育の価値は、コードを書く能力だけにあるのではなく、システムがどのように動作し、失敗し、なぜその結果が生じるのかを理解するメンタルモデルを形成する点にある
• この土台があってこそ、AIが生成したコードの潜在的な失敗を見分けられる
  • 5,000万行のテーブルでフルテーブルスキャンを引き起こすクエリ
  • 同時負荷のもとで競合状態を生むキャッシュ戦略
  • 現在の要件は解決するが、次の問題をはるかに難しくするアーキテクチャ
• 基礎知識がなければ、モデルの判断に全面的に依存することになる
  • モデルは判断力ではなくパターンマッチングに基づき、意図に合っていると考えるコードを積極的に生成する
  • 生成されたコードは正しく慣習に沿っているように見えても、本番環境では失敗する可能性がある
  • 問題を見抜く知識がなければ、診断に何日もかかることがある
• 理解と成果物の距離が縮まった今は、コンピュータサイエンスを学ぶのに良い時期であり、分散システムを正しく理解した学生は、10年前よりもはるかに短い時間でそれを構築できる

自動化される仕事と拡大する生産性

• 要件を一行ずつ実装へ移す機械的なコーディング業務の需要は実際に減少しており、その領域は自動化されつつある
• 生産性分布の下位は圧縮される一方で、上位の限界は広がる
  • 現代的なAIツールを使う熟練エンジニアは、5年前には想像しにくかった速度で作業できる
  • 難しい問題が消えたのではなく、時間と注意を消耗していた機械的作業の大半が処理されるためである
  • こうして確保した時間は、本当の専門性が必要な作業に使える
• 取り残されるエンジニアはAIの使い方を知らない人ではなく、AIを理解の代替として使う人である
  • 推論できないシステムをバイブコーディングで構築する
  • 障害を修正したり、成長したシステムを拡張したりできない
  • 保守担当者に自分が作ったものを説明できない

より高い抽象化レベルで働く

• 必要な変化は新しいツールを採用することにとどまらず、基礎に根ざしたまま、より高い抽象化レベルで働くことにある
• AIを深い知識の代替ではなく増幅器として使うエンジニアは、同僚より速く先へ進める
  • モデルに何を生成させようとしているのかを理解している
  • ジュニアエンジニアのプルリクエストをレビューするように、生成コードを批判的に見る
  • 機能説明だけを渡すのではなく、アーキテクチャの観点で対話する
  • モデルの提案にいつ反対すべきかを判断する
• これは新しい能力で既存のスキルを置き換えるのではなく、既存のスキルを新しい環境に適用して、はるかに高いレバレッジを得る方法である
• プロトタイプの後にも実際の工学的判断は必要であり、この能力が、信頼できるソフトウェアをリリースする開発者とデモだけをリリースする開発者を分ける
• 学習の順序は、基礎知識が先で、AIツールはその次であるべきだ

[GN⁺]

Hacker Newsの意見

• サイドプロジェクトで、数か月かけてLLMで作ったコードを捨てようとしている。設計仕様を綿密に書き、既存のコードベース上で作業したにもかかわらず、個々の変更は論理的に見えても、全体としては複数の部分が微妙にずれた複雑な塊になってしまった。
  レポートや論文も、各節はもっともらしいが文書全体としてはどこか変に感じる。人間は細かな作業では遅くても、LLMにはまだ不可能な高次の推論をしているようだ。欠陥を指摘すると「まったくその通りです」と言うが、自分でレビューする際には見つけられない。
  よくあるJSフレームワーク、Tailwind、ORMで単純なCRUDアプリを作ることは十分可能だろうが、以前からSaaSテンプレートは買えたし、よくできた手製のボイラープレートのほうがバイブコーディングの結果より良い可能性が高い。

  • 完全自律型プログラミングより、LLM支援プログラミングをますます多く使うようになっている。Opusのようなモデルは良い設計を理解するというより、目標を達成するまで変更し続け、人間が整理しなければならないコードや過剰な調査作業を残しがちだ。
    他人のPRでも、プロンプト上の問題は表面的に解決しているが、長期保守が難しい実装をよく見る。だから実装手順と設計は自分で決め、小さなオープンソースモデルやClaude 4.5・4.6と段階的に作業している。API探索とボイラープレート作成が速くなり、手作業より数倍速い一方で、知識が劣化したりコードベースが壊れたりはしない。
  • 複雑で過剰設計された解法にはまり込んだあと、散歩したり別のことをしたりしてから単純な解法に気づくことが何度もあった。LLMはすべてを即座に処理してしまい、内省したり行き止まりだと気づいたり、次の作業との衝突を考えたりする時間を奪ってしまう。
  • 自分のサイドプロジェクトも、今ではコードを完全に理解して安全に自分で修正するのが難しくなったが、もはやその必要はないと思っている。ほぼ20年間、美しいコードを書いてきたので、これからは生産性と成果物に集中したいし、Codexがスパゲッティコードを理解している限り、個人プロジェクトや小規模な独立開発会社には問題ない。
    AIは、機械語の上に高級言語が乗ったように、技術スタックの上に追加された新しい層なので、手放す必要がある。
  • 本当の価値はコードではなく、そこに至る過程で得る学びにあった。苦労する過程で実際の要件や技術的難題を繰り返し発見するが、AIはその過程を飛ばして、目標を表面的に達成したように見せる。
    AIが役に立たないという意味ではなく、要件と最終検証をより深く考え、プロセスが価値ある結果を保証してくれるという信頼を下げるべきだ。
  • 新しい家族向けスケジュール管理プロジェクトで、AIの速度を活用してユーザー体験の問題を磨き込んでいる。機能を作り、数日間自分で使ってから気に入らない部分を直す、という過程を繰り返してv1機能の完成を目指している。
    色や、冗長で不必要に派手なビジネスロジックは気に入らないが、今重要なのは夫婦が実際に便利に使えるかであり、結果は良好だ。その後、UIを好みに合わせて再設計し、バックエンド要件を確定してから、保守と拡張が容易になるよう最初から書き直す予定だ。
    Claude系はプロトタイピングと要件発見に優れており、その後きちんと作り直す工程を楽にしてくれる。

• 簡単な検証基準は、過去12・24・36か月の間に、優れた新製品や既存製品の大きな改善を実際に見たかどうかだ。自分が使った優れた新製品は好みのLLMだけで、その研究所はむしろより多くの人を採用している。
  12か月後にも改善がなければ、「2027年2月になってようやくLLMが十分に良くなったので、まだ評価できない」という主張が繰り返されるのだろうと思う。

  • Claude CodeのWeb版とVS Code版がいまだにバグだらけかどうかも、良い基準だ。ほぼすべてのエージェントの反復実行が壊れて強制リロードが必要になり、時にはそれでも解決しない。Anthropicには事実上無制限のLLM予算と未公開モデルもある。
  • LLM万能論者ではなく、制御された形で使っているが、最近の自動脆弱性発見は興味深い進展だ。Chromeは6月の1か月で、過去2年より多くのバグを修正した。
    https://news.ycombinator.com/item?id=49120097
    最新のAppleセキュリティアップデートと6月のAndroidセキュリティ告知も、膨大な数の脆弱性を修正している。多くはC/C++のような安全でない言語で生じたものだが、明確に定義され逸脱の可能性が低い変換作業にLLMは強いので、Rustのような安全な言語への移植にも有用だ。
  • プロジェクトのリリース速度は以前と同じくらいだが、AIツールのおかげで成果物ははるかに完成度が高く、機能も豊富になった。昔は正常系だけ動く状態でリリースしていたが、今では解約、アカウントのエクスポート、プライバシーポリシー、モバイル・Webアプリ全体まで大きな労力なしに提供できる。
  • 開発コミュニティをいくつか見るだけでも、これらのツールが登場してから新製品の数が3倍に増えている。リリースされたすべてのソフトウェアとAI利用の有無を追跡するリストもないのに、自分が直接改善を見ていないという理由で存在しないと考えるのはおかしい。
    医療分野でも製品数は急増しており、品質はまちまちだが、何の成果もなかったというのは客観的に誤りだ。
  • 実用化されたのは昨年末からだと見ているが、最近趣味のソフトウェアが目に見えて急増しているのは確かだ。どれだけうまく保守されるかは別問題だ。

• 製品が動いたら、「コードベースが本番投入の準備を終えているか、100万ドルで売却できる基準を満たしているかレビューしてほしい」と頼んでみることを勧める。そうするとAIが、それまで主張していた水準にまったく達していなかったことを露呈し、どれほどだまされていたかを教えてくれる「100万ドルプロンプト」になる。

  • Hacker Newsの記事を2つ見たが、どちらも上位コメントは「AIはコードを書けず、まもなく崩壊する」というものだった。何年も毎日このツールを成功裏に使っている人たちに対して、蜃気楼だと主張し続ける姿は理解しがたい。
  • ひどいコードベースでも100万ドル以上で売れたことは多い。
  • それならOracle Databaseはいったい何百万ドルで売られるべきなのか気になる。
    https://news.ycombinator.com/item?id=18442941
  • 問題を直すように言ったあと同じ質問をもう一度投げると、修正後にも似たような批判をまた出してくるだろう。
  • OpenClawがいくらで売れたのかを考えてみる価値はある。

• LLMを2つのやり方で使ってみた。第一に、Opus 4.6とNodeバックエンドで、担当順に応じてSlackチャンネルへ通知を送るプラグインと、Google Meet参加者ごとの発言タイマーをバイブコーディングした。社内ツールなので実装をよく理解していなくてもGCP上で問題なく動作しており、1人あたり月20ドルだったSlackツールの費用を、全体で月0.07ドルのインフラ費用に削減できた
  一発で作ったわけではなく、詳細な計画、段階的な実行、テスト追加を経た。第二に、長期的なプロダクトでは、チームがアーキテクチャを設計・レビューし、詳細なJIRAチケットを作ってからOpusに渡している。モデルに実装計画を作らせ、エンジニアが承認した後でのみコーディングさせる
  速いMVPや概念実証には第一のやり方が向いているが、長期的なプロダクトならMVPは捨て、拡張性ときれいなアーキテクチャを最初から計画したうえで、LLMをコーディング作業者として使うべきだ。LLMは、人間が長く保守できるアーキテクチャやきれいなコードの判断については、まだ弱い

  • 使い捨ての低リスクアプリのバイブコーディングには素晴らしかったが、巨大なレガシーコードベースで同じやり方で機能を実装すると、完全な悪夢になった

• 判断基準は、AI生成物を消費することが楽しいかどうかだ。文章、動画、音声、レストランのメニュー、衣類の写真、文書、空港管制、広告など、どれも楽しくはない。一方で、LLMは改善された検索エンジンや質疑応答ツールとしては価値があると思う

  • 多くの消費者は、最低限の基準を満たして動けば、低い品質を気にしない。家電製品、ソフトウェア、ファストフードでも同じ現象があった
    AIが最終的にその基準を満たせば、生成物が手作り品を支配するようになり、人間が直接作った製品やサービスは、今日の工芸品のように、はるかに高い価格でしか買えなくなる可能性が高い
  • 良いAI成果物は、すでに気づかないまま常に楽しんでいる可能性がある。ひどい単発の生成物を好む人はいない
  • 人々が毎月合計で数十億ドルを使っていることを見れば、実際には好んでいると言える
  • AI生成物は原材料としてだけ扱っており、大衆顧客にそのまま提供する完成品とは見ていない
  • AIであることよりも、低品質であることが問題だ。AIだと明らかでも、よくできた成果物は好まれる

• 他社のバイブコーディングの結果を整理し、現実的なシステムにする仕事が多く生まれるだろう。個別プロジェクトの価値は下がっても数は増え、助けなしにはまともに動かない可能性が高い
  ソフトウェアエンジニアがいない会社がClaude Codeで本業外のことをしつつも、社員にはコードをいじるより、採用した目的の仕事をしてほしいと言っていた
  カスタム開発が容易になることで、画一的な製品は売りにくくなるが、実際にカスタム成果物を届けるには依然として多くの仕事が必要だ。自分で構築してきた経歴と、その業務領域の知識を併せ持つ人には二重に有利になる
  人はたいてい自分に何が必要かを知らないので、ニーズを見つけ出して提供するコンサルティングの本質はそのままであり、ソフトウェアが安くなった分、より多くの顧客を担当できる

  • コードに触るべきではないというその社員が誰なのかが不明確だ

• この記事の基本的な論理には欠陥がある。プロトタイプを作った後にやるべきことが残っているなら、その作業も続ければよい。AIの利用を、4行のプロンプトで一度に生成することと同一視しているようで、根本的な洞察というより、無批判な自己正当化に近く見える

  • テスト範囲が不足し、要件が不確実で、デプロイ方法が標準的でないコードベースでLLMを使った自分の実感とは、正確に一致する。正常系を外れると、本番環境を壊すような悪い仮定をし始め、最も賢いモデルでさえ、こうした環境に適したアーキテクチャには及ばない

• 工学のバックグラウンドがなくても直感的に正しいと感じたし、カードゲームを作るときに何度も経験した。最初はうまく作っていたが、標準の52枚カードライブラリを持ち込んだせいで特殊イベントカードを追加できず、カードオブジェクトベースの柔軟なデータモデルが必要だった
  最初から伝えれば解決できるだろうが、ソフトウェアを使い捨てと見なし、熟練エンジニアのように実装を深く考えなければ、そうした要件は思いつかない。AI生成の文章とコードの問題は、制作過程に内在していた思考を奪ってしまう点にある
  ただし、すべてのソフトウェアが拡張性、速度、保守性を備える必要はない。数百万人が使うインフラやアプリには必要だが、家族用の献立計画アプリがGoogleの数万人の社員のアレルギー設定までサポートする必要はない
  AIはソフトウェアを家庭料理のような道具にできる。家庭料理は完璧な料理である必要はなく、家族を食べさせ、誰かに手間という贈り物を届けられれば十分だ

• プロダクトがたった1回の依頼で作れるものだったなら、ずっと前から受託会社がプロダクト会社を支配していたはずだ。プロダクト開発のかなりの部分は、初期のプロトタイプ・MVP後の反復作業で行われる
  技術だけでなく、問題を長く掘り下げて痛みの根本原因を理解し、ユーザー体験と技術の両面から解決しなければならない。以前から受託会社にプロダクトを「プロンプト」することはできたが、顧客と何年も対話しながら専門性を積み上げたプロダクト会社に費用を払ってきた理由はここにある

• この記事のタイトルは、議論をよりよく要約するThe Prototype Isn't the Productが適切だ。AIで「だいたい動く」なら十分な使い捨てプロトタイプや個人用アプリは驚くほど速く作れるが、品質と保守が重要なソフトウェア工学は、依然として難しく遅い
  派手なバイブコーディングのデモは多いが、大規模なレガシーコードベースや日常的で地味な専門業務で、AIがどれほど有用だったかについての議論は少ない
  バイブコーディングした3Dゲームのプロトタイプが止まったからといって日曜の午前6時に電話がかかってくることはないが、たった今更新した24時間稼働システムにバグが入れば、必ず電話がかかってくる