正直、これを使うと、立ち止まって計画を立てることを強いられる。雑用のコーディングや低レベルの分析・テストは任せられるけど、デザインの責任は自分にあるべきだ。これのおかげで、タスクにかける時間の中で大局を考える時間が増えるから、その点が好きだ。ツールがユーザーに変更や提案を提示する方法には、まだまだ改善の余地があると思う。もっとインタラクティブになるべきだね。

GoogleのGenie 3が内部状態を失うまでに約1分しか動かないことを思い出させるね。私の直感では、この問題はトランスフォーマーのような新しいアーキテクチャが発明されるまで解決されないと思う。短期的なコンテキスト、長期的なコンテキスト、モデルの重みの自己調整（「学習」を模倣するため）を可能にするものが必要だと思う。（免責事項：機械学習の正式な訓練を受けていない趣味者です。）

最近これについて考えてたんだけど…今のところ、エージェントの階層を作って、最上位のエージェントが一般的なメンタルモデルを維持するっていうのが、もっと実用的な解決策かもしれないね（「下のエージェントがこのタスクは完了したって言った」以上のことはコンテキストに入れない）。一つのコードエージェントにすべてを任せようとすると、結局どこかでおかしくなることが多いし、元の指示の重要な詳細を無視したり、CLAUDE.mdに従ってるか確認しなかったりする。今はコードのエージェント機能でこれができると思うけど？誰か戦略を共有してくれない？

同じく。これを使って少し助けられたツールがあるんだけど: https://github.com/rizethereum/claude-code-requirements-buil... それと他のトリックで、少しはイライラが減ったかな。

これって「普通の」プログラマー、特にジュニアプログラマーとそんなに違うのかな？ > LLMは無限に混乱する：自分が書いたコードが実際に動くと思い込んでいる。テストが失敗すると、コードを直すべきかテストを直すべきかを悩む。フラストレーションが溜まると、全部削除してやり直す。これって、普通の開発者でもよく見かける光景だよ。手探りで、いろいろ試して、StackOverflowからコピペして理解せずに、最終的にはコンパイラにバグがあるか、宇宙線がビットをひっくり返してると思う。

LLMの401って、同じ一つの決定不可能なトークンじゃない？これって、コンピュータサイエンスにおける数学の決定不可能性に繋がるんじゃないかな？言い換えれば、アカウントを持つ人々に対応するエクセルの名簿があって、一部のアカウントを停止する必要があるけど、識別子として名前しか持っていない場合、同じ名前の人が複数いるから、すべてのアカウントを停止することはできない。ユニークな識別子がないとどう解決するの？決定不可能なものを区別するためのユニークな識別子を求めなきゃいけない。それがなければ、その人もタスクを実行できない。人は推測はできるけど、その推測は悪い結果を繰り返す確率が高い幻覚に過ぎない。根本的に、こういった問題は解決されないと思う。多くの人がこの例を解決できずに苦しむだろうね（答えが与えられなかったり、タスクの枠組みで解決策を示唆されなかった場合、つまり名前のリストだけを渡されて不可能なタスクをやれと言われたとき）。

最初の車はいつも故障してた。航続距離も限られてたし、部品の供給も少なかった。修理できる専門家もほとんどいなかったし、燃料スタンドのネットワークも整ってなかった。馬は実績のある方法だった。今、LLMができないことは、業界の変化の波の中ではほとんど関係ない。改善が進めば、明日にはLLMができるようになるかもしれないんだから。

プログラマーは主にビジネスルールをコンピュータの非常に形式的なプロセスに翻訳している。ルールの意味とコンピュータの動き（少なくとも自分が使っている抽象化されたバージョンの動き）を理解する必要がある。翻訳は最初はごちゃごちゃしてるから、何度も見直す必要がある。特に後から来るルールが、これまでの仮定を挑戦したり、矛盾したりすることがあるからね。人間の言語間の翻訳（曖昧さを許す）でもごちゃごちゃすることがある。もし対象言語が、誰かがその行動を悪いと判断しない限り、指示通りに動くシステムのためのものであったら、想像してみて。

AIは、権限不足の場合は401じゃなくて403を使えって言うかもしれないよ。

