29,372 文字
さて、やりますよ、やりますよ、やりますよ、やりますよ。感覚によるコーディングは未来です。やっていきましょう。感覚によるコーディングです。まるで誰かが夜に巨大な豆の木の種をばらまいて、朝起きたらわぁ、何が起きてるんだという感じです。
私が思うに、今の感覚では、これは一時的な流行りではなく、これは消えるものではありません。これはコーディングの主流な方法になると思います。もしあなたがこれをやっていないなら、取り残されるかもしれません。
私はいつもその言い方が嫌いでした。とてもシンプルな理由があります。誰もが「今使っていないと取り残される」という全く同じ主張をするからです。「本当に？じゃあAIは一年後も同じままなの？」と聞くと、「いや、いや、数年以内に全く違うものになるよ。今やっていることは数年後には全く違うものになる」と言います。
そこで「ちょっと待って、今学んでも数年後にはどうせ学び直さなきゃいけないの？」と聞き返す必要があります。つまり、今AIを使って学んだことは、数年後には追いつけないということですか？あなたが実際に私に売ろうとしているものは何なのか分かりません。今学べば将来も安泰なのか、それとも数年後には全く違うものになるのか？これは奇妙な主張であり、筋が通っていないと思います。
ちなみに、動画がスタートして20秒しか経っていないのに、すでに一時停止しています。ここからが本番です。33分の動画なので、長くなりそうです。
ライトコーン・ポッドキャストの回です。編集が素晴らしいですね。私はゲイリーです。こちらはジャレッド、ハージとダイアナです。私たちはYコンビネーターのパートナーです。総合して、私たちは単なるアイデアと数人の人々だった時点から、何千億ドルもの価値のある企業に投資してきました。
今日は「感覚によるコーディング」について話します。これはアンドレ・カーパシーの最近話題になった投稿からのものです。「感覚によるコーディング」とは、完全に感覚に身を委ね、指数関数的な成長を受け入れ、コードの存在自体を忘れるような新しいコーディングのスタイルです。
私たちは現在のYCバッチの創業者たちに、感覚コーディングについての意見を調査しました。今、Redditのチャットやチャットジーピーティでの投稿を読むと、みんな「助けて、僕のプログラムは30ファイルになって、すべてがフリーズして常に壊れているみたい」と言っています。
感覚によるコーディングよりいいものなんてありませんよね。専門知識もなくてただ気にしないことが…。おそらく多くの人が、ある企業で働いていて、その会社が開発パターンを設定しようとした経験があるでしょう。その中で決断を下すときでも、時間が経つにつれて難易度が指数関数的に上がっていきます。
そのため、アーキテクチャを再構築して、一時的に曲線が平らになりますが、時間が経つとまた指数関数的な難易度カーブに直面します。何かを変更するたびに、問題が膨らみ、より困難になり、奇妙な副作用が起き始めます。これが繰り返し起こるのを目にします。
でも今、完全に「感覚」でいくと決め、アーキテクチャのことを気にしなかったらどうなるでしょう？現実的にどれくらい続けられるのか、試してみる価値はあるかもしれません。感覚によるコーディングでどこまで行けるのか？
私たちはDevinに126のコミットをさせ、ゲームを完全に感覚でコーディングしました。Devinにのみプログラミングさせました。専門のゲーム開発者にコードをレビューしてもらったとき、かなり奇妙な経験でした。ゲーム開発の可能性を映し出すようなアイデアがたくさんありましたが、どれも正しいやり方ではありませんでした。
例えば、Z軸でソートするけれど、実際にはZ軸ソートを使わなかったりします。通常はそうするものですが、統計的モデルは通常、Z軸でソートしてから何かを行うものです。しかし、それがコードベースに現れるのは、統計的にそうなるべきだからかもしれません。なぜかわかりませんが。
私たちは基本的に彼らにいくつかの質問に答えてもらいました。「どんなツールを使っていますか？」「ワークフローはどう変わりましたか？」そして「ソフトウェアエンジニアリングの未来はどうなると思いますか？感覚によるコーディングの世界でソフトウェアエンジニアの役割はどう変化するでしょうか？」
かなり興味深い回答がありました。皆さんは、創業者からの引用で好きなものはありますか？
私が一つそのまま読みます：「ソフトウェアエンジニアの役割は製品エンジニアに移行すると思います。コードとツールがみんなを10倍のエンジニアにしていくため、人間の感性が今まで以上に重要になっています」これはOutletの創業者からのものです。
コード生成があなたを10倍のエンジニアにするのでしょうか？彼らが言おうとしていることは理解できます。つまり、あなたはより…結局、すべてのプログラミングは、あなたが何かを実際に好きなものに変える能力に帰着します。例えば、ゲームを作るとき、最終的には自分のビジョンを実行するためのプラットフォームを作るための難しいことの集まりです。
10倍という部分には納得できませんが、この考え方は理解できます。コード生成が十分に速ければ、技術的には二度とコードを書く必要はありません。それが彼らが主張していることだと思います。
スタートアップの創業者たちは、この質問に対して最も適切でない人たちだと思います。その理由は、創業者たちは基本的に、製品を維持したり長期製品に機能を追加する人たちとは異なる方法でプログラミングをするからです。創業者たちはアイデアをできるだけ早く形にするためにプログラミングをします。
使用する技術、選択する言語、利用するサービスなどに妥協し、とにかく何かを形にしようとします。そのため、全体的なアーキテクチャが最優先事項ではなく、特定の部分を「感覚」で進めることも問題ないかもしれません。
コードを千行以下の小さなセクションに分割すれば、感覚によるコーディングが機能する世界は存在するかもしれません。アーキテクチャをセットアップして、小さな部分を感覚でコーディングする方法も考えられます。予測範囲が小さいほど、LLMが正確に生成できる可能性が高くなるからです。
私も一生単体テストを書き続けたくはありません。テストと仕様を書いて、それが機能するようにプロンプトするだけの世界もあるかもしれません。
アストラのアビーは「私はあまりコードを書きません。ただ考えてレビューするだけです」と言っています。エンジニアで実際にこれがいいことだと思う人はいるでしょうか？「もっとコードをレビューしたい」と思うエンジニアを知りません。これは非常に技術的な創業者からの言葉で、前の会社も開発ツール会社でした。彼はコーディングが非常に得意なので、そのような人がこういうことを言うのは興味深いです。
コピーキャットの別のアビー、アービーは「今はコードへの執着が少なくなりました。コードを破棄するか改良するかの判断にバイアスがかかりにくくなりました。3倍速くコードが書けるので、必要なら破棄して書き直すのも簡単です」と言っています。
このテクノロジーの本当に素晴らしい点は、並列化が非常にうまくいくことです。K60のヨーは「私はすべてをカーソルで書きます。時には2つのカーソルウィンドウを並列で開いて、2つの異なる機能についてプロンプトを出します」と言っています。なぜ3つではなく？実際、たくさんできるでしょうね。
マージのようなものですね。もちろんそうですが、それは単に2人の作業者が働いているようなものです。マージの衝突は自然なことで、それほど心配していません。
彼が「コードが気に入らなければ破棄して改良し、再度やり直せる。コードに執着しなくなった」と言っている部分について、まず、それは心構えの選択であり、コードへの執着は常に直せます。それはスピードとは関係ありません。
速くなりたいなら、言語を学び、速くタイプすることです。何をしているかわかっていれば、本当に多くのコードを書けます。その上、それはおそらく無関係でしょう。コードが速く変わるほど、バグを再導入したり、微妙で非常に難しい新しいバグを導入する可能性が高くなります。これは確かに興味深い課題です。
また、誰かが会社を売る能力を、その人が聞くべき人かどうかの判断基準にするのは好きではありません。本当に賢い人もいれば、運がよかっただけの人もいるでしょう。他の人が見て、その人のやり方を真似て、単に売って早く撤退しようとしている人もいるかもしれません。
何かが成功する理由はたくさんあります。その人が実際に賢くて、先見の明があり、正しい時期に正しい問題を解決できたからかもしれません。「彼は会社を売ったから話を聞くべきだ」というのは、良い理由なのでしょうか？
Train Loopの創業者は、コーディングの変化について「6ヶ月前に比べて10倍速くなり、1ヶ月前から今までは100倍速くなった。指数関数的な加速だ」と言っています。
100倍速くなったというのは本当でしょうか？それ以前はどれほど遅かったのでしょう？100倍速くなったというのはとんでもない発言です。コードの書き方を知らない人がコードを書こうとするのを見ると、ifステートメントの構築方法を考えているのを見るのは、爪を引き剥がすようなものです。とても苦痛です。
そのため、Co-Pilotのようなものが実際に10倍速く感じるかもしれません。もはや単に論理のみに頼っているわけではないので、速くなるのです。それは理解できます。
それは本当に興味深いですね。広く起こっていることかもしれませんね。実際には2つの異なる役割になります。今日のエンジニアの自己割り当て方法に対応しています。フロントエンドかバックエンドのどちらかであり、バックエンドはインフラストラクチャについてであり、フロントエンドはPMの役割に近くなります。
あなたはほとんど民族学者のようになり…民族学者という言葉がどういう意味か知りませんが…GDPの未開発部分に入り込み、GDPのその部分の人々が実際に何を望んでいるかを抽出し、それをコードに変換するのです。
Triple Biteを運営していたとき、これは実際に技術的な評価と同じくらい重要なことの一つでした。特定の会社に合うエンジニアを見つけようとする場合、技術的能力の一定の閾値が必要ですが、それ以上は、実際にユーザーと話したいかどうかです。
一部のエンジニアは、ユーザーが誰かを知り、彼らとコミュニケーションを取り、生の反応を得て反復できるような仕事にずっと動機づけられます。つまり本質的に製品エンジニアになります。一方、他のエンジニアはそれをまったく望まず、ユーザーとのやり取りを煩わしく感じ、ただ難しい技術的問題や、バックエンドの改良に取り組みたいと思います。
それが私たちがバックエンドエンジニアと呼ぶものです。フロントエンドとバックエンドだけではなく、ツールエンジニアもいます。これは非常にウェブ中心の見方です。
私個人的には顧客と直接仕事をすることはあまり好きではありません。むしろ自分が顧客になり、自分が抱えている問題を解決する製品を構築したいです。他のプログラマーの問題を解決するツールを構築することは大好きです。それは自分自身の問題でもあるので、非常に深いレベルで理解できるからです。
フロントエンドでもバックエンドでもない他の分野も存在します。彼らが話しているMLも、MLエンジニアでいっぱいですが、彼らはフロントエンドでもバックエンドでもありません。
これはこのアンケート回答で出てきたテーマです。LLMが実際のコード作成を重要でなくする可能性があり、あなたが製品の問題を解決するセンスを持っているか、またはアーキテクトとしてシステムの問題を解決したいかの選択を迫られるという考えです。
彼は今、バックエンドエンジニアにはセンスがないと主張しましたか？完璧な表情で一時停止しました、本当に完璧な表情です。バックエンドエンジニアにはセンスがないだって？
彼が言おうとしていることは理解できます。つまり、製品の実際の構築よりも、美観や使いやすさを好むということです。これは少し奇妙な区別だと思います。フロントエンドにもこれが必要だからです。
複雑なプロジェクトであれば、例えばCADのようなものや、フロントエンドを含まないユーザーインターフェースを構築する場合、実際の論理が横にあり、全体的な状態の世界があり、そして小さなフロントエンドがあります。その場合、その人はバックエンドエンジニアと同等かもしれませんが、実際にはフロントエンドで作業しています。
Google Sheetsは技術の驚異です。それは恐らく99%バックエンド、一部フロントエンド、あるいは80%バックエンドコーディングと呼ばれるものです。フロントエンドにあるにもかかわらず、UIに関するものですが、全てにも関わらず。そして20%が実際のUI作業です。
興味深いことに、このアンケートが示したのは、これらのツールはデバッグが酷いということです。人間がまだデバッグをする必要があります。実際に何をしているのか、バグは何かを理解する必要があります。誰もが大好きなデバッグですね。論理エラーがあり、正しく理解できない…「デバッグして」と言うだけの方法はないようです。
非常に明示的にする必要があります。初めてのソフトウェアエンジニアに指示を与えるように、指示を細かく与えなければならないとあなたは言っていました。デバッグさせるには本当に丁寧に指示しなければなりません。あるいは感覚を受け入れて、アンドレ・カーパシースタイルで、バグを無視して再ロールするだけです。最初からやり直すように指示するだけです。
そんな生活を実際に送ることは想像できません。なぜか、コンテキストフリー文法からコンテキスト依存文法へ移行し、今度はコンテキスト依存文法の上にコンテキストフリー文法を作ってまた作り直しています。どうやってこの状況になったのかわかりませんが、ここにいます。
RNGプログラミングは、アンドレ・カーパシーが実際に説明したのはフォートナイトのようなものです。「タワーに降りて、運良くショットガンを手に入れ、相手が斧しか持っていないか、あるいは相手がショットガンを持っていて自分が斧しか持っていないかもしれない。成功するまで何度も試す」という感じです。
実際にコードを書くことが1000倍安くなると、コーディングスタイルがどれほど変わるか、驚くべきことです。人間なら、長時間かけて作業したものをバグがあるからといって捨てて最初から書き直すようなことはしないでしょう。常にバグを修正するでしょう。でも、LLMなら1000行のコードを6秒で書き直せるなら、なぜそうしないのでしょう？
それは、人々がMidjourneyやPlaygroundで画像を生成する方法に似ています。アーティファクトや気に入らないものがあっても、プロンプトを変更せず、単に再ロールをクリックして5回試して、時には「これなら使えるぞ」というものが出てくることがあります。
ここで少し離れる必要がありました。人生について考えました。少し単純すぎるかもしれないと思ったのは、C.S.ルイスが「人間廃止」の第3章で魔術の死と科学の誕生について語っていることです。科学の誕生では、知識の追求があり、知識そのものが目標でした。科学が進むにつれて、科学は自然を支配したり、対象を量に変えて売ったり、人間に対して力を持つために追求されるようになりました。
第3章の主要な議論の一つです。そして気づいたのは、おそらく魔術の死と科学の誕生のスタイルに適合するコーダーの世代がいるということです。彼らは目的のための手段としてプログラミングを追求します。旅が目的地なのです。より良いプログラマーになりたい、より多くの問題を学びたい、コンパイラの仕組みを理解したい、コンパイラ自体を構築したいというような。
コンパイラを作る速度よりも、コンパイラを作ること自体が重要なのです。そして、それが私が見ているものの一部です。知識への欲求と自然を支配する欲求という、コインの両面があります。
「人間廃止」は本当に良い本です。第1章は本当に興味深いですが、第2章は正直言って完全に理解しているかどうか確信がありません。第3章は私の最も好きな章で、人間の苦境と何が代償となっているかについて語っています。非常に興味深いです。
このフレームでシステムを構築しているのは、基礎から段階的に構築しているのではなく、本当に最初から行っているからです。基本的に今日のこれらすべてのツールは、潜在空間のどこかに隠されている生成コードの世界から来ているので、最初から異なる勾配を見つけ、行き詰まらないようにする必要があります。そして少しランダム性を加えて再生成させたいのです。
しかし、次の世代の05では、実際に構築できるようになるかもしれません。現時点では、ほとんどは再ロールして書き直す必要がありますが、まだその上に構築することはできません。しかし、現在のコーディングツールのどれも推論とうまく機能しているのを見ていません。
私たちは持っています。03は3.5 Sonnetよりはるかに優れたデバッグができます。6ヶ月後にこの議論をする頃には、これが真実ではなくなるかもしれません。
はるかに優れているって？3.5 Sonnetは、私が話したほぼすべての人が、Sonnet 3.7が出るまでは最高だと主張していたように思えます。これは単なる感覚的な発言ですか？
Twitterを現実の表現と捉えるのは問題ですが、Twitterは現実を表していませんが、私が見たすべてのコーダーは、AnthropicのClaudeが一般的にはるかに優れていると言っています。
私は実際にはコード生成ツールを使用しません。そのイテレーションループは非常にイライラするもので、自分で書いた方が速く、将来についても考慮できます。使用すると本当にイライラするので、使えません。
Twitterのほとんどはただのジャバスクリプトを書いている、その通りです。ダイアナ、人々が使用しているモデルやIDEについて話したいですか？いくつか本当に興味深い傾向があります。
数エピソード前に言及したように、2024年夏にバッチの大部分がカーソルを使用し始め、変化が起き始めましたが、今では圧倒的にリーダーです。しかし、他にも起きていることは、これは非常に速く変化する環境であり、ウインドサーフは急速にフォローしており、カーソルに対して非常に良い製品になり始めています。ジャレッド、あなたはウインドサーフがカーソルより優れている理由の経験がありますよね。
もう一つ質問があります。飛行機に乗っていてコードを書きたい場合、インターネットアクセスがなかったり、Amazonがダウンしていたりするとどうなるのでしょうか？完全に立ち往生してしまうのでしょうか？これが私たちが向かっている世界なのでしょうか？「インターネットが切れたら全員帰れ、何もできないぞ」という世界？
人々が切り替える主な理由は、今日のカーソルは主に見るべきファイルを指示する必要があることです。公平を期すために、先ほどの点に戻りますが、飛行機でのコーディングは私の最高のコーディング体験です。理由は、インターネットから完全に切断されるからです。飛行機でインターネットを使おうとしても、不安定で、ウェブサイトに行くのに45秒もかかることがあります。
そのため、Googleを使わなくても解決できる難しくて面倒な問題について考えることが多いです。最後の飛行機での仕事では、大きな製品のテストを追加しました。ユニットテストから全体の製品を統合テストできるようにしました。これは実際に必要なものでした。小さなバグが発生し続けていたからです。
これは「飛行機コーディング」の一例です。飛行機でのコーディングは実際に素晴らしいものです。インターネットやその他何も必要とせず、問題をすぐに解決できるものを構築できるからです。実際に非常に気持ちいいです。
「刑務所コーディング」とも言えますが、思考方法や問題へのアプローチを変えるものです。使用している言語や作業している領域に精通している必要があります。とても楽しいですし、多くの視点を変えることができます。自分がどう思うかによって問題を解決する最良の方法を探索するのであって、誰かが道を示してくれるわけではありません。
「アンカーバイアシング」という概念があります。「この映画の制作費はいくらだと思いますか？」と聞かれて、私が「2億ドル」と答えると、あなたは答えを知らない限り、その2億ドルという数字に基づいて答えるでしょう。何も知らなければ、私の答えに引きずられて「おそらく1億5千万ドル」と答えるでしょう。しかし、私より先に答えていれば、まったく異なる答えを出していたかもしれません。
これらのツールに常に頼ることで、彼らが最初に教えてくれる答えに非常に偏りがちになります。自分の創造的な方法で空間を探索するのではなく、潜在的に最適ではない局所的な最適解に沿って作業することになります。飛行機でのコーディングには楽しい要素があります。難しい問題から創造的に抜け出す方法を考えるのは、非常に独特で楽しい方法です。プログラミングの最も好きな形の一つです。
コードベースに関して、大きなコードベースがある場合、どうすればいいか指示できますが、どこを見るべきか指示する必要があります。ウインドサーフは全コードベースをインデックス化して、どのファイルを見るべきか自分で判断するのがかなり上手です。他にも違いはありますが、現時点ではそれが最も重要だと思います。
ウインドサーフとカーソル、どちらを使用しているかについて簡単な質問です。両方を使用した場合は、ウインドサーフなら1、カーソルなら2と答えてください。ウインドサーフなら1、カーソルなら2です。
奇妙なことに0が多いですね。恐らく、私は創業者ではないチャットに入っているからでしょう。現実は、ほとんどの人は創業者ではないということです。もしTheoのチャットでこの調査をやり直せば、回答の内訳はかなり異なるでしょう。
創業者でなければ成功しないという事実です。もしlevels.ioが全く同じ調査をしたら、あるツールと別のツールを使用している人の割合も非常に異なるでしょう。
Devinについても言及されていますが、あまり真剣な機能には使用されておらず、コードベースを理解していないというデメリットがあります。主に小さな機能に使用されています。私はたくさん使用したことがあります。彼らが使用する理由は、実際に推論モデルを使用したいからです。デバッグの質問をポストして、より強力な推論モデルを使用するためです。現在、カーソルとウインドサーフはまだ古い世界にいます。6ヶ月未満前の推論モデル以前の世界です。創業者たちはそれを使用しており、一部はモデルを自己ホスティングしています。これは、より重要な機密IPを持っている場合があるためです。
モデルの変化について言えば、コード生成の大きな流れは6ヶ月前にはClaude Sonnet 3.5でしたが、今でも大きな競争相手です。ほとんどがまだ使用していますが、01、01 Pro、03、つまりこれらの推論モデルが使用され始め、ほぼSonnet 3.5と並んでいます。
もう一つは、コード生成にはほとんど使用されていないGPT-4です。興味深いのは、DeepSeek R1も言及されており、実行可能な競争相手として使用され始めていることです。Geminiはほとんど言及されていません。Geminiについて聞いたのは、非常に手頃な価格であることです。
ところで、Gemini…問題は、Geminiは最初の立ち上げがあまりにも馬鹿げていたため、人々が「Geminiを試してみるべきだ」と言っても、「いいよ」としか言えません。「Geminiを使うよう説得しようとしているの？それはクレイジーだ」と思います。
最も長いコンテキストウィンドウを持っていると、何人かの創業者から聞いています。彼らの使用方法は、コードベース全体をGeminiのコンテキストウィンドウに入れ、バグの修正を指示するというものです。彼らのコードベース全体がnpmパッケージのグルーコードにすぎず、数百行しかないからです。
常にうまくいくわけではありませんが、コンテキストウィンドウに全体があるため、時には一発でバグを修正できることがあります。最近リリースされたFlashback 2.0を搭載した推論モデルでの採用が増えるにつれて、これは興味深いでしょう。まだ試していない人もいると思いますが、フラッシュバックウィンドウと推論の組み合わせが良い競争相手になるかもしれません。
現在のバッチでLLMによって書かれているコードの推定量はどのくらいですか？これはかなりクレイジーです。具体的にこの質問をしました：「あなたのコードベースの何パーセントがAI生成だと推定しますか？」この質問の解釈は、インポートしたライブラリを含まない、実際のコードベースの文字の何パーセントが人間の手で入力されたか対LLMによって出力されたかというものです。
驚くべきことに、創業者の4分の1が、コードベースの95%以上がAI生成だと答えました。これはかなり馬鹿げた答えだと思いますし、これは良くない質問だと思います。より良い質問は、コード行のうち、どれだけがAIによって100%生成されたのか、対人間が何らかのレベルで介入したものかということです。
なぜなら、もしあなたがプログラミングをしていて、「view」と入力し、「yes.yes.yes」とタイプした場合、そのコードの何パーセントを実際に入力したのかという議論になります。実際には多くのコードを入力したわけではなく、LSPを使って多くのコードを入力したのです。実際に入力している割合とそうでない割合についての議論です。
あなたが一行を生成し、「view」と入力し始め、「いやこれは欲しくない、これが欲しい」と言ったとしましょう。AIが行うことを修正する必要がある場合、それを90%と呼ぶのは難しいです。文字自体は良い測定方法ではないと思います。
LLMによって純粋に生成された、修正されていないコード行であるべきです。それが非常に良い回答でしょう。もしコードを常に書き直す必要があるが、LLMが多くを行っていると感じるなら、人々は割合を予測するのが非常に悪いのです。
これは狂っていますね。私たちが資金を提供したのは非技術的な創業者ばかりではありません。これらの人々は誰もが非常に技術的で、1年前には自分自身で一から製品を構築する能力を完全に持っていました。しかし今、その95%はAIによって構築されています。
ただし、あるいはnpmパッケージのためかもしれません。1、2の例があるようです。彼らは若くて、過去2年間でコーディングを学んだので、カーソルが存在しない世界を知らないのです。
彼らはあまり技術的ではないでしょう。これらのAIツールだけを使って学び、それだけを使用している人が多くのことを知っているとはとても思えません。もしオフラインになったら、実際に何かできるのでしょうか？疑わしいです。
もう一つのドッグの割り込みですが、犬が脱走してしまいました。電気フェンスが実際には機能していなかったからです。単に切れていたのです。GPSベースの電気フェンスなので、犬は敷地から脱走できません。
プライベートジム、このメッセージが長くなりすぎないといいのですが、提供してくれるコンテンツに心から感謝したいです。1年半以上あなたのYouTubeハイライトとTwitchストリームを見ていて、ソフトウェアの向上と改善を続けるための大きな動機付けになっています。
AWSでインターンとしてのオファーをもらったばかりです。そのインターンシップを活用して素晴らしいことをしてください。あなたがそれから何かを得られたのであれば嬉しいです。これが私たちがこれらのことをする大きな理由です。
私はあなたが単に「感覚」コーダーになることを望んでいません。AIには素晴らしい使い方がたくさんあり、私も定期的に使用しています。学びたくないときや、コーディングの特定の部分に関心がないときなどです。
例えば、Tree Sitterを使ってC++を解析し、深さグラフを構築するような場合です。それを使って面白いものを見つけました。ドキュメントを読む必要はなく、ただ愚かなツールを完成させたかったのです。そのツールは絶対的にひどいものでしたが、いくつかの基本的な変更を加えました。
基本的に「感覚」でそれを通り抜けましたが、全てのコードを捨てて二度と使わないつもりだったので問題ありませんでした。AIの素晴らしさを軽視したくはありませんが、皆さんが興奮して学びたいと思ってくれることを願っています。
それにより、「感覚」でコーディングするときも、すべてをダブルチェックし、なぜそれが悪いのかを理解し、生成した「感覚」（別名「馬鹿げたもの」）を実際に有用なものに改良できるのです。
このバッチの私の最高の会社の一つがまさにこれです。創業者たちは非常に技術的な頭脳を持っていますが、コンピュータサイエンスとプログラミングで古典的に訓練されているわけではありません。彼らは信じられないほど生産的で、本当に驚くべき製品をたくさん生産でき、AIがほとんど全てを書いています。
これはデジタルネイティブ世代に関する議論を思い起こさせます。私にとってはそれは恐ろしいことですが、同時に、十分な粘り強さを持つ人なら誰でも何かを作れるというのは素晴らしいことでもあります。希望的には、彼らはプログラミングに魅了され、プログラミングを学びたいと思うでしょう。
LLMによって偶然にプログラミングに魅了された人々が、プログラミングを学びたいと思うのは素晴らしいことです。それにはポジティブな面もあり、完全に軽視したくありません。
なぜ恐ろしいのかというと、彼らが生成するソフトウェアがとても難しくなるからです。彼らが会社を売却したり、エンジニアを採用したりする時、もし古いコードベースで働いたことがあれば、それは全くの無法地帯のようになり、非常に難しくなります。そこにはいくつかの酷い経験があります。
ここに良い例があります。このコードは存在し、あなたはそれを使用し、それで遊んだことがあります。ただ、それが実行されていることに気づいていなかっただけです。誰かがそれを書き、誰かがそれを維持する必要がありました。「波動拳コード」ですね。
インターネットとともに成長したデジタルネイティブと同様に、これはAIコーディングツールとともに成長した世代です。彼らはソフトウェアエンジニアの古典的なトレーニングをスキップし、いわゆる古典的なトレーニングとは、6ヶ月のReactブートキャンプではありません。
良い点は、コンピュータサイエンスは現代のプログラミングと比較すると大部分が無関係になっていることです。プログラミングは理論よりもむしろ技術になってきています。金属がある温度で溶ける理由の基本を知らなくても溶接ができるようなものです。ただ、これくらいの熱を使い、これを良くするだけでよく、実際の活動に熟練すればよいのです。
理論ではなく、それで問題ありません。それがプログラミングが変わりつつあることだと思います。感覚でやるだけです。しかし、彼らは実際に非常に技術的な思考を持っています。数学や物理学の学位を持っています。彼らはシステム思考と呼ぶべき生の能力を持っています。
何が変わらず何が変わったかについて話すべきかもしれません。この感覚コーディングにより、数学や物理学のような他の技術分野から来る人々が、過去よりもはるかに速くプログラマーとして非常に生産的になることができるでしょう。
昔、コーディングブートキャンプがあって、物理学者をプログラマーに再訓練しようとしましたが、あまりうまくいきませんでした。構文やライブラリ、本当に生産的になるために知る必要があるすべてのことを学ぶのに時間がかかりすぎたからです。しかし今は新しい世界です。
これは文字通りC.S.ルイスの「人間廃止」第3章の議論です。質を量に変えたいということです。これは純粋に生産性に物事を還元しています。これは実際にかなり野生のことです。私たちが人間を単なる原子と動きに還元し、それだけにしてしまう様子を見るのは興味深いです。
ブートキャンプも特に会社に雇われることに焦点を当てています。これは2015年頃のことで、会社自体が構文が彼らの採用プロセスで最も難しい部分ではないと考え直していた時期です。
私はここで言いたいのですが、彼が「学ぶのに時間がかかった」と言っていますが、私も学ぶのに時間がかかりました。再帰に本当に苦労し、最初は優れたプログラマーではありませんでした。しかし、非常に高い向上心を持っていました。そのため、学習の遅さは高い向上心によって克服されました。速く学ぶことができなかったので、代わりに1日15時間を費やしました。それが学習の遅さを速くする簡単な方法です。
再帰をどのくらいの頻度で使用しますか？再帰は非常に重要です。ソフトウェアエンジニアと彼らの採用プロセスでは、本当の変化がありました。古典的に訓練されたコンピュータサイエンティストを雇いたいという考えから、実際に生産的で速くコードを書く人を雇いたいという考えへの変化がありました。
これらの議論のいくつかは永遠に存在します。Railsが最初に登場したときを覚えています。データベースとやり取りする方法としてのActive Recordは、「内部を本当に理解していないと、低性能なウェブソフトウェアを書くだけだ」と見なされていました。
今から見ると、最も成功した企業として、StripeとGustoは本当に頭に浮かぶ例です。彼らはツールで本当に生産的な人々を求め、採用プロセス全体を変更して、ツールを使いこなす人々を選ぶようにしました。
StripeはAPIとして最悪のものとして知られていませんか？Stripeは最悪です。StripeのAPIは意味不明です。インタビューは「考え方を教えてください」から「ラップトップで3時間以内にToDoリストアプリを構築してください」に変わりました。これらの企業は大きな成功を収めています。
彼らが成長し、スケールするにつれて、古典的に訓練されたシステム思想家を持つことが実際にボトルネックになりました。エンジニアの採用方法は変化していますが、まだ十分に速く変化していないようです。
この調査の結果は、私たち4人にとっておそらく比較的驚くべきものです。アマゾンの面接でチートをしている男が、多くの企業が定期的に騙されることを認識し、物事が変わる時が来たと考えるような大きな変化を引き起こすでしょう。
かなり衝撃的なことが、過去6〜9ヶ月の間に私たちの裏庭で起こっています。私の推測では、エンジニアリングの採用はこれにまだ追いついていません。人々はまだホワイトボードに立って、そういった種類のことをしています。生産性に基づいて採用する代わりに。
Stripeのようなところはゲームをリードしており、今ではみんながこの方法でエンジニアを雇う必要があります。それさえも古いやり方になるかもしれません。アンケート回答から浮かび上がったのは、「私たちは皆、製品の人々である」という考えです。実際に必要なのは、何を構築すべきかを理解する優れたセンスです。
二つ目は、システム思想家やアーキテクトになり、大きな絵を本当に理解することも価値があるということです。おそらく本当に生産的なコーダーになるということ、これは常に偉大なエンジニアの定義に入っていました。つまり、彼らは実際にコードを非常に速く書くことができるということ、それは時代遅れかもしれません。
LLMが実際にコードを素早く書くのが本当に上手で、あなたが言ったように、今では実際にコードを最初から書き直して、デバッグする方が安くなっているなら、スキルは完全に異なるものになるかもしれません。
問題は、二つの異なるステージがあることです。0から1への段階では、速度が…私が完全に公平に言うと、このパネルと私では非常に異なる動機があります。このパネル全体の目標は、資金を必要とする人々や企業を見つけ、資金を提供し、製品をある程度の収益性にし、年間10万ドルの収益を達成し、シードラウンドからシリーズAに移行することです。
そして、会社をシリーズA、シリーズBに進め、最終的には莫大な収益で撤退することです。彼らが最終的に求めているものは、これらの会社の結果として働く多くの人々が求めているものとは異なるかもしれません。
シリーズCやシリーズDで長く存在している場所で働いている場合、シリーズAで行われた選択は、シリーズAの時とはかなり違った感じがするでしょう。異なる意見を持つかもしれません。
Railsの戦いは実際に手詰まりになりました。Active RecordやRailsを使用することで、確かに0から1へ非常に素早く行けましたが、Twitterに何が起こったでしょうか？それは「失敗クジラ」になりました。基本的に1に達すると、そのアーキテクチャでは10億や100億、1000億ドルの評価やユーザーに到達することはできません。
単に機能しません。Twitterの失敗を見ることになるでしょう。あなたが言ったことには微妙な点がありますね。0から1に到達すること…午前10時に何かがあるのではないですか？
午前10時にはあります。午前10時PT（太平洋時間）です。この配信を見れば、それが42分後に始まることもわかります。心配しないでください、Biscoさん。忘れていました。それは午前10時PTです。心配しないでください。ありがとう、Biscoさん。
その姿勢が好きです。私はモンタナ時間でさえもしません。私はモンタナ時間だけをやっています。そして迅速に、そして10億ユーザーにスケールする能力は、まったく異なる二つのスキルセットです。
そして、現在のところ、人々の周りでは置き換えられないかもしれません。私が発見したことの一つは、最大のRailsサイトの一つをスケールしていた時、あなたも最大のRailsサイトの一つをスケールしましたが、それを行わなければならない人はそれほど多くないということです。1に到達することはとても稀です。
あなたが0から1に非常に速く到達した方法は、オープンソースをたくさん使用したことでした。そして、ある時点で、多分2年後、スタートアップに1年半後くらいには、もうランダムなGemを使用できなくなりました。Gemを使えなくなりました。それらは私たちのスケールを持つ会社のために設計されたことがなく、単に崩壊してしまったからです。
ところで、これは実際に良い指摘だと思います。TJはこれを「ヨットの問題」と呼んでいます。実際、このマインドセットにも多くの価値があると思いますので、少し矛盾した部分があります。
何が機能することを証明するためのコードを作るという馬鹿げたコードの価値は何でしょうか？対して、時間が経つにつれてさらに機能をハックして作るのに実際に役立つものを作ることの価値は？
彼らが説明している二つの異なる世界があります。彼が特に説明している世界は「ヨットの問題」の世界です。10億ユーザーを持ち、ヨットを手に入れ、スケールする方法を見つけなければならない問題です。それは非常に異なる問題のセットです。
少なくとも彼が、これは人間の問題に戻る必要があると認識していることを嬉しく思います。PCは常に本番コードになります。それが常に本番コードになります。それが私たちが見ている固有の問題です。
この会話で微妙な点が見られることを嬉しく思います。それは非常に良いことです。もう少しまとめると、0から1は創業者が非常に速く機能をリリースできる感覚コーディングに最適ですが、製品市場適合性に達すると、まだたくさんの本当にハードコアなシステムエンジニアリングがあり、1からnまで到達する必要があります。
非常に異なる種類の人々を雇う必要があり、それには非常に良い歴史的な例があります。例えばFacebookも。1からnは書き直しでもあります。これは個人的に恐ろしい言語だと思います。炎上するかもしれませんが、これは悪い言語だと思います。
私もそう思います。申し訳ありませんが、非常に悪いです。しかし、非常に素早く物事を提供できましたが、ある時点で機能をリリースするための大きなボトルネックになり、ハードコアなシステム人材を雇って、ヒップホップという裸の金属で速く動作するカスタムコンパイラを構築する必要がありました。
そのような人々は感覚コーディングの人々ではなく、このハードコアなシステム人材であり、私たちの調査によると、現在のツールはこの低レベルのシステムエンジニアリングに優れていません。
Triple Biteが何かを知らない人のために、「ハードコア」という言葉はほとんど何も意味しません。実際、ハードコアは何かを意味します。これがLLMではない理由です。LLMは「それが何を意味するのかわからない、音楽か、ポルノグラフィーのことを指しているのか」と言うでしょう。
しかし実際には、何かに非常に熱心に取り組んでいる人を指しています。コーディングに本当に熱心で、その難しい部分に入ることができる人をハードコアと呼んでいます。LLMではないので、その区別ができるのです。
これは実際に関連していますが、何かを説明してもらえますか？Triple Biteは私が2015年に始めた会社で、本質的にエンジニアのための技術評価を構築していました。私たちの目標は、ソフトウェアを使用してソフトウェアエンジニアを評価する方法を自動化することでした。
多くのことをするだけで専門家になるわけではないことを覚えておいてください。多くの人にインタビューしたからといって、必ずしも優れたインタビュアーになるわけではありません。単にたくさんインタビューしただけです。一次元の測定は専門知識の良い測定ではありません。
あなたはどうやってこれを行いましたか？コード生成モデル以前のこの方法は、エンジニアをインタビューするための独自のカスタムソフトウェアを構築しました。基本的にデータにラベルを付け、コードを書くように頼んでインタビューしました。
非常に典型的でした。アルゴリズムの問題も含まれていました。あなたとあなたの共同創業者は、地球上の他の誰よりも多くの技術インタビューを行ったと本当ですか？
そうだと思います。純粋な時間で考えると、それが初期の日々でした。毎日、何千人もの人々に対して行いました。その後スケールアップし、約100人のエンジニアと契約して、インタビューごとに支払いました。
あなたは正確にこの質問をするのに最適な人です。文字通り地球上の誰よりもこれについて考える時間を費やしました。今日Triple Biteを再び始め、エンジニアのための新しい技術評価を設計する必要があるとしたら、どうしますか？
多くのことをしたからといって、必ずしもその分野の最も有能な専門家になるわけではないことを覚えておいてください。多くのインタビューをしたからといって、良いインタビュアーになるわけではありません。単にたくさんインタビューしただけです。一次元の測定は専門知識の良い測定ではありません。
大きな収穫は、人々は異なることを望んでいるので、あなたが評価しようとしているものを事前に正確に知り、その周りに技術的なスクリーンを設計する必要があるということです。これは、StripeやGustoのような企業が基本的なCS知識を持っているかどうかを気にしないことを知っていたので、その点でスクリーニングすることは意味がなかったという点です。
彼らは実際に仕事で行うことをスクリーニングしたかったのです。私たちの製品は、会社が求める可能性のあるすべてをスクリーニングし、誰かの最大スキルを見つけ出し、そのスキルを評価する会社に最大スキルを持つ人を送ることでした。
私が思うに、それは素晴らしいインタビューになるでしょう。これを聞いて、私も大部分同意します。激しいリートコード問題は良い測定ではないと思います。確かに指標ではあります。ホワイトボード上で激しいリートコード問題をプログラミングできるなら、少なくともコードを書けることはわかります。
コードの品質と長期的な能力には疑問がありますが、それでもコードを書くことはできるでしょう。そこには非常に重要な何かがあります。しかし、私はより対話的なインタビューが好きです。私が受けた最高のインタビューの一つは、誰かがAmazonのSNSとSQSの周りにラッパーを書くように頼んだものでした。それをより便利に使うためにはどうラッパーを書くでしょうか。
基本的なダミーアプリを作り、基本的なライブラリがあるとして、「これを構築してください」と言うことができます。プログラミングが得意なら1時間もかからないはずですが、プログラミングが本当に得意なら6つの質問をして、あなたがどこまで到達するかによって、コードを見たことがなくても、良いAPIを持ち、全体的に理解できるものを構築する能力を測ることができます。
これは、「ヒープを知らないから」というようなことではありません。「ライブラリを使ってもいいですか？」と実質的に聞いているのは、「ライブラリの周りに堅牢なシステムを構築できますか？」ということです。これは良いことだと思います。なぜなら、a)誰かがプログラミングできることを示し、b)LLMはあまり役立たないことを示します。なぜなら、それは「GitHub CLIを使えますか？」というような質問ではなく、LLMがコードを出力するだけの質問ではないからです。これは愚かな質問です。私はGitHub APIを学びたくないので、おそらくLLMに「これとこれとこれの方法を教えて。わかりました、これらの方法を知っているので、これらすべてを使用する製品を構築します」と頼むでしょう。それは愚かだと思います。
代わりに、「これが私たちの理論的なアプリです。この種の体験を構築してほしい。5つの異なるAPIがあります。どうぞ、xを構築できますか？xを構築した？では次に、機能yを追加できますか？」という感じです。そして、誰かが「良いものを構築したい。あまり抽象化しすぎないが、いくつかのフォローアップ質問をすることを最小限に準備してほしい」というような方法で作業するのを見ることができます。
もし誰かがxすら通過できないなら、「この人は本当に素晴らしいものを構築することができない」と思うでしょう。そして彼らは「ラップトップを持ってきてください。Linux、Mac、Windowsのビルドがあります。好きなものを持ってきて、好きなエディタを使ってください。準備してください。ここにgitリポジトリがあります。コードを早めに見ることもできます。ここにAPIがあります」と警告するでしょう。
「プログラミングができることを証明してください。言語はそれほど重要ではありません。Go、Rust、C、JavaScript、TypeScriptのどれかを選んでください。あなたの好みを選んで、それをやってください。プログラミングができることを証明してください」というような。「ゲームボーイを持ってきて」。今日の世界ではPythonですね。
実際に、少なくともこれらのツールの使い方をどれだけ知っているかを考慮したスクリーンがあるでしょう。再び、先ほど言ったことと矛盾するかもしれませんが、製品をどれだけ速くコードできるか、実際に明示的にスクリーンする何かかもしれません。そして、バーをずっと高く設定する必要があるでしょう。
おそらく異なる質問をする必要があります。なぜなら、元のTriple Bite評価に戻ると、それらの質問の多くは文字通りコピー＆ペーストしてChatGPTに貼り付けると、完璧な答えを吐き出すでしょう。その場合、あなたは本当にそれほど多くを証明していません。
誰かがコードを書けることを証明する一つの方法です。それは唯一の方法ではありませんが、もし誰かがホワイトボード上で疑似コードを書いて「深さ優先探索の方法はこうです」と言えるなら、彼らが物事を知っていることはわかります。どの程度かは別として。
もし単にコピーしているだけなら、質問は100倍難しくする必要があります。それはものごとに答える素晴らしい方法ではありません。必ずしもそうではありません。なぜなら、スクリーンにどのような条件を課すかによって異なるからです。それは興味深いと思います。
古典的な質問は「tic-tac-toeを構築せよ」でした。もちろん、それを監視なしで行い、誰かがtic-tac-toeの解決策を持ち帰るだけなら、それは2秒しかかからないでしょう。彼らを見たいなら。
ところで、技術的なインタビューで誰かが「tic-tac-toe」と言い、あなたがジッピディに行ってtic-tac-toeを作り、それを彼らに渡したとしたら、インタビュアーとして、あなたの全体的な目標は考え方を示すことだということを覚えておく必要があります。
また、インタビューは双方向です。あなたもその人をインタビューします。その人と話すのは好きですか？もしその人と話すのが好きでないなら、そこで働きたくないかもしれません。もし彼らのインタビュー方法が好きでないなら、実際にそこにいたくないかもしれません。
私は質問があります。古い質問でLLMなしでコードを強制的に書かせるのか、それともLLMを使わせて、古いものが陳腐になったので新しい質問が必要なのか？今、ソフトウェアエンジニアを雇っている人は誰でも考えるべきことだと思います。
正しい答えが何かはわかりません。私にとっては答えが明らかに思えます。誰かがプログラミングできることを確認したいので、ツールを使う時に活用する方法を知っています。これがそれほど明らかでない理由には少し驚いています。
興味深いですね。おそらく異なることをテストすることになるでしょう。私も多くのエンジニア採用を行ってきました。一つの重要なスキルは、コードを読んでデバッグする能力です。LLMが出力する悪いものと良いものを判断する味とトレーニングを持っている必要があります。
候補者がツールを使用していて、LLMが合理的な解決策を出力し、候補者が「これは実際には悪い」と言うのを見ることができます。それは良い兆候です。良いコードと悪いコードを判断する高いレベルの思考を知ることは、良い感覚コーディングをするために必要です。
まだ味を持つ必要があり、必ずしも古典的にトレーニングされている必要はないかもしれませんが、何が良くて何が悪いかを判断するのに十分な知識が必要です。
彼女が言っていることは、10年間のプログラミングと、多くのことが間違ってしまい、あなたのすべてのプログラムが絶対的ながらくたに変わるのを見る必要があるということです。そしてそれを経験した後、何が良いものを作り、何が悪いものを作るかを実際に理解できるようになります。
何が良いものを作り、何が悪いものを作るかと言うとき、私は一般的に、すべてのソフトウェアは1行から10,000行のコードの1から10,000のチャンクに分解できると考えています。これは私がほぼすべての機能を見る方法です。
滅多に、それ自体で完全なもので、何らかのライブラリや何かによって抽象化できないものを見ることはありません。そしてこれに落ち着くことができれば、ワンショットでこれを行うことができれば、非常に優れたプログラマーになることができます。なぜなら、システムを通じて設計する必要のあるインターフェースがいくつかあり、これらの10,000を簡単にワンショットできるからです。
古典的にトレーニングされたものが、古典的なトレーニングとは何かという冗談です。私の古典的なトレーニングさえも、古典的なトレーニングではありません。私のコードはオリーブオイルのようです。
ところで、オリーブオイルは良いですよ。オリーブオイルは本当に良いです。十分な練習があれば良くなります。それが私の意見では一定のものです。
それは興味深いですね。コードの生成よりも、コードレビューをインタビューとして行うということですね。システム設計のような形式もあるでしょう。彼らが製品をどれだけ良く出せるかを知りたいのですね。
それで味をテストしていますね。デバッグ能力と味をテストします。しかしどうやって、私たちがAIコーディングネイティブと呼ぶこれらの子どもたちが、古典的にトレーニングされた世界から来ていない場合に、味を発達させるのでしょうか？次世代にとって興味深いですね。
持たなければなりません。そうでなければスタートアップは死にます。この創業者が、AIによって95%書かれたコードでスタートし、1年後、2年後には1億人のユーザーがそれを使っているとします。それは崩壊するでしょうか？
それも良い証明だとは思いません。1億人のユーザー向けのコードを書くことと、10人のユーザー向けのコードを書くこと、1万人のユーザー向けのコードを書くことは、すべて非常に異なる側面です。
アメリカ全体があなたの製品を使うようにするだけですね。コードをそのように測るべきではないと思います。これらのシステムは、最初の推論モデルのレルムでは、デバッグにはそれほど優れていません。実際に起きていることの深みに降りる必要があるでしょう。
彼らができないなら、別のアーキテクトを見つけなければなりません。誰かを雇う必要があるでしょう。それは世代になるでしょう。1万人のデイリーアクティブユーザーを持つ会社を始め、データベースとしてGoogle Sheetsを使用することもできます。多くのことを考える必要があります。
しかし、それはそうすべきだという意味ではありません。ただ、そうできるということです。そのため、ユーザー数は必ずしも、ソフトウェアエンジニアの良し悪しを判断する良い基準ではありません。
これらのコード生成ツールですべてを再ツール化するのが非常に簡単なので、十分に良いエンジニアはたくさんいるでしょう。参入障壁が非常に低いので、十分に良いエンジニアはたくさんいるでしょう。しかし、例外的な、上位1%になるためには、意図的な練習に取り組む必要があります。
私たちが話している類似は、マイケル・グラッドウェルが専門家になるための10,000時間の練習という概念を普及させましたが、これはアンダース・エリクソンの研究に由来します。その研究は非常に特定的で、世界クラスのバイオリニストをどのように見つけるかについてでした。それは単に時間を費やすことではなく、実際に計画され考えられた意図的な練習の時間でした。それは難しい仕事です。
もっと少ない時間で専門家になることができます。今、コード生成ツールで起きていることは、出力が非常に速いので、時間を費やすことが非常に安くなっていることです。十分な良さに到達することはできますが、世界で最高になり、最高の創業者になるためには、その意図的な練習が必要で、詳細に入り込み、システムを理解する必要があります。再び、ある程度古典的にトレーニングされる必要があります。
彼女はほとんど私を説得しそうでした。脱線すると思いましたが、いいえ、良い答えに戻りました。究極の答えは、単にプログラミング方法を学ぶ必要があるということです。なぜなら、コードを読んでいるなら、良いコードがどのように見えるか知る必要があるかもしれないからです。
良い例は、歴史的にピカソです。彼は偉大な画家の一人で、実物そっくりの絵を描くのが驚くほど上手でした。これは彼が有名なことではありません。ピカソを想像するとき、その反対を想像します。彼が抽象的な牛にどうやって到達したかという有名な一連の絵があります。
実物そっくりから始まり、いくつかの反復を経て、彼が非常によく知られている抽象芸術の本質に到達します。しかし、彼は世界で最高になるためには、実際に非常に優れた画家であり、古典的にトレーニングされ、非常によく描くことができなければなりませんでした。しかし、それは彼が知られていることではありません。
これらのエンジニアの二つのクラスを見ることになると思います。「十分に良い」という非常に太いクラスがあり、それらのエンジニアは必要です。しかし世界最高の、外れ値になる創業者は、意図的な練習を積む必要があるでしょう。
はいとも言えますが、いいえとも言えます。世界クラスのシステムレベルの素晴らしいエンジニアがCEOやCEOになった素晴らしい例がたくさんあります。Max Levchinを考えます。ShopifyのToby Lukeを考えます。これらは実際に素晴らしい人々です。
しかし、そうではない人もたくさんいて、それでも会社のCEOや共同創業者です。そして、これは先ほど言っていたことにつながります。それは採用に戻ります。また、これは運が大きな要素を占めることを示しています。
素晴らしい会社を始めることができますが、それが1年か2年ずれているだけかもしれません。「早すぎるか遅すぎるだけだ」という感じです。文化が変わり、ムードが変わります。運とタイミングは、素晴らしいスキルとタイミングが作れるものは驚くべきものであり、スキルがなくてもタイミングが良ければ同様のものを作れることも驚くべきことです。
あなたが言及したTwitterの類似について考え続けています。FacebookとTwitterを比較すると、両方のケースで、スクラップで素早く動き、物事を壊す方法で0から1に非常に速く移行しました。Facebookはスケーリングの技術的課題を印象的な方法で解決することができました。
ほとんどの人がそう思うでしょう。MarkZ Zuckerbergははるかに技術的で、はるかに詳細に関わっていたと思いますが、Twitterのスケーラビリティの課題も使用パターンに基づいてより難しかったと思います。
Facebookの使用について言えることは、一日中かなり滑らかに成長することです。人々はそれを常に使用しています。Twitterの問題は、使用が信じられないほどスパイク的であることです。スーパーボウルや世界的なイベントがあると、突然10倍の使用量があります。
フィードのファンアウトの仕組みは、根本的に非常に難しいコンピュータサイエンスの問題だと思います。それは公平な指摘です。しかし、ツールによって本当に制約されていたとも思います。
この恐ろしいQシステムを使用していたのを覚えていますか？Starlingと呼ばれていました。私はそれを使用しました。なぜなら、Twitterは私たちよりずっと大きく、彼らはとても賢いので、クズのようなものを使用するはずがないと思ったからです。いいえ、彼らは完全にクズを使用していました。
そしてNetflixはReactive Socketsなど、さまざまなものを発明しました。探してみると、JavaScriptでそれをパースする方法についての私のコミットが見つかるかもしれません。それは起こります。私はクズを使用し、それをうまく機能させることができませんでした。大企業は多くの悪い判断をしました。
これは床に仕事を落としていました。こんなクレイジーなバグが起こり、最終的に「もうこれは使用しない。MQかその他の正しいものに切り替える必要がある」と言いました。
Rubyは信じられないほど遅い言語で、PHPよりも10倍遅く、PHPはすでに遅すぎました。だから、基本的にあなたは1に到達できて幸運だと言えます。
あなたはトレーニングを受け、本当に深いシステム思想家であることに利点はありますか？私がPalanteerにいた時の話します。そこで数年後に燃え尽きて、ロゴを設計した後、YCスタートアップを始める前に6ヶ月間インタラクションデザイナーとして過ごしました。
このひどいベンチャーバック企業があり、最終的に倒産しました。それはクレジットカードソフトウェアで、最悪でした。6ヶ月間、基本的にインタラクションデザインを構築していました。それは本当に楽しく、空き時間に自分のスタートアップに取り組むことができました。
レンタカーのようなものの、ファセット検索を設計していたことを覚えています。その後、私の開発マネージャーとエンジニアとの会議に行き、彼らがそれを実装することになっていました。
一瞬だけ一時停止する必要があります。ここにはジョークがあるに違いありません。それがジョーク以外の何かであるとは信じられません。「シェブロン付きの円、バム！ゲイリーに成功！」と言うくらいですから。
彼らは「ああ、それはできないよ、そのやり方ではできない」と言いました。私は「何を言っているの？インデックスをこのようにするだけだよ」と言いました。彼らは「うわ、どういう意味？」と言い、私の履歴書を調べました。
それを聞いてください、あなたのインタラクションデザイナーから。基本的に彼らは「どうやってそれを知っているの？」と言い、私は「お前は私に嘘をついた」と。それが重要なことです。データベースにインデックスを使用するだけで、人々が「なんてこった」と言ったのですか？
覚えておいてください、プログラミングのスキル分布はおそらく非常に急なガウス分布か、おそらくアルファベータ分布です。インデックスによって制約されている。クレイジーです、絶対にクレイジー。
周りを見回すとき、おそらくバイモーダルです。おそらく、構文を書くのに十分な能力よりも少し上の人々が大多数で、残りは、ああ、そこには暗い世界があります。
これが職場での究極の教訓でした。職場では、採用した人々は嘘をつかない、怠けない、私たちは皆目標と使命のためにいると想定しています。しかし、違います。彼らが嘘をついていることを見抜けなければ、彼らは嘘をつくでしょう。
ところで、彼は正しいです。これはスティーブ・ジョブズの「ボゾ爆発」に通じます。彼は絶対に正しく、これは実際に良い反論点で、彼は偶然にもこの始まり全体を逆転させています。
感覚ベースのプログラミングを知らないプログラマーが創業者の一人である場合、彼らは雇用も上手くできません。それが現実です。それをどうするか？他の会社にオフロードしますが、その他の会社の能力は何でしょうか？その他の会社が優れたエンジニアを提供できる能力があるかどうかをどうやって知るのでしょうか？
何をしているかわからなければ、その仕事をうまくできる人を雇うことはできません。だからこそ、通常は他の側面を知っている人と一緒に創業し、初めての創業者は常に最悪の傾向があります。彼らは創業者になるために知る必要のあるすべてのことを知らないからです。
彼らはしばしば詐欺にあい、非常に悪い取引を受け入れ、絶対的に爆発することがよくあります。2回目の創業者は「いや、いや、いや、これらすべてが非常に間違っていることを知っている」と言い、それらの水域をはるかに上手に航行できます。
あなたが想像できるように、プログラミングが素晴らしいことが決してできなかったこれらの人々は、素晴らしいプログラマーを雇わないでしょう。運が良いかもしれません。常に運が良いことはあります。常に偶然によって正しい人を雇うことができます。
十分に良い推薦やつながりのある友人がいて、正しいものを得るのに役立つかもしれません。それは常に起こるでしょうが、何をしているかわからなければ、それが保証されることはありません。
最悪の部分は、時々彼らを呼び出さなければならないことです。時々、あまりにも丁寧な職場文化があり、人々は「ああ、それは通します。そして彼らの裏で悪口を言います」と言います。彼らを解雇すべきです。
因みに、AIエージェントも全く同じことをします。AIエージェントは人間と同じように絶対にあなたを欺くでしょう。偽りの丁寧さは実際には礼儀ではなく、邪悪なもの、あるいは狡猾なものと呼びます。
「有害」は正しい言葉ではありません。なぜなら、有害という言葉は愚かすぎて広すぎ、文化的に乗っ取られて意味をなさないからです。より良い言葉が必要です。マキャベリアンという言葉もありますし、多くの用語があります。しかし、丁寧という言葉は正しくありません。
「受益者を詐欺する」という言葉の方が良いかもしれません。ダンテの地獄の第9圏が良い描写です。もし技術的に十分でなく、彼らの馬鹿げたことを呼び出せなければ、「いや、あなたは私が要求した変更をしていない」と言えなければ、従業員はそうするでしょう。
あなたの観点に戻りますが、古典的にトレーニングされていることが依然として役立つ理由です。人間であれそうでなくても、あなたのために働くすべての人々を呼び出すことができなければなりません。それができる技術的な能力を持つことは超能力です。
まとめると、0から1は創業者が非常に速く機能をリリースできる感覚コーディングに最適でしょう。しかし製品市場適合性に達すると、1からnに到達するためのハードコアなシステムエンジニアリングがあり、非常に異なる種類の人々を雇う必要があります。
歴史的にもFacebookのような良い例があります。1からnは書き直しでもあります。これは個人的に恐ろしい言語だと思いますが、申し訳ありません、炎上するかもしれませんが、これは悪い言語だと思います。私もそう思います。
それは非常に悪いですが、物事を非常に素早く提供できました。しかしある時点で、機能をリリースするための大きなボトルネックになり、ハードコアなシステム人材を雇って、裸の金属で速く動作するHip Hopというカスタムコンパイラを構築する必要がありました。
そのような人々は感覚コーディングの人々ではなく、このハードコアなシステム人材です。私たちの調査によると、現在のツールはこの低レベルのシステムエンジニアリングには優れていません。
これらすべてのツールが最高のエンジニアに超能力を与え、悪いエンジニアをさらに悪くしているのでしょうか？これはTrain Loopの創業者からの引用です。「コーディングがどのように変わったか：6ヶ月前から1ヶ月前までは10倍速くなり、今は100倍速くなりました。指数関数的な加速です」。
私たちはNetflixでも全く同じような話を聞きました。それは実際に私たちに忍び寄りました。まるで誰かが巨大な豆の木の種をばらまいたようなものです。AIが自分を100倍速くしたと考える創業者には資金を供給したくありません。文字通り彼と一緒に仕事をしたくないでしょう。選択肢があれば。
私たちの現在の感覚では、これは流行ではなく、去るものではありません。これは実際にコーディングの主流な方法であり、あなたがこれをしていなければ、取り残されるかもしれません。これはここに留まり、あなたは取り残されることはありません。
ツールは大きく変わるでしょう。正直なところ、Claude 3.5が出た時のことを考えてください。今持っているものと比べると、Claude 3.5のスキルは完全に無価値です。変化の速さはあなたのスキルが窓から出ていく速さでもあることを忘れないでください。
そして今、注目してください。「正直なところ、あなたは取り残されていません。取り残されるとは何からですか？プロンプトスキルからですか？いいえ、あなたはイエスが戻ってきたときに取り残されているのです。そして今、Kirk Cameronが『Left Behind』（取り残された人々）という非常にひどく制作された映画に出演します」。
正直なところ、あなたはイエスが戻ってくることに準備ができていなかっただけです。それが彼らが意味することです。反キリストがここにいて、私たちは皆死にます。獣の印は実際にはSam Almanのジッピーのお尻の穴のロゴです。それが起こることです。かなり悪い未来です。
わかりました。ここにはたくさんの洞察がありました。彼らは私とはまったく異なる視点で世界を見ていると思います。そのため、他の人の視点を見るのは常に良いことです。そして私は、世界の大部分にとって、優れたエンジニアになる価値は優れたエンジニアになることではなく、莫大なお金を稼ぐことができる人になることだと気づきます。
少なくともこれらの人々にとって、価値はあなたを雇い、彼らのお金で100倍のリターンを得ることができることを願っていることです。それを覚えておく必要があります。特に仕事を探しているか、関連性を持ちたいと思っている場合は、ここで彼らが実際に何を求めているのかを理解することが重要です。
人気のいわゆる未来が今どこにあるのかについての良い洞察です。これにより、私は現在、ウェブサイトの立ち上げと構築が最悪かもしれませんが、奇妙な問題を解決するツールを構築するのは最高だと気づきます。では、それはトレンドのスキルセットでしょうか？
おそらく小さな企業ではあまりトレンドではないでしょう。私はそこにはいません。もし起業したい場合、私の流行のツールセットを変更する必要があります。それは、クレジットカードを気にせず、自動スケーリングのサーバーレスなどに投げ込むような、ウェブサイトを拡張して構築する究極の能力を持つ必要があります。
私はウェブサイトを簡単に立ち上げることができません。LaravelとLaravel Cloudを使って、それを立ち上げて実行することはできます。おそらく1日半でNext.jsを学んで、Next.jsで何か素晴らしいものを立ち上げることもできるでしょう。しかし、それは私が使いたいと思うスキルセットではありません。Reactでもう一度優れたスキルを持ちたいとは思いません。
それは私に喜びや充実感をもたらすものではなく、コーディングについて興奮させるものでもありません。そのため、他の開発者向けのツールを構築することを好むようになりました。それが私が常に好きだったこと、それが私の存在、それが私のいる場所、それが私が望むものです。
しかし、彼らの話を聞くと、そのスキルセットは必ずしも素晴らしい創業者のスキルセットではないことに気づかなければなりません。Tursoのような深く技術的な創業会社はたくさんあります。ちなみに、彼らは私にもう支払っていません。スポンサーではありませんが、それでも彼らを強くお勧めします。
Tursoは非常に技術的です。創業者たちは何十年もLinuxコア貢献者でした。彼らは素晴らしいです。ここで見逃していることは、すべて彼らが言っていることが実際には価値がなく、あなたが思うように進むわけではない、深く技術的なスタートアップもあるということです。
とにかく、良い話でした。ゲイリー、よくやりました。彼が開発に2年間かけたという非常に美しいロゴが今でも信じられません。5年でもそれを開発できるとは思いません。それは今まで見た中で最高のものです。
コメント