36,907 文字
私がAIブロになったのは、あなたも気づいたかと思います。私自身も突然のことでした。これらの新しいAIツールから日々のメリットを実感するまでには少し時間がかかりました。正直なところ、私の意識が変わったのはDeepSeekが登場してからです。これらのツールが単なる大企業からの低品質で高額なAPIではなく、技術を前進させる人々による完全なオープンソースのエコシステムであることを見たとき、もう少し深く関わりたいと思いました。
Cursorをより頻繁に使い始め、クールなチャットアプリで遊んだり、自分でアプリを構築したりしてこれらの知識を学ぶにつれ、AIは完全に私の脳を書き換えたと言っても過言ではありません。これはT3チャットが登場する前から持っていたビデオのアイデアで、ずっと考えていたことです。
人々との会話の中で浮かんできたことを少しずつリストに追加していて、ここで時間をかけて、AIが私の構築の考え方や実際の構築作業、そして一般的にテクノロジーとの関わり方をどのように変えたかを正式にまとめたいと思います。
これは、よくあるようなAIのハイプ的な「世界を支配する」という話ではありません。実際に私が日々AIとどのように仕事をしているか、そして予想外の方法で私のワークフローがどのように変わったかという実践的な日常に焦点を当てます。目標は、私が数年かけて学んだことを、皆さんが数ヶ月で取り入れられるようにすることです。
気に入ったものを取り入れ、気に入らないものは捨ててください。コメントで興味深いと思ったことを教えてください。始める前に、スポンサーからの一言があります。すぐに戻ってきます。皆さんも私も、以前よりもずっと多くのコードを出荷していると思います。
しかしそれは新しいボトルネック、特にビルドの問題を生み出します。ビルドが完了するのを今まで以上に長く、そして頻繁に待つようになりました。それは、今日のスポンサーであるBlacksmithを試すまでのことでした。彼らは実際にビルドの時間を半分に削減できるのです。信じられないほどです。
GitHubがどれだけ遅れているかを強調していますが、より重要なのは、問題に対して正しい解決策を構築することに集中したときに、物事がどれだけ良くなるかということです。セットアップは非常に簡単で、GitHubのYAMLファイルの1行を変更するだけで準備完了です。Nodeのような何かのGitHubアクションを実行すると、実行時間はほぼ半分で、コストは3分の1以下になります。
AndroidエミュレータやRustのTokyoのような他の巨大プロジェクトも、同様に驚異的な節約レベルです。コストの差も信じられないほどです。ちなみに、GitHubアクションだけではありません。Dockerビルドは同じボックス上にインクリメンタルキャッシュを配置するため、最大40倍高速になります。
そのボックスはゲーミングCPUを使用しています。本当です。それは狂っているように聞こえるかもしれませんが、ゲーミングプロセッサは単一スレッドのパフォーマンスがはるかに高く、従来のサーバーには必ずしも有用ではありませんが、コンパイルされたアプリをビルドしようとしてCPUを100%で実行している場合には、非常に優れています。
そのため、彼らはこのような驚異的なパフォーマンスを実現しています。データスループットがNVMeドライブに直接キャッシュを保存するため、驚くほど高いというのもその理由です。コロケーションされたキャッシュを使用すると、そのデータを取得するのが最大4倍速くなります。
ちなみに、GitHubの通常の10GBの代わりに25GBのキャッシュが得られます。彼らはすでにZigg、Go、Rust、JavaScript、Javaまで、あらゆる言語のランナーを用意しています。まだ試していないなら、試してみてください。毎月3,000分無料です。登録するだけで、クレジットカードも必要ありません。
もし気に入ったら、Theoが紹介したと伝えてください。今日swive.link/blacksmithでチェックしてみてください。
短くて簡単なところから始めましょう。私は好奇心旺盛な人間です。定期的に物事について変な質問を持ちます。数日前にYouTubeビデオを見ていたときに実際に持った質問の一つが「太陽はどれくらい古いのか？」でした。
以前なら、「！G」と入力してダックのバンを使ってGoogle検索をしていました。バンに馴染みがない方には、これは検索先を変えるためのクールな方法です。そして私は自分の検索エンジン「Unduck」を作り、好きなプラットフォームを少し速く、DNSルックアップをせずに検索できるようにしました。
「Theo made a search engine」という動画があるので、探してみてください。面白いですよ。私がそれを作った核心的なアイデアではなかったものの、誰かが提案したことの一つで、「そうだね、それは理にかなっている」と思ったので、T3バンを追加しました。unduckの検索クエリの最後に「！T3」と入力すると、すぐにT3チャットでの検索（というよりチャット）として開きます。
これが非常に便利だとわかりました。今では私はGoogleよりこちらをよく使います。これが私のワークフローにこれほど不可欠になるとは予想していませんでしたが、「ffmpegコマンドでH265 MP4 1080pに高速Macアクセラレーションで変換する方法」といった具体的すぎるクエリで検索する際に「これはGoogle検索には具体的すぎるな」と思って代わりに「！T3」を使うことが何度もあります。それでコマンドがすぐに手に入ります。
とても良く、とても便利です。これによってT3チャットのデスクトップアプリが近い将来登場することがより楽しみになりました。ブラウザ内の新しいタブビューではなく、専用のホットキーがあれば良いのに、と思います。
これは私のブラウザ内のZenです。新しいタブを開くとこの素晴らしいUIが表示され、GoogleではなくT3チャットで検索できます。これが非常に役立っています。チャットでは、ランダムなGitコマンドなどのためにこれをよく使うという人もいて、それらをすべて追跡するのは面倒だという点に完全に同意します。
これが私にとってどれほど有用だったか、驚くばかりです。だから最初に挙げたいのは、以前とは違う方法で検索を使っているということです。とはいえ、良い検索スキルを持つことは依然として重要です。AIが問題に答えられず、特定のニッチな情報を探すために狂ったようなGoogle検索をしなければならなかった経験は何度もあります。
Deep Researchのようなツールがどれだけクールでも、特定の技術に関する特定のエラーコードについての具体的なドキュメントを探したり、Appleさえ文書化していないSafariの奇妙なブラウザの動作と戦ったりするときには、遅すぎて間違いが多すぎるため、それらに頼ることはできません。
AIがそういった情報を正確に取得できるという世界はありません。単にできないのです。そしてAIができることとできないことについての直感を養うことは、Googleを使って検索から具体的な情報を取り除き、十分に一般的なものを見つける方法を学ぶのと似たスキルです。それは馬鹿げたことに思えるかもしれませんが、Googleを頻繁に使う若い年齢で学ぶことです。
エラーを検索するとき、まずはエラーコードだけで始めます。それがうまくいかなければ、エラーコードを完全に削除します。なぜなら具体的すぎて、必ずしも検索しているものに関連していないかもしれないからです。そのようにGoogleを使いこなす能力を身につけることはスキルです。そして、AIツールが単純な検索をより良く処理できるようになったため、そのスキルはより重要になっていると思います。
ただし注意点があります。AIツールは特定のことに対しては優れています。先ほど挙げたffmpegコマンドの例のように、そのような具体的なGoogle検索では探している結果を得られない可能性が高いです。しかし、それは単純なリクエストです。AIは具体的であっても単純なことに非常に優れています。
AIは、特に十分にニッチで具体的な複雑なことに対しては優れていません。だからチェックアンドバランスが必要です。私はこれが以前考えていたよりも気に入っています。この機能を追加したとき、私は懐疑的でした。そして今では、Google検索よりもこちらを使うことが多くなりました。これは起こるとは思っていませんでした。
ツールが実際にGoogleが私のワークフローで占める位置を意味のある形で変えるとは思っていませんでしたが、そうなりました。参考にしてください。私はこれを非常に有用だと思っています。
このリストのほとんどが開発者特有のものだと気づきました。だから開発者の脳に関する部分は別のセクションにしておき、まずは一般的なことについてもう少し話したいと思います。
AIがウェブの利用方法をどのように変えたかに興味がない場合は、少し早送りしてください。すぐに開発の部分に入ります。ただ、最初にもう一つ触れておきたいのは、人が言っていることに基づいて信頼しなくなったということです。
これは、インターネットやこれらのツールとテクノロジーを使うにつれて、何が信頼でき、何が信頼できないのか、どの信号が有用なのかを学ぶ必要があるという、Googleの使いこなしのようなスキルの一つです。
例えば、Redditで二人の異なる人からの返信があり、一人は「これは問題に対する本当に良い解決策だ」と言い、もう一人は「これはひどい。あなたは何を話しているのか分かっていない」と言っています。あなたが身につけるスキルは、その人の投稿履歴を見て、他に何について話しているかを確認し、誰の経験があなたの経験により近いか、誰の経験があなた自身についての情報をより有用に提供してくれそうかを判断することです。
何が言われているかよりも誰が言っているかが、非常に重要です。一般的に言って、私のように名前、顔、仕事を公開している人からのアドバイスを、Twitterのランダムなアニメのプロフィール画像のコメンテーターよりも真剣に受け止めるべきです。
同様に、テクノロジーについて何か起こるたびに数秒以内に投稿している人がいたら、例えば私が投稿するとほぼ即座に返信があり、それがある程度理解しているようだが、完全には理解していないように見える場合、私はコミュニティの中にそのような人がいることに気づいています。
正しい言葉を使っているが、基礎となる知識が少し欠けている、そんな不気味な谷のような感じがします。たとえ十分に理解している人であっても、本当に経験豊富な人のように見えるが、わずかに間違っている発言をするのです。
これはよく見られることですが、今ではかつてないほど重要になっています。Twitterへの返信からランダムな履歴書の山へのアップロードまで、AIに車輪を任せ、それによって運ばれるようにしている人の数は多いです。私はこれまで以上にオンラインの人々に対して懐疑的になっています。そして大部分において、それは良いことです。
印象付けられにくくあるべきです。誰かが言ったことだからといって、ただ信じるべきではありません。その人を信頼してから、彼らが言うことを気にすべきです。明らかに、彼らが言うこと、彼らがすることを見て、そしてピースを組み合わせることで信頼を築きますが、誰であるかはかつてないほど重要です。
詐欺師、嘘つき、生成者、実際には何を話しているのか理解していない人々を避けることを学ぶことはかつてないほど重要です。以前は、物事を説明するための正しい言葉を知っていることは、その人がある程度何が起こっているのか分かっているという十分な指標でした。
今はもはやそうではありません。言語以上に、誰かがその仕事に優れているかどうかを識別するためには、もっと多くのものが必要です。しばらく前に私が自分のために構築したもの、それは私が誰かを切り捨てるために使う赤旗のセットのような精神モデルです。
オンラインで情報を共有する人が多いので、十分に知っていることがあり、誰かがそれについて間違っていれば注意を払わなくなるという状況を持つことが非常に重要です。
これの私のお気に入りの例の一つは、実はアップルの世界におけるバッテリーゲートです。チャットに聞いてみましょう、バッテリーゲートとは何ですか？できれば2文以内でバッテリーゲートを説明してください。あまり意地悪はしませんよ、約束します。たぶんiPhone 6でした。はい、「スロットリング」は重要な言葉です。
ここでいくつかのことが見えてきます。「バッテリーの健康を保つためにデバイスのパフォーマンスを下げる」というのと、「バッテリーを節約するために電話の速度を落とす」という二つの文の違いがわかりますか？この二つの文の間には違いがあります。
バッテリーゲートで実際に起こったのは、アップルが初めて大きなサイズの電話であるiPhone 6で、バッテリーの健康状態が通常よりも速く劣化するという問題があることに気づいたことでした。
多くの人はバッテリーには「ジュース」があり、その容量が時間とともに減少すると考えているようです。実際には、バッテリーの劣化とは、バッテリーが経年劣化するにつれて、電力を供給する特性が変化することを意味します。劣化したバッテリーの挙動が異なる方法の一つは、低出力から高出力への切り替えが遅くなることです。
アップルはiPhone 6のユーザー、特に寒冷地の人々が、アプリを開くなど特定の操作をすると電話が勝手にシャットダウンする問題に気づきました。問題は、プロセッサをフルスピードにするためには、バッテリーからの電圧を大幅に上げる必要があったことでした。
それはアプリを開くことがCPUに非常に負荷をかけるタスクだからです。ストレージからメモリへの移動、プロセッサがデータを移動し、アプリを起動し、すべてをロードして初期化することは多くの電力を必要とします。ホーム画面にいるときはプロセッサの5%程度しか使用していませんが、アプリを開くと一時的に100%使用します。
つまり、バッテリーから引き出される電力量が一時的に大幅に増加します。問題は、プロセッサの電力需要が急速に増加するにつれて、バッテリーは非常に少量の電力から多量の電力を急速に送る必要があります。バッテリーが劣化している場合、その需要に応えることができず、電話はシャットダウンします。
そこでアップルは、電話のスピードは同じままで、最高速度に達するまでの時間を遅くするアップデートをプッシュしました。車の最高速度を変えるのではなく、0から60までの加速時間を変えたのです。彼らはこれを電話が勝手にシャットダウンする可能性を減らし、長期的にバッテリーの健康を保つために行いました。
これは「計画的陳腐化」として描かれ、アップルが意図的に電話を遅くして新しいものを買わせようとしているという批判がありました。しかし実際には、アップルは購入数年後も電話が悪い体験にならないよう努力した唯一の会社であり、購入数年後も電話を使い続けてもらうというビジネス上のインセンティブを持つ唯一の主要な電話メーカーです。
面白いことに、彼らは多くの点で計画的陳腐化を行っていない唯一の会社です。そして、これは彼らが計画的陳腐化とは逆のことをしている例です。彼らはあなたの電話とその健康を保つために本当に一生懸命努力しています。それがアップルの目標だからです。
アップルはあなたができるだけ長く電話を保持することを望んでいます。そして、もしアップグレードするなら、それを娘や友人に渡してエコシステムに参加してもらいたいと思っています。アップルは彼らのデバイスが故障することを望んでいません。それは明らかです。
この話を持ち出した理由は、バカをフィルタリングするのに非常に役立つからです。アップルについて話している人が突然、アップルがユーザーを嫌っている証拠としてバッテリーゲートを持ち出した場合、「ああ、ミュートボタンを押して、二度とあなたに注意を払わないでいい、なぜなら話していることを調べもしないからだ。自分が理解していないものに対する武器として使っている。」という感じです。
あなたが悪い人だとは言わないが、バカな人だと言わざるを得ない、あるいは少なくとも不誠実だ。どちらであるか自分で選んでください。どちらであれ、私はあなたを無視して人生を続けます。
今こそ、このような物事に対する心の枠組みを持つことが非常に重要です。誰かがあなたがよく知っていることについて十分に愚かなことを言ったら、その人を切り捨ててください。しかし、誰かがあなたの見方に反することを言い、あなたが学ぶことができるほど十分な経験をその分野で持っているなら、それも受け入れてください。
例えば、私がFlutterについて話すとき、それは悲劇だと思います。しかし、Flutterコミュニティには、私と深い会話ができるようにその強みをうまく説明してくれる人々がいます。しかし、彼らの誰かが「まあ、React Nativeのようなウェブビューよりは良いよね」というような愚かなことを言った瞬間、「ああ、あなたは実際にこのことを何も理解していないんだ」と思います。
このような誰かを無視するための枠組みを頭の中に持つことは、今日ほど重要だったことはありません。話は変わりますが、AIもこの罠に陥りやすいです。AIにバッテリーゲートについて尋ねたら、アップルの計画的陳腐化について教えてくれるでしょう。そしてアップルが対処するよりも安かったので和解した訴訟も引用するでしょう。そうです、良いコメントです。この文脈ではAIはあまり変わっていないようです。
インターネット上の多くの人々は、AIのあるなしにかかわらず愚かです。違いは、以前よりもはるかに知的に聞こえ、AIが適切な言葉遣いを助けてくれるので、より多くの正しい言葉を使うでしょう。ほとんどの意見は、間違った情報で正当化できます。
AIはその情報を見つけたり、さらには作り出したりすることを非常に簡単にしています。そしてそれは情報経済と真実らしさのオンライン状態にとって本当の災害です。だから、これらは私たちが注意しなければならない本当の問題です。そして公平に言って、このトピックは私の脳を書き換えています。これらは私の脳がすでに配線されていたことですが、以前よりもこれらの配線を多く使っています。
とにかく、一般的なことについては十分です。私の開発者としての脳と、AIが登場して以来それがどれだけ絶対的に変わったかについて話す必要があります。まず、テクノロジーの選び方から始めましょう。
多くの皆さんにとっては驚きではないでしょうが、私は新しい技術が大好きです。毎日直面する問題に対する新しい解決策が大好きです。誰かが新しい同期エンジン、APIを扱う新しい方法、アプリケーション全体でより良い型推論を持つ新しいTypeScriptツールを構築するのを見ると、このチャンネル全体がTRPCテクノロジーへの愛から始まりました。それらで行える素晴らしいことが私を駆り立て、素晴らしいものを作るよう促します。
それは私のモチベーションの多くの源です。私はそれが大好きです。だからこそ、これから言うことを言うのは難しいです。もう二度とT3スタックのようなものは現れないでしょう。
T3スタックを始めたとき、私が大きく注目したポイントの一つは、Rails、MEAN、MEARNがあった時代を懐かしんでいたことでした。私が始めた頃は、LAMP stackの時代でした。しかし、これらの時代、これらのコミュニティ、これらの動き、これらのテクノロジーには、その瞬間を表す言葉がありました。
それは単なるスタックではありませんでした。「ああ、これら4つのものを一緒に使う」というだけでなく、それは時代と考え方を表していました。そして私はしばらくそのようなものがなかったと感じていて、たとえそれが全く関係なかったとしても（私はT3スタックがどこかに行くとは思っていませんでした）、そのようなものが欲しかったのです。
モダンなフルスタックの型安全性についての考え方を表現するために使いました。これはMEANやMEARNがバックエンドでTypeScriptが意味のある形で使われる前に起こったことです。私はそれが大好きでした。T3スタックはこれらのことに非常に適していました。
では、なぜ「もう二度と現れない」と言っているのでしょうか？T4がすでに成功しているからではありません。それは私たちが今日使用しているテクノロジーがAIのトレーニングデータだからです。寿命はいつも問題でした。私たちがそれを見るのはPythonが依然として人々が使用する言語だからです。何かが十分に人気になると、それがどれほど悪くても、決して取り除くことはできません。
これをReactがどれほど良いか悪いかの議論にしたくありません。皆さんにはそれぞれの意見があり、ここでそれを変えるつもりはありません。Reactは関連性があり、誰もそれに反対しないことを願っています。Reactは多くの場所で使用されており、さらに重要なことにツールの巨大なエコシステムと、これらすべてのトレーニングの参考として使用される大量の優れたオープンソース資料があります。
Reactと周囲のツールに関する膨大な作品は、以前に見たことのない位置を保証しています。公平に言って、Pythonにも同じことが言えます。Reactのフック時代のような、Reactの書き方を変えたタイミングでさえ、もう一度起こることはないでしょう。
それは、これらのAIツールが私たちをとても速くしているため、アプリのパフォーマンスが10%向上するような開発者体験の20%の改善は、私たちが構築しているAIツールの精度が70%低下することにもつながるのであれば、もはや十分ではないからです。
私たちが毎日使用している言語、構文、そして構築するモデルは、過去10年間と同じ方法で変化する可能性は低いです。そして、私はT3スタックを行うことが大好きで、本当に何か似たようなものが来て、それを真に超えることを望んでいましたが、それはできないと思います。単にできないのです。
それはより趣味的なことになるでしょう。以前は、最もクールな新しいCPUアーキテクチャを構築できる人が多く戦っていたようなものです。ランダムな人々がガレージでプロセッサを構築していましたが、それらが十分に洗練され、確立され、使用するものが十分に標準化されたので、自分のプロセッサを構築するという考えは少し面白いものになりました。
今、自分のフレームワークを構築することもそうなるのではないかと心配しています。間違っているかもしれません。これについては全体のビデオがあり、「React the last framework」というタイトルで近々公開される予定です。このビデオが公開されるまでには既に出ているかもしれません。金髪のビデオだったので、古いものです。本当に投稿する必要があります。
しかし、理解していただけると思います。今日私たちが使用しているツールが、少なくとも開発者言語のフレームワークライブラリ側で、置き換えられるとはもう確信していません。これは何を意味するでしょうか？私は少し違った選び方をしています。以前よりも人気に基づいて選ぶことが多くなりました。
私の全コンテンツを通して伝えようとしてきたことの一つは、何かに早く取り組むことは助けるのと同じくらい、それ以上に傷つけるという考えです。私が常に挙げる例はモバイルアプリです。
2001年だと想像してください。モバイルアプリケーションの発展がいかに速いか、ハードウェアがいかに急速に改善しているかを見ています。ポケットのスマートフォンを大切に思い、未来はコンピュータではなく電話になると確信しています。だから決意します、「最高のモバイル開発者になろう。BlackBerry電話のJavaアプレットとKaio Era 2の業界をリードする専門家になろう」と。
5年経過し、iPhoneが登場します。さらに1年経ち、App Storeが登場します。あなたはApp Storeの1、2年後にモバイル開発を始めた人よりも良い立場にいるでしょうか、それとも悪い立場にいるでしょうか？8年のリードがあったにもかかわらず、彼らより遅れています。なぜなら間違ったものに投資して多くの時間を失ったからです。
それは間違ったことをしたという意味ではありません。その情熱と興奮があれば、それをしないと満足できなかったでしょう。そして、あなたを動機付けるものをすべきです。でも、十分に早く始めなければ取り残されると感じるべきではありません。
あなたの興奮に従ってください。もしSolidやSpeltやFlutterや新しいプログラミング言語（ElixirやRustのような）に熱狂しているなら、私の言葉であなたを止めないでください。ぜひやってください。しかし、必要だと感じていて、取り残されることを恐れているからそれを学んでいるだけなら、恐怖に基づいて学ぶのはやめてください。それは最悪の動機付けです。
恐怖からしか学んでいないなら、学んでいることを本当に理解することはできません。あなたが抱える問題を解決するから、あるいはあなたが気にすることに合うからこそ、ものを選んでください。先に行きたいからという理由で選ばないでください。取り残されることを恐れているからという理由で選ばないでください。
これは常に当てはまることでした。早くからTRPCを理解した人の一人になるメリットはありましたか？はい、絶対にありました。しかし、GraphQLに全力を注いでいた人よりそれほど雇用可能性が高くなるわけではありません。
TRPCは私にとって大きな利点でした。それは私をエンジニアとして市場で非常に有利なものにしたからではありません。それは5人のチームよりも速く動けるようにしてくれたからこそ良かったのです。
それが以前に私が異なるテクノロジーを選んだ主な理由でした。出荷する品質を犠牲にせずに最速になるものを選びました。TRPCのようなものは、GraphQLが要求する多大なオーバーヘッドとバイインを必要とせず、GraphQLが提供するフルスタックのセキュリティを提供してくれたので素晴らしかったです。
TRPCは私がGraphQLで可能だった同じ品質レベルで出荷することを可能にしましたが、10倍速く、単一のエンジニアとしてです。それは信じられないほどでした。
しかし、Emilyが言ったように、開拓者たちは崖から落ちる人たちです。TRPCは信じられないほど優れていて、今でも私はそれを支持していますが、今日のようなものに賭けることは大きなリスクでしょう。それが軌道に乗らない可能性があり、AIツールに正しいトレーニングデータが存在しない可能性があるだけではありません。
それはAIツールがそのギャップを埋めつつあるからです。Primeが以前ビデオで言ったことを考え続けています。正確な言葉は覚えていませんが、本当に感じた雰囲気がありました。
お気づきかもしれませんが、私は速くタイプします。新しいKinesisキーボードでは、約140〜150WPM程度です。現在は100程度ですが、それは2時間の練習でした。すぐに上達するでしょう。
私が速く出荷できる理由の一つは、考えるのと同じくらい速くタイプできるからです。そして、タイプが非常に速いので、アイデアを出すことができます。しかし、構文が非常に冗長な場合、私のタイピング速度は限界があります。
だから、もっと簡単な方法で書くことができるソリューションを選ぶでしょう。そうすればアイデアをより速く出せます。そうしないと、ADHDが勝ち、アイデアが完成しても入力が半分しか終わっていなければ、ファイルを完成させません。自分自身をそれほどよく知っています。
私はVimの使用者でした。深く使っていたわけではありませんが、Primeが言ったことが印象に残っています。PrimeがVimでどのように操作するか見たことがあると思います。彼はそのエディタで飛ぶように動きます。正しいファイルにジャンプし、正しい行に行き、一部を抜き取り、別の何かに置き換え、別の場所に移動して置くという彼の能力。彼は考えるのと同じ速さでVimを動かします。
ほとんどの開発者は、コードベースを移動し、同じ速度で考えながら変更を加えるという感覚を経験したことがありません。彼らは様々な要因によって妨げられています。使用してきたツールによって妨げられています。長い間前に行った、あるいは5年前に会社で働いていない他のチームメンバーが行った悪いテクノロジーの決定や悪いアーキテクチャの決定によって妨げられています。
タイピング速度によって妨げられています。エディタによって妨げられています。Vimを使わないか、Vimを間違った方法で使うことによって。LSPが遅すぎることによって妨げられています。様々な要因によって妨げられています。
そしてAIはそれらの妨げを減らすのに役立ちます。多くの人がAIツールを初めて使ったときに感じた魔法の感覚は、「これは自分では書けなかったコードを書くことができる」というものではありませんでした。今日ではそういったことも多いですが、多くの人にとっては「考えるのと同じ速さでコードを出すことができる」というものでした。
PrimeやJoshのような私たちは既にそれを持っていました。私たちは考えるのと同じ速さでコードを書くことができます。しかし、その一部は私たちがシステムをセットアップする方法でした。コードベースをセットアップする方法の一部でした。そして一部は妥協点でした。それが私がテストに反対する理由の一部です。
AIツールは、ほとんどの人にPrimeの瞬間、Vimゴッドの瞬間を体験させてくれます。間違いなく彼らがそれに値する前でさえも。コードベースで何年も働いて、あなたが思考からコードへと積極的に移行できるほど流動的に感じるべきです。
AIツールが可能にしたのは、はるかに経験の少ない人々がその同じ速度で動けるようになったことです。彼らがどの方向に動いているかは重要ではありません。これが最も重要な点です。AIはあなたが本当に速く動くことを可能にし、あなたがどの方向に行くかを気にしません。
通常、人々が何かに本当に速くなると、速くなるプロセスが自分自身を方向付ける能力も向上させます。例えば、車のレースが本当に速くなったけれど、ハンドルの操作方法を知らない人を想像してください。最速の陸上スピードレーサーが地図のナビゲーション方法を知らないようなものです。
これが私がAIツールに見てきたことの一部です。まだナビゲーション方法を知らない人々が、彼らにはまだ資格のないスピードを得ているのです。これはAIへの懸念についてではありません。これは私個人の脳がどのように再配線されたかについてです。そして、これが私に与えた影響は、以前ほどこれらのことを気にしなくなったということです。
私は以前離れた技術に戻りつつあります。その理由はいくつかありますが、トレーニングデータが増えたのでAIがそれに対してより優れていることと、私がイライラしていた面倒な部分が自動化されたことの組み合わせです。
以前なら嫌だったであろうことを、例えばT3チャットのコードベースの中の巨大なファイルを見せましょう。ここに、T3チャットのすべてのモデルを定義した巨大な893行のファイルがあります。これは以前なら何としても書くことを避けたでしょう。
しかし今、何か変更する必要がある場合、例えば「name」を「model_name」に変更したい場合、クレイジーなコマンドを使ったり、Vimで全ての「name」のインスタンスを選択したりする代わりに、単に「model_name」と入力を始めるだけで型エラーが表示されます。そこへ行って、「あ、そこだ」「あ、そこだ」とジャンプします。簡単にできます。何の努力もいりません。タブを何度も押すだけです。
あるいはコマンドKを押して、「nameをmodel_nameに変更」と指示することもできます。コマンドKは今いる領域を選択します。あるいはコマンドIを押してファイル全体に適用することもできます。
これらの種類のことは、以前は特定レベルのエディタの習熟度と流暢さを必要としていましたが、今はそうではありません。Vimの神と同じくらい速くエディタを飛び回ることができます。
そしてはい、「rename symbol」機能は存在します。それは正しく推論されているものには素晴らしく機能しますが、「satisfies」や他の部分を使用している場合はそれほどうまく機能しません。
ですから、チェックとバランスが必要ですが、それでも「rename symbol」機能を使用する場合でも、それが何であるか、どのように機能するか、アクセス方法、そして制限を知る必要があります。あるいはコマンドIを押して「nameをmodel_nameに変更」と言えば、それだけで実行されます。
実際、Geminiは何をするか教えてくれますが、それを実行しない傾向があります。すぐに修正されるでしょう。今回は実際に実行してくれています。適切にすべてを変更してくれています。そして、私が他の多くの開発者と同様にADHDを持っているので、同時に他のことをChrome上でできます。
それはクールだと思います。必ずしも良いとは思いませんが、めちゃくちゃクールです。以前なら行っていたような多くの技術的決定が変わりつつあります。以前と同じように俊敏性のために技術スタックを構築する必要がなくなったからです。しかし、他の重要な方法でAIのために技術スタックを構築する必要があります。
モノレポのようなものは依然として最悪です。今はかつてないほどです。ほとんどのAIモデルに巨大なモノレポを与えて「これを修正して」と言っても、どこから始めればいいか分からないでしょう。そのコンテキストを自分で追加する必要があります。
しかしレポが十分に小さければ、コードを気軽に書いてかなり良い時間を過ごすことができます。だから私は日に日にモノレポへの傾倒が少なくなっています。そして驚くべきことに、以下の言葉を言うことさえできません。よく分離されたマイクロサービスが必要なのです。
これを今言うことさえ信じられませんが、本当にそうなのです。いくつかのプロジェクトでこれがうまくいきました。その中でも最も大きなものの一つはPick Thingです。Pick Thingを約6回再構築しました。このプロジェクトを再構築するための本当の誠実な努力を3回行いました。なぜなら私のチャンネルにそれが必要だからです。
ご存知ない方のために、Pick Thingは一連の画像を取り込み、背景を削除し、ワンクリックでコピーして貼り付けられる素敵なダッシュボードを提供するツールです。
私はAffinityを写真編集ソフトとして使用しています。PhotoshopなどでもいいでしょうPCのネイティブソフトウェアはとても速いです。なぜエレクトロンを使う必要があるでしょうか？Affinityは私が使うネイティブアプリの中で最速の一つですが、開くのに1分半かかります。
これがAffinityで、今コマンドVを押すと、背景がとてもきれいに除去された私の写真が表示されます。個々の髪の毛まで保存されています。このツールはあなたにとって本当に役立つか、あるいは完全に無用かのどちらかです。そして99％の人々にとっては無用のカテゴリに分類されるでしょう。
では、なぜこれについて話しているのでしょうか？URLについて話しています。このURLを見て、URLを見るのにもっと適したものを見てください。気づくことがあります。image.engineeringからきています。image engineeringとは何でしょうか？未完成のサイドプロジェクトですが、私がここで使った方法はマイクロサービスとしてです。
Pick Thingを構築した他の各回では、画像の背景除去をアプリレイヤーの一部として構築しました。最初の2回このアプリを構築したとき、データベースモデルはやや複雑でした。画像にはソースURL、ステータス、背景除去されたURLがあり、現在背景除去が保留中のすべての画像をバッチで処理し、データベースを更新するキューから来ていました。そしてあなたはUIで待っている状態でした。
5秒ごとに更新を確認していました。そして私はずっと荒い部分をきれいにし、改良し、何度もキューと戦い続けました。異なるサービスのレート制限に当たらずに効率的に背景でこれを生成するためのさまざまなキューイングシステムと戦うのに多くの時間を費やしました。
そして、クリーンなカットポイントがあることに気づきました。画像をアップロードしてから、URLを別のサービス（この場合はimage engineering）に渡すとどうなるでしょうか？この新しい画像URLがあり、これはページに埋め込まれるURLで、ページに埋め込むだけでフェッチがトリガーされます。
これは別のサービスに存在し、URLをチェックして、アップロード時に私のアプリケーションからのものであることを確認します。そうであれば、キャッシュをチェックして、既に背景除去されたキャッシュにあるかどうかを確認します。あれば、キャッシュエンティティを返します。なければ、背景除去をトリガーしようとします。
現在、画像とその背景除去のステータスはこのコードベースに全く存在しません。Pick Thingのコードベース全体をオープンソース化しても、画像を管理するための素敵なUIと、半焼きのStripe実装を得るだけでしょう。実際に画像除去を行うものは得られません。なぜならそれはCloudflare image engineeringに構築した別のサービスだからです。
image engineeringは非常にシンプルな入力と出力です。クエリパラメータとして画像URLを与えると、背景が除去された画像が返ってきます。好きなだけURLでアクセスでき、好きなだけの数のURLを使用でき、それは気にしません。Workersで構築されているため、水平に無限にスケールします。問題解決です。そしてこれによりこのコードベースは信じられないほど単純になりました。
私の直感では、すべてがモノリシックな場合と、メインサービスと2つのマイクロサービス（面白いことに、画像を最適化して解像度を変更し、フルの4Kではなくより小さな形式で埋め込めるようにする別のimage engineeringがありました）がある場合では、コードが大幅に増えると思っていました。
結果的にはコードが大幅に減りました。なぜなら非常にシンプルな入出力で画像の問題を解決でき、そのパスを徹底的にクリーンにできたからです。そしてアプリコードもはるかに単純になりました。そして「ここで正しいカットポイントがあれば、マイクロサービスはそれほど悪くない。でも間違ったポイントを選ぶと最悪だ」という魔法の気づきがありました。
とはいえ、このアプリケーションを最初に構築したとき、DOMに画像を配置するURLが正しいマイクロサービスになると予想していたら、「何を言っているんだ？」と思っていたでしょう。それはまったく予想できませんでした。
しかし、これを二回間違った方法で構築したので、すぐに正しい方法を見つけることができました。これはAIが私の脳を書き換えたというテーマの続きになります。
間違った方法で物事を構築することはかつてないほど速く、それらを取り壊して正しい方法に置き換えることはかつてないほど安価です。これらの部分がもっと簡単に通信できればいいのに。おお、この新しいテクノロジーは任意の接続を簡単に作成できます。すべてを統合しています。あ、接続が多すぎます。バグやセキュリティホールを作っています。ああ、今度はこの新しいテクノロジーが任意のものを安全なサンドボックスに簡単に封じ込めることを可能にします。
明確にするために言うと、私がこれを行った理由は、これらの部分間の通信を最小限にしたかったからです。なぜなら、それらがコミュニケーションすればするほど、アプリはより複雑になり、それは必要ないからです。
間違ったものを構築することが正しいのです。以前は、構築したいものをどのように構築するかを考えるのに多くの時間を費やしていました。3つの異なるコンポーネント間の状態をどう管理するかなど、それほど重要でないことでも考えすぎていました。
今、私の方法は非常にシンプルです。ステップ1、簡単な方法で構築します。ステップ2、簡単なことをしたために壊れるものを修正します。そしてステップ3、自分で作り出した混乱を修正するハードな方法に置き換えます。これが今の私の構築方法です。
特に簡単でシンプルな解決策がある場合（簡単さとシンプルさは異なることに注意してください）、簡単さは明瞭さであり、容易さは速度です。5つの場所に何かをコピー&ペーストするような簡単に行えることでも、必ずしもシンプルではありません。なぜなら今や5箇所で変更が必要だからです。
将来的に問題が出るかもしれない問題に対して、簡単かつシンプルな解決策があれば、私は今そのようにします。そして、その道に来たら、その道の問題を解決します。
チャットからの良い指摘です。スタートアップの構築方法にも反映されています。頭の中で数ヶ月かけて解決策を完璧にしようとするよりも、早期に大まかな形にすることに集中します。また、簡単さとシンプルさについて。シンプルさは理解する労力です。簡単さは行う労力です。とても良い指摘です。
強調したいのは、これはスタートアップのマインドセットだけではないということです。多くの人が私の構築方法をスタートアップ向けのものとして片付けるのを見ています。ただ「いいえ、あなたは間違っています」と言うこともできますが、少し考えてみましょう。
大企業は何で構成されていると思いますか？チームです。これらのチームがすべて同じコードベースで作業していると思いますか？そう思うなら、実際にこれらの企業で働いたことはないでしょう。従業員の半分はランダムな特注のものに取り組んでいます。
そして、それらは多くの場合、異なるソリューションを試す絶好の機会です。Pingでは、もっとリポジトリを始め、もっと多くのコードを書き、より多くの成果を出しましたが、Twitchにいた頃は定期的に特定のセキュリティや安全性のインシデントが発生した際に、ランダムな一回限りのものを構築するために深く関わっていました。
これらのクールなAIツールが私の手元にあれば、どれほど多くの手間が省けたか想像もできません。信じられないほど素晴らしかったでしょう。Twitchで私を非常に効果的にしていたのは、すでにこれを行っていたことです。
問題に対するシンプルな解決策で構築し、その限界に達したらスケールしないソリューションを意味のあるものと交換していました。なぜなら、スケールしない一つのシンプルな解決策と、スケールするが複雑な三つの解決策があれば、既に問題を経験していなければ、正しい複雑な解決策を選ぶことはできないからです。
何がうまくいかないかを伝えることができる場合、どれが理にかなうかを理解するのははるかに簡単になります。ここで奇妙な例えをしましょう。カメラです。私は大のカメラ好きです。気づいたかもしれませんが、ストリームがこんなに良く見えるのは、カメラ関係に多くのお金と時間と労力をかけているからです。
数週間前に新しいカメラを購入したので、React Miamiのために持っていけるものが欲しかったのです。セットアップを取り外すのに疲れていました。
なぜエンジニアリングのセクションでカメラについて話しているのでしょうか？聞いてください。私は定期的に「Theo、どのカメラを買うべき？素晴らしいコンテンツを持ちたい」と尋ねられます。
チャットの人々はすでに気づいています。マイクはカメラよりも重要です。まず第一に、それを常に強調します。ただ、ここで最も重要なポイントは、あなたが一つの重要なことを行うまで標準的なカメラを勧めないということです。
最新の2つのiPhone Proのいずれかを所有するまで、どのカメラを買うべきか教えません。なぜなら、あなたの電話のビデオカメラは、あなたがやりたいことに十分な可能性が高いからです。
ただし、それはあなたが何をしたいかによります。どんな場合でも、ビデオを真剣に撮影したいなら、ポケットに最新のiPhoneがあれば生活が楽になります。このカメラから得られるビデオの品質は驚異的です。そしてそれが十分でない場合、あなたはそれについて私と話すためのフレームワークと言語を持っています。
あなたが「iPhoneは私には十分ではない、オーバーヒートする」と言えば、それについて話しましょう。何をしてオーバーヒートさせていますか？長時間の録画ですか？では、Sonyカメラは買えません。iPhoneよりもさらに速くオーバーヒートします。Lumixラインに目を向けましょう。あるいは「iPhoneは使えない。もっとストレージが必要だ」と言えば、SDカード優先のカメラを指すことはできません。
iPhoneで問題に直面した後、より高価で豪華なソリューションのうちどれがあなたに適しているか、私たちはフレームワークを持って理解できます。そしてこれはいずれにせよあなたにとってメリットがあるでしょう。だから、私はいつもシンプルで十分に良いソリューションを押します。
なぜなら、それがあなたに合えば素晴らしいですし、複雑さに触れる必要もありません。そして、ほとんどの場合、「iPhoneを使いなさい、十分良いビデオです」と言うと、人々はそれに固執します。
そして、Pixelについては始めないでください。Pixelの写真カメラはAppleより10％程度良いかもしれません。Pixelのビデオカメラはミーム級に悪いです。Androidは効果的に撮影できません。iPhoneでビデオを効果的にするためにAppleが行っている狂ったことについて長く話すこともできますが、それは今回の目的ではありません。
私の第三のチャンネルでそのビデオを作るべきかコメントで教えてください。Appleのビデオパイプについて言いたいことはたくさんあります。それらは狂っています。
そのすべてを脇に置いて、iPhoneは非常に優れたビデオカメラなので、おそらくあなたには十分でしょう。そしてそれが十分でない場合は、なぜかを話し合いましょう。
これが私がスタートアップにGraphQLを勧める人を嫌う理由です。なぜならスタートアップにはGraphQLは必要ないからです。シンプルなものが必要です。そしてシンプルなものがうまくいかない場合は、その理由について話しましょう。
あなたが行き着く場所が「ああ、私たちにはiOSとAndroidのアプリがあり、それらは過去にGraphQLを使用した2つの会社で働いていたネイティブ開発者によって構築されているため、彼らはGraphQLに非常に詳しく、データがグラフモデルにうまく合う奇妙にネストされたデータを持っています。そして、APIに取り組んでいるエンジニアの一人は既に大規模なGraphQLサービスを構築した経験があります」という場合、最終的にGraphQLが個人としてのあなたにとって意味をなすかもしれません。
しかし、その点に達するまでは、ほとんど確実に意味をなさないでしょう。そしてその認識には、まず最初にどこかシンプルから始める必要があります。だから、間違っていると感じても、シンプルなことから始めてください。シンプルなものがどこまで行けるか驚くでしょう。
はい、これはデータベースとしてGoogleスプレッドシートを使用できることを意味しますが、実際には使用できません。なぜならそれは簡単に見えるだけで、そうではないからです。シンプルではありますが、簡単ではありません。GoogleスプレッドシートをデータベースとしてセットアップするのはAPI認証と承認を適切に設定するのが惨めなので嫌です。
しかし、AirTableやNotionのようなものでそれを行ってください。それらのAPIははるかに優れています。そしてそれらは良いスケーラブルなデータベースではありませんが、その問題に直面したときにそれに対処することを学ぶでしょう。まだ持っていない問題を急いで解決しようとしないでください。今持っている問題を解決し、後でその問題がある場合に解決してください。
私はビデオカメラと電話の話にあまり深入りしないようにしています。なぜなら毎回話すと永遠に冗談で終わりたくなるからです。このポイントは比較的明確だと思います。楽しい余談があります。自分自身を矛盾させますが、シンプルなことについては今までよりも考えなくなりました。複雑なことについては今までよりも考えるようになりました。
前に述べたように、私は複雑な技術的問題について座って考え、アイデアを出すのが大好きです。いつも「私の最高のコードはコンピュータに座っているときに書かれるのではなく、スケートボードに乗っているときやシャワーを浴びているときに書かれる」と言っています。
それほど重要ではないことについて考えるのに時間を無駄にすることがよくありました。たとえば、異なるコンポーネント間でデータをどのように渡すかの構文です。その時間の多くは、エンジニアとして成長するのに役立ったので無駄だったとは言いたくありませんが、実質的にはそうでした。これらのことにそれほど時間をかける必要はありませんでした。単にシンプルで明白なことをして、それが壊れたときに修正できたはずです。
しかし、この時間を必要とするものもあります。例えばT3チャットの同期エンジンです。T3チャットの同期エンジンについて、申し訳ありません、Markさん。彼は今隣の部屋で笑っています。しかし、そうなんです。実際にそれについて考える時間は、コードを書く時間の10倍以上を費やしました。
以前なら2〜3日考え、書き始め、足りない部分があることに気づき、もっとたくさん考え、そして数日間行ったり来たりして書き、すべての部分を整えようとしたでしょう。今では4日間考えて、それからCursorで2時間で実装し、はるかに速く完了できます。そしてその方法が間違った道だったことが判明します。
以前より速く壁にぶつかります。以前は間違った道の終わりに達するのに1週間かかりました。今はそうではありません。今ははるかに速く壁にぶつかり、それが意味をなすならそれを乗り越えるのもはるかに速いです。これらの壁を見つけて、それらを押し通したり回避したりすることがこれまでよりシンプルになりました。
しかし今、これらの壁がたくさんある難しい問題では、シンプルな解決策を作り、できるだけ多くの壁にぶつかり、そして確かに時間をかけすぎて、私たちの行く手を阻んだすべてのクレイジーなことを回避する方法について考えるのが良いと感じています。
同期についての狂ったパスについて永遠に語ることができます。部分的な更新や、ストリーミングされたチャット応答でトークンごとに更新するという狂った性質があります。認証がありますが、より重要なのは非認証ユーザーです。彼らのデータはどこに行くのでしょうか？それはクラウドで同期すべきでしょうか？おそらくそうではないでしょう。
そうでなければ、ローカルオンリーのソリューションと、認証されたユーザーと認証されていないユーザーが同じアプリの体験を持つようにするクラウドファーストのソリューションを処理できる部分的なパスをどのように持つことができますか？さらに重要なのは、すべてのことに対して2つのパスを持つことによって、開発者の体験を絶対に台無しにしないようにする方法です。1つは同期エンジンによって駆動され、もう1つは完全にローカルです。
これらはたくさんあり、長い間本当に狂ったように感じていました。だから間違ったやり方で行い、それから壁にぶつかったとき、例えば私が初めてT3チャットの同期エンジンを構築したとき、Reddisに単一のgzipされた塊として構築しました。それは最初の数週間は非常にうまく機能しましたが、制限があり始めていました。
そこで2日間かけて、Reddisのモノリスから個々のReddisエントリに移行し、それから1時間かけてそれをSQLに切り替えました。何ですって？まだ信じられないのは、文字通り2日でRedisからバラバラのRedisに私たちの全データモデルを移行し、それから2時間以内にSQLに移行したことです。
とても素晴らしく、選んだソリューションが私をまっすぐに壁にぶつけ、そこから非常に速く回復できたというのは素晴らしいことです。その多くは、これらのツールに対する私の馴染みと、SQLでどのように見えるかを書きながら考えていたという事実によるものです。
しかし、その多くは、私のエディタがSQLに使用するツールをよく知っていたためでもあります。そのため、間違ったものから移行するときに、より簡単に切り替えることができました。シンプルなものから始めて、間違った複雑なソリューションを選びました。だからその後、正しい複雑なソリューションに切り替え、それは私たちにとって信じられないほどうまくスケールしています。
これらは私の考え方に大きな変化をもたらしました。最初に出荷する前に、どのデータモデルを使用するかについて、以前ならもっと時間をかけて考えすぎていたでしょう。しかし今では、私たちはもっと先に進むことができます。
そして公平に言って、今それをしています。どこで物事を切り分けるかについて考えすぎています。しかし、それは今私たちがここにいるからであり、以前と同じように焦ることはないでしょう。公平に言って、Markはパニックになっています。彼のサポートチケットの半分は「同期エンジンが壊れた。同期が壊れている。なぜメッセージが消えるのか？」というものです。
そしてそれはすべて私のせいであり、申し訳ありません。私たちはそれに取り組んでいますが、もう一つの間違った複雑なソリューションを行いたくありません。だから、それを解決するための時間を自分に許しています。その時間の一部は、異なるソリューションを試すことです。
私は異なる道を試すために5つのミニT3チャットを構築し、それらの制限を確認しました。はい、私たちがどこに行くか本当に興奮していますが、もっと遠くに行けると感じています。例えば、スケールを描くとすれば（今考えると縦になるべきですね）。
下が皆さんのお気に入りのゼロユーザーで、上にはもっと多くのゼロがあり、おそらくその前に数字があります。以前はシンプルなソリューションがあなたをある地点まで連れて行き、そしてそのギャップを埋めるために難しい作業をする必要がありました。そしてそのギャップを埋めるために必要な作業量は最悪でした。
そして、シンプルな方法の終わりに達する前に早く取り組み始めることが多かったでしょう。地獄、最初からこれを始めるかもしれません。しかし、すべてのソリューション、最も複雑なものでさえ、ある規模では問題を抱えるでしょう。そしてシンプルな方法がどれだけ進めるかを横に、それを行うのがどれだけ難しいかを縦に表すとします。
明らかに、シンプルなものは複雑なものほど進むことができません。だからこのように構築することは、あまり意味がありませんでした。最初にそれを行うことで開発サイクルの3分の1を失ったのですから、時間とお金をそこに投入すべきでした。
しかし、複雑なバージョンを構築するのが、シンプルなものを構築するのと同じくらい複雑だったらどうでしょうか？シンプルさと複雑さが今やAIがあまり気にしない恣意的な区別だったら？突然、この構築をとても早く始める理由はありません。なぜなら、ゼロユーザーから重要な数まで行くのにかかる時間も、あなたが下した悪い決定を解決するのに十分な時間だからです。
それはとても素晴らしいことです。そして、これが私をそこまで連れて行くと思ったけれど、実際にはここまでしか行かないソリューションを選んだ場合、素晴らしい。もっと遠くに行くであろう別のものに切り替えます。そして間違っていたら、これが何か実体のないものなら、問題ありません。私はそれを再度転がします。
これが新しいものの魔法です。これらの異なるソリューションをテストするための実装時間が大幅に短縮されました。シンプルで十分にスケーラブルなソリューションを作ることができれば、正しいソリューションを見つけるための時間が大量に得られます。
しかし、ここにはより重要な現実があります。それは、ほとんどのアプリがそこに到達することさえないということです。ほとんどのアプリはここで死にます。これを「2ユーザーライン」と呼びましょう。その2人のユーザーは誰でしょうか？あなたとあなたのお母さんです、明らかに。本当のところ、私のものも最初の2人のユーザーはそうです、面白いことに。
2ユーザーラインは、ほとんどのアプリが超えないものです。私のアプリについては現実的に言って、おそらく200に近いでしょう。私には専用のユーザーがいて、たとえ悪くても私が構築するすべてのものを試してくれるからです。
しかし、私とIDとAIツールがすべてよく理解している、シンプルなソリューションを持つことは素晴らしいことです。それによってアイデアを出し、それが良いかどうかを確かめることができます。そしてそれが良ければ、スケーリングの問題に直面し始め、それを修正できます。良くなければ、アプリを捨てて多くの時間を無駄にしたという感覚を持つことはありません。
それは素晴らしいことであり、私が構築しているものについての考え方を根本的に変えました。以前よりもSQLiteのようなものを使用する可能性が高くなりました。なぜなら、アプリの構築に時間をかけることが、それが成功するまで押し進める必要があるということを意味するわけではないからです。それは私が持っている問題を解決する必要があるということを意味します。
そして時々、それらのソリューションを構築するとき、Pick Thingのように私や他の数人の人々を助けることがあります。時には、T3 Chatのように、私の人生の軌道を根本的に変えることもあります。しかし、最初はT3ChatもPick Thingも同じ方法で構築しました。特定の問題と、それを解決するためのシンプルな道がありました。
間違った選択をし、何度も部分を再構築する必要がありました。しかし、それらは私が持っていた問題をとてもよく解決し、そのソリューションを誇りに思っていました。Pick Thingの3回の反復を経て、この新しい構築方法が本当にしっくりくるまでに、T3 chatの頃には私ははるかに良くなっていました。
シンプルで明らかな方法でただやるというこのアイデア。あなたはそれがスケールしないことを知っています。「これはスケールしないと分かっている」という衝動と常に戦わなければなりません。しかし今では、それを乗り越えました。
しかし、妥協しないのはDX（開発者体験）です。既にコメントが見えます。あなたが書いているのが見えます。投稿者は「スケールをそれほど気にしなくなったなら、なぜまだVercelとサーバーレスを使っているの？」と言っています。
それはDXも良いからだよ、クソったれ。PRを出して、CTOがプルリクエストのリンクをクリックするだけで、私が作成したばかりのビルドをすぐに見ることができることは、大きな価値です。それがうまくスケールすることは素晴らしいです。それはビジネスがより良くなっても、Vercelから移行する必要がないことを意味します。
しかし、それはあまり使われていないものがコストがかからないことも意味します。スピンアップした各サイドプロジェクトに無限の数の月額20ドルの請求書があるのではなく、ほとんどが0ドルです。なぜなら、それらはサーバーレスで構築されており、それによってはるかにシンプルで簡単に展開でき、これらのすべての素敵なことができるからです。
それは私のDXの勝利であり、その結果として私がよりシンプルな方法で構築していると感じます。それは素晴らしいことです。
これらのことについて話しているところで、シンプルに構築することと、私が既に行っていて本当に役立つと思うことについて、もう一つ余談を言いたいと思います。FP（関数型プログラミング）純粋主義者として、こんなに良い気分になったことはありません。
AIは順番に上から下まで読むことができるものが得意です。AIは、物事の間の複雑な関係をマッピングするのが苦手です。AIがマッピングする複雑な関係は、トークン（4〜8文字）の間であり、あなたのコードベース内の別の場所15ディレクトリ離れた場所から隠れた深くネストされた関数をコンストラクタから呼び出している異なるファイル間ではありません。AIはそれに非常に弱いです。
それはそれに非常に悪いです。だから、入力が入り、出力が出る単純な関数型パイプとしてあなたの物事をアーキテクチャすることができればできるほど、これらのモデルがあなたが何をしているかを理解するのが簡単になります。特に型の安全性や彼らが何をしているかを説明するコメントがある場合に、そして特に、これはマイクロサービスのことを言ったときのような難しいことの一つです。
それを声に出して言う勇気さえありません。気分が悪いです。おそらくTypeScriptの戻り値の型は、かつてほど無用で悪くはないかもしれません。それらにはまだエッジケースがあります。戻り値の型が好きではない理由についての私のビデオを見て、それらをたくさん使い始める前に確認してください。なぜならそれらは万能ではないからです。
それらは開発者として私たちが実際に行うことに対する素晴らしいソリューションではありませんが、それらはAIが少し混乱するのを防ぐのに役立ちます。確かにそうです。Matt PCOsが私にこれを再考させました。彼は正しいですが、それは私を傷つけます。TypeScriptの戻り値の型が大嫌いです。それらは多くを壊しますが、ここでは確かに役立ちます。
はい、私のスタンスのいくつかは以前よりも痛みを伴いますが、いくつかはより役立っています。フルスタックの型安全性、入力から出力への関数パターンなどです。これらのパターンは素晴らしくスケールしており、本当にシンプルな入力があるときには非常に嬉しいです。
T3チャットのコードベースで私たちの生活をはるかに簡単にしたものの一例です。チャットエンドポイントに行くと、最近非常に複雑になっていたため全体を改装しました。そしてその大部分は、これらのヘルパー関数を分離することでした。
一つは「verify request」です。「verify request」は検証済みのチャットリクエストを返します。はい、ここで戻り値の型を使用しました。なぜなら、それは重要だからですが、また、それはresult型であり、正のケース、負のケース、エラーケース、または成功ケースを返すことができます。
だから、これはもしあなたがこれらのことのいずれかに失敗した場合に、あなたに送信する多くの異なるエラーの一つを返します。そして成功した場合、チャットストリームレスポンスの生成を開始します。しかし、私はこの検証されたリクエスト、つまり私の解析された管理されたものをこれに渡しています。
そして、この検証されたリクエストパラメータは6つのファイルで17回出現します。なぜなら、私は必要とする少しのためにそれらの入力を非常に特定かつ正確に定義するのではなく、この巨大な入力の塊をすべての関数に渡しているからです。
なぜなら、一つのことだけを行う関数が、少しだけ多くのことをする必要があったり、渡すことを考えなかった別の何かにアクセスする必要があることがよくあるからです。そして、それをそこに取得するために15か所に触れる代わりに、私はこの1つのリクエスト本文を渡します。私はそれを検証し、すべてのものがこの入力として持つように多くの変更を加えました。
それには識別子、ユーザー情報、サブステータス、プロユーザーのブール値などがあります。これらすべてのものが今、この1つの入力フィールドに存在し、他のすべての場所に渡すことができます。これはコードベースを理解しやすくし、異なる場所で何にアクセスできるかを知るのを簡単にするだけでなく、AIもこれらの自動補完がはるかに良くなります。
なぜなら、それは常に検証済みチャットリクエストへの多くの参照があるため、どのデータを持っているかを常に知っているからです。これは以前は好きではなかったパターンです。関数ができるだけ最小限で特定的であってほしいと思っていました。ここに必要なものだけがあり、それ以上でもそれ以下でもないと。なぜなら、もし関数が変更されるなら、それは私かチームの別のエンジニアが変更しているからです。
今は、これを渡すだけです。素晴らしいです。Mircalはここに気づいています。純粋な関数と不変性が新しい規範になるだろうと。絶対に同意します。それは素晴らしかったです。関数はトラックを仮定しています。世界は救われました。何もコメントしません。
しかし、理解していただけると思います。検証済みチャットリクエストパラムが何であるかを知るためには、コードベース全体のより多くの知識が必要です。しかし、一度その表面的な知識を持てば、コードベース内の何かを変更する能力が大幅に向上します。
それは私がTRPCについて好きなことに似ています。フロントエンドでコマンドクリックするだけで、バックエンドに直接連れて行ってくれます。これらのパターンとパラダイムは、素晴らしいものから、これらのAIツールを実際のスケールで使用したい場合はほぼ必須のものになりました。
その点で、先ほど言ったモノレポのことを覚えていますか？モノレポはまだ最悪です。今モノレポが大嫌いです。モノレポは悪いですが、バックエンドとフロントエンドは今、同じレポにある必要があります。
私たちは皆、そこにいました。フロントエンドで作業していて、バックエンドの変更が必要で、コードをレビューするために誰かが数日待つ必要があり、適切に作業を始めることさえできないという経験をしました。
私たちは皆、バックエンドにいて、フロントエンドチームが意味のない絶え間ない要求をしてきて、まだ非常に古い特定のiOSクライアントがあるため、廃止したい奇妙な名前のフィールドを保持しなければならないという経験もしたことがあるでしょう。それはすべて最悪です。
AIはそれにさらに弱いです。それは使用ケースを見ていないものを廃止するのが大好きです、特にClaude 3.7は。だから、そのバックエンドを消費しているものがCLaudeが認識していない別の場所にある場合、あなたはそれをすべて壊すことになるでしょう。それはこれらのものがどのように機能するかの性質です。
しかし、それらが同じコードベース内にあり、型安全性のようなものをチェックするツールへのアクセスがある場合、バックエンドで変更を加え、フロントエンドでそのフィールドがもはや存在しないというタイプエラーが発生すると、突然エージェントはそのものを修正するか、間違いを犯したことを知ることができます。あるいは、もしできなければ、あなたはそのタイプエラーを見ることによって間違いを犯したことを知るでしょう。
そのレベルのフルスタック統合は、特に型安全性と組み合わせると、かつてないほど重要になっています。型安全性はこの世界では必須に近いです。Pythonがこれほど多くのAIものに選ばれている言語であることをまだ信じられません。なぜなら、文字通り全く機能しない多くのPythonコードを書くことができ、実際に実行しようとするまでPython環境からまったくエラーが出ないからです。
AIエージェントはあなたのコードを実行して動作するかどうかを確認しているわけではありません。彼らはあなたのコードを書き、それが正しいかどうかを確認するためにエディタのフィードバックをチェックしています。それをうまく処理するツールを使用することがより必須になっています。
考えてみると面白いことですが、LSP（言語サービスプロトコル）は究極のツールです。Microsoftが言語サービスプロトコルをIDEの一部にして言語がより簡単に統合してエディタにフィードバックを提供できるようにするために投入してきたすべての作業は、彼らがエージェントや私たちが使用しているAIツールにフィードバックを提供することも可能にします。
これらのものがこれほど役に立つようになったのは奇妙ですが、そうなっています。そして、LSPと良い型安全性統合への私の感謝は年々強くなっています。
これらのAIツールはTRPCを本当によく知っていますか？いいえ。それらが間違えると、良い型エラーが出て、彼らが修正するか、私が修正できます。それはとても素晴らしいです。
最後の部分は、他のビデオでも何度か言及したことですが、強調することが本当に重要だと思います。コードは今、とても安いです。コードは以前のように高価ではありません。エンジニアは高価です。彼らは多くのお金がかかります。
以前は、エンジニアがコードを書くのに多くの時間を費やし、そのソリューションが大部分間違っていることが判明した場合、正しいソリューションで書き直すには多くの時間がかかるため、そのすべての作業を捨てるのは本当に難しかったでしょう。
今はそれにかかる時間がはるかに少なくなっています。ピースがどのように一緒に来るべきかについて明確なモデルがあれば、その明確なモデル（特に正しい場合）から機能する実装までの速度は信じられないほどです。
だから、シンプルだけど間違ったソリューションを構築している場合、または複雑だけど間違ったソリューションを維持している場合、スレッジハンマーを持ち出す価値はかつてないほどあります。
これは私がキャリア全体を通じて戦ってきた戦いです。私は常に、「ねえ、これは意味をなさない。これをスレッジハンマーで壊してもっとシンプルにできますか？」と言う人でした。Pingを立ち上げる前の最後の仕事では、バックエンドとフロントエンドのウェブソケット接続を管理するためのNodeでのRedux Sagaを使った20,000行以上のコードの恐ろしいマイクロサービスがありました。
それは私が今まで見た中で最も恐ろしいコードベースだと思います。私は正気を失いそうでした。それを置き換えることを懇願していました。しかし、「あなたはフロントエンドエンジニアだ。バックエンドに触れることはできない」と言われました。しかし、私はその実装の複雑さをある時点でとてもよく知っていたので、「くそっ」と言ってすべてを書き直しました。
1〜2週間かかると言いましたが、実際には2日で終わりました。ウェブソケット管理サービスだけでなく、バックエンド全体の完全な実装が500行未満のコードでした。そして2日でそれをすべて構築しました。そして反応は「それを出荷することはできない。テストがない。2日で適当に作った塊でよくテストされたコードを置き換えるとは何様だ？」というものでした。
そこで、私は1時間かけて800行のコードのテストファイルを作成し、100％のコードカバレッジを達成して、辞表とともに提出しました。私がスレッジハンマー男であることがお分かりでしょう。私は喜んで入って、「これは非常に間違っているので、それを考えることも、ましてやそれを構築したエンジニアを考えることさえ自傷行為だ」と言います。
このクソを捨てろ。以前は「いいえ」と言う理由がたくさんありました。主に、「もう私たちはこれを構築するのに多くの時間を費やした。それを置き換えるのにとても長い時間がかかるだろう」という理由です。それはもはや議論ではありません。
物事を置き換えることはかつてないほど安価になりました。それを再構築することがはるかに安価であり、また間違っていて古い方法が正しかった場合、それをはるかに速く理解できるからです。
だから、Theoがあなたのものをスレッジハンマーで壊そうとするとき、2つの道しかありません。彼らが正しければ、彼らはあなたに多くの時間とお金を節約し、あなたをはるかに速くしてくれるでしょう。または彼らが間違っていて、彼らがそれを認識するためにある程度の時間を費やす必要があります。
間違っているときに間違いだと気づくのはこれまでよりもはるかに速いです。そしてそのホールから自分を掘り出すこともかつてないほど安価です。
既存のコードベースへの感情的な愛着は、多くの開発者が苦しんでいることです。そして私のコードが削除され、置き換えられるのは私のお気に入りであるという点では奇妙です。それは重荷が持ち上げられるように感じます。誰かがTwitchで私が構築した古い混沌としたものを廃止し、正しいソリューションに置き換えたという話を聞くたびに、私にとっては素晴らしいことです。
しかし、多くのエンジニアにとってはそうではないことを知っています。彼らはコードが置き換えられると不安を感じます。さて、推測してみてください。あなたのコードはクソだからこの数年間は本当に不安を感じるでしょう。私のコードはクソです。みんなのコードはクソです。そしてAIコードもクソです。ほとんどのコード、コードの大多数はクソです。
良いコードベースでさえ、その中のコードの大多数はクソです。それらは表面レベルの素敵な領域を持っているので、それらがどのようにアーキテクトされているかを評価できるだけです。
しかし、FFmpegのコードベースは私が今まで見た中で最も恐ろしい怪物の一つです。OBS（これらすべてを作成し、強化するために使用するツール）のスパゲッティの量。オープンソースメディアエコシステム全体で最も重要なライフラインの一つは災害です。変なC++エンジンのPhDを持っていない限り、私はそのコードベースに触れることを誰にも勧めません。
今、私たちはその事実を受け入れなければなりません。そしてあなたが持っているのはそれを認めず、自分が良いエンジニアだと自分自身を説得することではなく、たとえ他の誰かがそれを行っていても、それが理に適うとき、それを置き換えることに興奮することです。
もしあなたがエンジニアとしての能力を本番環境にある行数で判断しているなら、あなたは本当に不安な人であり、悪いエンジニアです。今すぐこれを卒業しなければなりません。その時代は終わりました。乗り越えてください。
コードはあなたが現在稼いでいる給料を得るには安すぎます（もしあなたがそれについてそれほど不安なら）。そして今、あなたは同僚があなたが消えたときに何が起こるかを恐れている事実に甘んじています。彼らがあなたのコードをすべて置き換えれば、あなたは今や価値がありません。
だから、どの行のコードが本番環境にあるかに関係なく、価値をもたらす方法を見つけてください。キーボードの後ろにいるかどうかに関係なく、速く移動する方法を見つけてください。
私のCTOが誇りに思っていることの一つは、複雑な問題のセットを取り、それを彼が自信がない、または解決策を持っていない、または私の経験がより関連するであろう1つか2つの部分に蒸留する能力です。
そして彼が行ってきた3日間の思考作業をすべて私に持ってくるのではなく、彼が確信が持てないその真ん中の10分を持ってきます。そして私はその部分を手伝うことができ、時にはものを間違った方法で実装したり、奇妙な道を進んだりする1日か1週間さえも節約することができます。
そして時々私は「もしかして問題はもっと上にあるのかな？もう少しコンテキストを教えてもらえますか？より良いカットポイントを見つけられるかもしれません」と言います。そして私がエンジニアリングチームにもたらす最大の価値は、彼らが考慮していなかったシンプルな道を示す能力です。それによって、多くの…私はそれが大好きです。
そして私の価値の多くはそこから来ています。そして、これらのことをより多くできれば、頭の中でコードベースをモデル化し、コードの行を読むだけでなく、それについて話すことができれば、この時代にはより成功するでしょう。
AIツールはあなたよりもコードを書くのが上手くなるでしょう。しかし、彼らはあなたがコードベースをモデル化するのと同じくらい優れることはないでしょう。あなたがそれに優れている限りは。AIがあなたのコードをあなたより理解していると感じるなら、あなたは絶対的にクソであり、今すぐそれを修正する必要があります。
これらのツールをまだあまり使っていない場合は、このようなアプローチを試してください。あなたはものがどのように一緒に機能するかについてより多くの時間を考え、その内部のfor loopについて考える時間を減らすことができます。
そして私がそれについて好きだったことは、関数の本体に費やす時間が少なく、これらの関数がお互いを呼び出している方法やバックエンドとフロントエンドの間の関係などのものをオーケストレーションすることにより多くの時間を費やすことです。それは本当にシステム設計へのシフトです。
伝統的なReact開発のような多くのタスクがあり、それは90％がJavaScriptとHTML、10％がアプリケーションアーキテクチャです。今やその90％がエディタによって自動補完されるので、私はもう一方に多くの時間を費やしています。
小規模なチームは、10％だったものが今やAIによって自動化され自動補完されるため、あなたの時間の90％に拡大できるため、はるかに複雑なものを出荷できます。そしてそれは私が構築する方法を根本的に変え、より重要なのは、構築しようとしているものについて考える時間の使い方を変えました。
他にもいくつかの小さな部分があります。例えば、以前よりも問題に対して素早い一回限りのソリューションを構築する可能性が高くなりました。以前は問題を解決するための適切なパッケージを見つけることに多くの時間を費やしていました。今は自分で構築します。
あるいは、良いスニペットやパッケージを見つけた場合、従来の方法で依存関係を使うだけでなく、コードを引き抜いて自分のコードベースに埋め込む可能性が高くなりました。
画像のリサイズや正方形化、背景色の変更などの特定の問題を解決するための一回限りのウェブアプリを立ち上げる可能性も高くなりました。より良い、より速いツールが欲しいからといって、一日で自分の検索エンジンを立ち上げる可能性も高くなりました。
毎日使うものを置き換え、自分が毎日使うものを自分で構築する可能性が高くなりました。なぜなら、問題に対するシンプルなソリューションを構築することがかつてないほど簡単になり、問題を特定し、他の人の問題のすべての荷物を持ち込まずにソリューションへのシンプルな道を見つけることができれば、本当に素晴らしいものを作ることができるからです。そして今はそれを行うことがかつてないほど簡単です。
そして、誰にも特によく合わない多くの万能ソリューションがあります。これらの多くは私が好きなものです、例えばReact Queryのように。React Queryの機能の80％は、私がほとんどのコードベースでまったく使わないものですが、それらは十分な人々にとって有用であるため存在します。そしてReact Queryはすべての人に役立つことを望んでいます。
私は自分のReact Queryを十分に構築してみて、それが愚かなアイデアであることを伝えることができます。それはT3チャットで私が持っている非常に特定のニーズのための独自のReact Queryタイプのものを構築しようとしているとき、以前ほど愚かではありません。1年前なら、それは言えることの中で最も愚かなことでしょう。
なぜなら、もし私がReact Queryの20％の複雑さと能力を持つ独自のライブラリをここに構築し、それをすべて自分で維持しなければならないとすれば、それは高価だからです。React Queryは維持するのが複雑なものですが、他のことをはるかにシンプルにし、楽観的な更新レイヤーが私たちにとってより良く機能するでしょう。
そして、十分に特定のソリューションを構築している場合、万能ツールはツールとしてよりも参照としての方が良いという考えは、まだ消化しようとしている考えですが、今や非常に多くの恩恵を受けています。
コードベースのツールを所有することは、特に優れたエンジニアにとって、かつてないほど現実的になっています。そして、これが私が強調したい最後のことです。最後の再配線、Primeが決して言わないこと。優れたエンジニアは今とても恵まれています。悪いエンジニアはとても恵まれていません。
これは私が受け入れるのに少し時間がかかった重要なことですが、それは現実です。以前は私にはエンジニアのチームがありました。私が運営したチームが悪かったとは決して言いませんが、彼らはしばしばスキルが低かったです。
問題を考え、それを特定し、最も面倒だが理解できる部分がどれかを理解し、チームの4人のエンジニアがそれらの部分を行うためのロードマップを構築することに多くの時間を費やしていました。
おそらく、より複雑な部分は、私に最も近いところに住んでいるエンジニアに行くでしょう。なぜなら彼らは私ともっと話し、より良い関係を持ち、質問することをあまり心配しないからです。おそらく、より面倒だがよりわかりやすい部分はチームに新しく加わった人に行くでしょう。なぜなら彼らはその馴染みを構築する必要があるからです。
どのタスクがどの人に行くかについて考えることに多くの時間を費やしていました。それは十分に特定されているか？彼らはどんな障害に当たるか？誰が彼らを助けられるか？これらすべてのこと。今は代わりに自分で作業を行うことができます。
人を雇うことに、これまでにないほど意欲を感じていません。それは狂っています。私は常に速すぎるほど小さなチームを運営することが大好きでした。2人で入り、10人で1年かかる仕事を2人で3ヶ月で完了することは私の大好きなことです。私はキャリアを通じてこれを何度も行いました。それは以前はユニークなスキルでした。
私は優れたエンジニアであり、速く動くことができました。今、優れたエンジニアであることは、より速く動くことをずっと簡単にします。あなたは単にこれらのツールとテクノロジーを使う意思があるだけです。
以前は、速く動くエンジニアであることは、あなたの邪魔をしているものをブロック解除するために、これらの最先端のもの、これらの新しいテクノロジーを活用することを意味していました。
以前は、速く動くエンジニアであることは、TRPCのようなものに深く詳しくなければならないことを意味していました。今はそうではありません。
この枠組みが大好きです。「小さなチームが多くのものを出荷するのは天国のようだ。低いELOでスマーフィングのように」。絶対に同意します。私はキャリアにおいて非常に幸運で、大部分は素晴らしい人々と働いてきましたが、ランダムに悪いチームや悪いエンジニアに対処するよう任されたことがあり、それは常に傷つきました。
そして私は常に、彼らの全体を書き直し、彼らの仕事を無意味にするという私がやりたかったことをしないように自分自身を説得しなければなりませんでした。私は今すぐそれを行うことはできないでしょう。私がTwitchにいれば、解雇をストレートに加速させたでしょう。
私は嫌いだったチームが維持していたものを、彼らよりも優れ、彼らよりも速く構築し、彼らを消滅させるでしょう。なぜなら悪いエンジニアはもはや努力に値しないからです。
彼らは以前は努力に値していました。なぜならコードを維持する誰かが必要であり、彼らが良いエンジニアになる可能性があったからです。これらの両方がもはや関連していません。悪いエンジニアによって維持できるものは、Devonによって十分に維持できます。
そして良いエンジニアになる可能性があった人々は、今やそうなるためにあなたの会社で働く必要はありません。なぜなら彼らは多くのサイドプロジェクトを構築し、AIを使って多くの質問をし、はるかに速くレベルアップすることができるからです。
私は2日でCloudflareに慣れることができました。以前なら1ヶ月かかったでしょう。そしてAIは常に間違っていましたか？絶対に。しかし、それは公式のCloudflareドキュメントよりもわずかに幻覚が少なかったので、良かったです。
しかし、私のレベルアップする能力はAIに大きく影響されています。それが問題の一部です。私たちが使用するAIツールは、悪いエンジニアが理解を構築することを決して許さないからです。彼らは単に何度も再試行して、機能するコードが出てくるまで続けるでしょう。
それは優れたエンジニアがかつてないほど速く改善することを可能にします。なぜなら彼らは質問をし、その結果としてはるかに速く学ぶことができるからです。
そのギャップは広がっています。悪いエンジニアと優れたエンジニアの間のギャップは、この時点で深淵になりつつあり、それを越えることはかつてないほど不可能に感じます。しかし、誰かがどちら側にいるかを識別することもかつてないほど簡単です。
私のキャリアで、16歳の子供が信じられないほど才能があり、彼らが信じられないほど才能があることを知るのがこれほど簡単だったことはありません。特に、その17歳よりも遅く出荷している私の年齢（30歳以上）の人々と比較すると。
これは前にも起こりましたが、それらは十分に似ているように見えたので、区別するのが難しかったです。今はそれは圧倒的です。今、私のコミュニティには私にインポスター症候群を与える子供たちがいます。これは狂っていることです。なぜならその一部はAIが彼らのために難しい問題を解決したからですが、ほとんどは彼らが知識の欠如を乗り越えてそのプロセスで構築できることを知っていたからです。
そして私は今夏インターンシップのために連れてくる予定の人がいて、彼をフルタイムで雇う準備をしていました。彼にそれを伝えた後、彼の履歴書を受け取り、彼が17歳だと知りました。なんてこった。以前はそうではありませんでした。コミュニティには常にクールな子供たちがいました。
彼のような子供たちは、以前よりもはるかに速く、はるかに遠くに行くことができます。それは私たちが今、無制限に食料へのアクセスを持っているようなものです。今や多くの店、多くの場所に食べ物があります。現在、食べ物を買える場所から10マイル以上離れることは基本的に不可能です。
より健康的に食べたい人々にとって、それは素晴らしいことです。牛や家畜を育てることに時間をかけるのではなく、店に行き、食べ物を買い、それから戻って自分がやりたいことをやりたいなら、それはかつてないほど簡単です。
しかし、それはまた太っていて怠け者になることもかつてないほど簡単であることを意味します。何百年も前は、食べ物が不足していたので太ることは基本的に不可能でした。太るためにはすべての食べ物を得るために努力する必要がありました。
今、食べ物は非常に豊富なので、フィットネスを維持する動機がない人々はそうならず、動機がある人々はそうなるでしょう。素晴らしい形になることはかつてないほど簡単ですが、悪い形になることもかつてないほど簡単です。
それは私たちが持ち、住んでいる今日の経済で起こったすべての狂ったことです。それはここで起こっていることです。AIツールは、動機付けられたエンジニアがかつてないほど優れるようになることを容易にします。それらはまた、動機付けられていない人がかつてないほど本当に悪いままでいることも容易にします。
これで私がここで話したかったことはすべて終わりだと思います。これは予想よりもはるかに長く、より混沌としたものになりました。
これがあなた方の何人かに役立つことを願っています。なぜなら私はこれらのことについて多く考えてきましたし、AIツールはそれに多くの助けとなりました。それらは私が構築する方法、考える方法、投資する方法、私の会社を管理する方法、アドバイスする方法、私が行うすべてのことを行う方法を根本的に変えました。
そしてこれらのものがあなたもそれらをより効果的に使用するのに役立つことを願っています。この話についてあなた方が考えることと、もしもっとこのようなものが欲しいかを教えてください。役に立ったことを願っています。そして次回まで、プロンプトを続けてください。
コメント