AI時代の到来により、ソフトウェア開発における従来の常識や最適解が大きく変化しつつある。フルスタック型安全性やTailwindといった手法は更に重要性を増す一方、サーバーコンポーネントやElectronへの評価、テスト手法に対する考え方は微妙に揺らいでいる。型安全性はAIエージェントがリアルタイムでエラーを検知し修正する上で不可欠であり、むしろその価値は高まっている。一方でコードカバレッジやユニットテストは、AIが自動生成することで従来の問題点が軽減され、評価が若干上方修正されている。Electronへの批判は依然として過剰であり、Chrome/Chromiumの強力なレンダリングエンジンの恩恵は無視できない。また、コードベースの学習方法についても、プルリクエストの履歴を追うという従来の手法に加え、AIエージェントを使った対話的な探索が新たな有力手段として浮上している。開発者が長年抱いてきた強固な信念も、AIという新たな協働者の登場により柔軟に見直される必要がある時代である。
私は間違っていた──AI時代に変わる開発者の信念
私にはたくさんの過激な意見があります。それが私の特徴みたいなものですね。私は決して大多数の人がやっている方法に従うタイプではありませんでした。自分なりのやり方が好きなんです。時には一般的なやり方と重なることもあります。でも重ならないこともあります。
私はReactのような人気のあるソリューションを擁護することもあれば、TRPCのようなマイナーなものを布教することもあります。そのため、私には大量の意見があって、それらは市場が変化したり、私たちの開発方法が変わったり、すべてが変化するにつれて変わっていかなければならないことがよくあります。そして今、私たちはまさにそういう時期にいます。AIがソフトウェアの開発方法を根本的に変えているのです。
AIは私と私のすべての仕事を変えました。そして私の周りの多くの人々や彼らの開発方法も変え始めています。おそらくあなたにも影響が出始めているでしょう。しかしこの変化が起きるにつれて、私の意見の多くもそれに合わせて変わる必要があります。そして私が過去に強く主張してきた意見の多くが、実はかなり良く持ちこたえていることに気づいています。
でも、そうでないものもあります。私の意見がより強固になった部分もあれば、市場全体が変化する中で完全にシフトした部分もあって、それを見るのは興味深いです。Reactへの愛から、フルスタック型安全性への布教活動、アプリの過剰なネスト化への深い深い憎しみまで、すべてが何らかの形で変わり始めています。
その変化の度合い、その内容、そしてAIを使った開発がどう機能するかによって弱まり始めている、長い間強く保持してきたすべての意見について話したいと思います。でも、うまく機能するものが何か分かりますか?今日のスポンサーです。今日の広告はちょっと違います。というのも、私はこの製品を何年も使ってきたのに、最近になってあなたたちがどういうわけかこれについて聞いたことがないと知ったからです。
真面目な話、なぜあなたたちはRailwayを使っていないんですか?今のところサーバーをデプロイする最高の方法です。GitHubのリポジトリをオンラインにしようとしているだけなら、もう探す必要はありません。Railwayがダントツで最高のソリューションだと約束します。信じられない?証明しましょう。これがYumamiです。Google Analyticsに代わるオープンソースでプライバシー重視の選択肢です。
もちろん、これはRedisとPostgresが動作していないとデプロイできません。待って、Railwayはそれら全部をホストしています。つまり、ワンクリックでデプロイできるテンプレートがあるんです。今すぐこれらすべてのパーツを処理する新しいプロジェクトが作成されます。デプロイをクリックすると、すべてがセットアップされて連携されます。
リンクしたいGitHubリポジトリがあればそれもできますが、私にはないので大丈夫です。ここでキャンバスが見られます。すべてがデプロイされていて、プッシュ時の自動再デプロイ、クイックロールバック、超高速ビルドなど、現代のプラットフォームに期待されるすべての良い機能があります。なぜなら彼らは裏でNixを使ってクレイジーなことをやっているからです。
ちなみに、Railwayの創設者は私がNixについて初めて聞いたのがこの人からでした。2021年にさかのぼります。実は私はほとんどそこで働くところでした。実際、私がRailwayで働かなかった唯一の理由は、創設者が私のことをどれだけ欲しがっていても、おそらく自分のことをやるべきだと言ってくれたからです。彼は本当に正直な人で、本当に正直な会社です。
そういえば、もうデプロイが完了しています。今、私は20秒以内にデプロイした完全に動作するYumamiインスタンスを持っています。しかもすべてが設定済みです。Postgres、Val key、必要なものすべてがここにあって、こんなに簡単に動いています。ここにもっと追加したければ、別のGitHubリポジトリでも別のデータベースでも、ボタンをクリックするだけでできます。
あるいは、コードベースで同じくらい簡単に設定することもできます。フロントエンドからバックエンド、データベースまで、デプロイするのにこれより簡単な方法はありません。そしてこれより安い方法もありません。なぜなら使った分だけしか請求されないからです。アクティブでないCPUはお金がかかりません。これはAIワークロードが山ほどあるこの時代には巨大なメリットです。
彼らがこれをできる唯一の理由は、今自分たちのサーバーを運用しているからです。彼らは自分たちのサーバー倉庫を作るために膨大な時間を費やしました。Jakeがそれをやっているのを見るのはクレイジーでしたし、本当に誇りに思います。彼らは大成功しているからです。これらの料金は信じられないほど安いです。私のリンクを使えば20ドルのクレジットがもらえますが、それを使い切ることができたら驚きです。
今すぐsort.link/railwayでチェックしてみてください。では、当時最も過激だった私の意見と、それがどう変化したかを見ていきましょう。個人的なお気に入りから始めます。フルスタック型安全性です。このアイデアに馴染みがない人のために説明すると、この概念の核心はバックエンドとフロントエンドが密接に型安全な関係を持つべきだということです。バックエンドでフロントエンドで動作しない変更を加えたら、開発に使うツールを通じてすぐにそれが分かるようにするのです。
フルスタック型安全性──より重要になった信念
つまり、もし私のフロントエンドがユーザーにファーストネームとラストネームを持つことを期待していて、バックエンドで単にnameに変更したら、フロントエンドのコンポーネントに赤い波線が表示されて、バックエンドが違うものを返していることを教えてくれるのです。過去にはこれを実装するためのクレイジーな方法がたくさんありました。
Open API仕様に対するコード生成だったり、GraphQLとそこから型を推論しようとするクレイジーなジェネレーターだったりです。私はこれをやってくれるツールを通じてやるのが好きです。サーバーコンポーネントとその利点だったり、tanstack startのサーバー関数を定義することで直接やったり、当時の私の個人的なお気に入りはTRPCで、バックエンドの型定義をフロントエンドで再利用するものでした。
これを実現する方法はたくさんあります。今ではconvexも含まれます。フルスタックのデータベースバックエンド型の処理をするための私のお気に入りの製品の一つです。フルスタック型安全性を実装しやすくするものはたくさんあって、それは素晴らしいことだと思います。AIにとってもです。これは今では以前よりもさらに良い意見だと言えます。今の私の気持ちは10点満点中10点です。ぜひやってください。
フルスタック型安全性がなくてAIで何かを作っているなら、問題が解決されていないときにAIがフィードバックを得られないため、積極的にAIを悪化させています。エージェントがバックエンドとフロントエンドが一致していないことを確認するコマンドを実行できなければ、それらが一致していないことを把握するのに実際の努力が必要になります。
既に受けた質問の一つは、バックエンドでTypeScriptを使っていない場合のフルスタック型安全性の良いライブラリはあるかということです。答えはイエスですが、ただしその「ただし」が重要です。両側で同じ言語を使っている場合ほど良くはなりません。なぜなら、その場合LSP自体、つまり言語サーバーがフロントエンドとバックエンドを一つのエンティティとして一緒に理解して、ずっと信頼性が高くなるからです。
異なる言語を使う場合の代替手段は、常に何らかの形のコード生成になります。つまり、一つの言語のバックエンドコードが標準化された仕様、通常はOpen APIを出力しなければならず、その仕様を見てその結果として型定義を生成するビルドステップが必要になります。
Open API TypeScriptコード生成でGoogle検索すれば、これを簡単にする様々なプロジェクトがたくさん見つかります。Open API TSが最も人気があるようです。React Queryと直接使うためのパッケージもあると思います。だから、これらのタイプのものすべてを使えば、かなり近いところまで行けます。とはいえ、私の別の意見は、おそらくTypeScriptはあなたがやっていることのバックエンドとして十分に良いということです。
バックエンドで実際に異なる言語が必要になることは非常に稀です。だから、できるならバックエンドでTypeScriptを使ってください。特にインターフェースを取らなければならないクライアントコードがある場合は。Rustが好きなら、Goが好きなら、何でも好きなものを楽しんでください。ただ、実際の体験にそれを接続しなければならなくなったら、人生が難しくなることを覚えておいてください。
一般的に言って、AIを使う場合は、使っている言語よりも構築している機能をもっと気にするべきです。Rustは、すべての計算サイクルを節約したい場合に理にかなう非常に便利な依存関係です。でも、おそらく最近心配しているビルドは計算ではないでしょう。
一般的に人々はRustに頼るのが早すぎます。そして、その意見は今まで以上に強くなっています。だから、フルスタック型安全性は確立されました。バックエンドとフロントエンドが互いに一致していることをエージェントに伝えるコマンドが必要です。使っている技術のせいでそれができないなら、その技術はダメで、悪い気持ちになるべきです。
これは私がずっと持っていた意見で、今まで以上に強くなった意見です。次はTailwindがCSS-in-JSより優れているという話です。これが面白いのは、当時は過激な意見だったのに、それ以降過激な意見ではなくなったからです。Tailwindはこれらのツールのほとんどすべてが使うデフォルトです。
競合するソリューションを持つ会社でさえ、開発者向けの製品を作るときにはTailwindを使います。それだけ便利だからです。スタイルとロジックとユーザー体験の関係がすべて同じファイル、さらには同じコンポーネントにあるのです。なぜならTailwindは、どこか他のランダムなCSSファイルに存在するクラスを定義して、それらを適切に追跡して、正しいピースがあって、誤って再利用されていないことを願うのではなく、単にスタイルと見た目をコンポーネントの文字列定義の一部として書くだけだからです。
非常に、非常に大変です。Tailwindはスタイル、ロジック、UIを一箇所に配置することで、人生をはるかに楽にしました。まだ試したことがないなら、本当に試すべきです。移行したすべての人が決して離れない理由があります。慣れるまで少し時間がかかりますが、一度慣れれば、CSSモジュールを少しも懐かしく思わなくなります。
サーバーコンポーネント──期待ほどではなかった
次はサーバーコンポーネントです。ああ、正直に言うと、私はかなり長い間サーバーコンポーネントで何も作っていません。彼らが本当にうまくやっていることはたくさんあって、私は本当に大好きです。サーバーコンポーネントを使えば、データベースから読み取るようなバックエンドのことをするバックエンドコードを書いて、それでもJSXを返すことができるという事実は、今でも魔法のような感覚があって、それをしないツールを使うときに恋しくなります。
最近、私は主にフロントエンドにReactとViteを使ったシングルページアプリを作っています。より複雑なルーティングがあるときは、時々tanstack routerやtanstack startを導入します。バックエンドにはTypeScriptでconvexをデータベースと他のすべてに使って、その2つの間を行き来しています。サーバーコンポーネントは多くの問題の解決策になれたはずですし、多くの点で今もそうあるべきです。私は今でも深く愛しています。
しかし、バックエンドとフロントエンドを混ぜ合わせる性質は理解するのが混乱します。多くの人々、ツール、エージェント、プラットフォーム、そしてサーバーコンポーネントを深く理解し、採用し、実装し、サポートし、布教する必要があるすべてのもの、既にReactをよくサポートしているためです。これらの多くはサーバーコンポーネントを本当に深く理解し、採用し、実装し、サポートし、布教するのに苦労しています。
これの多くは、最大のReact開発者たちが一般的にサーバーにあまり興味がなかったことに起因していると思います。サーバーコンポーネントの力を本当に理解するには、Reactとサーバーとブラウザーをすべて深く理解する必要があります。そしてそれには、落とし穴や妥協があって、それらへの深い理解を構築していなければすぐには明らかになりません。
サーバーコンポーネントを使うために知る必要がある量が、使うには高すぎるんです、分かりますか?Reactなら、弱いReactの知識でも絶対にやっていけます。サーバーコンポーネントの弱い知識は、かなりひどく銃で撃たれることを意味します。そのため、この意見については10点中3点か4点といったところです。
もうあまり推奨しません。もうあまり使いません。もうあまり話しません。理由はたくさんありますが、まあ、分かりますよね。サーバーコンポーネントは私が未来であると高い確信を持っているものではありません。彼らがうまくやっていること、正しくやっていることはたくさんありますが、今のところほとんどの人にとって重要だとは思いません。
企業のYouTubeチャンネル──今も不要
今のところほとんどの人にとって重要でないと言えば、企業のYouTubeチャンネルは削除すべきです。開発者が一般的にものをどう認識するか、マーケティング全般についてもっと多く話していましたが、あなたたちのほとんどが気にしていないことに気づきました。実際、画面を2回タップしてこの部分をスキップしようとしているのが見えます。分かります。
理解しています。簡潔にします。約束します。ほとんどの人は企業のYouTubeチャンネルを見ません。視聴履歴をスクロールすれば、見ているもののほとんどが、企業が既に作っているものについて作成するのではなく、人々がものについて話しているものだと分かるでしょう。企業が成功するには、やっていることに本当に集中する必要があります。
YouTubeはそうすべきことの一つではありません。なぜなら、そうするとYouTubeに夢中になりすぎている私と競争することになり、苦労するからです。AIはこれを全く変えていません。AIが変えたのは、これらの企業が持っているお金の量と、彼らがどれだけ激しく競争しているかです。多くの企業はマーケティングが今まで以上に重要だと気づいています。
だから、今まで以上に多くのお金をマーケティングに浪費しています。私のスポンサーを除いてです。彼らは本当に良いリターンを得ています。ちなみに興味があればYouTube at3.ggです。とにかく、企業のYouTubeチャンネルは新しいユーザーを獲得しません。企業のYouTubeチャンネルは既存ユーザーとのより深い関係を確立するのに役立つかもしれませんが、それはYouTube動画をドキュメントに埋め込むことで同じくらいうまく確立されるでしょう。
YouTubeチャンネルを正しくやっている企業はいくつかありますが、そのほとんどは大幅に使いすぎていて、文字通り10分の1のお金を使って私に彼らのことについて話してもらえば、その結果としてはるかに多くを得られると私は主張します。だから、もしあなたがYouTubeに夢中でなければ、それが生命線でなければ、無料でやるつもりがなければ、全くやるべきではありません。
YouTubeは企業が遊び回る場所ではありません。なぜなら誰も企業のYouTubeチャンネルを見ないからです。しかし悲しいことに、今まで以上に多くの人々が試みています。つまり、私の意見は今まで以上に強いということです。エンジニアをYouTubeから離して、仕事に戻してください。私にYouTubeをさせてください。他のクリエイターにYouTubeをさせてください。それはあなたの仕事ではありません。
コミュニケーションが上手になることは今まで以上に重要だと思います。あなたの会社はその価値を説明し、今まで以上にうまくピッチする方法を知るべきです。でもそれを誰も見ないYouTube動画を通じてやるべきではありません。ああ、みんなが嫌がるもう一つの話です。ブラウザーとElectronへの私の擁護です。私はChromiumとElectronの支持者として少し知られています。
Electron擁護──今も変わらぬ信念
彼らが受けるべき以上のひどい扱いを受けていると思っています。今私のコンピューターで開いているアプリを見てみましょう。ZenはFirefoxベースなので非Electronです。NotionはElectronベースです。HeliumはChromiumベースです。Ghostyはziggで書かれたネイティブアプリで、Chromiumを全く使っていません。CursorはChromiumベースです。Macに組み込まれたプレビューです。Macに組み込まれたFinderです。
Leg cordはChromium Electronベースです。私が使うものの半分以上はElectronベースです。そしてそのものをどれだけ好きかは、それがElectronを使っているかどうかとほとんど関係がありません。Electronを使っていて大好きなものもあります。Electronを使っていて嫌いなものもあります。厳しい現実は、ほとんどのものがElectronを使っていて、その多くが様々な理由でそうしているということです。
クロスプラットフォームのサポートは巨大です。すべてのプラットフォームで信頼できる優れたテキストレンダリングを持つことは素晴らしいです。ウェブアプリとデスクトップアプリの間で多くのコードを共有できる能力は素晴らしいです。コード共有の力は非常に貴重です。なぜなら、3つのプラットフォーム全体で類似したコードを書いて、それをすべてメンテナンスすることは、浪費すべきではない非常に多くの作業と時間とお金だからです。
それともそうでしょうか?AIはここで多くを変えました。異なるプラットフォーム全体でネイティブコードを構築するのは今まで以上に安価です。Toriのように、メモリをはるかに効率的に使うことを約束するツールがあります。初めてネイティブアプリを構築している人々がたくさんいて、彼らはそれをやってくれるこれらのツールがあるため、それを単にできるのです。
既存の小さなElectronアプリを取って、Claude Codeに投げて、これをSwiftで書き直してと言えば、そうしてくれます。だから、明らかにブラウザーとElectronから離れて、最悪でもToriのようなツール、最良ではネイティブアプリケーションに移る時が来ました、よね?そうですよね?もし私がこの意見について今まで以上に強く感じていると言ったら?まず、Toriについて話す必要があります。やめてください。
申し訳ありませんが、Toriで構築された便利なアプリをまだ見つけていません。特にクロスプラットフォームをやろうとすると、あらゆる種類の混沌とした問題があります。なぜなら、各OSに組み込まれたブラウザーエンジンを使うからです。ToriアプリはRustで自分で書かなければならないため、Toriアプリのネイティブ部分へのバインディングはさらに悪いです。
Toriアプリで何かをしたい場合、例えばファイルを読みたい場合、そのコードをRust自分で書いています。何か便利なことをしたい場合、自分で構築することになり、おそらくネイティブプラットフォーム間の違いに対処しなければならないでしょう。Toriは、私の意見では、Electronのようなツールの利点の多くを殺します。
私が知っているToriで何かを構築しているすべてのまともな開発者は、これまでのところToriにあまり満足していません。例えば、Open Codeについて、チャットが正しく取り上げていますが、Open Codeアプリで作業している開発者たちは、これまでのところToriにあまり満足していません。でもそれはToriだけの話です。ネイティブアプリはどうでしょう?それらを構築するのは今まで以上に簡単ですよね?ええ。
そして、維持したくないアプリの3つの異なるバージョン全体で、奇妙で曖昧なバグを持つことも今まで以上に簡単です。誰かがLinuxであなたのアプリに問題を抱えていて、あなたがそれを解明したいのに、技術があまりにも異なるためMacで問題を再現できず、AIがあなたのためにそれを解明してくれることを願うだけなら、頑張ってください。
はるかに多くのトークンを燃やすことになり、構築しているもののコンテキストのサイズを大幅に増やすことになり、それによって出力の品質が意味のある量で低下します。変な問題があってネイティブアプリを楽しみで構築するためにAIを使うべきですか?絶対に。
でも、人々が実際に使う良いソフトウェアを構築しようとしているなら、私たちが毎日Electronベースのソフトウェアを使っている理由はたくさんあります。ネイティブ部分とウェブアプリ部分、そしてそれらの間のバインディングをすべて処理する信じられないエコシステムがあります。それらはしばしば混乱して煩わしいですが、それらの部分は主にAIで解決されています。
Chromiumのレンダリングエンジンがまだ芸術作品であるという事実もあります。Chromiumでできることとそのエンジンの力は信じられないほど素晴らしいです。誰かがElectronアプリを取ってSwift UIで書き直した後、パフォーマンスが悪くなるのを見た例はたくさんあります。なぜなら、Swiftでの高スループットのテキストレンダリングは、GoogleがChromiumのあらゆるエッジを最適化するために世界最高のエンジニア数千人にわたって数十万時間を注ぎ込んだため、Electronよりも悪いからです。
人々が忘れがちなことは、Electronで使うためにJavaScriptを書きますが、Electron自体はJavaScriptではないということです。それは世界で最も複雑で徹底的にテストされ構築されたC++コードベースの一つです。Electronには問題があります。誰もがメモリを引用するのが大好きで、確かに最近メモリは少し高価です。
でも同時に、私が開いているプログラムがどれだけRAMを使っているか見てみましょう。ああ、見てください。最もメモリを使っているのは、Firefoxベースのブラウザー、Zenです。へえ。Cursorは上位にいますが、600メガくらいです。Macに組み込まれたWindowsサーバーより下です。ああ、そしてまたZenが、1.6ギガをやっているGPUヘルパーとは別に、別の500メガです。
そしてZenのための分離されたウェブコンテンツのすべて。ブラウザーへようこそ。でもGhostyのようなツールからの意味のある使用量にも気づくでしょう。そしてもっと重要なタブ、エネルギー使用タブに行くと、最もエネルギーを使っているアプリは予想外のものだと分かります。Codex Barがこんなにも私のCPUを破壊していることに気づきませんでした。
だから、今すぐそのアプリを終了します。これが最近私のバッテリーがひどかった理由を説明してくれるでしょう。知れて良かったです。Macを使っている場合は、ここでもっと時間を過ごしてください。非常に便利です。ここで気づくでしょう、Notionは私が常に開いているアプリで、チャンネルを運営するために使っています。会社を運営しています。Notionで多くの時間を過ごしていますが、私のDiscordクライアントよりもはるかに少ない電力を全体的に使っています。
あるいは、Whisper Flowのようなネイティブに構築されたアプリ、私の音声テキスト変換、Dropbox、Shatterよりも。これらの間の差はあまり大きくありません。ストリームを開始する直前にコンピューターを再起動しなければなりませんでした。だから、これらの数字の多くは日々のワークフローに基づいて正確ではありません。でも約束します、Ghostyは定期的に最も電力を消費し、RAMを消費するものです。なぜなら、私はそれを使って実際の仕事をしているからです。
それが非常によく構築されて効率的であるという事実にもかかわらず、やっていることが難しい場合、それでもバッテリーを食べ、アクセスできるすべてを食べます。一般的に言って、人々はElectronとChromeに対してあるべき以上に厳しいです。そして実際、私はしばしばそれを、開発者がどれだけジュニアで自惚れているかの良い指標として見つけます。
誰かがElectronについて悪口を言っている場合、95%以上の確率で彼らは何も便利なものを構築したことがありません。そして、めちゃくちゃ速いElectronベースのオープンソースソフトウェアの黄金の例はたくさんあります。私は公開するすべての動画でアセットを切り刻むためにLossless Cutを使っています。これは本当に複雑なUIでFFmpegを効果的にラップして、今では私と私のチームのために自動化されている動画での面倒なことをするElectronアプリです。
Lossless CutとMiffyに感謝します。それは良いElectronアプリの素晴らしい例であるだけでなく、誰かが自分自身で構築した、自分が持っている問題を解決する便利なツールの素晴らしい例です。私は今でもElectronは素晴らしいと思っていますし、それに対するほとんどの問題はAIを使って解決できます。ものを作りましょう。便利です。
そして悪いElectronアプリを使っているからそれらを嫌っているなら、申し訳ありません。そのアプリを作った会社です。ブラウザーに付属しているすべてのもので良いアプリを作れないなら、それらなしで良いアプリを作れると思う理由は何ですか?10ギガのRAMを使うひどいウェブアプリを作る同じ人々が、Rustで十分に上手くなって、よりパフォーマンスの高いものができると本当に思いますか?ここで現実的である必要があります。
型安全性とテスト──AIで変わる評価
現実的であると言えば、型安全性は無料のテストです。私がよく与えていた意見は、ウェブ開発の世界でユニットテストをするために持っているツールが、TypeScript後にあるべきところから本当に本当に遅れているように感じるということでした。ウェブでテストに使う多くのツールは、TypeScriptが存在するずっと前、ましてや標準になるずっと前に構築され、反復されました。
私が見た多くのテストが、効果的に、文字列を期待する関数に数値を渡したらどうなるかというものだったか、数えきれません。なぜなら当時は反対側で何を得るか分からなかったからです。そして決して知らなかったので、すべての関数が投げられる可能性のあるすべてのものを処理することを確認するためにテストする必要がありました。
でも今は分かります。なぜなら、文字列だけを取る関数として定義されていれば、少なくともTypeScriptを使って型をチェックしている限り、その関数は文字列しか取れないからです。これは、私が今まで以上に強く感じている意見のもう一つです。型システムを利用して、エージェントが常にコードベースの完全なコンテキストを持っているわけではないために愚かなミスが起きたときにキャッチしていないなら。
エージェントがどこかで呼ばれているのを見た関数を呼び出しているが、関数自体をコンテキストに引き込まなかった場合、それができない時に数値を渡せると仮定するかもしれません。でも、型エラーが発生すれば、それができないことが分かり、それに応じて学習して調整します。型システムにアクセスできるエージェント開発ツールを使ったことがない場合、それらが何ができるかを見ていません。
ツールが動作するように見えるコードを書き、型チェッカーを実行し、エラーがあることに気づき、それを修正しに行き、それが完了するまであなたを煩わせないのを見るのは、本当にめちゃくちゃ信じられないほど素晴らしいです。とてもクールです。そのトピックについて、カバレッジについて話す必要があります。YouTubeを始めた頃、人々がよく推していた非常に一般的なトピックは、100%コードカバレッジというアイデアでした。
実際にテストでテストされ、ヒットされるコードの行数をチェックするものがあります。そして、テストがどこかで触れない実際のコードベースの単一の行があった場合、あなたは悪いエンジニアで、悪い気持ちになるべきです。これは、コードが実際に思った通りに動作しているかを知る方法が必要だった型以前の時代から来た意見の一つで、テストを通じてコードをチェックすることでそれを確認していました。
とはいえ、100%コードカバレッジはすべてがよくテストされているという意味ではありません。単にコードベースのすべてのコード行が何らかの形でテストによって触れられているということです。正しいことをテストしていないかもしれないし、意味のあることを全くテストしていないかもしれません。単に関数を呼び出して返すことを確認しているだけかもしれません。
それは意味のあるコードカバレッジではありません。それはCIの良い数字です。そして私たちは皆チェックマークと100%を見るのが大好きで、カバレッジが上がるのを見るのは気持ちいいです。でも実際には有用ではありません。チャットが正しく指摘しているように、コードカバレッジは常にある種の冗談でした。すべての行の些細なケースをテストするだけで、良いテストなしで100%を得られます。
それだけでなく、テストカバレッジはメンテナンスで問題を引き起こす可能性があります。実際の機能ではないものをテストしている場合、変更時に壊れる実装の詳細をテストしている可能性があります。良い変更をしたときに壊れて、悪い変更をしたときに壊れないテストを書くのは非常に簡単です。
実際、私が見たほとんどのテストは大まかにそれに該当します。別の問題は、100%バーにないテストカバレッジを持っている場合、貢献しようとしている開発者にとって本当に変なエルゴノミクスになることです。これはTwitchにいたときに実際にあった実例です。本当にひどく実装された巨大な機能がありました。Twitchには85%のコードカバレッジバーがあったと思います。
少なくとも85%のコードにテストが関連付けられるというハードラインが設定されていました。そして約8万から10万行のコードを持つこの巨大な機能が根本的に壊れていました。私はその機能全体を約2000行のコードでゼロから書き直しました。たくさんのバグを解決しました。そしてここがポイントです。私の変更は100%コードカバーされていました。
だから、私は90%コードカバレッジで10万行のコードを交換していました。10万行のコード、90%カバレッジ、そして私はこれを100%カバレッジで2000行のコードと交換していました。明らかに勝ちですよね?もし私がそのコードを廃止できなかったと言ったら?そして今日まで、この廃止された機能がおそらくまだコードベースに残っていると言ったら?
なぜまだコードベースに残っているか分かりますか?なぜなら、コードベースが200万行のコードで85%だったからです。90%カバレッジで10万行のコードを削除すると、この数値が下がります。なぜなら、このコードの巨大な山がラインを超えていたからです。さらにラインを超えた少ないコードと交換しても関係ありません。なぜなら、私のPRは2000テスト済み、0未テストを貢献しましたが、ここには9万テスト済み、1万未テスト済みがあったからです。
9万行のテスト済みコードを2000行のテスト済みコードで置き換えると、数値を下回りました。そして今日まで、このコードはほぼ確実にTwitchのコードベースに残っています。なぜなら、それを削除することはマージできないからです。コードカバレッジが良い理由をもう一度教えてください。良くありません。コードカバレッジはめちゃくちゃな災害です。コードカバレッジで意味を成した唯一の数字は100で、それも意味を成しませんでした。とはいえ、意味を成さなかった理由の多くは、めちゃくちゃなメンテナンス作業と、これらのテストの多くが意味のあるものをテストしていなかったという事実でした。
ほとんどのテストがテストを書くのがあまり得意でないエンジニアによって書かれたという事実が、この問題をはるかに悪化させました。そして、それが変わった唯一のことです。良いエンジニアがテストを書いている場合、おそらくあまりよく書いていませんでした。なぜなら、それは彼らが書きたいものではなかったからです。そして悪いエンジニアがテストを書いている場合、何を期待するか分かりますよね。
誰もユニットテストに多くの努力を払っていませんでした。特にコードカバレッジのような任意のバーを達成しなければならない場合は。何を与えても常に全く同じ量の努力を払うのは誰か分かりますか?あなたのAIエージェントです。これがこの意見が少し変わった理由です。一般的にコードカバレッジは悪いパターンだと今でも思っていますが、悪いテストを作るものの多くが、AIにすべてのテスト書きをさせれば事実上根絶されるため、これを10点中6点に下げるでしょう。
テスト駆動開発もこれまで以上に意味を成すようになったことは注目に値します。エージェントが仕事に成功したか失敗したかを知るために実行できるものがあれば、成功するまでループで実行するのは本当に良いことです。そしてエージェントと協力してそれらのめちゃくちゃテストを定義できれば、クールです。既にチャットで懐疑論が見えます。
AIにテストを書かせるのはひどいアイデアではないですか?いいえ。テストを嫌う不満なエンジニアにテストを書かせたり、テストしているものを理解していないジュニアエンジニアにテストを書かせたりするよりもはるかに良いアイデアです。AIははるかに良い仕事をします。特にテストがコードと期待の間の関係を定義するためにあり、テストしていることを気にかけていることを知るために実際にテストコードを読む場合は。
テストされていないコードベースを取って、エージェントに大量のテストを書くように言うのは素晴らしいとは思いません。エージェントと一緒に書く計画の一部としてテストがあり、それが機能を実装する際の参照点として使用されるのは素晴らしいと思います。心配しないでください、テストについてはまだまだたくさん話すことがあります。
まず、モックは過大評価されています。モックには多くの問題があります。実際に書いているものをテストしているわけではありません。それらがすべきだと思うことをテストしているのです。コード自体というよりも期待をテストしているのです。それらを維持して最新に保つのは本当に本当に大変です。そして一般的に言って、これらのもの周辺のエコシステムと依存性注入のようにしなければならないすべてのクレイジーなことが、モックプロセスをある種悲惨にします。それが彼らを非常に過大評価させました。そして非常に長い間、
私たちのテストのゼロには意味のあるモックがありませんでした。それ以来変わりました。モックする価値のあるもの、定義する価値のあるもの、対処する価値のあるものはたくさんあります。そして今では、型定義をコピーして、エージェントに貼り付けて、このパターンと形状に合う10個のモックオブジェクトを作ってと言うのと同じくらい簡単なので、モックを痛みを伴うものにしていた多くのことがはるかに痛みを伴わなくなりました。
そのため、モックは少しは合理的だと思います。特にeffectのようなツールがサービスを通じて依存性注入を行うのを簡単にするからです。それでも全体的にはかなり過大評価されていると思います。そして、モック、注入、テストが簡単な方法ですべてを構築すべきだというこの考えは、あまり多くのことをしないはるかに多くのコードを書くことになります。
そして、より多くのコードが常により多くの問題を解決するわけではありません。実際、より多くのコードはしばしばより多くの問題を引き起こします。そして、テストカバレッジがどれだけ高いかとコードベースにどれだけバグが存在するかの間に意味のあるパターンはありませんでした。しかし、コードベースのサイズとその中のバグの量の間にはかなり明確な線形関係があります。
だから、より多くのテストはより多くのコードを意味します。より多くのモックはより多くのコードを意味します。そして、より多くのコードは一般的により多くのバグを意味します。それは何が変わろうとも真実です。でも、モックには多くの痛みのポイントがあって、それがはるかに痛みを伴わないように感じられます。だから、それらへの深い憎しみをあまり強く感じません。スナップショットはここに入れませんでした。私は一般的にスナップショットがかなり好きでした。
なぜなら、それらは実際に何をしたかを視覚化するからです。そして差分でスナップショットを変更したら、何が変わったかを見て、それが理にかなっているかどうかを理解できました。それをAIコードツールと組み合わせます。スナップショットは今まで以上に意味を成します。私がここに入れるのを忘れたので、ここにはありません。スナップショットテストに対する私の意見は、以前とほぼ同じです。でも手動テストはどうでしょう?
手動テストは過小評価されていると常に言ってきました。ほとんどの変更は、人がそれを試して期待通りに動作することを確認する必要があります。私は今でも手動テストが大好きですし、今まで以上にそうです。特に、撮影中にバックグラウンドで巨大なアプリをバイブコーディングしている場合、それらのアプリを実行して期待通りに動作することを確認すべきです。手動テストは今でも不可欠に感じます。特にAIにテストを書かせている場合は。10点満点中10点です。
もっと手動テストしてください。手動テストを今まで以上に煩わしくするものがあります。たとえば、並行して大量のエージェントを実行している場合、テストできるように開発環境にたどり着くのさえ本当に煩わしいことがあります。localhost 3000にもうない場合、サインインするのも煩わしいことがあります。手動テストを困難にする痛みのポイントを解消して、実際に動作するかどうかを確認するためにバイブコーディングされためちゃくちゃなこのブランチをスピンアップして、すぐに適切な状態にしてくれる人は誰でも。
良いお金があります。それをするツールにお金を払います。さて、誰かがそれを作るかどうか見てみましょう。今、本当のスパイスに入ります。ユニットテストは過大評価されています。この意見は非常に過激で、YouTuberとしての私の成功の大部分の責任があります。この意見は、当時口ひげとRustで有名だったある技術系YouTuberの注目を集め、彼は私を討論に招待することに決め、そこでテストとベストテスト実践について話すことになりました。
私たちがテストすべてチャートの側に行きすぎていて、テストが有用か有用でないかを戻って再考する必要があると、良い議論ができたと思います。特にすべてが型安全な世界で。全員が私に同意したわけではありませんが、徐々に多くの人々が私の考え方のいくつかの部分に賛同するようになりました。だからこそ、私の考えが大幅に変わったと言うのは辛いです。
ユニットテストは過大評価されていますか?はい。以前私が推していたレベルまで避けるべきですか?いいえ。これを3に下げます。ユニットテストを痛みを伴い退屈にしていた多くのことはAIによって解決されています。そして私の経験から、AIエージェントは開発者ほど無用なユニットテストを書くことに興味がないようです。
テストに夢中になっている開発者、テストを最初に話すことの一つにする開発者、ユニットテストをとても深く気にかけている開発者は、素晴らしい情報源ではなく、一般的に聞くべきではないと今でも信じています。テスト人間は素晴らしくなく、彼らが書くテストもしばしば素晴らしくありません。エージェントはこれまでのところそれをそれほどひどくやっていないようです。
Cursorが型安全でない関数に文字列を渡さないことを確認するためにユニットテストを書こうとしているのを見た瞬間、ここでやっていることを再考します。でも、テストファイルの型をチェックしている限り、型安全でないものをテストしている可能性は比較的低いです。だから、それを全部言った上で、私は以前よりも自分のものにもう少しユニットテストを入れていることに気づきます。
ここでツールがはるかに良くなったことも注目に値します。テストがより簡単に型安全になるという事実は素晴らしいです。Vestのようなツールが、そのようなテストを実行するのをはるかに簡単にしたという事実は素晴らしいです。AIがすべての退屈なめちゃくちゃをあなたのために書いてくれるという事実は素晴らしいです。そのため、ユニットテストは今でもかなり過大評価されています。
テストについて多く話す人々は今でも私の好みではありません。でも、少し変わったので、自分のテスト意見を少し撤回したかったのです。Primogenとの議論に私を導いた過激な意見と言えば、TypeScriptのリターンタイプは避けるべきです。私がTypeScriptと言ったことに注意してください。リターンタイプに関するあなたの意見がTypeScript固有でない場合、私はあなたについて話していません。
そして、これについてあなたの意見が私と違うのは理にかなっています。なぜなら、あなたは私が話していることと同じことについて話していないからです。私はTypeScriptについて話しています。リターンタイプがRustで多くの意味を成すなら、素晴らしいです。おめでとうございます。おそらくそうだと知っています。TypeScriptでは、多くの煩わしい落とし穴があり、隠すべきでない詳細を隠すため、少し危険な銃になる可能性があります。
私はこれについて非常に強く感じたので、私の最初のスクリプト付き動画の一つである動画を作りました。これ以前、ほとんどすべての動画は頭の中で話しているだけでした。そして今日でも、ほとんどはまだそうです。このビデオにはスクリプトが含まれていません。ある時点で話したいことのいくつかを書き留めた以外は。
この動画では、実際の徹底的なスクリプトを座って書き、ゲストを呼んで自分のパートをやってもらい、最後には多くの本当に深いTypeScriptの人々が、TypeScriptでリターンタイプはあまり意味を成さないと確認するハイライトリールがありました。これは本当に辛いです。明確にしたいのは、これについて以前の私の意見は10点中12点のようなものだったということです。
リターンタイプがTypeScriptで意味を成すと思うなら、おそらく間違って使っていて、危険性について知りません。危険性について知らないなら、私が言及したばかりの動画を絶対に見るべきです。でも、あなたがそうしていて、AIもそうしていて、それらのことに注意を払い続ける方法を知っているなら、これを7くらいに下げるでしょう。
とはいえ、私のカーソルルールをチェックすれば、必要ないときはリターンタイプを避けると指定しています。推論に頼ります。一般的に、これは今でも理にかなっていると思います。とはいえ、使っている多くのAIツールがコンテキストを引き込む方法で、リターンタイプがあることで恩恵を受けることも多いことに気づきます。コードにリターンタイプを入れず、型が何かを知りたい場合、関数の上にホバーすると、何を返すか教えてくれます。
エージェントにはその能力がありません。エージェントにはトークンがあるだけです。コンテキストがあるだけです。だから、これが何を返すと思うかについてエージェントにコンテキストを与える方法としてのリターンタイプは、役立ちます。以前よりもリターンタイプの使用例を多く見ています。そのため、時々理にかなっている場所でそれらを見たときに、以前ほど腹を立てません。返されているもののファイル内でコンテキストを提供します。
とはいえ、それらが推論を壊して、推論されるべき型を上書きしている場合、それらへの私の許容度は大幅に下がります。でも、以前のように、文字通り入ってすべてのリターンタイプを削除するほど怒ることはもうありません。そして時々、削除すると型エラーをキャッチすることがありました。なぜなら、削除すると、誤って操作していた型が突然見えるようになるからです。
だから、これに傾倒して多く使うものではありませんが、以前ほど素早く削除することはありません。初期に私が非常に怒っていたことと言えば、多くの点で今でもそうですが。プリコミットフックです。プリコミットフックは、開発チームを信頼していないことを伝える素晴らしい方法です。彼らがGitを適切に使うこと、好む方法で使うこと、壊れたコードを出荷しないことを信頼していません。
プリコミットフックは非常に明確な、あなたを信頼していない実装です。プロジェクトとアプリケーションとソースコードにデフォルトのプリコミットフックを追加する会社は、開発者を信頼していません。私はそのような会社で働きたくありません。私が働いている会社が、他の理論を試す前に今いる状態を保存したいので未完成の作業をコミットすることを防ぐプリコミットフックを強制して、私が使う方法でGitを使えないように言っているなら、彼らは私が良いコードを書くことを信頼していないからです。
もし彼らがそれだけ与えてくれるなら、2週間通知を渡します。プリコミットフックが嫌いで、エンジニアにとってそれらを必須にするという考えは私にとって吐き気がします。エンジニアが嫌いなら、解雇してください。制限しないでください。彼らの手を後ろで縛らないでください。それらのエンジニアが本当に本当に生産的で、本当に本当に安くて、感情を持っていない限り。
AIについて話しています。エージェントにコミットさせる場合、私はまだそれを乗り越え始めているところです。エージェントにGitを触らせるのは今でも私には怖いです。エージェントにコードを書かせて、その後Gitを扱うのを好みます。でも、もう少し太陽に近いバイブコーディングを始めているので、エージェントにGitを少し触らせています。
そして、プリコミットフックがこの点で本当に本当に便利であることに気づいています。プリコミットフックが、エージェントが壊れた型を持つコードをコミットしていないことを確認するための簡単な型チェックなら、それは本当に便利です。プリコミットフックがコードがコミットされる前にテストが通ることを確認して、それらのコミットを実質的にエージェントがコードベースを持ち込んだ良い状態として使用する場合、プリコミットフックは便利です。
プリコミットフックは、開発者を信頼していないことを伝える方法です。AIを信頼しないのは大丈夫です。エージェントが素晴らしいコードを書くことを信頼していないなら、彼らにプリコミットフックを与えて、そうしなければならないようにしてください。それは公平だと思います。とはいえ、私は今でもこのチャッターが提案することをやっていることに気づきます。それは、huskyを/dev/nullにリンクして、いくつかのリポジトリで組み込みのプリコミットフックを実行したときに、それらがすぐに通過するようにすることです。
エージェントにそれをさせないでください。エージェントにこのトリックが存在することを伝えないでください。なぜなら、彼ら自身がそれをやるからです。でも、エージェントが悪いコードをコミットするのをブロックしたい場合、プリコミットフックは合理的だと思います。だから、人間には10点中10点、エージェントには10点中0点と言うでしょう。エージェントに苦しませましょう。それが彼らの仕事です。
それが彼らが構築された理由です。変わったかもしれないし、変わらなかったかもしれない私の最後の過激な意見では、コードベースの学習方法。これは私がよく話してきたことの一つです。初期の開発者にとって大きなコードベースを理解することは最も難しいことの一つです。なぜなら、初期の開発者が作業してきたほとんどのコードベースは自分のものだからです。自分のものではないコードベースで作業したことがありません。つまり、大きくて混乱していて怖いコードベースで作業したことがないということです。
そのため、彼らは間違った方法でそれらを学ぶ傾向があります。このタブ、コードタブでそれらを学ぶ傾向があります。これは今でもコードベースを学びたい場合に行く最悪の場所です。私はこのコードベースを構築しましたが、それがどのように動作するかを学び始めるためにどこに行くべきか分かりません。なぜなら、それはコードベースを学ぶ良い方法ではないからです。
ここにははるかにはるかに良い方法でコードベースを学ぶ別のタブがあります。いいえ、wikiタブではありませんし、確かにエージェントタブでもありません。プルリクエストタブです。開いているプルリクエストだけでなく、もっと重要なのは、マージされたものです。ここで多くのことを学べます。なぜなら、大きなコードベースのコードの大部分はあまり触れられていないからです。
触れられて変化している部分が重要なのです。コードベース全体を記憶しても、どこにも行けません。コードベース全体をエージェントに渡してもどこにも行けません。このタブで時間を過ごして、何が変化しているか、なぜ変化しているか、そして最も重要なのは、チームがそれらの変更についてどう考えているかを見ることです。
それはコメントセクションを通じてで、非常に価値があります。それが学ぶ方法です。そして、新しい仕事を得たばかりで、コードベースにオンボードしようとしている場合、これは今でも学ぶための素晴らしい方法だと思います。でも今では他の方法もあります。これらの方法の一つで、私が非常に非常に価値があると思うのは、askモードです。エージェントに、このものがどこに実装されているかを尋ねて、すぐに見つけられるようにしたり、このものがどのように動作するか、このエンドポイントのエントリーポイントはどこかを尋ねられるのは、本当に強力です。
これらのタイプの質問ができる能力は非常に強力です。とてもクールです。そして、エージェントがそれを行うときにコードベースをどのようにナビゲートするかを見るのも同じくらいクールです。ターミナルの使い方、コードベースのナビゲート方法、どんな変更が存在するか、なぜ存在するか、重要なものがどこにあるかについて、プルリクエストタブとこのようなエージェントを通じてコードベースに質問することの組み合わせが、はるかに速くオンボードするのに役立つことを学べます。
巨大なオープンソースコードベースをダウンロードして、エージェントでそれらをつつくのが大好きです。これはどのように実装されていますか?これはどこに実装されていますか?このことをどうやってやりますか?コードベースをダウンロードして自分で読むことはナンセンスです。コードベースをダウンロードして、エージェントにそのツールを使ってあなたのために読ませることは非常に便利で、私のチャンネルマネージャーのBenは特にこのために自分のツールを構築し始めました。
Better Context、別名BTCAは、コードベースをダウンロードして、エージェントを使ってそれをブラウズして質問に答えるプロジェクトです。effectが望むことをしていない理由を理解しようとしている場合、エージェントは今effectソースコードをブラウズして理解できます。特定の機能の使い方を理解したい場合、ソースコードとテストとその他のすべてを読んで、それをよりよく理解できます。
コードベースに尋ねることは実際に価値があり、それはクレイジーなことです。なぜなら、過去に最初にこのタイプのアドバイスをしていたときには実行可能でさえなかったからですが、今では非常に強力なツールがあり、直接尋ねて良い答えを得ることができます。このタブで時間を過ごすべきだと今でも思いますが、コードベースをダウンロードすることが価値があると今では思います。
だから、この意見をどこに置くでしょうか?具体的には、意見はPRタブ内でコードベースを学ぶというもので、今でもそれは真実だと思いますが、それと組み合わせるべき他の同じくらい有益な方法があります。だから、これを7くらいに置くでしょう。なぜなら、以前は非常に厳格で、コードベースをダウンロードしても何も教えてくれないと言っていたからです。
今ではそれを通じて学ぶ方法があって、それは本当にクールだと思います。これで、私の最近の過激な意見と、それらがAIの結果としてどのように最近変化したかすべてです。自分が非常に強く感じていたことを振り返って、物事が変化したときに、それがそれと一緒に変化する様子を見るのは楽しいです。
そして、あなたもこれを楽しんでくれたことを願っています。私は物事について自分の意見が変わるという事実を隠したことはありませんが、時々座ってあなたたちと一緒に振り返って、それらを一つずつ見ていくのが好きです。そして、なぜそうなのかを理解してくれることを願っています。そしてもしかしたら、ほんのもしかしたら、これは役に立ったかもしれません。どう思うか教えてください。私のすべての意見は当時も愚かで、今も愚かですか?それとも、私の意見がそれらの周りの技術が変化するにつれて変化するのを見るのはクールですか?みんながどう感じているか教えてください。そして次回まで、平和、オタクたち。
コメント