新しいLLM中心のワークフローは、今やただのマネジメントの仕事になっちゃった。マネージャーやプロジェクトマネージャーは価値のある役割で、重要なスキルセットを持ってるけど、昔のソフトウェア開発の役割とはほとんど関係がないんだよね。「ビルダー」という一つのラベルの下にこの二つの役割をまとめるのはちょっと変だと思う。EDIT: コーディング（そしてすぐに他の知識労働も）今やただのマネジメントタスクだってことについて、もっと詳しく書いてるよ: https://www.oneusefulthing.org/p/management-as-ai-superpower...

同じことに気づいたけど、これを言葉にするのは難しかった。LLMベースのコーディングを試してみて、理解して賢く話せるようになりたいと思ってる（ただの不機嫌な人になりたくないから）。Claude Codeを使いながら、頭の中でずっと思ってるのは、「プログラミングが好きで始めたのに、これが何なのか…」ってこと。確かに、バカなものを早く作れるようになったけど、たくさんのものを作りたいからプログラミングを始めたわけじゃないんだ。データ構造やコンピュータが理解できる命令で問題を定義する楽しさ、そしてその命令をコンピュータに入力して、実行されるのを見て勝利を感じるのが好きだった。もし何かにやらせることに知的な興奮を感じてたら、マネジメントに進んでたはずだよ。

この分け方は、書くことにもっと関係してると思う。コンパイラ用の形式的な言語を書く仕事から、ジュニアの金魚のような記憶力を持つ開発者のために自然言語を書く仕事に根本的に変わらなきゃいけない。これはマネジメントに近くて、貢献者とは遠い。俺にとって、この違いが二つの主要なキャンプを分けてるんだ。

個人的には、これが完全に「新しい世界」ってわけでもないと思うんだよね。ただ、意見がさらに強調される新しい領域って感じ。これって、いろんなところで起きてるのが不思議だよね。要するに、コンパイル言語とインタープリタ言語、型ありと型なし、テスト戦略なんかがあって、少なくとも一部は、速さや出荷とメンテナンス性のトレードオフについての会話だったんだ。でも、これは技術だけじゃなくて、方法論や使われる言葉にも関係してる。「早く作って壊す」とか「YAGNI」、それから「デザインパターン」や「抽象化」みたいな。君が言うように、視点が違うんだよね。でも、業界としての最大の懸念は、これらが単に「同じくらい有効な」視点じゃないってこと。文字通り、ソフトウェアの異なる段階で、成功したソフトウェアはほぼ全てが通過しなきゃならないものなんだ。私のキャリアの多くは、「やる気のあるチームが作ったヒップなアプリ」から「利益を上げる信頼性のあるソフトウェア」への移行を経験してきたチームで過ごしてきたけど、これは本当に痛い。5人のメンバーが全ての詳細を把握していて、深刻なバグを修正したり数日で機能を出荷できる状況から、技術や問題領域、スキルレベル、意見がバラバラな100人のエンジニアにスケールするための明確な境界を持つものに移行するのは、本当に難しい。AIがこの問題を解決するとはまだ確信できないし、短期的には悪化させるリスクもあるんじゃないかと思ってる。

私は両方楽しんでるし、AIをバイブコーダーとは全然違う使い方してるよ。実装を生成するためにはほとんど使わないけど、ドキュメントやAPIを理解するのに、特にデバッグのためにはかなり使ってる。AIのおかげで、何がうまくいってないのかを理解するのにかなりの時間を節約できてるし、コードレビューでも助かってる。フルバイブコーディングは意図的に避けてるんだ。そうするとプログラマーとしてのスキルが錆びついちゃうと思うから。経験上、あんまり時間も節約できないしね。デザインが決まったら、実装が難しいわけじゃない。

彼は本当に何かを言おうとしていると思う。私はこれについてずっと考えてきた（HNでのLLMに対する持続的な懐疑心を理解しようとしている文脈で）、私が思いついたフレーミングは、トップダウンとボトムアップの開発スタイル、つまりコードを設計してから実装を埋めていくのか、コードを書いてアーキテクチャを進化させるのかってことだね。[1] https://www.klio.org/theory-of-llm-dev-skepticism/