あの参照リンクは、無資格で漫画みたいな受動攻撃的な内容が満載で、著者の「スワッグ」への可愛いリンクがさらに追い打ちをかけてるね。偶然にも、数日前にポッドキャストのゲストとして著者の作品に初めて出会ったんだけど、彼は「ダーティコード」アプローチを支持しつつ、アンクルボブの一般的な原則をストローマン論法で批判してた（ほとんどの場合だけど）。こういうのがTシャツやマグカップを売るんだろうね。/rant

君に同意するけど、「グルグ脳」って表現はちょっと失礼だよね。みんな、どこかでグルグだった時期があるんだから。

俺はもっと実践的なアプローチを取ってるよ。すべては人間が関与している。これが仕事を早く、質高くこなすのに役立つから、使ってるんだ。

少なくとも俺の場合、頭の中に大量のコンテキストを詰め込めるんだ。これは、テキストが全く関係なくてすぐに捨てられるからうまくいく。代わりに、脳がコードをASTのようなものに解析して、それが空間グラフとして表現される。プログラムをテキスト的なものではなく、論理的な構造としてモデル化するんだ。言語を超えて見ることで、プログラムに取り組むことができる。二つは全く別物なんだ。LLMがソフトウェアで失敗するのは、テキストに焦点を当てていて、プログラムの論理のメンタルモデルを構築できないからだと思う。何かを本当に設計して、大規模なシステムを理解するには、膨大な努力と頭脳が必要なんだ。LLMにはその抽象的な推論がないんだよ。

エラーコードを処理するコードをLLMに生成させられないなら、それは自分の責任だよ。確かに、時々変なことするけど、気にしないで。/undoして再試行すればいいだけ。Claude Codeを使うのはやめた方がいいよ、あれはまるでインターンがgitを使ってるみたいだから。（つまり、強制されない限り使わないってこと。）

• 失敗したテストの報告があったら、まずテスト対象のコンポーネントを特定しよう。コンポーネントについて深く考えて、その目的や制御フロー、コンポーネント内で発生する状態変化、コンテキストに対する仮定を説明してみて。分析結果は「component-name-mental-model.md」というファイルに書いておこう。 - 失敗したテストに対処する時は、必ずコンポーネントのメンタルモデルを考慮に入れてね。それをClaudeのプロンプトに貼り付けて、より良い結果が得られるか試してみて。LLMのメンタルモデルを読み取って修正することもできるよ。

うん。完全自律型の、100% vibe codedなサイドプロジェクト「steadytext」を始めたんだけど、最初は壁にぶつかると思ってた。LLMが非自明なバグを維持したり修正したりするのが難しいだろうなって。でも、間違ってたみたい。Claude Opusは、Pythonライブラリ、CLI、Postgres拡張を含むかなり複雑な7,000行のプロジェクトを作成できたし、それを自分で維持して、報告された問題や機能リクエストも完全に自動で修正できる。完全にvibe codedで、リポジトリの90%のコードを見たこともない。テストカバレッジも完全で、CIも通って、実際に運用でも使ってる！もちろん、CLAUDE.mdのためには慎重な計画が必要だし、すべての問題や機能リクエストには詳細な仕様が必要だけど、うまくいってる。だから、この件には100%納得してるわけじゃない。コーディングエージェントが効果的にソフトウェアを管理・作成するのは簡単じゃないし、特に既存のプロジェクトでやるのは難しいけど、私の経験はその全範囲にわたってる。コーディングエージェントにはがっかりさせられたこともあったし、いくつかのプロジェクトや数十のプルリクエストを放棄したこともあるけど、うまくいったことも見てきた。プロジェクトはここでチェックできるよ: https://github.com/julep-ai/steadytext/

これがKiroのアプローチなんだけど、まだ始まったばかりだよ。完璧ではないけど、その意図に従えばかなり良い結果が出るよ。

いいポイントだけど、LLMは能力が本当に頭打ちになってきてるよね？GPT-2クラスのモデルから3への改善はかなり大きかったけど、3から4はそれほどでもなくて、4から5もあんまり変わらなかった気がする。ここ数ヶ月、コーディングの文脈でLLMを使う際に見た雰囲気の変化は、データセットのキュレーションやUXの改善であって、根本的に良い技術ではないと思う。

こういうのって、選択的な後知恵だよね。残って成長した少数の製品だけを覚えていて、大半の製品が新しさが薄れた後に消えていったり、結局は停滞したことは忘れちゃう。俺はこの記事の著者に同意するよ。技術が最終的にはそこにたどり着く可能性はあるけど、今はそうなってない気がする。だから、未来の理想をただ信じるんじゃなくて、現実に基づいて判断したいんだ。

