同じことを感じてるけど、Claudeだけは使いやすい。他のモデルは使うのが辛い。

うん、最近はAIに対して懐疑的な気持ちが強いけど、それでもワークフローにAIを取り入れようとしてる。実際、楽しんでるわけじゃなくて、やりたいことを説明するのが難しくて、実際にやるよりも大変だと感じてる。でも、これはなくならないし、ある意味「未来」だってことは明らかだと思う。新しい道具を学んでおく方が、知らないままでいるよりいいと思う。ただ、まだこの分野のツールは発展途上だと思うから、面白いUXが出てくるのを楽しみにしてる。

私にとっての疑問は、専門家が関与しない場合、どの時点でそれをやるのが合理的だと感じるかってことかな？編集として、いくつかのプロンプトを読んだ後、非専門家がそれらのプロンプトを考えつく可能性はどれくらいあるのか？本当に興味深いのは、AIが実際にプロンプトを生成できるかどうかだと思う。

真面目な話、2ヶ月前（2025年1月）には、私（@kentonv）も同意していたと思います。「私（@kentonv）」って何を意味してるのか混乱してるんだけど、kentonvは別のユーザーだよね。[0] これはあなたの別アカウントってこと？それとも誤字/誤解？ 編集: あなたの投稿のほとんどがREADMEを引用していることに気づいた。明確にするために、>や*の文字を使うことを考えてみて。 [0] https://news.ycombinator.com/user?id=kentonv

一方で、スキルのあるエンジニアがこれらのツールを正しく使ってプロンプトを与えれば、LLMがそういうコードを生成できると思ってる。OAuthは新しいものじゃないし、公共プロジェクトからトレーニングデータとして盗める動作例がたくさんあるし、ほとんどのユースケースやニーズに合ったさまざまな言語もある。でも、私が懐疑的なのは、これが全く新しいもの、つまり研究や材料科学、経済、発明などに繋がるっていう主張が続いていること。これは、実際にその瞬間に生成している情報源から「リアルタイム」で学ぶ必要があるからで、文脈のない数十年分のStack Overflowの回答では無理なんだよね。そういう話は何年もされてきたけど、具体的に選ばれた例以外に証拠はないし、しかもそれはかなり制御された環境からのものが多い。私は、優秀なエンジニアがいれば、これらのツールを使って過去のデータセットから「新しい」コードを生成できるとは疑っていない。ただ、環境的にも社会的にもそのコストを考えると、これらのツールの有用性には疑問を持ち続けている。

もう一度、コミット履歴を確認してみて。特に初期のコミットを見れば、どうなったかが分かるよ。履歴の最初のページへの直接リンク: https://github.com/cloudflare/workers-oauth-provider/commits... たくさんの明確で具体的なプロンプトがあって、直接的な指示もある。最初のページのいくつかの例: https://github.com/cloudflare/workers-oauth-provider/commit/... https://github.com/cloudflare/workers-oauth-provider/commit/...

すべての行は、関連するRFCと照らし合わせて、以前にそのRFCに関わったセキュリティ専門家によって徹底的にレビューされました。これはコーディングのようだけど、もっと遅いね。

そうだね、YouTubeにはティックタックトーやフライングシミュレーターをLLMで作ってる人たちの例がたくさんあるよね。それが何を証明するの？OAuthはもう日常的なものだし。

百万ドルの（文字通りかもしれない）質問は、@kentonvがAIの助けなしにこのライブラリをもっと早く書けたかどうかだね。私の考えでは、答えは明らかに「ノー」だと思う。少なくとも、今持っているツールで達成できることを考えると、今後3〜6ヶ月でAIを使って新しいソリューションを完全にコーディングするのが、効果的に使えば絶対に早くなると思う。たくさんの作業が必要だと思うけど、しっかり文書化され、構造化されたコードベースで、迅速なフィードバックループ（良いリンティングやユニットテストなど）があれば、そこに向かって進んでいると思う。

「ソフトウェアエンジニアが追い出されるわけではなく…むしろ経験豊富なエンジニアがAIを使ってコードの一部を生成し、それを丁寧にレビューしてテストしている。」 でも、もし最後に20個のkentonvの代わりに2個だけ必要だったらどうする？他の18個を占める新しいタスクが見つかると思う？それが問題だと思う。著者はこの場合、かなり技術的なプロジェクトを実装してるけど、ルーチンのLoBアプリ開発はどうなの？

100万ドルの質問は、モデルがコーディングするスピードでレビューできるかどうかではなく、レビューだけで全てをキャッチできるかどうかだよ。もしロボットが超高速で車を組み立てるけど、時々ボルトをずらしてしまうとしたら、唯一の安全策がその後の目視検査だけなら、いくつかの欠陥が組み立てラインを通過してしまうことになる。人間のコーダーは、組み立て中に考えることで多くのバグを防いでるんだ。

「ソフトウェアエンジニアが追い出されるわけではなく…むしろ経験豊富なエンジニアがAIを使ってコードの一部を生成し、それを丁寧にレビューしてテストしている。」 でも、もし最後に20個のkentonvの代わりに2個だけ必要だったらどうする？他の18個を占める新しいタスクが見つかると思う？それが問題だと思う。著者はこの場合、かなり技術的なプロジェクトを実装してるけど、ルーチンのLoBアプリ開発はどうなの？