私は両方楽しんでるし、AIをバイブコーダーとは全然違う使い方してるよ。実装を生成するためにはほとんど使わないけど、ドキュメントやAPIを理解するのに、特にデバッグのためにはかなり使ってる。AIのおかげで、何がうまくいってないのかを理解するのにかなりの時間を節約できてるし、コードレビューでも助かってる。こう感じていたし、今もそうだけど、ある時点で管理の変動がリアルに感じられて、新しい問題に苦しんでいる気がする。もし、実際にサービスが単一のプロンプトからデプロイされることになったらどうしよう。以前はAIにコードを書かせていたけど、デプロイやその周りのことに興味があった。今は、そういうことを本当にきれいにやってくれるサービスがあるから（私はエージェントのハイプにはあまり乗らず、主にブラウザのLLMを使ってた）。一方で、プロジェクトを作る自由を感じるけど、プロジェクトの喜びは完全に減ってしまった。私はまだジュニア開発者の一人だから、AIが知らないトピックでコードを書いたりプロトタイピングするのは素晴らしいと感じていた。まだ、生成されたコードをコピー＆ペーストしたり、エラーを見たり、自分で試したりしていたけど、AIがそれを全部やってしまうなら、どうなるんだろう。最近、AIに対してあまり興味を持てなくなっている。プロトタイピングにはかなり使ってきたけど、最近のサービスでの完全にループから外れたプログラミングは私には非常に不自然に感じる。AIのために何かを買うと、その「価値」を最大限に引き出そうとする感覚がある。おそらく、あいまいな用語を使ったり、非常に小さなテキストファイルを入力として持っていると（例えば「Y言語でXの代替をやって」）、アーキテクチャの決定を理解できなくなってしまう。おそらく、明確にアーキテクチャを定義する仕様駆動開発か、最近見たPrimagenがやっていたように、AIが特定の関数のコードだけを操作するような開発が必要になると思う（ファイルに対してもそう想像している）。今は、何を作ったのかわからないことが多いから、もっと楽しめるかもしれない。ブラウザを使って遊びながらシングルファイルプロジェクトでプロトタイピングすると、依存関係や関数名から、始まりと終わりでコードがどんな感じで使われているかのアイデアが得られる。少し長くなったけど、これを感じさせるのは、誰かと話していて、AIとサーバーのサービスを紹介したときに、彼らがプロンプトで何かを求めて、私がそれを書いたんだ。その後、AIに仕事をさせたけど、自分がどうアーキテクチャを考えるかも考えていた（それは食べ物を検出してBMRを見つけるもので、最初はAPIを使おうと思ったけど、難しいかもしれないと思って、AIビジョンモデルを使おうとした）。それで、何が最適かを考えて、Geminiの無料プランを使っていたら、実際にそれを超えてしまった（おそらく私のキーのレート制限でうまくいかなかったかもしれないけど、正直言って、私もそれを試しただろう）。だから、AIがコードを書くのが早くても、私が作るアーキテクチャの決定を誇りに思っていたのに、それも奪われてしまった。正直、AIのコードを読むのがあまり好きじゃないから、今の時点では自分でコードを書く方がいいかもしれない。手を動かして学ぶのもいいけど、公共の場で早く作るという態度には問題があって、楽しめなくなっている。プロジェクトにもっと積極的に関わるべきだと感じ

でも、LLMが「正しいこと」をするって信頼できないなら、どうやって責任あるビルダーになれるの？例えば、あるプロジェクトのために最高の候補者を選んだソフトウェアチームのリーダーだとしたら、あなたのアイデアや意図を実現するためにチームメンバーを信頼できるのは理解できる。でも、LLMエージェントにも同じ信頼を置けるのかな？よくわからない。たとえLLMが非常に信頼できることが証明できたとしても、AIエージェントが責任を持たない存在だから、状況は人間とは全然違う。

もしかしたら、中間のカテゴリーがあるかも：ソフトウェアのデザインが好きな人たち？俺は、コーディングも楽しむけど、システムデザインの方がもっと魅力的だと思う。それは、ただ問題を解決するように見える不透明なアーティファクトを作るのとは違うんだ。

これは例としてはあまり一般的じゃないけど、3ヶ月かけて「夜と週末」のプロジェクトとしてリリースしたものだ: https://apps.apple.com/us/app/skyscraper-for-bluesky/id67541... 2009年からモバイル分野で働いてるけど、主にデザイナーとして、その後プロダクトマネージャーとして。今はエンジニアリングとPMのハイブリッドな仕事をしてるけど、特に強いプログラマーではない。こんなに洗練されたものを作れるとは思ってなかったし、ましてや3ヶ月でなんて。コードベースは約98%がClaudeのコードだよ。

