この動画では、AIアシスト開発ツールであるCursorエディタの有効性について詳細な分析が行われている。話者はテキストエディタとAI編集ツールの豊富な経験を持つ立場から、Cursorが実際に生産性を向上させるのか、それとも逆に「ネットネガティブ」な影響を与えるのかという重要な問題を検討している。特に、Cursorの公式サイトで宣伝されているRustコードの例を詳細に分析し、AI生成コードの問題点や、プログラマーが直面する現実的な課題について議論している。
プログラマーの立場から見たAI編集ツール
ネットネガティブなCursorについて話さなければなりませんが、私はテキストエディタについてかなり良い理解を持っていると感じています。AI編集も行うエディタについてもそうです。私はZedについても非常に興味深く思っていて、Zedが十分良い体験を提供するかどうかも気になっています。
始める前に重要なことを理解していただきたいのは、私がコードを書く時は独特な立場にいるということです。私は好みがあって、ここにいたいんです。これが私がいたい場所なんです。私はNeovimにいたいのです。VS Codeにはいたくないんです。そのため、私の意見は明らかにそれに影響されています。
時々Cursorを使うかって？ええ、使います。実際、つい最近も数時間使いました。Neovimにもライ知ってると思いますが、AIがあります。AvanteやSuper Mavenなど、楽しいツールがたくさんあります。私はプログラミングを楽しんでいるので、AI編集ツールでたくさん遊んできましたし、今でもたくさん遊んでいます。ただ、私がもっと好きそうな統合、コマンドラインからの統合を試したことがないんです。それが私に欠けている一つのことです。
私の意見について、コマンドライン体験について話さない場合は許してください。もうすぐOpenAIのcode機能を使ってみる予定で、それについて深く掘り下げて、良い感じかどうか試してみるつもりです。それを把握しなければなりません。
AIアシスト開発への懐疑的な見方
AIアシスト開発が最近大流行しています。私は懐疑的ですが、これらのツールに公平なチャンスを与えたいと本当に思っています。しかし、これらのツールが実際に何を成し遂げているかを見て、幻滅しています。これらのツールは役に立たないどころか、私たちをネットネガティブな生産性にしてしまう可能性もあります。
これは非常に大きな、重い発言ですね。これについて詳しく見る前に、簡単な投票をしてみましょう。この発言は明らかに重い発言だからです。新しい投票をしましょう。スキル問題でしょうか？この人はこの発言により、スキル問題を抱えているのでしょうか？発言は最初から非常に重く始まりますよね。すぐに「これはネットネガティブだ、幻滅した、良くない」と言っています。これはスキル問題でしょうか？皆さんはどう思いますか？
最も簡単な投票だと思いますか？彼らは「skeptical」のスペルも間違えています。まあ、つまり、この人はVimでこれを書いたんです。スペルチェックが有効になっていませんでした。何を言っているんですか？負け犬め、スペルチェックがあるなら使えばいいじゃないですか。
Cursorの宣伝例の分析
AI生成コード変更の最良の例の一つを見てみましょう。Cursorエディタが宣伝のフロントページで使っているほど良い例です。
現在私が得ている議論は、必ずしもCursorが問題なのではなく、LLM生成コードが問題だということのようです。私は大いに同意します。LLM生成コードは朝食にラッキーチャームを食べるようなものです。健康に悪いだけです。ショートカットのように思えて、美味しく感じられ、幸福への近道のように思えますが、その後は体に悪いものを食べたように感じて、人生が辛くなります。
Cursorが素晴らしいコードだと思っているものを見てみましょう。これは執筆時点でのCursorエディタのウェブサイトのホームページです。とてもカラフルですね。
rustmax_string_equals_this_one
おっと、彼らはフロントページに少しRustを置いているんですね。Cursorが獣人だとは知りませんでした。
彼らの最高の機能はタブ補完だそうです。lengthがmaxより大きければプロトコルシリアライゼーションエラー、mute_bytes_vec、read_exact_bytesなど。これは問題ありません。
エディタのスクリーンショットを見てみましょう。読みやすさのためにライトモードバリアントを使用しているそうです。ライトモードが読みやすさのためだとは知りませんでした。
Rustコードの詳細分析
画像はCursor IDのスクリーンショットを示していて、コード変更のためのAI提案が保留中です。コードはバイナリプロトコルから長さ区切り文字列を読み取るためのRust関数です。
文字列を読み取る関数があって、少しバッファを持つ、不変の実装、読み取り、結果を文字列プロトコルエラーで取得、少しネットワークエンディアンを読み取ります。ネットワークエンディアンって大きいエンディアンですね。
ちなみに、エンディアンについて面白い話があります。大学時代に初めて「エンディアン」という用語を聞いた時、私はエンディアンがインディアンだと思っていて、本当に混乱しました。「なぜ私のコードに大きなインディアンと小さなインディアンがいるんだろう？これは何と関係があるんだろう？」と。一週間ほどそう思っていて、本を読み進めて「エンディアン」だと分かりました。完全に間違っていました。
コードの問題点の発見
提案には「最大文字列長とサニタイゼーションの検証を追加する」というポップアップが付いています。transcript は以下のコードを提案しています。
私はRustが十分得意ではないので、これが良いか悪いかを教えることができません。これが理にかなっているかどうか。U16を使用していることは分かります。max_lengthを取得しているのは、U16の2の16乗が65536だからです。明らかに符号なし整数の最大長は2のn乗マイナス1です。
小さなmax_length文字列チェックを行い、それを読み込んで、バッファから16を読み取ります。私には悪いところが分からないんです。コレクションを行い、バイトをイテレータにして、allowスペースを行います。この部分については確信がありません。これが彼らが話している悪い部分、つまりプロトコルを通過するがレンジ外のものに反応しないサニタイゼーションの部分だと思います。だからサニタイゼーションが悪いのかもしれません。サニタイゼーションエラーにすべきであって、「大丈夫、すべて問題ない」にすべきではないのかもしれません。
長さ検証が完全に無意味である理由を指摘された方がいます。絶対にその通りです。なぜ長さ検証が完全に無意味かというと、U16を作成してからU16を読み取るからです。U16はU16の最大サイズより大きくなることは決してありません。これは200 IQの指摘ですね。その人は絶対に正しいです。長さチェックは宇宙で最も冗長なコードです。
サニタイゼーションも疑わしいですね。私たちも両方ともこれを疑わしく見えるコードの断片として指摘しましたが、これが疑わしいかどうかは分かりません。プロトコルが何なのか分からないので、これが疑わしいかどうか分からないんです。これは実際に完全に合理的かもしれません。
AI生成コードの根本的な問題
これについて本当に良い指摘もあります。私がこの種のものを見る時はいつも思うのですが、ウェブサイトを見てこのようなものがあるとき、AIコードエディタがここで見せびらかしているのはコード自体ではなく、エージェントがコードとどのように相互作用したかということです。
非常にジュニアなコード。ジュニアっぽいという正しい言葉かどうかも確信がありません。私たちは「ジュニアっぽい」という用語を使いますが、それが正しい言い方かどうか分からないんです。私がジュニアだった時、このコードを書いたでしょうか？おそらく書かなかったでしょう。
無意味な長さ検証。まず、AIが追加を提案したコードの部分に焦点を当てましょう。既存のread_16以外のすべての行について。
これは正しいという意味で、値65535は実際にU16型の最大数です。しかし、人間のプログラマーはおそらく同等の定数U16::MAXを使用したでしょう。とにかく、この方がずっと良く見えます。代わりに、私たちは不要なコメントを作っていたでしょう。
まあ、このコメントはとにかく愚かです。コメントは最初から必要ありませんでした。しかし、これはU16が含むことができる最大値です。つまり、この条件は決して真になることはありません。Clippyのようなより良いツールは、到達不可能なコードによるコンパイラ警告を指摘して警告するでしょう。
より良いAIツールへの提案
ここで、AIは最良の場合で無意味なコードを生成し、到達不可能なコードによるコンパイラ警告を実際に生成しました。有用なAI駆動開発ツールは、最大文字列長検証を追加する提案に反対し、「文字列長はU16から読み取られるため、文字列は既に最大でこの長さまでしかなれません。このままで大丈夫ですか、それともより低い制限を強制したいですか？」のような説明をしたでしょう。
実際、私はこの発言に同意しません。彼の問題はCursorとは何の関係もなく、すべてAI生成の問題なんです。これはCursorの問題ではなく、AI生成の問題です。生成するコードが大きく不快であることに同意しますし、コメントやそのすべてが嫌いですが、これらはすべて悪いものです。
しかし、プロンプトを見てください。プロンプトは「プロトコルバージョニングのヘッダーを追加し、複数のバージョンを処理する」でした。待って、どこに「最大文字列のためのサニタイゼーション検証を追加」というのがあったと思うんですが。
実際、それはまさにあなたが言ったことを正確に行ったんです。「最大文字列長の検証を追加」というのを文字通り正確にやったんです。答えが良いと言っているわけではありません。ただ、指定されたことに対して正確だったと言っているんです。
彼らが指摘すべきことは、Cursorがここで悪いプロンプトをしたということです。結果が悪かったのではなく、結果は完璧でした。サニタイゼーションルールを与えなかったので、それは空白をアスキーで処理するだけです。良い答えです。
実際、これはかなり疑わしいのは、bが32より大きく、小文字のzがどこにあるかより小さい場合を持つべきだったということです。小文字のzがどこにあるか忘れましたが、おそらく128のあたりでしょう。本当にそのあたりのどこかに行くべきでした。しかし、繰り返しになりますが、悪いプロンプティングです。実際にサニタイゼーションルールも与えませんでした。
サニタイゼーションコードの問題
疑わしいサニタイゼーションを続けてみましょう。
知らない人のために説明すると、32は、えーと、31が改行文字だと思います。アスキー表で32から物事が変わり始めます。32を見ると、スペースに入ります。その前のすべて、改行、スペース、backspaceやtabなど、ここには使いたくない文字がたくさんあります。8かどこかのtabのような、ここには使いたい文字がいくつかありますが、tabは9です。sinやnack、canadaのような文字は使うことはないでしょう。誰がcanadaを使いますか？誰も51番目の州さえ好きではありません。
コードは主にその通りのことをしています。数字はコメントでリストされている文字に対応しています。コードがバイトで動作しているため、文字ではなく、ちょっとした懸念があります。しかし、UTF-8はアスキーのスーパーセットなので、これは十分に近いです。
私の主な懸念は、これがあまり良いコードではないということです。悪いコードでもありません。悪いコードですか？これがルールだった場合、このコードは悪いですか？32以上、9または10または13と同等の場合。これは悪いコードですか？
いえ、全然そうは思いません。これはおそらく、素晴らしくもひどくもないコードです。他にどうやってやりますか？余分な割り当てが真実です。ヒープに新しいベクターを割り当てています。
より良い実装方法の提案
最初に、私が追加したコードは不要な割り当てを含んでいることについて話しましょう。bytes.retainを使用してインプレース操作に簡単に変更できます。これによりスペース、タブ、改行文字を許可します。retainについて知りませんでした。私もRustエキスパートではありません。
また、これを生成した人もおそらくRustエキスパートではないと思うので、これはおそらく問題ないでしょう。これは「私たちがコードを生成したことを示しただけ」というような瞬間の一つだと思います。
また、Rustは多くのLLMで貧弱な能力を持っていると思います。言語がたくさん変更され、多くの新しいインターフェースがかなり早く追加されるからです。LLMは多くの場合、1年半から2年遅れているので、新しいものが入ってくると、おそらく最新ではなく、今日ではなく、しばらく前から最新なのでしょう。
二番目に、述語が10の代わりに文字リテラルを使用した場合、コメントは不要になります。はい、良い読みやすさです。実際、私はこれの方が読みにくいと思いますが、残りはこれが理にかなっています。タブ、改行、またはキャリッジリターンの場合、問題ありません。
これはおそらく少し混乱しそうです。「スペース以上」って何を意味するのでしょうか？アスキー表でスペースから始まるという意味ですが、今は意味論について議論しているだけなので、どうでもいいです。しかし、この方が良く見えることには同意します。
引数として、コードはこのようなリテラルを全く使わず、代わりにRust標準ライブラリが提供する関数を使うべきです。asky::is_control_character、asky::is_whitespace。ああ、それは非常に良いですね。美しいです。
しかし、これはこのサニタイゼーションが正しいかどうかが明確でないという第二の懸念に近づけます。128以上のすべてのアスキー範囲があるからです。
例えば、ホワイトスペース文字とは正確に何でしょうか？提案されたコードはキャリッジリターンを許可しますが、一部の非Windows プログラムはこれを通常の制御文字と見なします。上記のu8::is_ascii_whitespace関数は、フォームフィード\fをホワイトスペース文字として扱います。他のプログラムには垂直タブ\vをホワイトスペースとして含むものもあります。
削除はどうでしょうか？これはすべての合理的な定義により明らかに制御文字ですが、アスキー範囲の最後に位置しています。これも除外すべきではないでしょうか？
非アスキーホワイトスペースや制御文字はどうでしょうか？バイトは直後にUTF-8としてデコードされ、段落分離符号、行間注釈、双方向分離符号など、さまざまなUnicode固有の制御文字があります。引数として、Unicode FE FF（ゼロ幅ノーブレークスペースバイトオーダーマーク）は先頭位置の制御文字です。
ここには二つのことがあります。一つは、この人がこれらすべてのことについて絶対に正しいということです。私はこれが正しいチームにいます。Lucaが殺しています。
また、私の唯一の反論は、そもそもサニタイゼーションが何であるかを定義しなかったことです。プロトコルサニタイゼーションを行っている場合、何をしているかも知る必要があります。誰かがこれをプロトコルサニタイゼーションとして手渡した場合、この人が正しいと仮定しなければなりません。これが私たちの要件である場合、それが何であるかを再確認したいでしょう。私がそれが正しいかどうかを言うことはできません。人間が知る必要があります。それから逃れることはできません。
プロトコル実装における問題
これも混乱しているように見えます。彼は上でアスキーホワイトスペースを使うべきだと言ったのに、その直後に「このフォームフィード文字はホワイトスペースと見なされます」と言っています。それは上のホワイトスペースを使うことでフィードフィード文字が許可されるということでしょうか？フォームフィード文字を使いたくない場合はどうでしょうか？
ここで答えられるべき多くの質問があり、プロトコル実装者がおそらく理解すべきものです。
ネットワークストリームからデータを読み取る低レベル関数でサニタイゼーションが適切かどうかについても多くの質問があります。多くのアプリケーションは、文字列が特定のコンテキスト（HTTPヘッダーやターミナル出力など）で使用されない限り、そのような詳細について不可知論的になることができます。また、一般的にセキュリティへの影響もありません。
先制的に制御文字を除去することは、すべての引用符を削除してSQLインジェクションを阻止しようとするのと同じ感覚です。私が同じようなことをしているなら、これらの文字が含まれている場合はプロトコルエラー、無効な文字のようなエラーにすべきだと思います。少なくとも私にはそれがより合理的に見えます。これらの文字がないことを期待している場合、おそらくそれらを取り除くべきではありません。奇妙に感じます。
これは正しいかもしれませんが、アプリケーションを破壊することもあります。ここでの結果は、read_stringとwrite_string関数がもはや互いに反映しなくなり、良いテストスイートが失敗する原因となることです。
有用なAI駆動開発ツールは単一の解決策を選ぶのではなく、問題空間を説明してプログラマーに情報に基づいた選択をさせるでしょう。
AIに対する過度な期待
AIに対して過度に多くを求めていると思います。AIの問題は、これが目標ではないということです。Cursorの提案を使って「サニタイゼーションを追加する必要があります。どのような技術を使うべきで、なぜそれらを使うべきなのですか？」と言い、その後「これらは最良のものですか？」と聞くべきでした。
これがAIを使う方法です。本当に愚かな問題解決ツールとして扱わなければなりません。ステートレスな解決策なので、解決策を思いついた後でも、この解決策が正しいかどうか尋ねる必要があります。なぜなら、多くの場合「いや、今作ったんだ。全然正しくない。申し訳ない、完全に申し訳ない。その関数が存在するとさえ思わなかった」と言うからです。
これはステートレスな愚かな解決策で、推論も思考もしません。人々は彼らが思考し推論すると思い続けていますが、そうではありません。推論しないし、思考もしません。やめてください。
推論とは文字通り「良いアイデアのセットを与えてください。さあ、戻って、あなたが言ったことを何度も何度もフィードしましょう」ということです。これがここで起こっていることです。
プログラミングにおける意思決定の重要性
プログラミングは意思決定についてです。記事のこの時点で、私たちは8行のdiffについて800語近くの詳細な分析をしています。この単純な例にも多くの隠れた複雑さがあります。AIは解決策を提案しましたが、追加されたコードは議論の余地があるほど無意味か間違っています。考慮すべき巨大な決定空間がありますが、AIツールはその決定に対する合理的な根拠なしに一連の決定を選ばなければなりません。
実際、これはLLMがコーディングにひどい理由について私が非常に明らかだと感じる一つのことに帰結します。彼らは即座の問題を解決するのです。それがコーディングで彼らを悪くしているのです。
私が意味するのは、私たちがしばらくAIにコードを書かせた時、Devinにしばらくコードを書かせた時に見直したコードのことです。彼らがClaude 3.5やOpenAIのどちらを使っているかは分かりませんし、どちらを使っているかは本当に問題ではありません。どれもまったく同じことをします。
それはコード全体にベクトル操作をインライン化しました。ベクトル加算もベクトル乗算もありませんでした。ベクトルを作り上げて、すべての距離計算、すべての平方根、すべての数学操作をその上でインラインで、あらゆる場所で、何度も何度も行いました。
私がAIを使うたびに、まったく同じことを見ます。一つの特異な空間で半分複雑なことをして、それを何度も何度も何度も繰り返すのです。
私が最近行ったことで、オフラインで作成している小さなゲームがあります（まだ見てもらっていませんが）、サーバーから来るデータに基づいて現在のプレイヤーを選択します。現在のプレイヤーを選択するあらゆる場所で、計算を再実行し、この2を法とする計算を再実行し、この配列インデックス作成などを使ったこのような法数学を再実行して、現在のプレイヤーを取得し、どこにも保存しません。代わりに、何度も何度もインライン化します。
新しいプロンプトが入るたびに「ああ、あの余分な次のことができる」と言って、再び再実行し、次のものに進み「ああ、次のことができる。また再実行できる」と言うからです。同じことの一連を続けます。
すべてのLLMの間で異なるトークン化ではありません。彼らの出力について話しているのです。彼らはすべて同じことをします。反復的に物事を解決するにつれて、関数の背後にあるべき複雑なコードを繰り返すということです。その決定を下すことができません。その決定をすることはありません。その決定を下すことは決してありません。なぜなら、それはそれができることではないからです。
経験豊富なプログラマーとAIの違い
優秀なプログラマーは提案された変更を見て、問題に気づき、逆方向に作業することができます。例えば、無意味な文字列長検証を見て、代わりにより低い制限を選ぶか、AI提案をスキップすることを決定します。しかし、一般的にそれはコードを自分で書くよりもより多くの努力を要し、多くのプログラマーはおそらくもっと後まで問題に気づかないかもしれません。
プログラミングは多くの決定、大小の決定についてです。アーキテクチャ決定、データ検証決定、ボタンの色の決定。いくつかの決定は重要でなく、安全にアウトソースできます。ソフトウェア開発にはたくさんのボイラープレートが関与していて、ボイラープレート重いコードを書くことはほぼゼロの決定を含みます。
しかし、他の決定は重要です。この種の作業では、コードがどれほど速く書かれたり生成されたりするかは重要ではありません。私たちが十分良い決定に効率的に到達することが重要です。
ここでAI駆動ツールが助けになり得るのは、重要でない決定をほとんどの場合正しく独立して解決でき、相関関係として、追加のレビューが必要な決定にフラグを立てることができ、良い決定を下すために必要なコンテキストを提供できる場合です。
このためにどれくらい離れていると思いますか？彼はAIに責任を持ってもらうことを求めています。あなたが仕事で感じるような責任感、他の人と将来の自分に対して、維持したいと思うコードを書く責任感を知っていますか？AIが責任を感じることができるかどうか分からません。
AIは比較的無限の速度でコードを書くことができるので、おそらく責任を感じる必要がないでしょう。将来の栄光のAI自慰日は、すべてのコードが単に置換可能なコードになる時です。コードはもはやどんな種類の堀でもありません。単に受け取って、出して、すべてを置き換えることができるのです。
私自身は同僚と将来の自分に対する責任を感じているため、特定のことをしないことがあります。しかし、行列乗算になると、それは単に存在しません。
しかし、2025年5月の時点では、それは起こっていません。この例では、AIは私たちにより良い決定を下すためのコンテキストを与えていない最適でない決定を下しています。
でも、それは良いことだと思います。それがポイント全体ではないでしょうか？私とLucas（またはLuca、名前だけからは分からないので、Lucasだと仮定します）のようなチームにいると思います。私たちは両方とも、コードを生成するたびに、本当に良いコードにしたい場合は多くの修正が伴うことに同意しています。
しかし、決定を下さなければならないのはあなたです。私がエージェントを使う時はいつでも、エージェントを本当に、本当に速いオートコンプリートだと考えています。オートコンプリートが良いということではありません。ただ、私のためにオートコンプリートしただけで、今私はオートコンプリートを修正しなければならないということです。
ちなみに、私はそれほど大きなAI愛好家ではありません。今でも分かっているはずですが、私はそれほど大きなAI愛好家ではありません。
Cursor自体の評価
これは私によって選別されていない例です。これはCursorが潜在的な顧客に最初に見せるもので、AI駆動ツールがどれほど良いとされているかを実証するためのものです。
そして私は、これは本当に良いものだと主張します。彼らは正確になぜそれが良いのかを示しています。エディタ内で提案をインラインで作成したのです。
知らない人のために説明すると、Cursorを使ってやることはこのようなことです。ここに行って、このようなことをハイライトして、Ctrl+Kを押して「これを現代的なGoで書き直してもらえますか？」と言えます。それが何を意味するのか正直分からないのですが。
「slices.containを使う代わりに反復的に書いてもらえますか？」それはなかなか良いですよね。Ctrl+Kは非常にクールな小さなものです。それはとても楽しい小さなアイテムです。
これがここで示されているものです。文字通りコードに入って、特定のセクションをハイライトして、実行させることができるのです。それは素晴らしいツールです。正しいツールだと言っているわけではありません。素晴らしいツールです。二つの非常に異なることです。
これは選別された例ではありません。これはCursorが潜在的な顧客に最初に見せるもので、AI駆動ツールがどれほど良いとされているかを実証するためのものです。この例はおそらくCursorマーケティングチームによって選別されて、可能な限り最高の最良を宣伝するためのものです。私は彼らが良い仕事をしたと感じています。
AI駆動ツールが無意味なコードで負担をかけ、間違った決定によりコードを破壊し、8行のdiffに800語のレビューと議論が必要なほど微妙に間違った変更を行うのであれば、そのツールは誰も特別に生産的にしていません。そうすると、このツールは生産性にとってネットネガティブです。
AIツール使用に対する個人的見解
これが一般的に私がたくさんのAIを使わない理由です。私は見たくないものや気にしないもの、フロントエンドの材料を生成するために使います。私は生成して「最も平均的なウェブサイトのように見えても気にしない。試そうとさえしていない。気にしない。バイブコーディングして、修正が必要なバグを修正するだけだ。CSSを見たくない。それと何もしたくない」と言います。
私がこれを見る時、そのように感じます。彼が言っていることは正しくもあり間違ってもいると思います。コードを生成するたびに、それが気にかけているコードに関するもので、それを再作業して正しく機能させなければならない場合、おそらく最初から書く習熟を得るべきです。生成してから完全に書き直すことを続ける理由はありません。
それがどう書き直すべきかを考える助けになるのであれば、それは悪いことではありません。多分それは一部の人にとって良い方法です。私は手で考えるのが好きです。一部の人は、コードを取ってホワイトボードに行き、すべてのボックスと矢印を描き出すのが好きで、いつも「一日中コードを書く人を理解できない。80%の時間は考えているべきだ」と言います。私は「ごめん、私は考えない」と言います。
それは私のやり方ではありません。私は手で考えます。そこに入って、書いて、書いて、書いて、書いて、「ああ、これが好きだ。これは好きじゃない。うわあ、そんなことは考えたこともなかった。そのことを理解したことは一度もなかった。ああ、この部分は好きだ。この部分は本当に幸せな気分にしてくれる。書いたものを削除して、これが私の新しいお気に入りのもの。これが私の今のアイデンティティで、私が書いたもので、美しくて素晴らしい」という感じです。
それが私の考え方です。誰もがそのように考えるわけではありません。紙に書いたりする人もいます。それは私には狂気に見えますが、デザインと呼ばれることは理解しています。それは私のアイデンティティではありませんが、私は手でデザインします。紙に書いてデザインしません。私は実際にものを構築するときにすべてのエッジケースを発見します。なぜなら、すべてのエッジケースを知ることはできないからです。実際にそのクソものを構築するまでエッジケースを知らないのです。なぜなら、構築するもののほとんどは、すべての問題を知らないからです。そして、それを行い、発見する瞬間に、それは以前に思っていたすべてを無効にする可能性があるか、その半分を無効にする可能性があります。
あらゆる創造において真実。フィードバックループが不可欠。Jeremy、分かりますよね。
だから、生成されたコードを使って解決策を思いつく人は悪いのでしょうか？いえ、唯一本当に悪い人は、バイブコーディングしてそれだけの人です。彼らは大規模なセキュリティ問題、大規模なバグを導入し、LLMの良さに縛られてしまうでしょう。それが唯一の本当の危険です。あなたが純粋にバイブコーディングしたものをリリースし、自分の人生にどれほどの恐ろしさが待っているかを理解していないことです。
私は本当にセキュリティについて心配しています。私は実際にこれをTwitterに投稿しました。ここに写真を保存したと思います。面白いからです。
「XDG openを使えますか？」パスキーが必要なようです。「セッションデータは安全ですか？つまり、誰かのユーザー名とIDを知っていれば、それを私のセッションに追加してなりすますことができますか？言い換えれば、ユーザーのなりすましを防ぐためにデータに署名したり、JWTのようなものを作成したりできますか？」
それは非常に良いセキュリティの懸念です。現在、セッションデータは改ざんに対して暗号学的に安全ではありません。これを改善しましょう。
私はCursorでウェブサイトを構築し、文字通りクッキーを編集できるログインを作成しました。セッションを編集して、任意のTwitchユーザー名を入力すると「あなたは今その人です。それがあなたです。あなたはその人です」のようになります。それは恐ろしいことです。
バイブコーディングしている人の数を考えてください。おそらくそれを持っているでしょう。「良いキャッチ」「基本的な」のように。データに署名すべきかもしれないと提案しなければなりません。データに署名することが何であるかも知らなければ、あなたは破滅します。
私がそれを知っているのは、JWTが存在する前にJWTを書いたからです。自分のログインを転がし、自分のパスワードハッシュを転がし、そのすべてのものを転がしました。これは私たちの未来にとって実際に恐ろしいことです。これらのことを知らなければなりません。
結論と個人的立場
実際、私はこの記事が本当に好きでした。彼は文字通り、コードにLLMのみに依存することが危険である理由すべてを指摘しました。これは素晴らしい記事でした。唯一の問題はフレーミングです。フレーミングは、Cursorがネットネガティブであるということでした。Cursorは実際にはこれらのツールとのかなり急進的な統合のセットです。本当の問題はClaudeやOpenAIです。
私はあなたのチームにいます、Lucas。あなたは素晴らしいポイントを作りました。それを愛しました。
今、私は本当に奇妙な気分です。なぜなら、インターネット上でみんなが私をアンチAIの人として見ているからです。それなのに、ここで私は擁護しています。これは何ですか？私はアンチAIの人なのか、それともAIの人なのか？私はAIブロ（bro）ではありません。それは真実だと知っています。私はAIブロではありません。
AI ブルーマー。私はAIブルーマーです。彼らをブルーマーと呼ぶこのアイデアが大好きです。
起こらない、「ブー」。
これはどのように起こったのでしょうか？何が起こったのでしょうか？私はただの人で、何度も何度も同じことではない、ニュアンスのある意見を持っているだけです。それが私をみんなに嫌われる理由になるのでしょうか？超親AI的なみんなは常にTwitterで私に意地悪なことを言い、アンチAIのみんなは常に私をAIボーイと呼ぶからです。
私はただのように感じています。みんなをどのように失ったのでしょうか？どのようにしてみんなを失ったのでしょうか？
コメント