CloudflareがOAuthをClaudeで作ってしまった 全プロンプトも公開！

まじでこの記事出してくれて、特にこのコメント欄に感謝！すげー役に立ったし洞察深かったわ。他のコメント見てると、これってほんとRorschachテスト（心理テスト）みたいに人によって見え方違うんだなーって面白く（でも予想通りに）思った。でも、著者の経験はAIコーディングのメリット・デメリットを客観的に示してて良かったよ。AIの出力レビューするのって、自分で書くより精神的に疲れる？他の人も言ってたけど、レビューの方が疲れる派なんだよね。人間相手のレビューはやりがいあるけど、AIだとそうでもないから、余計疲れる気がするんだ。著者さんがレビューについてどう感じたか聞きたいな。

そうだけど、考える速さと書く速さ、どっちが速いの？「ストーリーカード読んで、これならコードとテストで1時間で終わるな」って思ったこと、何度ある？俺の経験だと、たいていAIはコード書きを10分以内に終わらせちゃうんだよね。残りの50分でコードレビューしたり、必要な調整したり、別のタスクに移ったりできる。AI使う方が全然速いじゃん？

まさにこれこそ、AI支援コーディングが進む方向だと思うわ。エンジニアがリストラされて、ビジネスの人がボタンいくつか押したらアプリ完成！ってSFじゃなくてさ（LinkedInとかXで fantasie してる人は多いけど）。そうじゃなくて、経験豊富なエンジニアがAIでコードの断片を生成して、それを細かくレビューしてテストする、って方向。100万ドル（マジでそれくらいの価値かも）の疑問はさ、@kentonvさんはAI無しでこのライブラリ、もっと速く書けたのかな？ってことだよね。

＞ Not software engineers being kicked out … but rather experienced engineers using AI to generate bits of code and then meticulously reviewing and testing them.
でもさ、最後にkentonvさんが20人じゃなくて2人で済むとしたら？残りの18人分の新しいタスクが十分に見つかるって仮定する？そこが問題だと思うんだよね。それに著者はかなり技術的なプロジェクトをやってるけど、定型的なLoB appの開発だとどうなる？

＞ But what if you only need 2 kentonv’s instead of 20 at the end? Do you assume we’ll find enough new tasks that will occupy the other 18? I think that’s the question.
たぶん行きつく先はこれだよ。AIが全てのエンジニアを置き換えるとは思わないけど、必要とされるエンジニアの数がずっと少なくなるのは間違いないと思う。これって、俺のキャリアのsysadminの世界で起きたことと似てるんだ。ClickOpsからcloud & Infrastructure as Codeに全部移行した時。前は10人のsysadminが必要だったインフラ管理が、今は1人か2人のインフラ担当で済むようになった。仕事自体はあるけど、必要とされる量は劇的に減ったんだ。今の俺一人でやってる仕事、前ならAWS/Ansible/Terraformとか無しだとチーム全体が必要だったもん。

今、コスト的にエンジニアに作らせるほどじゃないから手付かずになってるソフトウェア開発の領域って、めちゃくちゃデカいと思うんだ。でも、エンジニアが何かを作るのにかかる時間が減れば、コストに見合うようになることがすごく増える。ニッチなユースケース考えてみてよ。どの会社にも独自のプロセスやワークフローがあるじゃん。ある会社の会計士と別の会社の会計士を比べてみて――仕事の大部分は同じだけど、結構違う部分が必ずある。そういうオーダーメイドのプロセスって、既存の会計ソフトじゃ会社ごとのカスタム機能を追加できないから、手作業になることが多いんだ。でも、それができたら？エンジニアがAIと組んで、顧客ごとの機能を以前より10倍速く作れたら？そしたら、実際にそういう機能を作る意味が出てきて、各会社の会計部門の生産性を上げられるようになる。エンジニアの需要が下がるか上がるかは断言できない。断言するフリはしないよ。でも、今後エンジニアがもっと増える可能性も十分見える気がするんだ！

AIを使ってライブラリを作るのに数日かかったよ。手書きだったら数週間、もしかしたら数ヶ月かかっただろうね。とはいえ、これはすごく理想的なケースだった：よく知られた標準を、よく知られたプラットフォーム上で、明確なAPI仕様に基づいて実装するっていうね。 Workers Runtime自体に変更を加えるのにAIを使った時は、正直そんなに時間は節約できなかったかな。でも、僕ほどコードベースを知らない人たちは、AIがすごく助けになったって言ってたよ。あと、他の人の複雑なコードベースに飛び込む時に、AIがめちゃくちゃ役に立つって発見したんだ。AIが手早く全体像を掴むのを手伝ってくれるから、今はそういうのも平気になった。前は避けてて、チームの誰かに変更頼もうとしてたんだけどね。