ClaudeとCodexは、ローカルマシンや開発環境でプロジェクトに関するコンテキストをLLMに与えるためのCLIツールだよ。「ChatGPT」という名前を使ってるってことは、大きなコードベースで作業するためにウェブベースのChatGPTインターフェースを使ってるってことだと思うけど、それはこの議論の本質から外れてる。ここで話してるツールじゃないよ。

彼が話してるのは、11月/12月頃にリリースされた特定のモデル群についてで、モデルの能力に関してある種の転換点に達したってことを理解するのが重要だよ。具体的には、AnthropicのOpus 4.5モデル。俺は異なるモデルにあまり注意を払ってなかったけど、どれも大体同じに感じてた。でもOpus 4.5は本当に違う。質的な違いではなくて、定量的なエッジにやっと達した感じで、日常的な作業にもっと依存できるようになった。ぜひ試してみて、Claude CodeやCursor、OpenCodeのようなしっかりしたコーディングエージェントと一緒に使ってみてほしい。俺はかなり複雑なモノレポで使ってるけど、印象はKarpathyとほぼ同じだよ。

どれくらいの大きさが「十分大きなコードベース」なのかはわからないけど、私たちには100万行のJavaアプリがあって、それは約10年前のもので、POSシステムを動かしてるんだ。Claude Codeはそれに問題なく対応できてるよ。各モジュールの詳細な出力を含む完全な分析も行ったし、具体的な問題を特定するのにも使った。ここではバイブコーディングは使ってなくて、分析だけだね。

ほとんどの場合、こういうメモはグリーンフィールドプロジェクトについてのものになるね。既存のコードベースに組み込もうとするのは（特にエンドユーザーがサポートとのやり取りから遠い場合）まだ愚かなことだと思う。ただし、しっかりレビューされたビジネスロジック以外の変更なら別だけど。とはいえ、シンプルなアーキテクチャを設定したり、ファイル名をリストアップして、エージェントに実装させるのはかなり印象的だよね。でも、ある程度の複雑さを超えると、実際の結果を見るためにはどんどん細かいところまでプロンプトを近づける必要があると思う。非技術的なプロンプターは、特定のプロトタイプの忠実度の閾値を超えることはできないし、成熟したコードベースに意味のある貢献をするのは難しいんじゃないかな。

私が$dayjob$で扱っているコードベースはレガシーで、20,000行のファイルが数個、10,000行のファイルがいくつかある。コードベースの中で物を探したり、つながりを見つけるのが難しい。まだLLMがその規模のコードベースをナビゲートして理解するのは無理だと思う。でも、最近ここで見かける大規模なプロジェクトは、何千ものファイルと何百万行ものコードを含んでいるものが多いね。

私の場合、golangのサーバーインスタンスとコア機能パッケージだけで、clocが4万行以上のコードを報告している。他のサポートパッケージは含めていないけど。先週はクロードに外部認証システムを引き剥がして、自家製のものに置き換えてもらった（その変更をGPT-codexにレビューさせた）。何より、クロードのおかげで、大きなコードベースを持つソロファウンダーとしては楽になった。1年前に書いたコードを再び慣れ親しむ必要がなくて、全体像を説明して、いくつかの重要なファイルを指示して、何をすべきかを考えてもらうだけ。grepや言語サーバー、他のツールを使って、何が起こっているかを探れる。さらに、重要なファイルを含む「エピック」をマークダウンで書かせて、次回のセッションでどのファイルを読むべきかを知ってもらうようにしている。このプロセスは本当に楽しかった。TFAが言うように、注意深く見守る必要があるけど、全体のプロセスはずっと楽で、普段よりも多くのことをやれた。

「ChatGPT」って何を指してるの？chatgpt.comにコードをコピペすること？AI支援のコーディングはそんなことじゃなかったし、それはひどいことだよ。典型的なワークフローは、選んだモデル（ほとんどがOpus 4.5がリリースされる前のAnthropicモデルのSonnet）を使ってCursorを使うことだった。最近では（IDEに加えて）Claude CodeのようなCLIツールを使うことが多い。OpusやCodex CLIと一緒にGPT Codex 5.2 high/xhighを使って。

大きなコードベースでは、特にごちゃごちゃしていて相互作用が明確でない場合、ほとんど役に立たないように見える。コードベースやそのごちゃごちゃした相互作用を説明するドキュメントはどんなものがある？それをLLMに提供した？それと、チームに新しく加わった人に、LLMに与えたのと同じタスクと情報を与えたことはある？その人はLLMと比べてどれくらい効果的だった？ > ClaudeがChatGPTよりどれだけ優れているかは分からないけど、ChatGPTには既存の大きなコードベースで役立つことがあまりできない。あなたのコメントからも分かるように、AIコーディング専用のツールを使ったことがないように聞こえるね。（でも、たとえ使ったとしても、十分なコンテキストなしでLLMに何かをさせようとしたら、失敗するだろうけど。）