LLMがここ数年でX倍良くなったから、これからもX倍良くなるっていう主張には賛成できないな。見ている限り、成長は主にいくつかの技術を最適化した結果だと思うけど、ローカルマキシマにハマる可能性が高いんじゃないかな（実際、そうなる可能性が一番高いと思ってる）。特に、LLMの限界は新しい知識を発見したり、見たことのない情報について推論することだと思う。例えば、ブルーベリーの中のbの数を数えたり、問題文にランダムな猫の豆知識を挿入して気を散らすことができない（最近見かけた問題だよ）。無駄なツールだって言いたいわけじゃないけど、過剰な期待には乗りたくないな。

一方で、これらの技術に対する期待は現実に合わなかったことが多いよね。これは、克服するのが簡単じゃない物理的な制約が原因だと思う。インターネットは速くて安定してきたけど、メタバースが普及しなかったのは、多くの人が少しでも酔ってしまうからで、10倍のスケーリングでは解決できなかった。君が「つまらない」と言ったことの多くは、その当時は「つまらない」とは見なされていなかった。携帯電話が遅いなんて誰も文句を言わなかったし、今のように使うとは思っていなかったから。インターネットも遅くて安定性がなかったけど、誰も文句を言わなかった。4K映画をストリーミングできるとは思ってなかったからね。これは時代錯誤だよ。XやYの方法でいくつかのことが改善されたからといって、LLMが君が思うように改善されるとは限らない。もしかしたら、もっと良い技術が発明されるかもしれない。ダイヤルアップ自体が速くなったわけじゃないし、ダイヤルアップ技術が1Gbpsの速度を提供するなんて言ってるファナティックはいなかったと思う。AIの問題は、コンピュータのスケーリングがブレークスルーをもたらしたから、スケーリングといくつかの技術的トリックで現在の問題を解決できると思っている人がいることだよ。誰もがこれを克服できる技術を発明できないとは言えないけど、LLMがその技術だと考えるのは疑問視されている。去年あたりから多くの洗練と応用の広がりがあったけど、ブレークスルーには至ってないね。

携帯電話はダメだったし、3G以前は遅かった。アプリストアやカメラがポテト品質になる前は、あまり使い道がなかった。 これは歴史の大改変だね。携帯電話が普及したのは、モバイルフォンがなかった時代は、家やオフィスにいる時にしか人に連絡できなかったから。人々は今では懐かしい時間帯に連絡が取れなかった。テキストメッセージが非同期をもたらしたんだ。「ポテト」カメラは、常にカメラを持っていることの始まりだった。ノキア3210を使っていた人たちは、自分の携帯電話が良くなることを期待していたわけじゃなくて、すでにそれ自体がキラーアプリだったんだ。それが改善されたのは、ただのボーナスだよ。

今、ホバーボード、自動洗浄シャツ、月面基地、飛行車、機能する民主主義、そして「スノークラッシュ」で描かれているVR技術について考えてみて。LLM（大規模言語モデル）は、どの位置に入るんだろうね？

3Dプリンティングで車が作れると思ってたけど、残念ながらそうはならなかったよ。ちなみに、3Dプリンティングはかなり進化したし、私も3Dプリンターを持ってる。でも、製造業を完全に変革するっていうのは単純に違うと思う。限界があるからね（木のポリマーを金属の先端から押し出すのってどうやるの？）。その限界は物理的なもので、技術的なものじゃないんだ。

LLMは今はソフトウェアを作れないかもしれないけど、2022年にチャットGPTを使い始めた頃より10倍は良くなってるよ。5年後にはこういう開発タスクができるようになるって考えるのは妥当だと思う。5年後にはもっと良くなるだろうけど、君の最後の主張はちょっと違うね。記事に書かれている問題を具体的に解決できるとは確信を持って言えないよ。もしかしたら、LLMが得意なことじゃないかもしれないし、新しいブレークスルーが必要になるかもしれないね。

人々はVRについてもたくさん文句を言ってたし、NFTにも大きな反対者がいたよね。そして、他にもたくさんの解決策について文句を言ってた。でも、それでも多くの投資家がVRやNFTで大金を稼いでいたんだ。投資が良いからって、何かが役に立つってわけじゃないよね。

