2025年夏、LLMを使ったコーディングはどうなる？最新レポート
引用元：https://news.ycombinator.com/item?id=44623953
Gemini 2.5 PROとかClaude Opus 4とか、有料LLMモデルが当たり前になってんのが悲しいわ。LLMはすごいツールだけど、プログラマーが第三者に強く依存するようになるのが理解できん。昔はオープンでフリーなツールでプログラミングできたのに、数年後には有料LLMなしじゃIDEやVimなしみたいになっちゃうかもって不安なんだ。“六桁稼ぐのに月200ドルくらい安いだろ？”って言い訳は問題の本質を捉えてないよな。
ローカルで動かせるモデルはまだ有料のほど良くないし、運用コストもめっちゃ高いんだよ。Claude 4レベルのモデルをローカルで安く動かせるようになれば、みんなそうするだろうな。今一番近いのはKimi K2を512GB Mac Studios2台で動かすくらいで、2万ドルくらいかかるらしいぜ。
“プログラミングはオープンでフリーなツールでできる活動だった”って言うけど、JetBrainsは俺の同僚より長くビジネスやってるし、MicrosoftのVisual Basic、C++、StudioもWindows向けソフト開発をめちゃくちゃ楽にしたけど、タダじゃなかったろ。
決定的な違いがあるんだ。JetBrains IDEは使うけど、いつでもVimやVS Codeに切り替えられるんだよ。でも有料LLMの問題は、オープンソースのに簡単に切り替えられないことなんだ。有料のほど良くないからな。つまり、避けられない依存関係ってわけだ。これは見過ごすべきじゃないって思うぜ。
“六桁稼ぐのに月200ドルくらい安いだろ？”って言い訳は、全然問題の本質じゃないんだよ。Black MirrorのエピソードCommon Peopleに出てきたような、他のサブスクモデルと全く同じさ。最初は値段の割に価値が高すぎるように見えるけど、結局は長期的に見て値上がりしたり、品質が落ちたりして、囚われの身になるんだから。
プログラミングが‘死ぬ’のが待ちきれないぜ。俺の人生から少なくとも10年を盗んでったからな。獣医がペットを助ける訓練を受けても、仕事の大部分が殺すことだと知るようなもんさ。言語論争とか、何千もの開発者との意見の相違とか、レガシーコードとか、手入れされてないライブラリとか、そんなことに10年も費やすなんて知らされてなかったわ。過去のプログラミングとはおさらばだ。新しい、違う現実を喜んで歓迎するぜ。
有料モデルの方が、はるかに、はるかに良いぜ。
Framework Desktopのセットアップってどう思う？マーケティングの口上か、それとも何かメリットあるのか？Ryzen AI Max+ 395と128GBメモリで1999ドルからって、AIワークロードにはすごい価値だってさ。Llama 3.3 70B Q6とか、DeepSeek R1 671Bみたいなデカいモデルも動かせるって。でもVRAM 384GB、メモリ512GBで1万ドル～1万2千ドルって試算は怪しいな。クラウドのコストと性能は常に動くから、損益分岐点の分析はさらに難しい。もしこういうセットアップが動くなら、費用対効果は謎だぜ。 https://frame.work/be/en/blog/introducing-the-framework-desk…
10年前はVim使いだったけど、今はPyCharmで仕事してるぜ。俺は問題を解決するためにお金をもらってるのであって、Vimの設定いじるためじゃないんだ。Vimで同じようにできるかもしれないけど、設定に何時間も費やしたくないし、そう考えるとPyCharmのライセンスなんて安いもんさ。LLMも全く同じだよ。AIに汚染されてない手作りの綺麗なコードが欲しいなら、そうすればいい。でも俺は問題を解決するためにお金を稼いでるんだ。早く解決したり、多く解決できれば、もっとお金もらえるしな。
プログラマってLLMには金払うのに、広告なし検索には払わないの変だよな。
昔はVimガチ勢だったけど、今はPyCharm使ってるよ。問題解決のためにお金もらってるんだからね。ツール最適化と問題解決は別で、VimもPyCharmも好み次第。俺はEmacsとVSCode両方使ってるよ。
LLMの依存はコストが高すぎるよ。良いエンジニアは高レベルの抽象化を使うんだから、LLMもオープンソースとかプライベートLLMに切り替えられるツールが必要だろ。そうじゃないと会社が暴走した時に対処できない。まるでLinuxプロセスやGitコミットにお金を払うみたいだ。
Claude 4クラスのモデルをローカルで動かすのは、Mooreの法則が終わった今、かなり厳しいね。コンシューマーPCの性能は限界で、電力や冷却の問題もある。Facebook、MS、Googleは市場を独占するためにお金を使い、イノベーターを締め出してる。Googleのプロジェクト中止やMetaverseの失敗を見ても、AIの未来にはあまり期待できないよ。
プログラミングっていつからオープンでフリーなツールでできるようになったの？昔から有料ツールはあったし、無料の代替品もあっただろ。LLMだって同じだよ。「高給取りなんだから月200ドルくらい払えよ」ってのは的外れだ。結局、LLMを使うか、オープンソースか有料か、自分で選べるんだから。
ソフトウェアはOllamaやvLLMがあるし、モデルもQwen3-30B-A3BとかDevstral-23Bみたいにそこそこ使えるようになってきた。でも、ハードウェアが全く追いついてないんだよ。開発用ノートPCじゃ厳しいし、Nvidia L4カードでも性能は限界がある。GitHub CopilotはOllama接続できるけどね。MoEモデルとか訓練の進化で希望はあるけど、Intel Arc Pro B60みたいなNvidiaの代替品が早く出てきてほしいな。
いくつもプロバイダーがあるから、簡単に乗り換えられるよ。俺は数ヶ月ごとに変えてるしね。ロックインとか心配してるのは、抽象的に考えてる人たちだけじゃないかな。競争が激しいから、みんなどんどん良くなってるしね。
彼、正直なだけだよ、失礼じゃないってば。
検索サービスにお金払ってるし、共同作業者にも何人かそうするよう説得したよ。
問題ないよ。LLMの進化が停滞するなら、高くて意地悪なサービスにこだわる理由はないし、オープンモデルも多いからね。もし停滞しないなら、どうせ僕らは時代遅れになるから、別のことに移るしかない。だから心配するだけ無駄さ。たぶん進化は停滞するし、大手企業の株は過大評価されてると思うよ。
’失せろ’とか’お前はいらない’なんてのは正直さじゃなくて失礼なだけ。正直なら’プログラミングは好きだし、もし消えたら悲しい。君はもっと好きな仕事を見つけるべきだ’って言うべきだろ。あと、元コメントの’メンテされてないライブラリやツール’って指摘は超的を得てる。商業コードはインセンティブのズレでダメなのばかり。Open Sourceも完璧じゃないけどね。
ツール最適化と問題解決を一緒にするのは違うって意見だけど、ツール最適化ってのは長期的に楽になるためじゃん？俺は10年以上Emacs使って、その後10年以上PyCharm使ってるけど、PyCharmは最初からEmacsで10年かけて設定した機能がほぼ全部揃ってたんだよね。時間かけてEmacsを最適化する”必要”はなかったけど、やった方がインテリセンスとかコードジャンプとかできて便利だった。
多分ほとんどのデベロッパーは無料検索使ってると思うよ。だって、まだ誰にも’Kagi使え’って言われてないし。
LLMの進化が停滞しないなら、僕らプログラマは時代遅れになるって話に、もっとニュアンスがあるかもね。急な停滞じゃなくて、収穫逓減になる可能性もある。それだと大手LLMプレイヤーが有利になるだろうな。大きなブレイクスルーの合間は、そのシナリオが一番ありそう。
プログラマがプログラミングするためにサードパーティに強く依存するのを気にしないってのが理解できないし、自分たちのコードベースを大手テック企業に無料で公開するのも気にしないのが不思議だね。
ロックインを避けるためにローカルでLLMを動かす必要はないよ。いくつかのクラウドプロバイダーがDeepSeek R1とかKimi K2を100万出力トークンあたり2〜3ドルで提供してるし。
まあ、収穫逓減は結局、停滞と同じ効果を生むさ。もし君が（はるかに安価な中国の）競合他社と一緒に進化の丸太に乗ってるなら、君の優位性はあっという間にちっぽけになるだろうね。
フェイシャルティッシュが欲しい時、箱がPuffsって書いてあってもKleenexって言うよね。だって、「Puffs取って」って言う人いる？LLMを使ったコーディングツールも、特定のツール名が代名詞みたいになるかもって話かな。
LLMツールって、他の開発ツールと全然変わんないよね。無料のオープンなツールはたくさんあるけど、有料版よりちょっと遅れてる。JetBrainsとかmacOSとか、Google Adsにもみんな金払うじゃん。強力なオープンモデルもあるけど、最先端じゃないし、ローカルで動かすにも結局金がかかる。競争が進んで、各社が最高のモデルを作ろうと頑張ってて、価格も下がって選択肢も増えるのはマジ最高。資本主義が機能してるって感じだね。
ちょっと話がそれるけど、筆者の「PhD-level knowledge」って表現には反対だな。antirezにはすごく尊敬してるんだけど。この言い方は誤解を招くし、博士課程の本質を間違って捉えてる。AIラボのマーケティングとか誇大広告に影響されてる感じ。明確な「PhD-level knowledge」なんて主張は意味ないよ。PhDの主な目的は、既存の膨大な知識を覚えることじゃなくて、研究の仕方を学ぶことだからね。
その意見に同意。あれはLLMが人間ほど得意じゃない他の部分を除いた、エキスパートレベルの知識って読むべきだよ。LLMの知識表現方法は独特で、ちょっと異質だから、やっぱり単純化しすぎてるんだね。例えば、LLMはトップレベルの人間コーダーほど上手くコードは書けないけど、反復なしで最初から最後まで非自明なプログラムを書ききれるんだよね。
もっとコメントを表示（1）
antirezさん、Geminiがプロダクションリリース前にバグを見つけてるって話がすごく気になったよ。もう少し詳しく教えてくれると嬉しいな。だって、普通AIはバグを作る側で、人間がそれを見つけるって考えるじゃん。でも、Geminiがテストを書くだけじゃなく、QAみたいにバグを見つけてるなら、それってすごい興味深いよね。
うちのチーム、LLMを自動コードレビューにガンガン使い始めてるよ。PRを見てコメントしてくれるんだ。APIガイドラインとか、”あなたはエキスパートのソフトウェアエンジニアでQAプロフェッショナルです。このPRをレビューしてバグや技術的リスクを指摘し、改善提案を簡潔にしてください”みたいなプロンプトを与えると、めちゃくちゃたくさんの問題を見つけてくれる。あと、ビルド失敗時に人間が見る前に、LLMが根本原因のレポートを作成するのにも使ってるから時間節約になるね。アラームのトリアージも試作中だよ。
LLMを活用したツールが有料製品としてもっと出てないのが意外だね。僕はCursorsのbugbotみたいなシステムをめちゃくちゃ使ってるよ。ノイズはあるけど信号は多くて、いつも正しいわけじゃないけど、自分が絶対見逃してたであろうバグをたくさん見つけてくれるんだ。
いくつかあるよ、Greptile、Ellipsis、GH Copilotとかね。多くの人が”自動レビューと修正”を試そうとしてる気がする。生成されたコメントを別エージェントに渡して適用させるのは魅力的だもんね。でも、それって新たな問題を引き起こすし、すぐにただのコードアシスタントサービスになっちゃうだけだよ。
チーム固有の知識とか基準に基づいた、具体的なプロンプトを使えば本当にうまくいくんだよ。「このコードでバグを探して」みたいな、ほとんどのコードレビューアがやってるような一般的なプロンプトじゃダメなんだ。
LLMにPRレビューさせる時って、精度どうしてる？「このPR見て」ってだけだと、大したレビューしてくれないよね。
確かにそれじゃダメだよね。うちはガイドラインとかPRのベストプラクティスをコンテキストに入れてるよ。LLMでそのデータを整形して、ルールを絞るのも効果あったね。
僕も数ヶ月前からコードレビューのルールディレクトリ作ってるんだ！何がうまくいって、何がダメか、話して情報交換しない？メールはilya (at) wispbit.comだよ。
PhDレベルの知識って、正しい問いを立てることだよね。LLMは言われないと自分で仮説を探らないから、「ultra-think」みたいな指示で深掘りさせないとダメなんだ。前、Claude Codeがコミット後にリフレッシュされてないORMオブジェクトのバグを勝手にコメントアウトしちゃってさ。
「ultrathink」は一語だよ（下に証拠あり）。Claude CodeのOpusで使ってるけど、同じ経験したな。複雑なテストさせようとしたら、コメントにテストプラン書かれた空の関数返ってきたし（笑）。Gemini 2.5 Pro試したいけど、Claude Codeみたいな体験ができるツール知らないんだよね。Cursorとかどうなのかな？
Googleのgemini-cliってClaude Codeにかなり近い使い心地で、無料枠も結構あるよ。個人的にはClaude Codeの方が上だけど、自動修正を鵜呑みにするとすぐに話がズレることも。でも、大きなコンテキストウィンドウあるからコードレビューやプランニングには便利だね。
PhDって知識だけじゃなく、その知識に簡単にアクセスできることがすごく大事って分かってたら、LLMの価値ってめっちゃ高いよ。前の仕事でPhDレベルの人が答えるような質問がよくあったけど、LLMは結構うまくやってくれるんだ。
LLMの回答、実験的に検証したの？それにこれって「PhDレベルの知識」っていうより、単に仕事で出てくる電気工学の質問じゃない？
全くその通り。「PhDレベルの知識」ってのは、博士論文の序論だよね。PhDの目的は、既に知られてる知識を超えて、LLMには知りえない新しい知識を生み出すことなんだよ。
2015年のデータサイエンスブーム以外で、博士号だけで「博士レベルの仕事」が得られる状況なんて一度もなかったんだよな。お前が博士号で学ぶことをどんなにえらそうに言おうと、博士号採用する奴は誰も同意しないよ。むしろ、ほとんどのPhD教授は博士号取得者を、お前が研究した超特定のテーマの器としか見てないんだから。自分の専門外のトップラボでポスドク取ろうとしてみろよ。俺は試して、そして諦めた！
＞博士号の主目的は、既存の膨大な知識を得ることではなく、研究のやり方を学ぶことである。一度博士号を取ったら、誰もその分野には関心がない、ってこと？大事なのは研究のやり方を学んだってことだけ、ってか？
LLMを使ったコーディングとか、Vibe Codingとかの議論では、ドメインとプログラミング言語の選択をちゃんと考慮すべきだ。この二つの変数の方が、どんなVibe Codingのやり方よりも10倍（いや100倍かも）説明力があるんだから。LLMでのコーディングが好きか嫌いかで混乱してる奴は、どんな問題に取り組んでるか聞けばいい。そうすれば相手の視点がよく分かる。そうしないと、「使い方が悪い」「最悪だ」みたいなメッセージだらけで、ノイズにしかならないよ。
プロンプトとか、出力チェックにかかった労力とかも共有すべきだよな。記事でも「LLMと協調するために必要なやり取りを受け入れられ、問題を明確に記述できるなら…LLMに大量の情報を提供する必要があるんだ。論文やターゲットコードベースの大部分…そして、何をすべきかに関する自分の理解の脳内ダンプ。その脳内ダンプには特に以下を含まねばならない：」って、どんだけ手間かかってるか示唆してるし。これだけ努力して、やっと生成されたコードが使えるレベルになったらさ、結局自分で書けばよくない？って思っちゃうよな。タイピングにかかる時間なんて大したことなくて、問題記述に費やす認知労力こそがプログラミングの本質なんだから。
＞結局、自分で書けばよくない？
いやいや、それでもLLMの方が断然、断然、断然速くて簡単だよ。解決策を見つけるのが難しいってのは全くその通り。でもタイピングに費やす時間は決して些細でも、認知的に単純でもない、特に複雑なタスクではね。プロンプト一つで数秒で5〜10倍ものコードを簡単に生成できる上に、さらに以下のメリットがあるんだ：
a) ほとんど全ての中間データ構造、クラス、アルゴリズム、データベースクエリを考えてくれる。
b) 全てのボイラープレートやドキュメントを処理してくれる。
c) 自分が考慮しなかったエッジケースまで考慮してくれて、計り知れない量の将来のデバッグ時間を節約できる。
d) 単に頼めばテストも含まれる。
実際、最近は解決策が分かったら、手動だと頭の中の設計をコードに十分速く落とし込めないことにイライラするんだ。AIが大量のコードを吐き出してくれて、すぐに実行（またはテスト）して期待通りの結果を見られるのはすごく満足感がある。もちろん、コミットする前に差分はしっかりレビューするけど、それは自分のコードでもそうするしね。
＞頻繁に自分が考慮しなかったエッジケースまで考慮してくれて、計り知れない量の将来のデバッグ時間を節約できる；
そして、お前が今まで考えもしなかった新しいバグも生み出して、同じか、それ以上のデバッグ時間を将来に生み出すんだよ :D
それはコードレビューでしょ :-) でも前のコメントに同意すると、俺は一年半以上、生成されたコードの中に微妙なエッジケースやバグを見つけたことがないよ。間違いや失敗モードは確かにあるけど、それはすごく分かりやすいから、そういうコードは捨ててやり直すだけ。とはいえ、俺はAIと仕事する上で、自分の状況に非常に効果的な特定のやり方を採用してるけどね（コメント履歴にも書いたけど、TFAの助言と似てるよ）。
Claude Codeみたいなツールを使うと、こういう微妙なバグが実際ほとんど出てこないことに驚いてるんだ。たいてい出てくるバグは、プロンプトの誤解によるもので、コードの作りが悪いわけじゃないから、すごく分かりやすいんだよ。AI生成コードのレビューは、実際には思ってたよりずっと簡単だったから、これは驚きだったな。多分、俺がLLMを使うのは簡単な説明ができるコードだけで、だから複雑じゃないからかもしれないね。もっと複雑なコードなら自分で書くし。
この話にはもううんざりだ。「LLMが膨大な量のバグを出す」ってのは、GPT-4の2023年あたりの見方だよ。みんな真剣にAIツールを学ぶべきで、こんなくだらないことを繰り返すのはやめろ。最も寛大に言うとすれば、1時間あたり20～50倍のコードを生成するから、お前が慣れてる時間枠でバグの『生の数』が増えるのはあるかもしれない。でもAIコーダーが人間よりバグが出やすいっていう考えは全くのナンセンスだ。それが当てはまらないのは、ごくニッチなシステムか、人間が事前に徹底的にコードを概念化して計画している場合だけだよ。それでもAIが次のステップとしては優れてるだろうね。
LLMは英語から高水準言語への翻訳みたいなニッチな作業は得意だけど、並行処理みたいな複雑な推論は全然ダメだよ。統計的なデタラメを返してるだけ。LLMは役立つツールだけど、過大評価も過小評価もあるね。
自分でコーディングすると、知ってるバグしか直せないけど、AIは考えつかなかったエッジケースを教えてくれることがあるよ。
＞1つのプロンプトで数秒で5～10倍のコードを生成できる
それって良くない結果だね。コードの行が増えるほどバグの可能性も負債も増えるからね。プログラミングで一番どうでもいいスキルはタイピングの速さだよ。
＞彼らもプロンプトを共有すべきだよ
最近のShowHN投稿にOneDriveの写真マップビューがあるんだけど、これにはLLMプロンプトの記録が全部載ってるよ。
https://news.ycombinator.com/item?id=44584335
「生成コードを受け入れるまでに自分で書く方がマシじゃない？」ってよく思うんだけどね。
でも、アホなロボットがプロジェクト設計に役立つって分かったんだ。設計書を作らせて、それについて議論して修正して、新しいアイデアを探って、最後にコードを書かせるんだ。まるで剃ろうとしてるヤクと話せるみたいで、最高だよ！
たぶん、LLMには一回大量の情報を渡せば（あるいは集めさえすれば）、それをいろんなタスクで使えるから、後は楽できるって言いたいんじゃないかな。
もっとコメントを表示（2）
コードの再利用を考えるなら、そんなに大量のコードを書く人なんていないよ。ほとんどの時間は、情報収集（特にステークホルダーとのやり取り）や、書いたコードで何も壊れてないかの確認に使われるんだ。
AIでクリエイティブなビジュアルマーケティングキャンペーンを立ち上げたばかりなんだけど、プロンプトのスキルでアウトプットにめちゃくちゃ差が出るってマジだよ。プロンプト次第で印刷できるレベルの画像も、ゴミみたいな画像もできちゃうからね。
ClaudeのGitHub actionを結構使ってるけど、ヒットとミスがあるから、LLM単独よりは「強化されたコーディング」が良いね。小さい変更やリファクタリングはテストがあれば安全で得意だよ。でも中規模以上は動いてるように見えても動かないことが多い。もっと大きいのは全然ダメ。PRレビューは小さいタスクには良いよ。まだ単独で何でもできるレベルには程遠いけど、僕の生産性はかなり上がった。
問題は、コード変更をユーザーに見せるためのインフラだよ。コードをプルしてデータを設定して、意図通りに動くか確認する手間があるし、生成コードが期待通りに動かないと、差分をチェックするだけで時間を無駄にしちゃうんだ。
LLMにコードを書かせる前に、まずやりたいことを説明させると、その後に生成されるコードの質がめっちゃ上がるって気づいたんだ。詳細な説明を求めて、何度かフィードバックしたら、あとは実装させればOKだよ。
同感！良い戦略だよね。LLMの強みを活かしつつ、暴走させないのがミソだよ。
元の記事の人とは違って、僕の経験ではGemini 2.5 PROとOpus 4はアーキテクチャとか抽象的なレベルで良い感じだったな。Sonnetはコーディング向きだね。GeminiとOpusは回りくどいことあったけど、Sonnetはサッと本題に入るんだ。
僕もそう思う！大きなデザインアイデアはGemini 2.5 Pro、コーディングはClaude Codeが最高だね。Gemini CLIはClaude Codeに全然敵わないよ。Claude Codeはデバッグも優秀なんだ。あとはDeepSeek R1もアイデア出しにはいいけど、ちょっと遅いかな。
それ、全然あり得るね。Sonnet/Opus 4は最高の出力はすごいけど、安定性や一貫性ではSonnet 3.5v2（3.6）や3.7より劣ることもあると思うな。モデルって複雑だし、使い方で性能も変わるからね。
社内の統計でも、OpusとGemini 2.5 proが実世界シナリオでSonnet 4より性能が悪いって確認されてるよ。
https://x.com/pashmerepat/status/1946392456456732758/photo/1
Gemini 2.5 PROはコスパ最強で推論も良いね！Cursorだと1リクエストだし、コードスタイルもシンプルで気に入ってるよ。無人島に一つだけ持っていくならコレだね。大仕事にはOpus 4を使うけどさ。
数ヶ月エージェントコーディングしてみて、この投稿に完全に同意するよ。今一番使いやすいのはフロンティアLLMだけど、オープンモデルもすぐ追いつくはず。LLMから学べるし、アプローチも相談できるんだ。Github Copilotも簡単な機能にはすごく良いよ。みんな、この新しい旅を楽しんで、学んだことを共有しよう！
AI/LLMがいかに非効率なコードを書くか、良い例があるよ。見てみて。
https://nullonerror.org/2025/07/12/ai-will-replace-programme…
同じく、AIはコードゴルフが苦手なんだ。秘密を全部知ってるって思うだろうけど、そうじゃないんだよね。冗長なコードじゃないとダメなんだ。
LLMをコードゴルフの例でファインチューニングしたら、どんなのができるかな？面白そう！
Claude codeはすごく進化してるよ。うちのPythonコードベースで複雑なアダプターパターンがあるんだけど、適切なプロンプトを与えれば、Claudeは新しいアダプターをほとんど完璧に実装できるんだ。すごいよね。
要するに、彼の会社は資金調達やValkeyとの競争のためにAI製品を出すってことだろ。AIがなくても十分生産的だった人たちが、今さらAIのちっちゃな証拠を探し回るのはすごく悲しいと思うよ。
LLMに関する投稿があるたびに、うちのポジティブなLLM体験は気のせいだとか、まだLLMのダメさに気づいてないだけだとか言ってくる人が湧いてくるのは、もっと悲しいよ。
俺たちは「想像だ」って言うだけじゃないんだ。証拠も提供できるんだぜ。ほら、これ見てくれよ→ https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o…
もしLLMが本当に役立つなら、そこらじゅうで叫び回る必要なんてないだろ。むしろ、極秘にするはずだ。
CursorなんてLLMの古い使い方だよ。それに、その研究では、調査前にCursorを使ったことのある人が半分以下だったんだぜ。
AIツールの変化がめちゃくちゃ速いから、どんなツールを使って研究が出ても、みんな「あー、あれは古いツール使ってたね」って言えるようになるだろうね。
そうでもないよ。LLMとのチャットは3年間も最先端だったんだ。Claude codeやGemini CLIが出てきたこの8～10ヶ月で、LLMとの関わり方に次の大きな変化があっただけさ。
俺の投稿読んだ？読んでないといいんだけど。この投稿はRedisとは全く関係ないし、会社に戻る前に書いた投稿の続きなんだ。