1. 良いドキュメントを書く、アーキテクチャ、動作の仕組み、コードスタイルなど。 2. 重要な依存関係のソースコードを同じディレクトリに置く。例えば、プロジェクトに_vendorディレクトリを作って、使っているタグと同じコードベースを入れる：Postgres、Redis、Vueなど。 3. 良い計画と要件を書く。受け入れ基準、コンテキスト、ユーザーストーリーなどをMarkdownファイルに保存する。それを何度もLLMとレビューして弱点を見つける。その後、実装ファイルに移って、何を変更するのか、なぜ変更するのか、何を生み出すのかを詳細に書かせる。 4. とても良いプロンプトを書く。LLMは明確な指示に従うけど、「あなたは積極的にXをするべきだ」は、「あなたはXをしなければならない」という意味では弱い指示だ。 5. LLMは完璧からは程遠く、限界がたくさんある。Karpathyがその欠点を長いリストでうまくまとめている。彼らの限界を知らないと、期待を誤管理して、彼らが大きな助けになるときに使わず、うまく対処できないことに時間を無駄にすることになる。それに加えて、すべてのLLMは「個性」が異なり、指示に従う度合いや創造性も違う。

こういう場合、少なくとも50%の確率でどこかでショートカットを取ってる気がする。ユニットテストがカバーしてないところで新しい大きなバグを作ったり、誰も文書化しようと思わなかった「暗黙の」要件を壊したり。これらは微妙で、探してないから気づかない。人間ならそんなこと考えないからね。もし気づいても、AIは「今、問題がわかったよ。もう少しコインを入れてくれれば、今回は本当に直すから、約束する！」って感じ。

それは安くなるかもしれないし、そうでないかもしれない。もし安くならなかったら、これは人類の歴史で初めて安くならなかった技術になる。（でも、昨年の半分のコストにはすでになってるけど）

最適化と新しいハードウェアのおかげで、電力はほとんど無視できるコストになってる。kimi k2では5.5Mトークン/s/MWが得られるから、今の価格の400倍安いんだ。今はNvidiaやTSMC、他のメーカーが利益を吸い上げてるだけだね。俺の予想では、中国は5年以内に現在のNvidiaに追いつくと思うよ。 [1]: https://developer-blogs.nvidia.com/wp-content/uploads/2026/0...

Linuxカーネルが動いてるのを見るのもすごいよね。スレッドのスケジューリングや、割り込みやAPIコールをこなして、全然汗をかかずにACLを傷つけることもないんだから。

この引用、私にも印象に残った。ちょっと違う理由でだけど。「粘り強さ」っていうのは、少なくとも過去20年のテック業界で成功するための秘訣だと思う。どの業界にも独自の複雑さがあるけど、新しいプロトコルやフレームワーク、パラダイムで稼いでいるエンジニアがいる一方で、10人以上がその無数のピースを組み合わせて、増え続ける複雑さを乗り越え、決して諦めないことで価値を提供している。粘り強さが足りないせいで道を外れた人たちも見てきたよね。ブートキャンプを辞めた人や、再帰に初めて直面して専攻を変えた学部生とか。頑固に「続ける」っていう特性は、分析能力やリードコードのスキル、企業政治のようなソフトスキルよりも重要だと思う。これが雇用市場に何を意味するのかはわからないけど、粘り強さだけでは足りないかもしれない。でも、私の中では、従業員にとって最も価値のある資質だし、クロードにはそれがある。

私にとって、この粘り強さは、誰かがハンマーで板にネジを打ち込もうとしているのを見るようなもの。もっと良い、早い方法があることが多いし、短期的には目標に達するかもしれないけど、その過程で長期的な問題を引き起こすことが多い。

