本動画では、Cursor、Claude Code、Windsurf Codexといった最新AI開発ツールが抱える根本的な問題について、実際の使用経験に基づいた辛辣な分析が展開される。これらのツールの多くは、初期の性能が不十分なAIモデルを用いて自己開発されたため、コードベースに技術的負債が蓄積し、UIの不安定さや非決定論的な動作といった深刻な品質問題を引き起こしている。特に「バイブコーディング」と呼ばれる、AIに過度に依存した開発手法が早期に採用されたことで、悪質なコードパターンが指数関数的に増殖し、もはや改善不可能な状態に陥っているという。動画では、コードベースの品質が開発開始後6ヶ月でピークに達し、それ以降は下降の一途をたどるという法則を提示し、技術的負債の管理方法や、スロップコード(粗悪なコード)を排除するための厳格な基準の必要性を説く。また、最新モデルの活用、積極的なコード削除、プロジェクトの分離、さらには「スロップ版」と「本番版」の二重管理という革新的なアプローチまで提案される。AI時代においてこそ、エンジニアリングスキルと規律ある開発実践がこれまで以上に重要であるという、挑発的かつ示唆に富んだ内容である。
AI開発ツールの現状と根本的な課題
ここ数年、開発ツールを次々と乗り換えてきました。CopilotからSuper Maven、Cursor、Claude Code、Windsurf Codex、Codexアプリまで、本当に多くのものを試してきたんです。でも、これらすべてのソリューションについて、あることに気づいたんですよ。すべてを足止めしている核心的な問題があるんです。皆さんもおそらく気づいているでしょうが、私と同じ見方をしていないかもしれませんし、それを引き起こしている根本的な問題を理解していないかもしれません。
率直に言うと、これらすべてがひどいんです。本当に悪いんですよ。私は、使っているツールが非常に慎重に細かく作り込まれ、超優れた動作をする時代から来ているんです。Cursorを開いて、何かをクリックするたびにUIがあちこち移動するのを見て、何も期待通りに動作しない様子を見ると、ほぼ毎日Sublime Textの時代を懐かしく思います。
これらすべてのAIツールによってコードを書くのがこれまで以上に簡単になっているのだから、より良く機能するものが手に入ると思いますよね。それについてなんですが、これこそが今日本当に話したいことなんです。これらのツールがすべてこれらのモデルで書かれているという事実は、利点ではないんです。多くの点で、それは不利な点なんです。
バイブコーディングの罠
Cursor、Claude Code、Codex、そしてこれら他のすべてのツールの問題は、それらが同じツールで構築されたということです。歴史的に、これは良いことでした。CコンパイラをCで書くと、素晴らしいことができるようになります。CコンパイラをCで書くことで、言語のドッグフーディングに適したターゲットになり、メンテナンスしているものが、それを使用する人々にとってはるかに保守しやすくなります。
一般的に言って、自分のものをドッグフーディングすることは良いことです。でも一般的に、そして今から物議を醸す意見を述べなければなりませんが、多くの企業にとってこれは正しい選択ではないと思うんです。実際、彼らがこれらのものに早期に賭けることを選択したことが、多くの問題を引き起こしているかもしれないと思います。
この動画は物議を醸すでしょうし、残念ながらその多くは私の友人たち、私のポートフォリオ企業などに属するものです。私はCursorの初期投資家です。Anthropicにも技術的には何か関係がありますが、実際よくわかりません。というのも、それはBunへのスカウトチェックで、今はAnthropicのWindsurf Codexの一部になっているからです。面白いことに、OpenAIには彼らの製品を使う以外の金銭的な関係は一切ありません。
ですから、いつものようにバイアスを考慮してください。できる限り透明性を保つよう努めていますが、これから企業について彼ら全員を怒らせ、おそらく私を困らせるような方法で話そうとしています。
Claude Codeの深刻な不具合
もし私の初期投資がここで話していることすべてのせいでゼロになるなら、お金を稼げるようにする必要があります。ということで、批判を始める前に今日のスポンサーのために少し休憩しましょう。
しばらく見ている方なら、私が今日のスポンサーであるAugmentをどれだけ気に入っていたか覚えているでしょう。本当に大きなコードベースで何が起こっているかを理解するための私のお気に入りの方法でした。彼らのインデックスエンジンが素晴らしかったからです。でも、他のツールを使い始めてから、Augmentをあまり使わなくなりました。最近はエージェントが必要なことを理解できるんじゃないでしょうか。まあ、ある程度は。でも、Augmentで気に入っていたあの異常なレベルの即座の応答性は得られないんです。
そこで彼らは、今日使っているどんなエージェントにも追加できるツールを介して、これを誰でも使えるように公開することにしました。皆さんもご存知のように、私はWindsurf Codexがかなり好きなんですが、永遠に情報を探し続けるという悪い癖があります。ここに巨大なT3 Chatのコードベースがあって、時々Codexはものを見つけようとして永遠に検索し続けることがあるんです。
まあ、Augmentには独自のCLIがあって使えるんですが、これが本当に素晴らしいんです。開いてコードベースをインデックス化するように指示しただけです。さらに素晴らしいのは、他のツールで使用するときです。インデックス化が完了しました。見てください。Windsurf Codexに切り替えます。MCPを起動したところです。ちょっと面倒なことを聞いてみましょう。
「有料ユーザーのサブスクリプションがどのように機能するかのロジックをトレースして」とすると、即座にAugmentが提供するコードベース検索ツールを使用します。このツールは、必要なものを正確に見つけ、それ以外はほとんど見つけないという奇妙な能力があります。これをどれだけ速く見つけたか見てください。これはリアルタイムです。20秒未満です。以前ならWindsurf Codexでこれは5〜10分かかっていたでしょうし、関連するものを見逃した可能性があったので、正確ではなかったかもしれません。
コードベースをインデックス化することで、Grepでは見つからない関連情報を見つけることが可能になり、結果はまったく同じプロンプトに対して期待以上に一貫して優れています。小規模なコードベースや小規模なプロジェクトで作業している場合、これは画期的なものではありません。しかし、小規模と大規模のコードベースを行き来する私たちにとっては、どちらもほぼ同じように感じられるようになり、より大きなものを構築している私たちにとっては魔法のような解放です。
Augmentは常に、エンタープライズや大企業の仕事を競合他社よりもよく理解していると感じていましたが、他のツールでコンテキストエンジンを使用しているときほど、それを感じたことはありません。エージェントがコードベースを理解していないと感じたら、今すぐsoyv.link/augmentで修正してください。
Cursorの使いにくさ
Cursor、Claude Code、Codexの問題を本当にシンプルに説明するなら、簡単です。使うのがひどいんです。超一貫性がないんです。モデルが非決定論的だからというだけでなく、頼りにしている実際のコードが本当に悪いからです。毎日変わるし、しかも迷惑な方法で変わります。
私の動画で最もよく受けるコメントの1つが「Cursorのナビゲーションバーでエージェントとエディタのタブをどうやって表示するんですか?」というものです。よく知らない方のために説明すると、Cursorにはこの素晴らしいエージェント・エディタタブのトグルがここのコーナーにあって、エージェントを見て管理するだけのエージェントモードと、エディタが二次的になる従来のエディタモード、つまり私たちがCursorに期待するものとの間を切り替えることができました。
これが大好きで、いつも切り替えていました。ほとんどの時間をエージェントモードで過ごし、本当にコードに深く入り込みたいときにエディタモードに切り替えていました。このローンチ、これはCursor 2.0のローンチでしたが、その直後に私はCursorオフィスに行って、抱えていた多くの問題について話しました。
Cursorクラッシュアウト動画になりそうなところまで来ていました。結局、Cursorの問題について多くの不満を言いました。Twitterでちょっとバズりました。彼らは私をオフィスに呼んで、甘い言葉で説得し、チョコレートを買ってくれました。今日まで恐怖を感じるようなことを話してくれました。そして私は立ち去りました。それ以来、彼らは進歩しています。
でも彼らが私に言ったことの1つで、私が「これはクソひどいし、バカげてるし、やるべきじゃない」と言ったのは、人々がもっとカスタマイズできるようにするために、エージェント・エディタのトグルを削除することにしたということです。その代わりに、今ではこれらすべての楽しいボタン、これらのトグル、レイアウト変更があり、その下にエージェントとエディタのレイアウトがありますが、これらは切り替えるものではありません。これらは、エディタをどのように構成したいかのデフォルトのテンプレート開始点なんです。
そして今、すべてがめちゃくちゃに壊れています。エディタモードに切り替えます。エージェントモードに切り替えます。サイドバーがある場所が変わります。ここではエージェント関連のサイドバーが左にあります。エージェントモードに切り替えると、右に移動します。以前はこれらを切り替えるホットキーがありました。変更されたと思います。
でも今、以前やっていたことのほとんどをやると、くそ、もちろん私のメールが漏れます。エディタにワンクリックでメール漏洩ボタンがあるという事実だけで、彼らを罵倒する理由として十分です。何なんですかCursor。Cursorほど私のメールを漏洩させた製品はないと思います。GitHubのメールを使っていて、実際に重要なものではないことに本当に感謝しています。なぜなら、アプリを開いた半分の時間で漏れているからです。
コードベースの品質低下メカニズム
何が起こっているか分かりますか。私はCursorでクラッシュアウトしないように努めています。投資家だからというのもありますし、会社が怖いからというのもありますし、クラッシュアウトコンテンツが私のお気に入りではないからでもあります。でもこのエディタを開く半分の時間で腹が立つんです。正直に言って、崩壊しているんです。悪いんです。
とにかく、私が言おうとしているのは、人々が私の動画で気に入って、コメント欄で尋ねている機能が、まったく理由もなく非推奨になったということです。エージェント・エディタのトグルを削除する理由はありません。彼らがそれをやったのはバカげていると思います。オフィスで彼らにそれをやるのはバカだと言いました。とにかく彼らはやりました。そして今、「あのボタンはどこですか。本当に便利そうですね」という質問をいつも受けます。同意します。本当に便利でした。クソひどい。彼らは削除しました。
わかりました、落ち着いて。Cursorに対する怒りをやめましょう。Command Qして、とりあえずVS Codeに戻りましょう。お願いですCursor、戻らせてください。戻りたいんです。使用を促すために大量のクレジットをくれましたよね。それでも使わないんです。今あなたのエディタを使うのが好きじゃないから。
今では、クソIDEよりもブラウザでCursorを使う方が多いです。とにかく、私のCursorクラッシュがひどいと思ったなら、Claude Codeについて話し始めるまで待ってください。
ああ、CLIがVS Codeのような巨大なアプリのフォークよりもさらに非決定論的なクソ動作をするという事実。真剣に想像してみてください。5年前に誰かが、よりシンプルでバグが少ないものが欲しいからIDEから離れてCLIに移行すると言ったと想像してください。そしてあなたは悲しくも「申し訳ありませんが、実はCLIの方がバグが多いんです」と答えなければなりません。
彼らはあなたを見つめて「何だって。CLIの方がバグが多い。何だって。どうやってここまで来たんだ」って。明らかに、画像を貼り付けるようなことは、ターミナルUIで最も一貫性のあることではありませんが、それが非常に非決定論的で壊れているという事実は馬鹿げています。先週のストリームで私がクソ切れるほど馬鹿げているんです。時間がかかりすぎました。
Claude Codeで私を狂わせていることがたくさんあります。そこで何が起こったか分かりますか。皆さんは私が押していたキーが分からないから。Claude Codeで画像を貼り付けると、時間がかかり、画像は十分に大きいことが多いので、サーバーにアップロードする前にローカル圧縮を実行する必要があります。
それが起こったときに入力をブロックしないし、何かが起こっていることも表示しません。だから画像が添付されるのを待っている間にメッセージを送信してしまいました。完了するまでブロックしたり待ったりしないので、画像が添付されずに送信されました。T3 Chatでさえ最初の月でこれを理解しました。
そして完了したとき、そこにありませんでした。ここの上の小さなセクションにも表示されませんでした。だから再度貼り付けて送信しました。そしてフォローアップを送ったとき、冗談でしょう。文字通り、これを説明している最中に、圧縮に失敗しました。
Claude Codeで真剣な作業をしている人がどうやっているのか理解できません。これは真剣なアプリケーションではありません。一体何が起こっているんですか。このモデル、このハーネス、このエコシステムは燃えているように感じます。何だって。
それがこの動画をやらなければならないと決めた瞬間です。そのときの怒りをまだ感じています。そこで起こった間違いの数。まず、画像を貼り付けても入力がブロックされませんでした。だから誤って画像なしで送信してしまいました。
でも、画像がまだ処理中にメッセージを送信すると、次に送信するものに静かに添付されることが判明しました。だから誤って2枚目の画像を貼り付けてしまいました。モデルにUIがどのように見えるか知ってほしかったので。スクリーンショットを再度貼り付けました。1つの添付ファイルがあることが表示されました。送信すると今度は2つになっています。迷惑です。
3枚目の画像を貼り付けてこれを実演しようとしましたが、送信する前に、他の画像を正しく圧縮できなかったために、存在した奇妙な競合状態のせいでコンテキスト制限に達しました。結果として、スレッドは死にました。このスレッドを復活させる方法はありませんでした。作業は失われました。ただ死にました。終わりました。完了です。
技術的負債の法則
クレイジーなAIのクソではない開発ツールを最後に使ったのはいつですか。UIの小さなバグ1つが、その作業の道全体を捨てて、最初からやり直しを強いるような。ミーム級です。クソミーム級です。これが今毎日コードを書いている方法だということが実際に理解できません。馬鹿げています。
アンチAIの人たちは、Copilotがひどいとか何でも文句を言っているようなことについて話すべきではありません。ツールを使ってから、これについて文句を言ってください。パフォーマンスについてさえではなく。パフォーマンスは受け入れられません。それには触れます。でもUXの状態、一貫性の欠如、私だけが使っているように感じること。なぜなら、これらのことについて文句を言っている他の人を見ないからです。とても悪いです。
Claude Codeでの経験で、古い壊れたUIを、あらゆる種類の非決定論的なクソと一緒にターミナルに無理やり押し込もうとしているように感じなかったことはまだありません。最悪の部分は常に失敗することではありません。二度と同じ方法で失敗しないことです。スロップフェストです。
そしてそれがここで強調したいテーマです。これらすべてのクソツールは、バイブコーディングに早すぎる時期にあまりにも強くコミットしてしまいました。確かに、バイブコーディングは蔑称です、何でも。私たちは皆、使いたい用語を持っています。ここで私が指しているのは、少し手放してエージェントにやらせることです。
操縦を減らし、コーディングを増やし、エージェントが作ったコードを受け入れることに少し寛容すぎること。私がこれについて誇張していると言えますか。彼らが実際にClaude Codeをバイブコーディングしたはずがないと。賭けてもいいですよ。
Anthropic内では、Claude Codeは急速に私たちがいなくてはならない別のツールになりつつあります。会社全体のエンジニアと研究者が、大規模なコードリファクタリングからコミットの圧縮、コーディングの雑用の処理まで、あらゆることにそれを使用しています。これは2024年2月24日でした。
待って、2024年2月24日じゃない。ああ、去年のクソ2月24日で、利用可能な最良のモデルがSonnet 3.7だったとき。彼らはすでにSonnet 3.7での作業の大部分にClaude Codeを使用していました。これが問題です。
Sonnet 3.7は非常に印象的なモデルでした。ツールコールを確実に実行できました。3.5よりも意味のある形でスマートでした。以前よりも優れた方法でちょっとしたUI修正ができました。おそらく、マージコンフリクトが十分に単純であれば、解決を助けることができたかもしれません。おそらく。
Sonnet 3.7で真剣なアプリケーションを構築することはできません。ここで正直になりましょう。これが強調したいことです。彼らはAIを使ったコーディングに早すぎる時期にコミットしました。なぜなら、彼らが作っているツールを使って、AIを使って物事を構築したかったからです。良いものを作る可能性を最大化するために。
より速く反復できるようにするためでもありますが、AIを使って物事を行うツールを構築しながら、AIを物事に使うことにコミットしたかったからでもあります。そして結果は完全なクソスロップフェストです。
これをよりよく説明するために、皆さんの多くは従来の仕事をしたことがないので。そして、したことがある人でも、おそらく何年も前から存在している巨大なコードベースに入れられたでしょう。時間の経過とともにコードベースがどのように機能するかは非常に興味深いです。
これを非常に曖昧な時間経過による品質としてやると、コードベースでの作業が時間とともにどのように機能する傾向があるかというと、こうです。最初は、まあまあです。すぐに良い場所になります。少し下がりますが、気にして、回復させますが、最終的にはプラトーに達して改善が止まります。
ここで品質と言うとき、多くの異なることを意味します。ユーザーが提供している体験の品質を意味します。依存しているコードベースに存在するパターンの品質を意味します。使用しているパッケージやそのバージョンのようなものを意味します。そもそもパッケージをアップグレードする可能性を意味します。
新しいプロジェクトを初期化してReact 19を使っていて、1ヶ月後にReact 20が出たら、おそらく更新するでしょう。そのコードベースを4年間使っていて、React 20が出たら、更新する可能性ははるかに低くなります。コードベースの慣性は本物です。
すべてのコードベースには、その中で作業する品質が改善を止め、チームの焦点でなくなる時点があります。そこに到達するのにかかる時間は、さまざまなことに基づいて大きく異なる可能性があります。一般的に言えば、チームからの集中的な努力の3〜6ヶ月が得られるもので、その時点でコードベースの品質は到達する基準だと主張します。
物事は悪化する可能性があります。絶対に。信じてください、物事は常に悪化します。しかし、6ヶ月時点でのコードベースの品質は、それが今までで最高になります。6ヶ月の時点でコードベースを正確にあなたが望む方法で、あなたが作業したい方法で機能させていなければ、下り坂になり、二度と光を見ることはありません。
そして、それが大量のこれらのプロジェクトに起こったことだと思います。6ヶ月の時点がSonnet 3.5と3.7で書いたバイブコーディングされたスロップの山だったなら、もうダメです。良くなりません。そしてこれが問題です。これらのプロジェクトの多くはもはや数ヶ月ではありません。今では何年も経っています。
Claude Codeは約1年3ヶ月ほどです。最初の6ヶ月間は本当に良かったです。8月か9月くらいまでは一貫して改善しているように感じていました。そして今、バグが増え、遅くなるにつれて、下降傾向を感じているだけです。
今では、ここでお気に入りのものをお見せします。Claude Codeを開いて、すぐに入力を始めます。これが私です。さて、今回はそんなに悪くありませんでした。Claude Codeを開くとき、1語か2語入ってから実際に入力を認識し始めるまでの半分の時間です。
CLIアプリがどうやって入力ボックスをロックするんですか。これがウェブで起こったことは、ウェブの評判を破壊したミームでした。キーが粘着性を持つという考え、変更を表示し始めるのに時間がかかりすぎる。そして今、ターミナルにあります。何だって。
最新モデルの可能性と限界
ああ、明らかにWindsurf Codexもこれについて悪いようです。入力してみましょう。入力。うわあ、文字を認識し始める前にかなり入力しなければなりませんでした。こうしましょう。1から10まで指を走らせるだけです。最後まで行っても、まだ入力を認識していませんでした。かなり面白いですね。
そのモードから抜け出したらそれが得られるものです。データベース移行をしたばかりなので、それはクールです。では、もう一度試してみましょう。さて、8と9まで行きました。ええ、狂気です。ああ、どうやってここまで来たんですか。
Cursorチームには少し同情します。なぜなら、彼らは最も複雑な巨大なコードベースの1つから始まり、エンジニアの誰もそれに取り組んだことがなかったからです。VS Codeをフォークしたので。それは本当に難しい課題です。VS Codeのような大きなものを取って、意味のある変更を加え、実際のOGコードベースから必要なものが上流に送られるときにそれを持ち込みながら、時間をかけてメンテナンスしなければなりません。
それはひどいです。本当に難しいメンテナンス作業で、彼らは今、元のものから非常に分岐しているので、物事を持ち込むことは基本的に実行不可能です。正直なところ、そのコードベースと縁を切る時かもしれません。聞こえはクレイジーですが、何百人ものエンジニアが何年も取り組んできたことを考えると、手を洗ってゼロから始めた方が良いかもしれません。
ハーネスを持ち込んで、それ以外は何もしないかもしれません。分かりません。コードベースにいません。どのように機能するか分かりません。知っているのは、使うのがひどいということだけです。
Claude Codeには言い訳がありません。Claude Codeはゼロからのスタートでした。しかし今、チームがClaude Codeのコードの100%がClaude Codeによって書かれていることを主張しているため、スロップフェストは、彼らが引き起こした地獄のようなパフォーマンス問題を修正できることを望んで、BunというコアディペンデンシーのBunを購入する方が、彼らがやったことのクソを解除するよりも簡単になるまで続きます。
ちょっと馬鹿げたレベルを評価できますか。JavaScriptランタイムをZigで構築している業界で最も才能のあるネイティブ開発者の1人と彼のチームに莫大な金額を費やして、物事をよりパフォーマンス良くできるようにする。CLIツールが2ギガバイトのRAMを使用しないようにできることを願って、それを獲得する。
何だって。どうやってここにいるんですか。ミームは、ああ、彼らはReactを使って、Reactが悪いということではありません。ミームは、彼らが全体をバイブコーディングして、今ではスロップの山にいるということです。
コードベース管理の実践的アプローチ
これまでに何がありますか。コードベースの慣性は本物です。6ヶ月時点でのコードベースの品質を、そのコードベースが存在する残りの時間で上回ることはありません。そして、これらのモデル、Sonnet 3.5のような初期モデル、古いGPTモデル、コードに使用したこれらすべての初期モデルに早期に賭けた人は全員、非常に速くクソをスロップ化して、もう戻れません。
明確にするために、最新のモデルは素晴らしいです。Opus 4.6とWindsurf Codex 5.3。彼らは奇跡を起こす人です。想像もしなかったことができます。悪いパターンをクリーンアップしようとするよりも、新しいパターンを作ろうとする方がはるかに悪いです。
そしてここに厳しい現実があります。コードベースがまともだとしましょう。90%が良いです。良いものを緑にして、ここに残っているもの、10、20、測定したいものは何でも言いましょう。ここの他のセクションは悪いです。これがあなたのコードベースです。
今、コードベースは大きくなる必要があります。より多くの人が来ています。より多くの変更が行われています。コードベースは急速に成長しています。一般的に言えば、バイブコーディングをしているか、AIツールを使用しているか、従来の人々を雇っているかは関係ありません、コードベースはコピーされます。
ある場所で使用されているパターンは他の場所で使用されます。そして一般的に言えば、使用されているパターンは、見つけやすくコピーしやすいものです。残念ながら、見つけやすくコピーしやすいものは、良いパターンであることは非常にまれです。
結果として起こることは、コードベースの良い部分は線形に拡大し、悪い部分は指数関数的に拡大する傾向があります。したがって、6ヶ月時点での開始点、到達点を持ったら、時間の経過とともに物事がどうなるかというと、悪い部分が指数関数的に増加し、良い部分が線形に増加します。したがって、非常に迅速にスロップフェストになります。
モデルはこれを加速します。Windsurf Codexは、行う作業で使用する例をコードベースから参照するのが大好きです。Windsurf Codexは、あなたの基準を通過したと思うので、コードベースのどこかからクソパターンを喜んでコピーして他の場所に適用します。コードベースにあります。正直なところ、それは公平です。
Twitchでの時間で最高の瞬間の1つは、Twitchサイトになった新しいウェブリポジトリ、Reactでのスクリプト全体の書き直しに最初のPRをファイルしたときでした。そしていくつかのバカな変更を加えました。
それをレビューしている人の1人が「待って、なぜそれをやったの?」と言ったので、それらの変更について尋ねられたとき、見つけたコードの例と、ここに導いたドキュメントのページを見せました。彼らは「ああ、それは本当に悪いですね。これはどこでも起こるべきではありません」と言いました。
だから私がPRを修正する前に、彼らはドキュメントを更新してその方法で導かないようにしました。そして、私のようなあまり経験のないTypeScript開発者がその立場に陥る可能性を低くするために、同様のパターンを持つ他の場所を削除する複数のPRをファイルしました。
エージェントはそれを加速します。ジュニアTheoが入ってきて、どこか他の場所からコードをコピーしたためにバカなミスをすることができるなら、エージェントはそれを10倍速くすることができます。そして彼らはそうします。
したがって、エージェントがコードベースを引き継ぐ前に本当に良い場所から始めていなければ、おそらく少しクソです。そしてそれが起こっていることだと思います。どのモデルも、それが始まるコードより良くなることはできません。そして、これらが始まるコードはゴミです。なぜなら、その多くが過去のより悪いモデルによって書かれたからです。
そして経験から、これがほぼすべての私が取り組んできたものに当てはまることを伝えることができます。だからこそ、T3 Chatのカスタム同期エンジンからConvexへの移行を行ったのは、ほぼ正確にその6ヶ月の時点でした。なぜなら、コードベースで物事を良くすることができなくなる時点に急速に近づいていることを知っていたからです。
リンターをより良いものに変更するなど、多くの微妙な改善を行うことができます。新しいリントルールを適用して、いくつかのことをクリーンアップできます。ここやそこでライブラリをアップグレードできます。しかし、その6ヶ月の時点の後、そのコードの大部分はそこにとどまります。ただそうなんです。
そして、すでに確立したパターンは、どこにも行きません。では、これをどのように修正しますか。これをどのように防ぎますか。最初にコードベースを快適にし、人間とさらに重要なことにエージェントの両方にとって快適なままにするにはどうすればよいですか。
これは実際に私がある程度資格があると感じることです。特に私はこれを頻繁にやらなければならなかったからです。他のすべてのコーダーが悪くて私が良かったからではなく、速度と開発者体験について多く気にかけていたからです。そして、それらはコードベースの品質と非常によく一致する傾向があります。
より速く進むことがコードベースがより良いことを意味するわけではありません。実際にはその逆です。コードベースが本当にうまく構築されてレイアウトされていることが、変更を速く行うことを容易にします。
したがって、最初のことは、容易さ、明確さ、速度を最適化することです。貢献しやすく、何をするかが明確で、変更が速いパターンを早期にコードベースに確立しようと本当に努力することです。理想的には、小さな変更は少数のファイルにのみ触れる必要があります。
そして、大きな変更はおそらく多数のファイルに触れる必要があります。よくある間違いは、人々がコードベースを設計することです。したがって、大きな変更は簡単で、結果として小さな変更が本当に本当に複雑になります。
小さな変更と大きな変更が同じ量の努力を要するなら、両側をクソにしていて、とても一般的です。これがTailwindのようなものが非常にクールである理由でもあります。なぜなら、変更を行うために触れなければならないサービスの数を減らすからです。
これがGraphQLのようなものが悪い理由でもあります。なぜなら、UIに少しの情報を追加するだけではるかに多くのクソに触れなければならないからです。したがって、何が起こっているかを理解しやすく、より明確で、貢献が速くなるようにコードベースを最適化することは素晴らしいです。
しかし、ここで本当に強調したいより大きな部分があります。何も許容しないでください。悪いパターンが入ったら、それは増殖します。悪いコードは良いコードよりもはるかにはるかに速く増殖します。なぜなら、悪いコードは便利でなければ入らなかったからです。
悪いコードと便利なコードには、重複する特性がたくさんあります。しかし、悪いコードは決して入れないほど積極的に増殖します。これについては厳格でなければなりません。まあ、この締め切りに間に合わせる必要があるので、これが遅いことは分かっていますが、後で修正しますという例外を作ることはできません。
ソフトウェア開発の世界では、後でというのは決してという別の言葉です。修正しません。したがって、許容しないでください。コードベースに入れないでください。そしてその線に沿って、悪い何かに遭遇したら、コードベースで匂うものを見つけたら、ためらわないでください。
履歴を調べないでください、なぜそこにあるのか疑問に思わないでください。激しく殺してください。私たちのコードベースにスロップの余地はありません。あまりにも速く広がります。もし遭遇したら、それを殺すためにすべてを捨ててください。
どんな締め切りが逃されても気にしません。どんなマネージャーが怒っても気にしません。どんなエージェントがそれが完全に問題ないと主張しても気にしません。匂いがするなら、それは悪いです。そしてそれが悪いなら、削除されるべきです。許容しません。
これは、もう少し注意を払わなければならないことを意味します。すべてのコード行を読む必要があるわけではありませんが、コードベースが進化している一般的なパターンに目を光らせておく必要があります。これらのものはどのように相互作用していますか。物事を定義するために使用する方法は何ですか。どれほど簡潔に物事を説明できますか。
これの簡単なリトマステストは、エージェントに機能がどのように機能するか尋ねることです。3分未満で良い答えを与えることができれば、おそらく大丈夫です。物事を検索するのに5分以上かかり、良い答えを与えない場合、そのどちらかが当てはまる場合、正直に、捨ててください。
コードを読むだけでなく、エージェントがコードを完成させるのにかかる時間を見ることで、これに対する直感を構築し始めます。単純であるべき何かをするようにエージェントに頼んで、それがそうであるべきよりも長くかかる場合、何かがおかしいことを知っていて、それを修正する必要があります。
Twitchでの時間で知られていたことの1つは、私がハンマースタイルの開発と呼んでいたものでした。それが機能するはずの方法で機能していない何かに入ったとき、壊れているものを修正しようとするよりも、それを削除して再び始める方がはるかに簡単なことが多かったです。
それがうまくいかない理由は、それを再現するにはあまりにも高価だったからです。5,000行のコードを捨てたい場合、幸運を祈ります。なぜなら、平均的なエンジニアは1日に10から100の間で競争するので、すべてを置き換えるのに50日かかるからです。
もしそうでなかったらどうでしょう。数時間で正しく書くことができたらどうでしょう。ここで実際にこれをどのように行うことができるかに入ります。
AIエージェント時代の開発戦略
現在、これらの問題の多くは、AIがコードベースの自然な問題を加速したためです。より多くの開発者がより大きなコードベースを維持していて、コードを見ることが少なくなっています。マネージャーとしての仕事をするだけなら、これはAIなしでまったく同じ方法で起こる可能性があります。
このコードベースを書いて、まともな状態にして、チームに引き継がせ、あまり厳密にコードレビューせず、彼らに彼らのことをやらせると、技術的負債が積み重なり始めます。悪いパターンがクローンされ始め、コードベース全体に現れ、そしてすべてが崩壊します。
私はマネージャーとしてこれに対処するパターンをすでに学ばなければなりませんでした。そして、それらの同じパターンがここに適用されます。しかし、1つの大きな違いがあります。エージェントに間違ったことをしたと言っても悪く感じる必要はありません。
クソひどくて修正する必要があります。Claude Codeでのログが公開されたら、私はそれに言ったことのいくつかのために、おそらく施設に入れられるでしょう。私は従業員に失礼ではありません。そのために非常に努力しています。チームに声を上げることさえしません。その考えは本当に気分が悪くなります。
しかし、クソがクソひどいとき、時々それについて叫ぶ必要があります。そして、それがクソをやったときにエージェントに叫ぶのはちょっといい感じがします。しかし、さらに重要なことに、エージェントにクソの仕事を与えることができます。
5年以上前のコードベースを最新のパターンにアップグレードする人になりたい人はいません。エージェントはそれをやります。会社の15人が使用するこの古い内部サービスを移植したい人はいません。しかし、エージェントはそれをやります。
ハンマーのコストは指数関数的に下がりました。歴史的に、5,000行のコードを削除して置き換えることは単に価値がありませんでした。置き換えるには高すぎたからです。今は、そうではありません。新しいソリューションが十分に整合していることを確認する必要があります。
しかし、ハンマーで叩いて再構築する価値のあるコードベースの適切にコンパートメント化された部分を見つけることができれば、今では絶対に価値があります。そして私はこれをたくさんやってきました。多くのコードベースの多くの場所で「これはただクソひどい。これを書き直せますか」と言って、うまくいきました。クレイジーです。
そして、これらの新しいモデルがスロップを決して生成しないことができると言っているわけではありません。コードベースに多くのスロップがある場合、モデルはエンジニアよりも速くそれを再現します。そして、両方ともすでにかなり速くできます。
しかし、モデルとの計画をうまくやれば、正確に何が欲しいかを仕様化すれば。なぜなら、これはおそらく新しいモデルが著しく優れていることです。計画と会話です。モデルとのやり取りに多くの時間を費やしてください。より良い計画を書いてください。
モデルに伝えてください。「これはひどい。このフォルダ全体を削除したい。一緒により良いバージョンを作りましょう。どのように見えますか?」いくつかのアイデアがあるかもしれません。より良いと分かっている構文やパターンやAPI定義があるかもしれません。モデルと一緒に書き出してください。行ったり来たりしてください。
最後に、読んで、これが良いか悪いかを判断できるマークダウンドキュメントがあります。そして、これが意味があるかどうかを決定したら、構築するように指示できます。そして、その部分を開始する前に十分に良い計画があれば、おそらくうまくいくでしょう。
人間による手書きのコードと同じくらい良いでしょうか。人間に大きく依存します。平均的な人間は、この時点で平均的なモデルよりも悪いエンジニアだと主張します。私のキャリアでWindsurf Codex 5.3よりも優れた多くのエンジニアを雇っていません。
何人か雇いました。見つけるのは難しいですが、彼らは皆間違いを犯します。彼らは皆同じ問題を抱えています。そしてそれを防ぐシステムを構築する必要があります。
最初のポイントは、計画モードではるかに多くの時間を費やすことが大いに役立ちます。良い計画があることを確認するためにモデルと一緒に作業するだけです。計画のすべてがあなたにとって良く聞こえます。時間をかけてください。それが何ができるかに驚くでしょう。そして実際に計画を読んでください。
多くの人がもう計画を読んでいないことを知っています。変更のサイズとどれだけ気にするかによります。しかし、このコードベースが時間の経過とともに保守可能であることを確認したい場合は、それに応じて扱ってください。
次に、そしてこれまでに明らかだったことを願っています、最新のものを使用してください。会社がまだOpus 4.5を承認していないためにまだSonnet 4を使用している場合は、承認させるか、本当の仕事を得てください。これを理解していない会社は非常にクソです。
これに似て、はるかに多くのコードを捨ててください。ほとんどのエンジニアがまだコードに執着しすぎていて、5,000または10,000行を捨てることを恐れていることがわかります。そうしないでください。積極的に捨ててください。あなたの一部が「おそらくこれを削除すべきだ」と言っている場合、おそらく1ヶ月前に削除すべきでした。
ほとんどのエンジニアは、コードを置き換える代わりにコードを修正しようとしすぎるため、このバーを不適切に構成しています。そしてそのノートで、実際に、ブランチオフすることを恐れないでください。
私が意味するのは、コードベースにそのコードベースに本当に属していないあまりにも多くのものがある多くの時間を見てきたということです。これは、他の場所に再びこれをデプロイするのが難しすぎるようなことのためによく起こるので、すべての機能をバージョン1に詰め込むだけです。
これの愚かな例、私はTwitchストリーマーです。主にYouTuberですが、実際にTwitchでストリーミングしています。今、この動画を撮影している視聴者とライブ配信しています。Twitchで働いていました。Twitchで安全性に取り組んでいました。内部安全プラットフォームを構築していて、コアTwitchサイトの構築も手伝っていました。
ある特定のゲームがひどい、恐ろしい、厄介なもので溢れかえっていた本当に悪い事件がありました。カテゴリには、偽のストリーマーが大量に立ち上がり、悪質なクソをストリーミングしていました。当時、内部安全ツールには、事前報告で物事をレビューする方法がありませんでした。
内部ツールのポイントは、報告をレビューすることであり、ライブストリームがライブであるときにライブストリームをレビューすることではありませんでした。つまり、私たちの安全モデレーター、管理者、内部安全ツールチームが、カテゴリを簡単に通過して、多数の異なるコンテンツクリエイターを禁止する方法がなかったということです。
はい、これはアーティファクト事件でした。神様、この事件がどれほどクソだったかから、アーティファクトという言葉は今日まで私を悩ませています。このカテゴリで厄介なことをやっている場合、管理者が迅速にストリーマーを禁止する方法を設定する必要がありました。カテゴリを閲覧するだけで、彼らが実際にゲームをプレイしているかどうかを簡単に見ることができました。
Twitch安全チームはこれに対処する方法が必要でした。そして私に与えられた提案は、管理者だけがクリックできる永久禁止ボタンをメインTwitchサイトに追加することでした。したがって、管理者がTwitchにサインインしている場合、カテゴリをスクロールして、ワンクリックで即座に禁止できます。
私はすぐにそれに飛びつき、「冗談ですか。公開されたクソTwitchコードベースに内部永久禁止エンドポイントを決して公開しません。冗談ですか」と言いました。いいえ、決して。そして明らかに、通常のユーザーは、グローバルモッズと管理者の昇格されたオフを必要としたため、それにヒットすることはできませんでした。
しかし、コードがメインサイトに入るだけでも恐ろしかったです。そして、ここでのすべての潜在的なセキュリティ安全性の影響に関係なく、1日に何百万人もに提供するコードベースで、10〜15人にのみ適用されるカスタムコードパスを持つというコードの匂い。
いいえ、1日に何百万人もに提供するコードベースで10〜15人のための機能を構築していません。冗談でしょう。基本的な技術的負債の計算でそれをしないように指示します。しかし、これらのタイプの提案は今日まで非常に一般的です。なぜ本当に速く機能を追加しないのですか。
まあ、おそらく独自のコードベースに属していますよね。それからすべての正しい依存関係にリンクする必要があります。チームからデプロイする許可を得る必要があります。ホストする必要があります。これらすべての部分を理解する必要があります。認める必要があります。
この1回限りのことを行うための新しいプロジェクトを作ることは、ただ価値がなかっただけです。幸いなことに、この特定のインスタンスでは、内部コードベースの十分な所有権と外部のものへの十分な精通があったので、管理者がそこから人々を禁止しやすくするために、内部ツールでカテゴリブラウザをすばやく再作成できることを知っていました。
だからそれをやりました。結局うまくいきましたが、やらなければならず、チームと戦わなければなりませんでした。「申し訳ありませんが、これは少し時間がかかることは分かっています。それほど長くはかからないし、大きなリスクにはなりません。この方法でやる必要があります」と言って。
そして彼らが私にさせた唯一の理由は、実際には内部対外部のことやセキュリティやその他のことでさえありませんでした。外部のコアTwitchサイトは、覚えている限り午後1時頃に1日1回しかデプロイされなかったからです。
だから、管理者のためだけにこの1つのボタンを追加するために、再デプロイするための例外を得なければなりませんでした。しかし、私が所有していたので、私の内部ツールはいつでもデプロイできました。したがって、私が所有していたので、内部デプロイが少し簡単だったというデプロイアーキテクチャの問題でした。
それが、このボタンが公開コードベースに入らなかった唯一の理由です。では、なぜクソこの接線に行ったのですか。聞いてください。すべての理由、公開Twitchサイトの既存のコードベースに新しいものを作ったり、内部のものに入れたりする代わりに、それを入れる理由の100%。
それらの100%がなくなりました。新しいコードベースを構築することがこれまで以上に簡単です。コードベースAからコードベースBに機能を移植することがこれまで以上に簡単です。物事をデプロイして出荷することがこれまで以上に簡単です。もう言い訳はありません。
そして、これらの厄介なコードベースの多くは、属していないものを作ることのせいだと思います。Claude Codeベースが、機能フラグの下に隠されて出荷されなかった非推奨の機能でいっぱいではなかったら、驚くでしょう。もう誰も使っていない古いモデルに固有のもの。存在しないシステムとの統合。外部ユーザーに持たせたくない、彼ら自身が使用する内部ツール。
Claude Codeのコードベースの50%未満がそのようなものだったら、床に倒れるでしょう。そして、その本能と戦う必要があります。物事がコードベースに属していないときに押し戻す必要があります。
私たちの生活の中でみんなが持っているコードベースの数は、来年10倍になるはずです。私は積極的に2〜3のコードベースで作業していたのが40くらいになりました。そして、はい、管理するコンテキストがたくさんあります。はい、それは多くのことが起こっています。
しかし、厳しい現実は、それらのコードベースのほとんどが1つのことをしたら、別のコードベースのクソフォルダが触れられる必要がないのと同じ方法で触れられる必要がないということです。問題は、その大きなコードベースで何かをしなければならないときに来ます。
この場合、Twitchサイトのような重要な1つの主要なコードベースがある場合、Reactバージョンへのアップグレードを行うには、誰も2年間使用していない内部ツールもバンプする必要があるべきではありません。
ここで強力な規律を構築すれば、無関係なものをそのコードベースから遠ざけることが得意になれば、メインコードベースにある必要のないもののための新しいモジュール、新しいリポジトリ、新しいプロジェクトを作るだけで、突然メンテナンスがはるかに悲惨でなくなります。
そして、これらのどれもそのように機能していないことを確実に知っています。Cursorは物事をCursorに追加し続けています。彼らは混乱の上に構築し続けていて、結果は不安定なクソショーです。Claude Codeはスロップフェストで、誰も使わず、もう必要さえないもので常に自分自身の上に構築しています。
その衝動と戦ってください。物事を遠ざけるよう押してください。チームがこれを行うことも容易にしてください。新しいサービスをデプロイすることが難しすぎる場合は、それを修正してください。会社の誰でも新しい内部サービスを新しい内部URLまたはサブドメインにデプロイすることが簡単であるべきです。些細なことであるべきです。
内部GitHubエンタープライズまたは代わりに使用しているクソソースソリューションで新しいリポジトリをスピンアップするのがコードベースにとって難しい場合は、それを修正してください。会社の誰でも1日に10個の新しいコードベースをスピンアップしてデプロイすることが些細なことであるべきです。
エージェントは他のすべてを簡単にしました。その部分がブロックされている理由である場合は、それを修正してください。古いプロジェクトのスロップ化の代わりに新しいプロジェクトの作成を奨励してください。ユーザーの大部分が使用している機能に不可欠でない場合は、他のものにしてください。
二重コードベース戦略の提案
そして最も重要な最後の部分は、質問することです。具体的には、AIエージェントが作業しているときに、何をしているのか尋ねます。なぜそれをやっているのですか。どこからこのアイデアを得たのですか。なぜこれが重要だと思うのですか。なぜこの道を選んだのですか。
エージェントが何か間違ったことをしているのに気づいた場合、それには理由があります。これらは非決定論マシンです。二度と同じことをすることは決してありませんが、十分に近いことをするでしょうし、理由は比較的一貫しています。
この間違ったことをした場合、どこからアイデアを得たのかを理解してください。コードベースから来た場合は、それを排除してください。クアッドMDから来た場合は、それを修正してください。調整してください。
これらのツールの問題は、どれだけ速く出荷できるかに集中しすぎていて、どれだけうまく出荷できるかに集中していなかったため、この勤勉さがなかったことです。そしてこれを深く感じます。Cursorに、新機能なしの月とスロップのクリーンアップだけをいじめるほど深く感じます。
正直なところ、これらのコードベースのいくつかは、おそらくゼロから最初からリセットする必要があるだけです。私がよく考えるプロジェクトがあって、皆さんは私がこのウサギの穴に行くことで狂っていると思うでしょうが、聞いてください。
Vampire Survivorsというゲームがあります。皆さんの多くはこのゲーム以前に聞いたことがあるかもしれません。Vampire Survivorsは元々、円を描いて歩き回り、銃が自動射撃してモンスターを破壊し、最終的にすべてを終わらせることができなくなって死ぬというクソモバイルスロットウォーゲームに基づいていました。
Vampire Survivorsについての面白い事実、それはブラウザでPhaser.jsで書かれましたが、右にNintendo Switch用のVampire Survivorsが見えるかもしれません。Nintendo Switchは有能なコンソールではありません。発売されたとき、すでに2年以上前のプロセッサで発売されました。
RAMの速度はほとんどのハードドライブよりも遅いです。これらのハードドライブとしてではありません。Switchはクソのハードウェアでした。完全なJavaScriptエンジンと一緒にPhaser.JSバージョンをSwitch用にかすかにパフォーマンスの良い方法で動かす世界はありませんでした。
だからC++で書き直しました。それがVampire Survivorsコンソールバージョンになりました。それは今、Steamで入手するバージョンでもあります。それについては間違っているかもしれませんが、SteamバージョンもC++だとかなり確信しています。
リード開発者はC++を知りません。彼は他のシステムにゲームを移植するために参加する追加の開発者を何人か雇いました。しかし、ここで本当に楽しくなります。ゲームのクリエイターがゲームの新機能を構築したい、新しいアイデアをテストしたい、物事で遊びたい、ゲームを改善したいとき、C++コードベースで物事を編集することによってそれを行いません。
彼はブラウザ用の巨大なクソショーのPhaser.jsでスロップすることによってそれを行います。そして、ゲームがうまくプレイされると感じる十分に良い状態になったら、それを実際のコードベースで構築するためにチームに渡します。
彼らは並行して2つのコードベースを維持しています。1つのバージョン、ウェブバージョン、phaser.jsバージョンは、ゲームデザイナーとクリエイターが、何が機能し何が機能しないかを理解するため、アイデアを反復するため、ゲームを改善するために使用するものです。
そして、そのバージョンが物事を理解したら、チームは洗練された、洗練された、信頼性の高いC++エディションに移植するタスクを割り当てられます。
今後、これの多くが見られると思います。このような何かに似た未来を本当に信じています。特定のコードベースの2つ、あるいはそれ以上のバージョンを維持する場所です。おそらく、機能するものを作り、理論をテストするために、バイブコードスロップウェアツールを使用します。
おそらく、そのバージョンを一部のユーザーに出荷して、彼らがどう反応するかを見るかもしれません。過去にFramerモックを使用してユーザーのアイデアをテストするようなことをすでに見てきました。これをもっと真剣にやったらどうでしょう。実際の設計方法論の一部としてこれを行ったらどうでしょう。
スロップを通じて構築することをアイデアをテストする方法として考え、次により確立されたエンジニアリング実践を使用して、それらのアイデアを良い信頼できる製品に変えたらどうでしょう。
Cursorが損失を削減し、既存のコードベースをスロップフェストバージョンとして扱い、それを使用してアイデアのプロトタイプを作成し、物事で遊び、次に重要な部分を移植し、重要でないすべてのスロップを残して、ゼロから新しいバージョンを開始したらどうでしょう。
それは突然はるかに安くなります。同じコードベースを2回維持する、プロトタイピング用の内部バージョンとして1回、実際の使用のための外部バージョンとして1回は、狂気に聞こえ、過去にはまったく意味がありませんでした。
それが始まっていると思います。これが実際に物事になるかどうかわかりません。これがどこかに行くかどうかわかりません。しかし、スロップフェストに自分自身をスロップ化してコーナーに入れられていて、そこから抜け出す必要があるが、スロップフェストエディションでできる反復速度と実験を失いたくない企業にとって、これは実行可能な道だと思います。
これが意味をなすかもしれないと思います。そして、T3で調理しているいくつかの楽しいもののために、自分自身でドッグフーディングすることさえ検討しています。Juliusがライブになって以来、すべてのT3コード関連のもので調理しているのを見ます。彼はすでにホットキーを追加したようです。
すべてがうまくいけば、これはこの動画が出るまでに出ることを願っています。そうではないかもしれませんが、T3 Codeの作成に深く入り込んできました。これは、これらのエージェントとやり取りするためのはるかに安定した方法を意図しています。
そして、これは、バイブコーディングされたスロップバージョンがあり、かわいそうなJuliusが実際に確実に機能させるタスクを任されている、その理論をテストする最初の時間になるかもしれません。
私たちは効果的にすでにこの方法で作業しています。私は機能を機能させ、私の意図が何であったか、何をすることを期待していたかを示すスロップPRを出し、次にチームがそれを正しく構築します。
T3 Chatでの私のPRの半分以上は、AI以前でもマージされません。なぜなら、これらの多くを構築してUXの感触を示し、正しく機能するかどうかを確認し、そうでない場合は再試行してもう一度やり直し、次にチームがそれを実際の良い信頼できる機能にするという恐ろしいタスクを任されるからです。
いつも起こりました。JuliusによってクソPRがトランプされた回数は本当に面白いです。AIはそれを加速しているだけですが、ここに何かがあるかもしれないと思います。コードベースの2つのバージョンを維持する、または少なくとも使用しているコードの多くを捨てる、出荷するためではなくアイデアをテストするために大量のコードを書いていることを知っているというこのアイデア。
2回測定し、1回切断する、私のこれまでのお気に入りのフレーズの1つの代わりに。おそらく2回ファイルし、1回マージです。おそらく10回PRし、1回です。しかし、コードが安いので、この安いコードをすべてマージすべきだという考え。ひどい、恐ろしい、厄介です。今日私たちが陥っている地獄をもたらしました。
おそらくこれらのツールは、役立つのと同じくらい、アイデアを吟味するのに適しています。そして、最終的にコミットする最終バージョンは、アプローチにもう少し注意を払います。
おそらく、またはおそらくモデルがとても良くなるので、これのどれも重要ではなく、とにかくゼロからすべてを書き直すことができます。誰が知っていますか。これはすべてどこにでも行くことができます。これは機能するかもしれないしそうでないかもしれないパターンについてのすべての推測です。
大規模なコードベースを維持するための私の経験とすべてとそれ以上。エンジニアリングスキルが重要ではないと言う誰も理解できません。今日ほど自分のスキルが限界まで押されていると感じたことは一度もありません。
良いエンジニアが今素晴らしいことをする機会があります。そして、この馬鹿げた暴言が、なぜかを理解するのに役立つことを願っています。また、これらすべてのスロップフェストがどれほど悲惨に機能し、使用するかを理解するのにも役立つかもしれません。
既存のCursorとClaude Codeベースが機能したり、使用した結果が良くなったりする未来は見えません。彼らがスロップフェストであると扱われる未来は見えます。ゼロから新しいより良いものが構築され、結果として彼らはより良いアプリを持ちます。
しかし、Claude Codeコードベースが良くなる未来は本当に見えません。新しいコードベースがそれを提供するために使用されるため、Claude Code実行可能ファイルが良くなる世界は見えます。
これがすべてどこに行くかは分かりません。ただたくさん文句を言いたかっただけです。皆さんが聞いてくれたことに感謝します。これがコードベースを少しよく維持するのに役立つことを願っています。少なくとも、これらの既存のツールに対する不満をもう少しよく発散することにも役立つかもしれません。
エージェントがそれらをズタズタに引き裂くことを喜んでいるので、コードベースをよく維持することがこれまで以上に重要になりました。これについて皆さんがどう思うか、または私がただ狂っているだけかを教えてください。次回まで。
コメント