生産性が上がれば、その分チャンスも増えるんだよ。「よし、ソフトウェアでやるべきことは全部やり遂げたから、もうエンジニアはいらないな」なんて時代は来ない（少なくともすぐには）って。

でも、「人間がソフトウェアエンジニアリングのプロセスに経済的な価値を提供できなくなる」時代は、すぐそこに来るかもしれないね。もしAIが年間1万ドルで、人間が1年かけてやることをできたとしたら（今はできないけど）、なんで人間を6桁の給料や、たとえ2万ドルでも雇うの？誰も「やることがなくなる」から人間が職を失うなんて言ってないんだ。「AIが超高性能で超安くなるから、人間が経済的な価値をゼロしか提供できなくなる」ってことなんだよ。

それ、あと数年で巨大隕石が地球に衝突して人類文明が終わるかもしれない、みたいな話だよ。年間20万ドルのソフトウェアエンジニアの仕事が、年間1万ドルで完全に代替できる魔法のAIがあるなら、ぜひ見てみたいね。それが実現するまでは、この議論全体がサイエンスフィクションだわ。

LLMは、エンジニアを雇う予算がない会社じゃなくて、エンジニアがもっと速く、たくさんの仕事をするためのツールって感じ。つまり、エンジニアの仕事が減るってことじゃないかな。

エンジニアを1人か2人雇う予算があれば、今までは5〜10人必要だったような仕事を任せられるようになるかもね（あくまで理論だけど）。

そうだね。この議論の仕方そのものが、ソフトエンジニアの需要が減るって考え方に基づいてるよね。タスクを達成するために、より少ない人数でよくなるってこと。