そして、あなたはおそらく実際のコストを支払っていない。これはAIに対する最も弱い姿勢の一つだ。「バブルで、無料のVCマネーが止まったら、何も残らない」みたいな。これらのモデルを運用するのがどれだけ高価か、まるで謎のように言っているけど。今、Kimi K2.5やGLM 4.7のようなオープンウェイトモデルがある。これらは非常に強力なモデルで、トップラボから数ヶ月遅れているだけ。スケールで運用するのもそれほど高くない。計算してみて。実際、これらのモデルを利益を上げて提供している第三者もいる。お金がかかるのはこれらのモデルをトレーニングすること（中国のモデルのように効率的であれば、それほどでもない）。一度トレーニングされれば、推論コストに比べて大きな利益率で提供される。OpenAIやAnthropicは、間違いなくモデルを運用するコストよりもはるかに高い価格でAPIを販売している。

どこかで、GPUやNPUが熱く動いている。設計された温度で動いている。 > 必要なデータをすべて送信する、普段は共有しない情報も含めて。GitHubやクラウドプロバイダーにすでに保存されているデータを送ったことがないから、そこに違いはない。 > そして、実際のコストを支払っているわけではない。だから？投資家の補助金が止まってコストが倍になったとしても、それほど変わることはない。コンピュータの歴史全体を見ても、物事は安くなる傾向がある。 > あなたとあなたのビジネスは、この主要なゲートキーパーに依存することになる。そんなことはないよ。ClaudeとGemini、あるいは新しい競合の間を切り替えるのはかなり簡単だ。私は他の100のビジネスサービスやプロバイダーに依存しているのと同じくらい、これにも依存しているわけじゃない。

それはまるで「ドゥームスクロール」に似てると思う。ドゥームタブ？もっとクリエイティブになれるはずなんだけど、AIがすでに動いてるから、次に何をするかを見るのがすごく簡単なんだよね。だから、完成するのを待ってるだけで、完成したらまた新しいことを頼むだけ。ドゥームスクロールみたいに、1分間何かを見て、次にスクロールして新しいものを見るって感じ。進歩の概念が完全に偽物に感じる。なんか、ずっとAIをウェブブラウザで使ってた時期にいた気がする（チャットGPT3が出たときみたいに）。無料だったからワークフローは変わらなかったけど、最近新しい無料サービスが出てきたから変わった。「ドゥームタブ」や完全にループから外れたAIエージェントプログラミングは、楽しさを奪ってる気がして、コードを書くのに特に興味があるわけじゃない自分がいる。長い間AIを使ってコードを書いてきたから。自分はコーダーよりもコンピュータいじりが好きだと思ってたから、AIがコーディングに来たとき、いじりのスキルが向上した（以前はできなかった好奇心からのプロジェクトが作れるようになった）。でも今は、AIエージェントが自律的に動くようになって、いじりが奪われた気がする。自分のいじりの能力や興味、知識、経験が考慮されてない気がする。AIエージェントがマルチファイル構造でコード全体を書いて、コマンドを実行して、ウェブサイトに直接デプロイするから。つまり、いじりはアクティブな趣味だったのに、今はパッシブな趣味になってる。ドゥームいじり？なんか、心の中で感じてたことにちょっと早く気づいた気がするけど、これを感じてるのは自分だけなのかな？自分が感じてることに名前をつけるとしたら、何だろう？

これは脳の萎縮だけじゃないと思う。モデルの使い方を学ぶことに集中するために、私たちが積極的にトレードオフをしているのが一因だと思う。自分の脳を使ったり、お互いに協力する方法を学ぶのではなく。これ自体は問題ないけど、ひとつだけ問題がある。それは、LLMの使い方を学ぶというメタスキルも価値が下がること。今日のLLMはいつか消えるし、使い方も変わる。新しいモデルの使い方を学び続ける永遠のトレッドミルに乗っている感じ（しかもそのためにお金を払わなきゃいけない！）。自分を依存させたり、萎縮させたり、ずっとトレッドミルを走らせるつもりはない。借りているもので、手元に残せないもののために。もし依存してもいい安いハイが欲しいなら、もっと楽しいものが他にあるよ。

LLMにはひどいパターンがあるけど、どうすればいいの？クラス名をServiceにして突っ込むだけだよ。クソみたいなものには本当に気をつけないとね。

俺の失望は、自分の仕事をコスプレしてるだけって感じから来てるんだ。コスプレイヤーの中で何が違うのか分からない。今や、ソフトウェアをデリバリーしてるだけで、自分がコントロールしてるわけじゃないんだよね。

私の経験は逆だな。しばらくの間、頭を使ったことがなかった。文字を打つことが、開発者が評価される理由じゃなかったし。作る楽しさも戻ってきたよ。