Twitterはクソだった [...] 電気自動車もクソだった [...] スマホもクソだった これらのものはブラックボックスじゃなくて、ほとんど決定論的だよ。入力に基づいて、出力が何か正確にわかる。LLMの場合はそうじゃない。どうやって訓練されて、内部でどう動いているかはわからない。入力を調整して望む出力を得る方法は確かにわかってきたけど、君が言った例と同じレベルで保証されるわけじゃない。それがLLMの根本的な問題だよ。そして、業界のプレイヤーがその問題を解決するためにどうやってソリューションを構築しているかを見ることができる。推論（思考の連鎖）は、決定木を狭めるための応急処置みたいなもので、LLMは本当に何かを「推論」しているわけじゃない。結果は、より多くのトレーニングデータでしか良くならない。実際、役に立つ結果を得るためには brute-force しなきゃいけない。最近のモデルリリースの停滞は、この技術にとってあまり良くない兆候だね。

私は、Railsのような既知のフレームワークでのCRUDには特にうまく機能すると思ってる。一方で、RustでDirectDrawを使ってネイティブWindowsアプリを作ろうとしたら、ひどい目に遭ったよ。もっとみんなが自分の作るものについてオープンになってくれたらいいのに。

モデルがハックやトリックを使って失敗したテストを通そうとするのは、よく文書化された行動だよ（ハードコーディングされた解決策とかね）。

今のところの経験では、「キャパシティ」をジュニアエンジニアに制限しているなら、特に以前に問題を見たことがある場合はそうだね。すぐに解決策を見つけて、その解決策が機能するか確認できる。でも、見たことがない問題にはあまりうまくいかない。その時は問題を説明して、解決策を指示する必要があるから、結局はメンターとしての役割を果たしてるだけで、自分で解決策を実装する能力を使ってるわけじゃない。私のチーム全体が、「claude-code」のやり方にすごくハマってて、何年もバックログにあったサイドタスク、例えば簡単なリファクタリングや二次的な分析システムに取り組んでる。基本的に、時間に制約されてるけど、誰もがやりたがらない道を進むのにぴったりなんだ。個人的には、コードの一部をハイライトして、LLMに「5歳の子供に説明して」って頼むのが楽しいし、潜在的なレースコンディションを探すのもいい。元のエンジニアが去った後も残ってる古くて脆弱なモノリシックなコードブロックを理解するのにLLMを使うのは魔法みたいだよ。でも、これらのものをより良く書けるわけじゃないのがポイントで、ここが重要なんだ。あまり見かけない新しいものを作るのは得意じゃないし、既存のスタイルとはかなり違うコードスタイルを持ってるから、コードを挿入するときは、周りのスタイルに合わせて書き直さなきゃいけないことが多い。すでに「AIが読むために書かれたコード」って言ってる人たちのささやきを聞いてるけど、それにはちょっとイラッとする。追加のメンタルバンド幅のための見返りが今はあまり価値がないように思えるから。

私の経験から言うと、これはプログラミング言語やプラットフォーム、ビジネスドメインによってかなり変わると思う。正直、Railsを使ったことはないし、Rubyにも何年も触れてないけど、そこでうまくいくのは驚きじゃないね。Ruby on Railsのプログラミング文化は、やり方がかなり一貫してるから。おそらく、それがLLMがトレーニングデータからある程度（もっといい言葉があればいいんだけど）まともなモデルを導き出せる理由なんだろう。一方で、Pythonに関しては結構混乱することが多い。私が一番困ったのは、いろんなPythonのコーディングイディオムがランダムに使われること。これがTDDを特に難しくするんだ。テストは、あるパターンの変更に従って設計されたコードに対してはうまくいくけど、全く違う変更パターンに従ったSUTに対しては全然合わないから。結果として、意味不明な理由で何度も壊れる脆弱なテストができちゃうんだよね。それに、そこからの反復もかなりややこしい。私のお気に入りのケースは、実際の欠陥が「クエリの結果をソートするのを忘れた」なのに、提案される解決策が「SqlAlchemyを取り除いてDjangoに置き換えろ」っていうやつ。Rコードはさらにひどくて、最初に仕様に従ったコードを生成するだけでも難しいことがあるよ。

1分間のネットリサーチで、君がアマゾンのマーケティングマネージャーだってわかったよ。だから君の意見には利害の対立があるし、それは開示すべきだね。