ソフトウェアエンジニアが追い出されて、ビジネスパーソンがボタンを押すだけで完全に機能するアプリができるってのは（LinkedInやXでの多くの幻想で起きていること）、「ビジネスパーソンがボタンを押す」アプローチは、品質を下げてもコストを削減するために追求されるっていう「エンシティフィケーション」の理論がある。ただし、そのアプローチが品質を損なうほどになってビジネスモデルを崩壊させるまでは誰もその品質の妥協の許容度がどれくらいあるかは分からない。

経験豊富なエンジニアがAIを使ってコードの一部を生成し、それを丹念にレビューしてテストしている。じゃあ、ジュニア開発者を全部AIに置き換えたら、経験豊富なエンジニアはどこから出てくるの？クラスを書くという地味な作業から得られるメリットはたくさんあるよ。たとえそれがその時は単なる雑用に見えてもね。

AIは重い作業をこなしたり、知識を引き出すのには素晴らしいけど、すべての決定を下した後には、自分で重要なコードを書くことができるんだ。

AIを使ってライブラリを作るのに数日かかった。手作業だと数週間、場合によっては数ヶ月かかると思う。でも、これはかなり理想的なユースケースだね。よく知られた標準を、明確なAPI仕様のあるプラットフォームで実装するというものだから。AIを使ってWorkers Runtime自体に変更を加えようとしたときは、あまり時間が節約できたとは感じなかった。ただ、私ほどコードベースを知らない人たちは、かなり助けられたって報告してる。私は他の人の複雑なコードベースに飛び込むとき、AIがすごく役立つと感じてる。今はそれができるようになったし、AIがすぐに道を見つけてくれるから、以前は飛び込むのを避けて、チームの誰かに変更を頼むことが多かったんだ。

「古いやり方でコードを書くよりも、ずっと認知的に負担が大きい」 どうやって使ってるの？最近は自分のエージェント（最近はDevstralを使ってる）と「ペアプログラミング」をしてるんだけど、生成されたコードを全部打ち込むよりもレビューがずっと楽だよ、少なくとも時間的にはね。ちょっとだけバイブコーディングも試したけど、その場合は同意するよ。何かをレビューしたい時にコンテキストがないからね。基本的に、プロジェクトが最初からバイブコーディングされてると、コードベースに入るのがすごく難しい。でも、LLMとペアプログラミングする時は、すでにコンテキストができてて、どうしたいかも分かってるから、ペアプログラムされたコードのレビューはバイブコーディングされたコードのレビューよりずっと早く進むよ。

2. 昔ながらの方法でコードを書くよりも、ずっと認知的に負担が大きいと思う。面白いことに、私は真逆だと感じてる。細かいことを一つ一つ考える時間を無駄にしなくて済むから、すごく楽になった。アーキテクチャや高レベルの変更に集中できるようになったんだ。

これ、俺の経験や話した人たちの意見と一致してる。LLMを使ったコーディングは、物事をすごく早く進める方法だけど、精神的なコストやエネルギーはかなり増えるよね。不思議なことに。

同じく。でも、個人的には真っ白なファイルや関数から始めるより、最後の部分をやる方がずっと楽だと思うから、私には合ってる。

「途中まではうまくいくけど、そこからめっちゃ苦労する。」 会話を最初からやり直してみて。何か間違ったことがあったら、最初から始めるべきだと思う。メッセージのチェーンや会話の中でのどんなミスも、その後の出力をすぐに悪化させる気がするんだよね。「修正」しようとしても。だから、どこかで間違いがあったら、最初のメッセージに戻って、同じ間違いを繰り返さないようにプロンプトを明確に調整して、そこから会話を再生成する必要がある。

これが、私がこれらのツールには実際の理解がないと思う理由で、代わりに理解できないほど大きなパターン認識データのプールから新たな出力を生成しているんだと思う。

163行から172行のコメントには、完全に間違っているか、または非常にA/S依存の主張が含まれていて、この投稿の妥当性を疑問視せざるを得ない。A/Sが大量のトレーニングデータに基づいて擬似生成される可能性はあるけど、各実装は非常に特定のデザイン選択をする。例えば、Auth0のA/Sは、ネットワーク条件を考慮してリフレッシュトークングラントフローの範囲内で「余裕」の概念を許可するけど、他のA/S実装はこの点でずっと厳格かもしれない。私の言いたいことは、RFCがあって（想像の余地がたくさんある）いくつかのOSS実装をトレーニングに使ったとしても、各実装には特定の選択肢が多すぎて、LLMが何かをまとめるのは簡単じゃないってこと。自分で書くのと同じくらいの監視努力が必要になると思う。

生産の幻想なのか、それとも実際に生産レベルのシステムを作るのに長期的に工数を節約できるのか、研究結果を待ってるところだよ。

同じく。

それはないと思う。Vibecodingは今のところ、リスクが低いものに最適だよ。GUIを作ったり、CRUDの作業をしたり、ちょっとした一回限りのアプリを作ったりね。そこにはたくさんの使い道があるし、以前はその能力がなかった人たちに力を与えているんだ。これはvibecodingじゃなくて、LLMを使ったコーディングだよ。

自分で使い捨てのスクリプトを作ると、使ってるツールに対する親しみが増すのが一番の利点だね。それに、実際にはそのスクリプトを捨ててるわけじゃないし。俺のファイルシステムやシェル履歴には、過去にどうやってタスクをやったかをチェックするためのランダムなスクリプトが転がってるよ。