AIで数日でできたって言ってるけど、コミット履歴(https://pastebin.com/bG0j2ube)見ると2月末から3月までやってるし、他の人も手伝ってるよね？
でも、良いユースケースで、2ヶ月かかるところを1ヶ月で終わらせたのはすごいと思うよ。

AIコーディングの方向性として、ベテランがAIでコード書いてレビューって言ってるけど、中間もあるかもね。ビジネス担当者が、OAuthみたいなデカいタスクを、経験浅い開発者にClaude使って丸投げしちゃって、ベテランがいらなくなるってパターン。

経験浅い開発者にAIコードを丸投げって、うまくいくかな？そのコードが正しいかどうかわかるの？見つけにくいバグとか、どうやってデバッグするの？保守性とか拡張性とか、わかるのかな？単に前のコードの上に新しく生成するだけにならない？

AIなしで速く書けたかっていう問いへの答えは、明らかにノーだと思う。今あるツールと使い方を学んでる状況から考えると、あと3〜6ヶ月で、AIを使った方が速くコードを書けるようになるのは間違いない。そのためには、しっかりした基盤作りが必要だけどね。

コードベースを知らない人はAIがすごく役立ったって言ってるけど、これってダニング＝クルーガー効果みたいなもんじゃない？知らないことだらけだと、AIが賢く見える。でも、知ってると、これはダメだってわかる。自分が詳しい分野のニュースは間違いに気づくけど、詳しくない分野は信じちゃうのと似てるよね。

重要なのはAIが速くコード書くスピードでレビューできるかじゃなくて、レビューだけで全部見つけられるかってことだよ。ロボットが超速で車作っても、たまにボルト間違えて、後から見ただけで全部見つけられる？人間のコーダーは、書くときに考えるから、バグをいっぱい防げるんだよ。

ベテランがAIでコード書いてレビューってやり方、俺の経験だと自分で書くより遅いんだよね。AIってたまにしかちゃんと書いてくれないから、結局最初から自分でやった方が楽。まさに’下手な手伝いはしない方がマシ’ってやつで、今のAIはまさにそれ。

そんな風には言ってないよ。他の人と間違えてない？
でも、その人もそう言おうとしてないと思うな。
開発が簡単になれば、予算不足で無理だったプロジェクトが可能になって、かえってエンジニアの需要が増える場合もあるって話だよ。

いや、言ってるよ。ハッキリこう断言したじゃん。「1人か2人分の予算しかない会社でも、以前なら5〜10人必要だった作業を任せられるようになるかもしれない」。
自分の言葉だろ？5〜10人かかるプロジェクトが1〜2人でできるようになったって。
開発が簡単になれば、需要が増えるって？それ希望的観測だよ。
君の例でも開発が簡単になることは需要を減らすだろ。結局エンジニアの需要は減るのが真実だよ。今エンジニアを雇ってる会社は、そんなに人を必要としなくなるだろうからね。

大きな利害関係がある「専門家」（AIスタートアップ経営者、AIコース販売者、株価を上げたい人）を除けば、この意見を持つ分野の専門家はごくわずかだよ。

それは違うよ。プロジェクトに唯一いる20万ドルのエンジニアをクビにするのと、3人目とか10人目のエンジニアをクビにするのは違うんだ。
AIがエンジニアの生産性を上げてるなら、チームにもっとエンジニアを追加する必要性は減るんだ。クビになるか、拡大しても新しく雇わない（か、雇う人数を減らす）ってことかもしれない。既存のエンジニア＋AIで増えた仕事量に対応できるからね。

「経験の浅い開発者はAIが作ったコードが正しいかどうかわかるの？」って？問題ないね。業界はバグだらけで、かろうじて動くコードを許容するようになった。LLMは何も変えない。
簡単な自動テストスイートを実装できるから、むしろ改善される可能性すらあるね。
「本番稼働してから微妙なバグが見つかったら？」って？それはLLMなしでも現実世界で起きてることだよ。

「エンジニアを雇うコストに見合わない、未開発の広大なソフトウェア領域がある」って？確かに面白いけど、IT部門を巻き込まずに、個人が自分で問題を解決するようになるんじゃないかな。
複雑なExcelワークフローとか、ひどいAccessデータベースとかで、今すぐ問題を解決してるのをすでによく見るよね。リソースはもらえないから。
たぶんAIはその答えになるんだ。Excelで砂上の楼閣を建てる代わりに、こういう非技術系のチームがもう少し頑丈なものを持てるようにね。
会計部門は一番AIを使う部門だと思う。もうExcelとかERPのDSLsで実質的にプログラミングしてるからね。
新しい開発職は増えないけど、「誰もがプログラマーになる」がAIで実現して、高度なコンピューティングが日用品になるのかもね。

誰もその知識を社会的に再生産しなくなるから、知識がなくなっちゃうんだよ。

「5〜10人必要なプロジェクトが1〜2人でできる。自分の言葉だろ」って？それはエンジニア需要が減るって意味じゃないよ。
以前10人必要で2人分の予算しかなかった会社は、そのプロジェクトに取り組まなかった（エンジニア0人）。AIで2人でできるようになったから、今度は取り組める（エンジニア2人）。これが元々言ってたことだよ。
開発が簡単になることは需要を減らすって単純じゃない。長期的にどうなるかは誰もわからない。増えるシナリオも減るシナリオもあって、ネットでどうなるかはみんな推測してるだけだよ。

「AIを使って完全にコード書くのが速くなることはない」って？この議論は別の視点から始めるべき。技術も問題の解決法も変わったんだ。
エンジニアがLLMなしでできるかの話じゃない。本質は、納品されるコードの全体的な品質と、そのレベルに到達するのにかかった時間だよ。
LLMはコード書くより、今見てるものが何を意味するか説明してもらうのが主な使い方。Googleの代わりやラバーダックとして使われるとしても、開発者は今までできなかった方法で既存プロジェクトを理解できるんだ。
プリンシパルエンジニアと会議を予約して質問する必要はない。Copilot Chatに聞けばいい。
もう一つ重要なのは、LLMが選択肢を早く試せて、イテレーションを助けてくれること。MVPの最初のバージョン出す時間で、もっと安定したプロジェクトを簡単に納品できるんだ。

30年以上ソフトに関わってきた経験から言うと、アプリの設定はデフォルトで覚えるのが一番だよ。だって、転職したり環境変わったりすると、カスタマイズした努力が無駄になるし、結局デフォルトの使い方を覚え直さなきゃいけないからね。
会社の固有設定も似たようなもんで、維持が大変だし、LLMも知らない変更だから、誰かが手作業でメンテしなきゃいけなくなる。LLMに学習させても、たった1例しか見てないから全部うまくいく保証もないし、人が間違いに気づけるかも怪しい。テストコードを山ほど書けば別だけど、そんなの非現実的だね。

でもさ、どうなの？
筆者みたいなすごいエンジニアが、OAuth2の実装みたいな「雑務」をやるなんて、もしかして新しい開発手法（AI使うやつ）を試したかったからじゃないの？
普通のエンジニアが毎日やるような仕事で、本当に100％も生産性向上できるのかな？ちょっと疑問。

＞AIは他人の複雑なコードを読むのにすごく役立つって分かった。これで自信持ってコード読めるようになったよ
これ、分かるわ。でも逆に、AIがうまく機能しないコードベースってある？例えば、コードが複雑すぎてLLMのコンテキストサイズに収まらないとか、AIの学習データにない独特なコードパターンとかさ？

筆者がコードだけじゃなくてプロンプトも公開してくれたの、マジ感謝！
俺もLLMでコード書こうとしたけど、幻覚（ハルシネーション）がひどくて全然進まなかったんだ。他の成功例見て、たぶんプロンプトの書き方が悪いのかなと思ってたんだけど、今回公開されたプロンプト見たら、自分のやり方もそんなに外れてなかったんだなって分かったよ。
たぶん俺がやってる問題（SAP ABAPのリバースエンジニアリングとか、Snowflake上のデータで.NET実装とか）がちょっとニッチすぎて、LLMが苦手な分野なのかもしれないね。

これ、俺も気づいてた。ちょっとニッチな分野に入ると、LLMの出力品質が劇的に落ちるんだよね。
そういえば、SAP ABAPのリバースエンジニアリングって聞くだけでゾッとするね。

一番たちが悪いのは、品質が落ちても、自信満々なトーンが変わらないことだよ。平気で間違った、ひどい時には危険なコードを自信満々に出してくるから、それが間違いだって気づくには、そもそもLLMより賢くないといけない。
いつか人間を超える日も来るかもしれないけど、今はまだそこには全然到達してないね。

いつもの解決策としては、段階的なアプローチがあるよ。
まずは大きなコンテキストを持つLLMを使って、全体計画を立てるのが良い。できればチェックボックス付きのMarkdownファイルとかでね。
次に、その計画を元に、もう少し専門的な分野に特化した別のLLMに、タスクを一つずつ実行させるんだ。こうするとコンテキストが絞られて、幻覚を減らしながら作業できるよ。

＞真面目な話、2ヶ月前（2025年1月）なら、私も（＠kentonv）同意しただろう。
この「私も（＠kentonv）」ってところが混乱したんだよね。自分のことなのか、それとも別のユーザーkentonv[0]のことなのか。あなたの別垢？それともタイプミスか勘違い？
あ、分かった。たぶんほとんどの投稿がREADMEからの引用なんだね。引用記号（＞とか＊）使ってもっと分かりやすくした方がいいかもよ。

あー、彼はプロジェクトのREADMEから引用してるんだよ。あのテキスト（引用部分）は、全部俺が書いたやつ。

コメントありがとう！
ちょっと提案なんだけど、技術って本当にすぐ変わるから、READMEに「Claudeのどのバージョンを使ったか」って書いとくと、後々すごく役に立つかもね。特に最近v4が出たばっかだし。
あと、どのコーディングツールを使ったかとかも、再現性を高めるためにはちょっとした情報でも助かるんだ。

AIをがっつり使ってライブラリ作ったんなら、正直に言うべきだと思うんだよね。全部自分で書いたみたいに見せるのはなんか違う気がするし、知ってるとなかなか面白い情報だからREADMEに載せるべきだよ。（他の人がどうするかは知らないけどね）ほぼ全部Claude Sonnet 3.7で作ったんだ。READMEにバージョンも追記するべきってのは同意するよ。

それ面白いね。俺のSonnet 3.7の今年の初めの経験は結構ひどかったんだ。問題をはっきり説明しても、単独じゃ正しい解決策にたどり着けなくてさ。ダメなコードも手直しはできたけど、構造がいけてなくて実際のプロジェクトではメンテナンスしたくない感じだった。よくある hallucinated APIs みたいな問題もあったし、リファクタリング体験はもっとひどかったな。たぶんドメインにかなり依存するんじゃない？俺の場合はGISだったよ。

＞ プロジェクトのREADMEに入れるにはかなり論点がずれてるかも
って書いてあるけど、このリポジトリの目的って、今のLLMがペアプログラマーとして十分かどうか検証することみたいじゃん？だから、READMEから消すのはその文脈だと全然意味なくない？

このライブラリ、俺たちのMCPフレームワークの核となるコンポーネントなんだよね。単なる実験じゃないんだよ。

それは考えたんだけどね、このリポジトリ「kentonv が適当にやったやつ」って名前じゃないし、CloudflareのブランドでCF workers向けのプロバイダーライブラリってはっきり書いてあるんだよ。Claudeを使った部分を入れるのが「完全な開示」なのか「AI推し」なのか、単にクールだからなのか、細かい話は置いといてさ。論点がずれてるって言ったのは、READMEの半分が使い方で半分が開発過程の話だったら、読む人が「これって実用？遊び？」って混乱するかなと思ったからなんだ。

READMEに入れるのはかなり変だなと俺も思ったよ。例えば、fiverrとか codementor.io にコード書いてもらったとしてさ、READMEに「Fiverrで質の高いコードが書けるかかなり懐疑的だったけど、試してみたら結構良かった！」なんて書くの変じゃない？たぶん会社としてAI関連を何かやろうっていうプッシュがあったんじゃないかな。最近そういう会社多い気がするよ。

逆なんだよ。俺自身がこれを試してみようって強く思って、その結果に基づいて、最終的に会社にもっとAIを採用するように働きかけたんだ。

あれ、READMEからの文字通りのコピペだよ。引用されるはずだったのに、親コメントの人がなんかしくじったんだと思う。https://github.com/cloudflare/workers-oauth-provider/blob/fe…

（このコメントはもともと https://news.ycombinator.com/item?id=44159167 への返信だったんだけど、そのコメントがREADMEを分かりにくく要約してたんだ）

俺、ここ数ヶ月 greenfield project で Claude（Cursor経由）使ってるんだけど、気づいたことはさ、
1. 前よりずっと生産的／効果的になった。
2. 昔ながらのコード書き方より、認知負荷はかなり高いね。
3. この短期間でもツールがすごく改善してて、上の2つの点がさらに強調されてる感じ。

LLM使ってコード書くと、すっごく早くできるんだけど、逆にめちゃくちゃ精神的に疲れるしエネルギーも使うんだよね。なんか変な感じ。

「コンパイル通った！」みたいな、ちょこっとした達成感（ドーパミン）が全部自動で消えちゃって、ひたすら最終目標だけで頑張らなきゃいけない。
問題は複雑にならざるを得なくて、LLMが微妙に間違えたところをどう直すか考えなきゃいけないんだ。辛いけど、効果的なのかな？

「変な感じ」って言ってたけど、俺は全然変だと思わないな。普段コーディングであるような面倒な定型作業（構文とかフレームワークの枠組みとか）が無くなるから、AIがそこを全部やってくれて、まるで「思考のスピード」でコードを書けるようになるんだ。だから脳みそフル回転になるんだよ。
もちろん、生成されたコードが本当に正しいか、ちゃんと確認する必要もあるしね（将来はAIがこれも手伝ってくれるといいけど）。

「昔ながらの方法より認知的負荷が高い」って言うけど、どんな使い方してるの？
俺は自分のエージェント（最近はDevstral使ってる）と主に「ペアプログラミング」みたいにやってるんだけど、生成されたコード全部自分で打つより、レビューする方が時間的にはずっと楽だと感じるんだ。
「vibe coding」もちょっと試したことあるけど、あれは同意だね。何かレビューしたい時に文脈が全くないから。要するに、プロジェクトが最初からvibe codedされてると、コードベースに入り込むのがすごく難しくなる。
でもLLMとペアプログラミングしてる時は、既に文脈ができてて、どうしたいか理解してるから、ペアプロで作ったコードのレビューはvibe codedよりずっと速いんだ。

いろいろ試したけど、今はほとんどCursorをagentモードでClaude Sonnet 4と一緒に使ってる。小さめのプルリクエストくらいの単位でプロンプトしてるんだ。Claude 3.7の時ほどコードを慎重にレビューしなくてもよくなったけど、今はアーキテクチャ設計がボトルネックだと感じてる。
chatGPT-o3と設計パターンについて長〜い議論をして、何日も考えることもあって、その後にCursorで比較的素早く実装セッションをする、って流れになってる。

こういう状況が、ソフトウェアのアーキテクチャとか概念をどうドキュメント化するかっていう標準を改善するかどうか、見るのが面白そうだね。

「昔ながらの方法より認知的負荷が高い」って話だけど、面白いことに俺は全く逆だと感じるんだ。細かいディテール全部をいちいち考えなくていいってだけで、すごく安心するよ。おかげでアーキテクチャとか、もっと高レベルな変更に集中できるようになった。

つまりさ、前は細かいディテールって、なんか“思考停止”でできるようなもんだったんだよね。眠ってても書けるコード、みたいな。今は考えるべき部分だけをやればいいってこと。

これはつまり、細かいことについてはLLMがちゃんとやってくれるって、完全に信頼してるってことだね。

このコミットから：https://github.com/cloudflare/workers-oauth-provider/commit/…
===”Claudeのバグを手動で修正。”
”Claudeは前のコミットでバグがあった。複数回プロンプトしたけど、ずっと間違ったことばかりしてた。”
”だからこの変更は人間が手で書いたんだ。”
”OAuth 2.1の仕様の問題についてREADMEも追記した。”
===
これ、AIツール使ってみた俺の経験とマジで共感できるわ。途中までは行くけど、そこから先がめちゃくちゃ苦労するんだよね。