私もそんなことを考えてた。LLMは、みんながリールやティックトックにハマっている時に登場したみたい。なんでか知らないけど、私たちはスワイプ、スワイプ、スワイプして、面白いことや衝撃的なことを探している。そうすると、1秒間だけ気持ちいいドーパミンが出て、もっと欲しくなって、またスワイプする。LLMを使うのもほぼ同じ。時々「わあ！こんなの見たことない！」って瞬間があって（それが役に立つかどうかは別として）、短い気持ちいい瞬間を得て、また別のヒットを求めて使い続ける。ちょうどティックトックと同じように、ちょうどいい間隔でそれを提供してくれる。

もっと書くべきだと思うけど、最近似たようなことを感じてるんだ。最近、デフォルトとしてClaudeのコードやCodexを使ってみてるから、サイドプロジェクトを始めることにした。過去にAIツールに対して不満だったのは、私がやってる仕事が大きくて複雑だから。以前のモデルでは、十分なコンテキストを提供したり、大きなアプリケーションでのコンテキストの劣化に対処するのが効率的じゃなかったんだ。特に、そのアプリケーションがオンラインにたくさんの例があるわけじゃないからね。今、RustでBevyを使ってサーバー権限のあるマルチプレイヤーゲームを実装しようとしてる。Bevyを選んだのは、最新バージョンがClaudeのカットオフ後で、いくつかの破壊的な変更があったから。深い例もあまりないしね。全体的にはうまくいってるけど、一つの欠点は、コードを「自分の骨の中で理解していない」ことなんだ。もし明日、レイテンシを最適化しなきゃいけないとか、1/100のエッジケースがあったら、どこを見ればいいかも分からないし、ゲームエンジンがどう動いてるかも説明できないと思う。過去には、自分のツールを本当に理解しないとここまで来れなかった。今は半分機能するゲームがあるけど、正直言ってECSが何か、その利点が何かも分からない。これって大きな問題だと思う。もしこれを本番で維持しなきゃいけなくなったら、SEV0バグが出た時に、修正できる自信があるか？それともモデルが解決できる自信があるか？モデルがコードベース全体をスキャンして解決策を直感的に見つけられるほど優れているか？この3つの質問には答えが必要だよ。さもないと、脳の萎縮が現実のリスクになる。

最近、特定のデザイン目標を設定した場合、それに従うはずなんだけど、数回の反復の後にはまた忘れて元のアプローチに戻ったり、二つを混ぜたりすることがある。コンテキスト管理や適切なプロンプト、明確な指示、適切なドキュメントはまだ重要だよ。

「脳の萎縮」について心配してるんだけど、これ、私も感じたことある。萎縮だけじゃなくて、むしろ「自己満足」に進化してる気がする。MLの出力を信じないことが第一歩で、それが知的に関与することを保ってくれるんだよね。でも、ほとんどの問題を自分で解決するのとはまだ遠い感じ（結局、MLがうまくできなかった問題だけを解決してる）。第二歩として、面白い仕事とつまらない仕事を分けて、クラウドが後者のペアプログラマーになるんだ。アイデアをぶつけたりして、知的なゴムアヒルみたいに使ってる。RESTコールでDBから顧客を取得するようなつまらない作業には飽きちゃうけど（でも、出力はちゃんと確認するよ）。

自分のスキルレベルがリードよりまだ数歩遅れてる気がするし、もっと経験を積もうとしてるんだけど、今の段階でAIに頼りすぎると自分の足を撃ってるんじゃないかって不安になる。学びたいと思ってるシニアエンジニアは、コードの質を見極める判断力がすごく高いから、AIを上手に使いこなしてる。私もAIを使いすぎると、自分の判断力を磨くチャンスを逃しちゃうかも。難しいジレンマだね。

明らかにプラスだと思うのは、純粋なフロントエンドコード（HTML + Tailwind）だけ。スパゲッティだけど、視覚化だけだから大丈夫。これって、FrontPageやDreamweaverのWYSIWYG時代に戻ったみたいだね。うわぁ。

アメリカの軍事産業は、もうGrokを軍事システムに統合する計画を立ててるんだって。コメントは特にないけど。

ちなみに、人間にも同じことが言えるよね。だから、そのボタンの周りにはめっちゃ手続きやら規制があるんだ。リスク管理はできるし、LLMの使い方でもそれを選ぶことができる。もし、常に100%正しい全知全能の機械の神みたいな幻想を信じるなら…結局、自分たちを責めることになるよね。手動でそのボタンを押し続けてた方がマシかも。

完全に不慣れなドメインやスタックの一部でコードをレビューするのは、LLMが登場する前から難しかったよ。