この動画では、元OpenAI創設者でテスラのAI責任者だったアンドレ・カルパシーが提唱した「バイブコーディング」という概念について批判的に検討している。バイブコーディングとは、大規模言語モデルとの会話的なやり取りを通じてコードを生成するプログラミング手法である。しかし、この手法はプログラミングの本質的な問題を見落としており、コードを書くことがプログラミングの最も困難な部分であるという誤解に基づいているという。真のプログラミングの困難さは、問題を正確かつ決定論的な指示に分解することにあり、自然言語の曖昧さと不正確さでは複雑なソフトウェアシステムを構築することはできない。さらに、AIが生成するコードの品質管理、変更可能性の確保、継続的な改善という根本的な課題についても言及している。
バイブコーディングという新概念の登場
今年の2月2日に、OpenAIの創設者でテスラの元AI責任者やったアンドレ・カルパシーが、AI支援によるプログラミングスタイルの新しい用語を紹介したんや。彼はそれを「バイブコーディング」と呼んだ。
長すぎて読まれへんとか意味が拡散してしまうっていう考え方には慣れとるけど、これはある種の記録やったかもしれへんな。これは1000文字のツイートで、ほとんどの人が後半まで読まへんかったみたいや。
アンドレは1000文字のツイートの最初の300文字ほどでバイブコーディングが何を意味するかを説明してる。残りの部分では、このナイーブで玩具のような町のプログラミングアプローチの結果について説明してるんや。
アンドレを個人的に知ってるわけやないから、彼がツイートで何を考えとったかは分からへんけど、皮肉として読めるんや。ツイートの終わり近くで、彼は「使い捨ての週末プロジェクトにはそれほど悪くないが、本当のコーディングではない。ただ物を見て、言って、実行して、コピペして、たいていはうまくいく」って言ってる。
だから、バイブコーディングは少なくとも今年これまでで最悪のソフトウェアアイデアの賞候補やと思うで。それにもかかわらず、バイラルになったみたいで、今では我々の分野でよく知られた言葉になってしもた。そして、それが今日のトピックや。
こんにちは、デイブ・ファーリーです。モダンソフトウェアエンジニアリングチャンネルへようこそ。初めての方は、ぜひ購読をお願いします。そして内容を楽しんでいただけましたら、いいねを押してください。より多くの視聴者に届けるのに役立ちます。ご協力ありがとうございます。
プログラミングの本質についての誤解
大規模言語モデルとリラックスした会話をすることで動作するシステムができるっていう考えと現実は印象的で魅力的やけど、プログラミングが実際に何についてのものなのかという点をほぼ完全に見逃してるように思えるんや。
これはソフトウェア業界の悩みの種、つまりコードを書くことが難しい部分やっていう考えに戻るんや。技術者やない人々はこれが真実やと信じてる。なぜなら、コードが彼らにとってとても複雑で神秘的に見えるからや。開発者がこれが真実やと信じてるのは、コードが彼らにとって心地よくて貴重で、明確に彼らのスキルを定義し、コードを読めへんからおそらくそれほど賢くない技術者やない人々と区別してくれるからや。
我々はこの前提に基づいて技術採用業界を築いてきた。優秀なプログラマーの決定的な特徴は、彼らが知ってる言語とフレームワークの集合やっていう前提や。我々には自分の仕事を使うツールで定義する人々がおる。Javaプログラマーやとか、React開発者やとか。
以前認めたことがあるけど、プロジェクトで使ってる技術と同じものを使ったことがないプログラマーを雇ったことがあるし、これまでのところそれを後悔したことはない。
私の経験では、プログラミングが得意なら、プログラミング言語を数日、せいぜい数週間でなんとかなるレベルまで学べるもんや。ソフトウェア開発をうまくやることは難しい、非常に難しい。でも、その難しさはプログラミング言語によって生み出されるもんやない。
アンドレのツイートの出発点について考えてみよう。我々はバイブに身を任せて、コードが存在することさえ忘れることができるってことや。まあ、そうすることがある他のグループの人々は、コンピューターを通じて何かを達成したい時々技術者やない人々や。
しかし、これまでは我々人間のプログラマーが、この会話でコーディングアシスタントの役割を果たして、彼らが望むことを動作するものに翻訳してきたんや。それで、それは通常どれくらいうまくいくか？あんまりうまくいかへん、と私は主張する。
確かに、任意のサイズや複雑さのソフトウェアにとっては非常に貧弱や。これはしばしば本当にひどくいくもんや。そして、これまでのところ、我々人間はまだマシンより賢い。
これは人々が望むことをプログラミング言語に翻訳するのがそれほど困難やからやない。問題を正確で決定論的な指示に煮詰めるのがとても難しいからで、大規模言語モデルであろうとなかろうと、コンピューターが最終的に動作する方法は依然としてそうなんや。
ここで一旦止めて、スポンサーに感謝を述べさせてもらうわ。Equal ExpertsとTransfigにスポンサーになってもらって、非常に幸運や。Transfigは高度な継続的デリバリー技術を適用して、世界最大の金融機関の一部に低レイテンシの貿易ルーティングサービスを提供する金融技術会社や。しかし、これらの会社はどちらも、毎週このチャンネルで議論してるトピックと非常によく一致した製品とサービスを提供してる。
だから、継続的デリバリーとソフトウェアエンジニアリング全般での優秀さを求めてるなら、下の説明にあるリンクをクリックして、ぜひチェックしてみてください。
プログラミング言語の役割と重要性
昔のプログラムと現代のプログラムを見ると、なんか奇妙なことが起こってる。動作するプログラムを作るために表現する必要がある詳細レベルに、ある種の持続性、一貫性があるように見えるんや。
そして、それは何十年も真実やった。必要な詳細レベルをどのように符号化しても、それはかなり一貫してる。プログラミング言語は、プログラマーの何らかのファッションやマゾヒスティックな特性のせいで奇妙なわけやない。
それらは、現代のコンピューティングデバイスを構成する数十億のスイッチの箱から結果を達成するために必要な精度レベルで、アイデアを明確に表現するのが得意になるように進化したツールなんや。
プログラミング言語は現実世界の人間の言語より複雑やない。より単純で、より厳密に制約され、より正確や。それはプログラミングする時に我々の目標を達成しようとする上で我々にとって有利なんや。
プログラミング言語は、我々が目指してる結果を達成するために必要なステップに問題を分解できるように、我々の思考を構造化するのを助けるように設計されたツールや。
だから、人間の言語にある曖昧で不正確な表現の豊かさを採用すれば、コンピューターでの動作を正確に定義できるっていう考えは、真実からは程遠く、私にとってはほぼ完全にポイントを外してるように思える。だから、バイブコーディングは正しい答えにさえ近くないんや、本当に。
人間が自然言語で明確さと精度を達成しようと試みるもう一つの例は法律や。そして、何らかの目的で何らかの法的文書を読んだことがあるなら、明確さと精度の面で我々が望むようなものではないということに同意してもらえると思う。
プログラミングの本質的な目標
プログラミングの行為は様々な異なる視点から考えることができる。これについて考える最も一般的な方法は、おそらくプログラミング言語でコードを書く行為として考えることやろう。
でも、私はこれの有用性にいくらか懐疑的や。それはレンチの使用の観点から配管工を定義するようなもんや。それ以上のものがある。
そして、コードの構文と組織を超えたものが、プログラミングのより興味深く、より複雑な部分や。我々がコードで描く形と、それで達成する結果の両方が、コード自体よりも興味深く、有用や。
私は、究極的にプログラミング言語には本当に重要な3つの目標があると思う。一つは、問題についての我々の思考を整理するのを助けること。二つは、我々の理解を他の人間に伝えること。そして三つは、我々が望むことをコンピューターに伝えること。
これらのそれぞれはプログラミングの行為にとって重要で、我々が書くプログラムの異なる価値レベルを表してる。
プログラミングの最も困難な部分は、我々が直面してる問題を、我々が思いつくものが良い解決策になりそうだと分かるほど十分詳細に理解することのように思える。
プログラミング言語は、我々が目指してる解決策の我々の絵を区画化できるように、我々の思考を制約する方法でツールを与えることで、この問題を解決する。そうすることで、我々はそれをスコープし、その複雑さを管理できる。
それらは、モジュール性、凝集性、関心の分離、抽象化、管理された結合のような技術を使って、他の部分とは別に問題の部分を扱うことを可能にしてくれる。
プログラムを書くことについてのこの種の思考は、これらの構造を我々のコードに構築するのを助けてくれるプログラミング言語構造と、経験から築き上げる設計の我々の生来の知識と理解の混合や。
プログラミング言語は、その設計を通じて我々の思考を導くことができ、残りは我々次第や。
AI時代のプログラミングの課題
我々プログラマーにとって、そしてプログラマーとしての大規模言語モデルにとっての大きな問題は、これらの言語構造を効果的に使うために、我々の設計選択にある種の良いセンスを適用することを学ぶ必要があることや。そして、みんながそうするわけやないっていうことを知るのに十分な反例を我々は皆見てきた。
でも、我々の哀れな大規模言語モデルは、すべてのコード、良いもの、悪いもの、醜いものに対して訓練されてきた。そして残念ながら、良いものよりも悪くて醜いものの方が多く存在してる。
そして、職業としての我々も、悪くて醜いものと区別するために、本当に良いものがどのように見えるかを定義するのがあまり得意やなかった。
10人のプログラマーに良いコードと悪いコードの違いを作る一つのことを教えてって頼んだら、おそらく15の異なる答えを得るやろう。これは、大規模言語モデルが訓練データから良いコードを作るものについて素晴らしいセンスを持つ可能性は低いってことを意味する。
だから、我々は彼らに教えるか、悪いコードを作ることを受け入れるかのどちらかや。そして公平に言うと、これはすべてかなり複雑で微妙な話や。なぜなら、ある文脈で素晴らしいコードを作るものが、別の文脈では単純すぎるかもしれへんし、やりすぎかもしれへんからや。
私は確かに自分自身の一連のデフォルトを持ってるし、私の本は私が一般的に役立つと思う一般的な礎石のアイデアを定義する試みや。でもそれでも、それはやはり文脈的や。
私のバックグラウンドと経験は、設計と開発に対するかなり防御的で進化的なアプローチに私を導いた。私は最も強いメンタルアプローチは、我々の推測が何であれ、おそらく間違ってるって仮定して、我々がどこで間違ってるかを見つけた時にそれを修正できる方法で働くことやと思う。
私は我々のコードの品質の唯一の意味のある尺度は、それを変更する我々の能力やと信じてる。だから、私は見つけることができる最もシンプルで、読みやすく、変更しやすい解決策を常に目指してる。
でも、大規模言語モデルがどんなに小さな変更でも、ほぼ毎回すべてのコードをゼロから書き直す時、変更の容易さは本当に何を意味するんやろう？それはすべてのコードが今等しく変更しやすいってことを意味するんか？まあ、そうやない。
コードが変更しやすいのは、各変更の後で、どんなに大きくても小さくても、それがまだすべきことをすべてやってるって判断できる場合だけや。でも、我々のシステムが何をするべきかを詳細に正確に指定しない限り、どうやってそれを判断できるんや？
人間にとって、これがするべきことのセンスはしばしば暗黙的や。それは通常コードに書き込まれてへん。でも、AI生成コードにとって、それはさらに大きな問題や。
AIをプログラミングで使うことが我々にとって浮き彫りにする大きな問題が3つあると思う。何らかの精度で我々が望むことをどのように指定するか？我々が望んだものを得たことをどのように確認するか？そして小さく制御されたステップで測定可能な進歩を作る我々の能力をどのように保持するか？
最初の問題は自然言語の曖昧さと不正確さに関わる。二番目は、AIが書いたコードにとって自動化されたテストのさらに重要な役割を浮き彫りにする。そして三番目は別のかなり深い問題、マシンがコードを書く方法と我々人間がする方法の間の深刻な違いについてや。
基本的に、これは結果を確実に再現する我々の能力のせいで重要や。成功するシステムはすべて時間とともに進化する。それは、我々の状況や理解が変わった時に、それらを変更できる必要があることを意味する。
複雑なシステム構築が得意な人間は、システムの一部での変更が他の部分に漏れ出ることなく、システムの一部で安全に変更を行う能力を保持できるように問題を区画化することでそうしてる。
これは物理工学だけでなくソフトウェア工学でも真実で、我々がそれらの構築をどのように組織しようとも、すべての複雑なシステムがこの一連の小さな変更で構築される結果になる。
だから、ソフトウェアの高品質の定義が変更の容易さによって定義されるという私のアイデアは、我々がほぼ常にそれを変更できる必要があるため、かなり重要やと思う。
これは、複雑なソフトウェアシステムを構築するための継続的インテグレーションと継続的デリバリーのアイデアの重要性を浮き彫りにする。私にとって、これはコードを書くのにAIを使うかどうかとは無関係や。
しかし、AIは我々がする方法でコードを書かへん。それらのほとんどは、しばしば小さな変更の後でも、ゼロからコードを生成する。
皮肉なことに、既存のコードを再訪して修正や強化する重要性と能力を無視するこの同じ問題は、1990年代の4GLsとモデル駆動開発からローコードとノーコードシステムまで、プログラミングでの抽象化レベルを上げる他のすべての試みを躓かせた躓きの石やった。
それらはすべて、コードが最初から正しくて修正が必要やないという前提に基づいて構築されてたから、既存のコードに戻って修正や強化する能力のラウンドトリップは困難で、不可能やないまでも困難やった。
これらの試みの多くはバージョン管理さえできなくて、我々はAIプログラミングで再び同じ間違いを犯す危険にあるように思える。
コードを更新する問題を無視するのは愚かや。なぜなら、それは我々と世界が完璧であることに依存してるが、我々のどちらも完璧やないからや。
AIはこの問題を持ってるし、同時に持ってない。もしそれが何らかの指示を与えられて複雑なソフトウェアでもゼロから再作成できるなら、我々はまだ本当に増分主義が必要なんやろうか？
これには2つの答えがあると思うけど、どちらもバイブコーディングとはうまく一致しない。
もし私が人間のプログラマーとして複雑なシステム、私が欲しいものと私がしたことのすべての最後の詳細を頭の中に保持できないほど複雑なシステムを構築して、今物を壊すことなくそれに小さな変更を加えたいなら、私がそれをする能力に自信を持てるのは2つの方法だけや。
すべてをテストして、それらがまだ通ることを確認するためにすべてのテストを後で再び実行することができる。あるいは、他の場所で何が起こるかをあまり心配することなく、一つの場所でコードを変更できる方法でシステムを設計することができる。
でも、その2番目のアプローチは実行と設計での決定論的な増分主義の前提に基本的に構築されてる。私のコンパイラーや言語が、私が変更しなかったコードを前回とまったく同じ方法で解釈してくれると確信できるか？私のAIが同じことをできると同じように確信できるか？これを達成するために何をバージョン管理するんや？これを達成するために何をバージョン管理できるんや？
もしこれができるなら、私は新しい変更が正しいかどうか、そして古いコードと新しいコードの間の分離が私が頼ることができるほど十分良いかどうかを心配するだけでいい。でも、もしできないなら、私は迷子や。
もしAIが毎回すべてのコードをゼロから再生成するか、時々それをするか、新しいことを学んでるので私の指示をどう解釈するかを変えるなら、もう以前のように動作するものを再作成することを信頼できない。だから、それがそうすることを確認する必要がある。
これは、AIが生成したコードにとって、人間が書いたコードよりもさらに自動化されたテスト、継続的インテグレーション、継続的デリバリーを重要にする。
そして、これは私だけが言ってるわけやない。私は最近、OpenAIの研究者から同じポイントを述べる優秀なビデオを見た。
私のポイントと彼のポイントは、AIをプロンプトする最良の方法は実行可能な仕様を使うことやってことや。つまり、あなたが構築したいシステムが明確に定義された反復可能な状況でどのように動作すべきかを正確に記述する精密で正確な例や。
これらの仕様がシステムに何をしてほしいかを明確に定義し、それがそれをすることを検証することも可能にするように。
プログラミングは実装の詳細を指定することから、我々が構築したいシステムの意図をより明確により正確に指定することに移る。
結論：ソフトウェアエンジニアリングの未来
これをどのようにするかについてもっと学びたいなら、私のトレーニングコース「Acceptance Testing BDD from Stories to Executable Specifications」をチェックしてください。これには、このようにAIでプログラミングする例が含まれてる。
だから、バイブコーディングはこれらの問題のどれも解決しない。それは単に十分やない。ソフトウェアエンジニアリングは死んでない、変化してるんや。
私はこれら3つの問題が、AI生成であろうとなかろうと、コードの性質にとって基本的やと主張する。そして、プログラミングの次のステップは、これらすべてに対処するか、うまくいかないかのどちらかや。
ご視聴いただき、ありがとうございました。モダンソフトウェアエンジニアリングチャンネルの我々の内容を楽しんでいただけましたら、Patreonコミュニティに参加して我々の仕事をサポートすることを検討してください。
そして、すでにPatreonメンバーの方は、あなたのサポートに再び心から感謝します。そして、メンバーであることから得られる特典を楽しんでいただいてることを願っています。
ありがとう、そしてさようなら。
コメント