12,413 文字
夜中に誰かが巨大な豆の種をばらまいたようなものです。朝起きてみるとそこにあるんです。つまり、私たちの感覚では、これは一時的なブームではなく、消えゆくものでもなく、これこそがコーディングの主流な方法になるでしょう。もしあなたがそれを活用していなければ、取り残されてしまうかもしれません。
ライトコーンのもう一つのエピソードへようこそ。私はゲイリーです。こちらはジャレッド、ハージ、そしてダイアナです。私たちはYコンビネーターのパートナーで、集合的に何千億ドルもの価値のある企業に、それがただのアイデアと数人の人々だけだった時点で投資してきました。
今日は「バイブコーディング」について話します。これはアンドレ・カーパシーの最近バイラルになった投稿からのものです。彼は言います「私がバイブコーディングと呼ぶ新しいコーディングの形があります。そこではあなたは完全にバイブに身を委ね、指数関数的な進化を受け入れ、コードの存在さえ忘れるのです」
私たちは現在のYCバッチの創業者たちにバイブコーディングについての見解を調査しました。基本的に彼らにいくつかの質問をしました。どんなツールを使っているのか、ワークフローがどう変わったのか、そして一般的にソフトウェアエンジニアリングの未来はどこに向かうと思うか、バイブコーディングの世界でソフトウェアエンジニアの役割はどのように変化するのかを尋ねました。そして非常に興味深い回答を得ました。
創業者たちからの印象的な引用はありましたか？
一つ読み上げると、「ソフトウェアエンジニアの役割はプロダクトエンジニアへと移行すると思います。コーディングツールが誰もが10倍のエンジニアになる時代には、人間の感性が今までになく重要になっています」これはOutletの創業者からの言葉です。
もう一つあります。Asraのオビーは「私はあまりコードを書きません。ただ考えてレビューするだけです」と言っています。これは超技術的な創業者からの言葉で、前の会社もデベロッパーツール企業でした。彼は極めてコーディング能力が高いので、そのような人が言うのは興味深いです。
別のRB、Copycatからのアールビーは「私は今、自分のコードにあまり執着しなくなりました。コードを破棄するか、リファクタリングするかの決断が以前より客観的になりました。3倍の速さでコードが書けるので、必要であれば破棄して書き直すことが簡単になりました」と言っています。
このようなことが並列化されるというのも素晴らしいところで、Cixのヨアブはこう言っています。「すべてカーソルを使って書いています。時には2つのカーソルウィンドウを並行して開き、それぞれに異なる機能について指示することもあります」これは理にかなっています。なぜ3つではないのでしょうか？実際、多くのことができます。
また、Train Loopの創業者からの言葉も素晴らしいです。「コーディングがどのように変わったか：6ヶ月前から1ヶ月前で10倍のスピードアップ、1ヶ月前から現在で100倍のスピードアップ、指数関数的な加速です」彼は「私はもはやエンジニアではなく、プロダクト担当者です」と言っています。
それは非常に興味深いですね。私はこれが広く起こっていることかもしれないと思います。実際には2つの異なる役割になっています。これは今日のエンジニアが自己割り当てする方法にも当てはまります。あなたはフロントエンドかバックエンドのどちらかで、バックエンドは実際にはインフラストラクチャに関するものとなり、フロントエンドはより多くのプロダクトマネージャーのような役割になります。あなたはある種の民族誌学者のようになって、GDPの中の見過ごされた部分に入り込み、「そのGDPの一部にいる人々が実際に何を望んでいるのか」を抽出し、それをコードに変換します。そして実際には評価がその中で最も重要な部分になります。
私がTriple Byteを運営していた時、これは実際に私たちが気づいたことの一つでした。特定の会社に適したエンジニアを見つけようとする際、技術的な評価と同じくらい重要だったのは、ある技術レベルのしきい値を超えていることに加えて、ユーザーと実際に話したいかどうかでした。一部のエンジニアは、誰がユーザーなのかを知り、彼らとコミュニケーションをとり、生のフィードバックを得て反復できるような作業にはるかに動機づけられます。本質的にプロダクトエンジニアになるわけです。
一方で、他のエンジニアは全くそれを望みません。ユーザーと対応するのは面倒だと感じ、ただ難しい技術的問題に取り組み、バックエンドをリファクタリングしたいと思います。
はい、それをバックエンドエンジニアと呼んでいます。
それはこの調査回答で出てきたテーマの一つですね。このアイデアでは、LLMは人々を選択するように押し進めるかもしれません。実際のコード記述はあまり重要ではなくなり、あなたが本当に感性を持ちプロダクトの問題を解決したいのか、それともアーキテクトとしてシステムの問題を解決したいのかが問題になります。
興味深いことに、この調査が示したのは、これらのツールはデバッグには非常に不向きだということです。人間はまだデバッグをする必要があります。「コードが実際に何をしているのか」「バグはどこか」「ロジックエラーがあるコードパスはどこか」を判断する必要があります。単に「デバッグして」と指示するだけの方法はないようです。
あなたは、初めてソフトウェアエンジニアに指示を与えるように、非常に明示的でなければならないと言っていました。デバッグさせるためには本当に細かく指示を与えなければなりません。または、アンドレ・カーパシーのスタイルのように、バグを無視して最初からやり直すこともできます。コードを書くことが1000倍安くなると、コーディングスタイルが変わるのは野生的です。
人間としては、長い時間取り組んだものを破棄して一からやり直すことは決してしないでしょう。常にバグを修正しますが、LLMであれば、1000行のコードを6秒で書き直せるなら、なぜそうしないのでしょうか。
それは、Midjourney や Playground のような画像生成で、画像に不具合や気に入らない部分があっても、プロンプトを変更せずに単に「ロール」をクリックして5回試して、時にはそれが機能し、「これなら使える」と思うようなアプローチに似ています。
これはシステム構築の非常に異なるフレームです。基礎から一歩一歩構築するのではなく、本質的に潜在空間に隠れているどこかから生成されたコードを使って一から構築するからです。別の勾配を見つけて行き詰まらないようにするには一から始める必要があり、少しのランダム性を加えて再生成を促したいのです。
しかし、次世代の*05（訳注：おそらくモデルのバージョン）が実際に構築できるようになるのはまだ先かもしれません。現状では、再ロールと再書き込みが必要で、まだ上に積み上げるようにはなっていませんが、今のところコーディングツールが推論とうまく機能しているのは見ていません。
いや、*03は3.5 Sonnetよりもデバッグが無限に優れています。6ヶ月後の次のエピソードを録音する頃には、これが当てはまらなくなるかもしれない方向に確実に向かっています。
ダイアナ、人々が使用しているモデルやIDEについて話してもらえますか？そこには非常に興味深いトレンドがありますね。
数エピソード前に言及したように、このシフトは2024年夏に始まり、Cursorがバッチの大部分で使用され始めました。そして今や圧倒的にリーダーですが、他にも起きているのは、これが非常に速く変化する環境であることです。Windsurfが速いフォロワーで、Cursorに比べて非常に良い製品になりつつあります。ジャレッド、あなたはWindsurfがCursorより優れている理由について第一手の経験がありますね。
人々が切り替えている主な理由は、現在のCursorが主にコードベースのどのファイルを見るべきかを指示する必要があることです。大きなコードベースがあれば何をすべきか伝えられますが、コードベースのどこを見るべきかを伝える必要があります。Windsurfはコードベース全体をインデックス化し、自分でどのファイルを見るべきかをかなり上手く把握します。他にも違いはありますが、現時点ではそれが最も重要な違いだと思います。
Devonも言及されていますが、Devonが重要な機能に使われていない欠点は、コードベースを本当に理解していないことです。主に小さな機能に使われていて、ほとんど言及されていません。
人々はまだChatGPTを使用しています。その理由は推論モデルを使いたいからです。デバッグの質問を投げて、より強力な推論モデルを使用しています。現在、CursorとWindsurfはまだ古い世界、つまり6ヶ月以内の推論モデル以前の世界にあります。創業者はこれを使っていて、一部はより重要で機密性の高いIPを持っているかもしれないため、モデルを自己ホスティングしています。
モデルのシフトについて言うと、6ヶ月前に大きなゲームだったのはClaude Sonnet 3.5で、まだ実際に大きなプレイヤーですが、*01、*01 Pro、*03などのこれらの推論モデルは、今やSonnet 3.5と同等になりつつあります。GPT-4oはコーディングにはほとんど使われていません。
また興味深いのはDeep Seek R1が言及され、使用されていることで、有力な競合になっています。Geminiはあまり言及されていませんが、最も長いコンテキストウィンドウを持っているため、何人かの創業者は使用していると聞いています。彼らの使い方は、コードベース全体をGeminiのコンテキストウィンドウに入れて、バグを修正するように指示します。常に機能するわけではありませんが、コンテキストウィンドウ内に全体があるため、一発で修正できることもあります。
新しくリリースされた推論モデルとFlashback 2.0がより多く採用されるのを見るのは興味深いでしょう。まだ試していない人が多いと思いますが、長いコンテキストウィンドウと推論の組み合わせは良い競合になり得ます。
現在のバッチでLLMによって書かれているコードの推定量はどれくらいですか？これはかなり驚くべきことです。私たちはこの質問を具体的に尋ねました：「コードベースの何パーセントがAIによって生成されていると推定しますか？」
私がこの質問をどう解釈するかというと、インポートしたライブラリを含まず、実際のコードの文字のうち、人間の手によってタイプされたものとLLMによって出力されたものの割合です。驚くべきことに、創業者の4分の1が「コードベースの95%以上がAIによって生成されている」と答えました。
これは驚異的な統計です。私たちが非技術的な創業者をたくさん支援したわけではありません。彼らの全員が高度に技術的で、一年前なら一から自分の製品を構築できていたはずです。しかし今では95%がAIによって構築されています。ただし、過去2年間でコーディングを学んだので、Cursorが存在しない世界を知らない若い創業者が1人か2人いるようです。
これは実際に今期の私の最高の会社の一つに当てはまります。創業者たちは非常に技術的な頭脳を持っていますが、コンピュータサイエンスとプログラミングで古典的な訓練を受けていません。彼らは信じられないほど生産的で、大量の素晴らしい製品を生み出すことができ、AIがほぼすべてを書いています。
これは、「インターネットと共に育った最初のデジタルネイティブ」という言説を思い起こさせます。これはネイティブなAIコーディングツールと共に育った世代で、ソフトウェアエンジニアの古典的な訓練をスキップして、バイブだけでそれをやっています。しかし彼らは実際には非常に技術的な頭脳を持っています。数学や物理学の学位を持ち、いわばより「システム思考」タイプの頭脳を持っているのです。
それについて少し話しましょう。何が同じで何が変わったのか。このバイブコーディングにより、数学や物理学などの他の技術分野から来た人々が、過去よりもはるかに速くプログラマーとして高い生産性を発揮できるようになるでしょう。
昔は物理学者をプログラマーに再訓練するコーディングブートキャンプがありましたが、構文やライブラリ、生産的になるために知らなければならないすべてのことを学ぶのに時間がかかりすぎたため、うまくいきませんでした。しかし今は新しい世界です。
ブートキャンプは会社に雇ってもらうことに非常に特化していました。2015年頃、企業自体が採用プロセスでソフトウェアエンジニアをどう評価するかを再考していました。古典的に訓練されたコンピュータサイエンティストをホワイトボードのアルゴリズム問題で雇うことから、実際に生産的で素早くコードを書く人を雇いたいという方向へと本当のシフトがありました。
これらの議論の一部は永遠に続くものです。Railsが最初に登場したとき、Active Recordがデータベースとやり取りする方法は素晴らしい抽象化と見なされましたが、同じ風味の議論がありました。「内部を本当に理解していなければ、低パフォーマンスのウェブソフトウェアを書くだけだ」というものです。
振り返ってみて、これらの議論がどう経過したと思いますか？私の感覚では、最も成功した企業の多く、例えばStripeやGustoは、ツールを使って非常に生産的な人々を望むというアプローチに大きく傾倒していました。彼らは採用プロセス全体を変更して、「あなたがどう考えるか教えてください」から「ラップトップで3時間あるので、ToDoリストアプリをできるだけ早く構築してください」というインタビューに移行しました。
これらの企業は大きな成功を収めました。彼らが成長し規模を拡大すると、ボトルネックは実際に古典的に訓練されたシステム思考家を持ち、物事をスケールアップしアーキテクトすることになりました。
エンジニアの採用方法は変わっていますが、まだ十分には変わっていないようです。調査結果は私たち4人にとっても比較的驚くべきものであり、外部の人にとってはさらに衝撃的でしょう。これは過去6〜9ヶ月の間に私たちの庭に突然現れたものです。エンジニアリングの採用全般はまだこれに追いついていないと思います。人々はまだホワイトボードに立って古いタイプのことをしています。
Stripeのようなところはゲームをリードしていて、今はみんながこの方法でエンジニアを採用しなければならないでしょう。
それさえも古い方法になるかもしれないと思います。調査回答から浮かび上がったのは、「私たちは皆プロダクト担当者になっている」というアイデアです。本当に必要なのは素晴らしい感性と何を構築すべきかを理解することです。二つ目は、実際に価値があるのはシステム思考者やアーキテクトであり、より大きな全体像を理解することです。
素晴らしいエンジニアとは誰か、という定義で常に当てはまっていた「本当に素早くコードを書ける」という次元が時代遅れになるかもしれません。LLMが本当に素早くコードを書くのが得意なら、あなたの役割は完全に異なる問題かもしれません。
そこには2つの異なる段階があります。ゼロから1へ、この場合スピードだけが重要な問題です。そしてActive RecordやRailsに関する戦いは実際には膠着状態に戦い抜かれました。もちろんActive RecordやRailsを使えば非常に素早くゼロから1へ進めますが、Twitterで何が起きたか？「失敗クジラ」になりました。基本的にいったん1に到達すると、そのアーキテクチャでは10億、100億、1000億ドルの評価やユーザー数には到達できません。
同じことが起きるでしょう。あなたの言ったことには微妙なニュアンスがあります。素早くゼロから1に行くことと、10億ユーザーにスケールできることは2つの全く異なる問題です。
私がスケーリングしていた最大のRailsサイトの一つで発見したのは、それを達成できる人はそんなに多くないということです。あなたもRailsサイトをスケールさせたでしょう？ゼロから1に素早く到達する方法は、多くのオープンソースを使うことでした。そして1年半か2年経つと、もうランダムなジェムは使えなくなりました。それらは私たちの規模の会社用に設計されていなかったからです。これはあなたの言ったことの非常に良い例です。
まとめると、ゼロから1への段階はバイブコーディングに非常に適しています。創業者は機能を非常に素早く提供できます。しかし製品市場フィットに達すると、1からNに進むために多くの本格的なシステムエンジニアリングが必要になり、非常に異なるタイプの人々を雇う必要があります。
Facebookも良い歴史的な例です。彼らはPHPで成功しましたが、個人的には酷い言語だと思います。炎上するかもしれませんが、悪い言語だと思います。
同感です、私も好きではありませんでした。申し訳ありません。
しかし素早く物事を提供できましたが、ある時点で機能を提供するには大きなボトルネックになり、すべてのコードを置き換えるには高すぎたため、カスタムコンパイラHipHopを構築するためにハードコアなシステム担当者を雇わなければなりませんでした。そのようなタイプの人々はバイブコードの人々ではなく、私たちの調査によると現在のツールでは低レベルのシステムエンジニアリングには適していません。
皆さんはTriple Byteが何かご存知ないかもしれませんが、実は非常に関連性があります。説明してもらえますか？
Triple Byteは2015年に私が始めた会社で、エンジニア向けの技術評価を構築していました。目標はソフトウェアを使ってソフトウェアエンジニアの評価を自動化する方法を見つけることでした。これらのコーディングモデルが登場する前に、エンジニアをインタビューするための独自のカスタムソフトウェアを構築し、人間がエンジニアをインタビューし、基本的にデータにラベルを付けました。コードを書かせることでインタビューしました。
非常に技術的なインタビューでした。はい、アルゴリズムの問題も含めました。
あなたと共同創業者は地球上で他の誰よりも多くの技術インタビューを行ったのは本当ですか？
そう思います。純粋な時間数で言えば、初期はまさに毎日何千ものインタビューをしていました。そして規模を拡大し、約100人のエンジニアを契約して、完了したインタビューごとに報酬を支払っていました。
あなたはこの質問をするのに最適な人物です。文字通り地球上の誰よりもこのことについて考える時間を費やしました。もし今日Triple Byteを再び始めるとしたら、エンジニアのための新しい技術評価をどのように設計しますか？
Triple Byteとそのスクリーニングで得た大きな教訓は、人々が異なることを望んでいるということです。あなたが何を評価しているのかを事前に知る必要があり、それに基づいて技術スクリーニングを設計する必要があります。
これはStripeやGustoのような企業が知っていたことです。彼らは誰かが基本的なCS知識を持っているかどうかを気にせず、それでスクリーンするのは意味がありませんでした。彼らは実際に職場で行うことをスクリーニングしたかったのです。
私たちの製品はより企業が望むあらゆることをスクリーニングし、誰かの最大スキルを把握して、その最大スキルを評価する企業にその人を送りました。
今日の世界では、人々がこれらのツールをどれだけ上手く使えるかをスクリーニングするようなものを持つでしょう。先ほど言ったこととは矛盾するかもしれませんが、製品を素早く構築できることが明示的にスクリーニングすべきことかもしれません。
しかしバーはもっと高くなるでしょう。恐らく異なる質問をする必要があるでしょう。元のTriple Byte評価に戻ると、そこでの質問の多くは文字通りChatGPTにコピー＆ペーストすれば完璧な回答が返ってくるでしょう。その場合、あなたはただコピーしているだけであれば、あまり能力を証明していないことになります。質問は100倍難しくなる必要があります。
必ずしもそうではありません。スクリーニングにどのような条件を設定するかによります。興味深いです。
古典的な質問は「tic-tac-toeを構築してください」でした。もちろん、それを無監視で行い、誰かにただtic-tac-toeの解決策を持ってこさせれば、2秒で終わるでしょう。彼らがコーディングするのを見て、LLMを使わせなければ…それは問題です。LLMを使わずに古い質問でコーディングさせるか、LLMを使わせて新しい質問を出すべきか、古い質問が簡単になったため。これは今ソフトウェアエンジニアを採用している全ての人が考えるべきことだと思います。
正しい答えが何かはわかりません。
恐らく異なることをテストすることになるでしょう。私もエンジニアリングの採用を多く行ってきました。一つの重要なスキルは、コードを読んでデバッグする能力が最大であることです。LLMが悪いものか良いものを吐き出しているかを判断するのに十分な味と訓練が必要です。
候補者がツールを使用し、LLMが合理的な解決策を出力し、候補者が「これは実際には悪い」と言う場合、それは一つのサインです。良いバイブコーディングをするためには、何が良くて何が悪いかを判断するための高レベルな思考が必要で、古典的な訓練が必要ではないかもしれませんが、何が良くて何が悪いかを判断するのに十分な知識が必要です。そして十分な練習でのみ上達します。それは一定のものでしょう。
それは興味深いですね。コードを生産するのではなく、インタビューでコードレビューをするようなものです。
システム設計の形式もあるかもしれません。彼らが製品をどれだけ上手く出せるかを知りたいので、それなら感性をテストすることになります。デバッグと感性をテストしますが、では古典的な訓練の世界から来ていない場合、どのように感性を育てるのでしょうか？これは次世代のために興味深い質問です。
でもしなければならないんです、そうしないとスタートアップは死にます。例えば、この創業者が95%をAIに書かせたとしましょう。証拠は1年後、2年後に出てきます。1億人のユーザーを抱えたとき、それは崩壊するのでしょうか。
明らかなのは、これらのシステムは最初の推論モデルのバージョンではデバッグがそれほど得意ではないということです。だから実際に何が起きているのかの深みに降りる必要があります。できなければ、別のアーキテクトを見つける必要があります。
コーディングツールでのリトールが非常に簡単なので、「十分に良い」ソフトウェアエンジニアの世代が生まれるでしょう。参入障壁が非常に低いので、十分に良いエンジニアがたくさん出てくるでしょう。しかし卓越した存在、トップ1%になるためには、意図的な練習が必要になると思います。
マルコム・グラッドウェルが普及させた「専門家になるには10,000時間の練習が必要」という概念がありますが、これはアンダース・エリクソンの研究から来ています。研究は非常に具体的で、世界クラスのバイオリニストをどのように見つけるかについてでした。単に時間を費やすだけでなく、意図的な練習、つまり計画され、考え抜かれ、困難な作業をする時間についてでした。より少ない時間で専門家になることができます。
現在のコーディングツールで起きていることは、出力が非常に速いため時間を費やすのが非常に安くなっていることです。「十分に良い」レベルには達することができますが、世界最高になり、最高の創業者になるためには、その意図的な練習が必要でしょう。詳細に入り込み、システムを理解し、ある程度古典的な訓練を受ける必要があります。
良い例はおそらくピカソです。最も偉大な画家の一人ですが、写実的な絵を描くのが驚くほど上手でした。これは彼が有名なものではありません。ピカソというと、その反対のものを想像しますね。抽象的な牛の絵に至るまでの有名なスケッチのシーケンスがあります。写実的なものから始まって、彼が有名な抽象芸術に至るまでの反復です。しかし彼が世界最高になれたのは、実は非常に優れた画家であり、古典的な訓練を受け、超上手に描けたからです。それは彼が知られているものではありませんが。
このように、2つのクラスのエンジニアが見られるでしょう。「十分に良い」エンジニアの非常に大きなクラスがあり、それらのエンジニアが必要ですが、世界最高、そして外れ値になる創業者たちは意図的な練習を積む必要があるでしょう。
そうですね。素晴らしいシステムレベルの世界クラスエンジニアでCEOになった例はたくさんあります。マックス・レブチンやShopifyのトビー・ルトキを思い浮かべます。彼らは本当に素晴らしいですが、それほど優れていなくてもCEOや共同創業者になった人もたくさんいます。
そして先ほど言及したTwitterの例に戻ると、それは本当に興味深いものです。FacebookとTwitterを比較すると、どちらも「スクラップで素早く、物事を壊す」ようなやり方で非常に素早くゼロから1へ行きました。Facebookは印象的な方法でスケーリングの技術的課題を解決できました。ほとんどの人がそう同意するでしょう。
マーク・ザッカーバーグははるかに技術的で、より詳細に関わっていたかもしれませんが、Twitterのスケーラビリティの課題は使用パターンに基づいて難しかったと思います。Facebookの使用は一日を通して比較的滑らかに成長します。人々は常に使用しています。Twitterの問題は、使用が信じられないほどスパイク状であることです。スーパーボウルや世界的なイベントがあると、突然10倍の使用量になります。フィードのファンアウトの仕組みは、基本的に非常に難しいコンピュータサイエンスの問題だと思います。
それは公平ですが、彼らのツールによっても本当に制約を受けていたと思います。彼らはStarlingという恐ろしいキューシステムを使っていたのを覚えていませんか？私はそれを使いました。「Twitterは私たちよりずっと大きい、彼らはとても賢いから、クソなものは使わないだろう」と思ったからです。いいえ、彼らは完全にクソなものを使っていました。私もそれを使ってうまく機能させることができませんでした。ジョブを床に落としていて、クレイジーなバグが発生していました。そして最終的に「もうこれは使わない、RabbitMQか何か正しいものに切り替えなければ」と思いました。
Rubyは信じられないほど遅い言語で、すでに遅すぎたPHPよりも10倍遅いです。基本的には、1に到達できれば幸運だと言えるでしょう。
技術的な創業者が古典的な訓練を受け、本当に深いシステム思考者であることのメリットはありますか？
トビーやマックス・レブチンはだまされません。Stripeも同じです。クレイジーな話をしましょう。私がPalantirにいた時、そこでロゴをデザインした後、数年で燃え尽きて、YCスタートアップを始める前の6ヶ月間、インタラクションデザイナーとして過ごしました。それは最悪の、クレジットカードソフトウェアのベンチャー企業でした。私は6ヶ月間インタラクションデザインを作っていましたが、それは実際に楽しかったので、それが私が空き時間にスタートアップに取り組むことを可能にしました。
レンタカーのファセット検索を設計して、それを実装するデブマネージャーとエンジニアとのミーティングに行ったとき、彼らは「それはできない、その方法ではできない」と言いました。私は「何を言っているの？インデックスをこのようにすればいいだけでしょ」と言うと、彼らは「えっ、どういう意味？」と言って、私の履歴書を見て、「インタラクションデザイナーからそれを知っているの？」と聞いてきました。
基本的に彼らは「どうやって知ったの？」と聞いてきて、私は「あなたは私に嘘をついていた」と思いました。それが教訓でした。職場では、雇った人々が嘘をつかない、怠惰ではない、皆が目標とミッションのために働いていると思いがちですが、実際にはあなたが嘘だと見抜けなければ、彼らは完全に嘘をつきます。
最悪なのは、それを指摘しなければならないことです。時に職場の文化があまりにも丁寧すぎて、人々は「それは見過ごそう」と思い、後ろで悪口を言うことがあります。そういう人を解雇すべきです。
ところで、AIエージェントも人間の従業員と同じように全く同じことをします。あなたが技術的に十分でなく、「いや、私が要求した変更をしていない」と指摘できなければ…これはあなたのポイントに戻りますが、古典的な訓練を受けている理由がまだ役立つ理由です。あなたのために働いている人々が人間であるかどうかに関わらず、彼らを指摘できるほど技術的であることは超能力です。
まとめると、これらのツールが最高のエンジニアにスーパーパワーを与え、悪いエンジニアをさらに悪くしているのは、Train Loopの創業者からの引用のとおりです。「コーディングがどのように変わったか：6ヶ月前から1ヶ月前で10倍スピードアップ、1ヶ月前から現在で100倍スピードアップ、指数関数的な加速」というものです。
実際には忍び寄ってきたんです。夜に誰かが巨大な豆の種をばらまいたようなもので、朝起きると「何が起きてるの？」という感じでした。
つまり、私たちの感覚では、これは一時的なブームではなく、消えゆくものではなく、これこそがコーディングの主流な方法であり、あなたがそれを活用していなければ、取り残されてしまうかもしれません。これは単に存在し続けるものであり、バイブコーディングは一時的なブームではなく、加速すべき時が来たのです。
以上で、次回のライトコーンでお会いしましょう。
コメント