エージェンティックコーディングは罠である

6時間前原文(larsfaye.com)

概要

AIによるコーディングが主流となりつつあり、人間はオーケストレーターとしての役割に移行
コーディングエージェント活用の進展に伴うスキルの衰退やベンダーロックインなどの課題
**Spec Driven Development（SDD）**の普及と、その影響の現実的なリスク
AI活用による開発者の思考力や問題解決力の低下が懸念
責任あるAI利用とバランスの取れたスキル維持の重要性

AI時代のコーディングと人間の役割変化

AIエージェントがコードを書く時代の到来
人間は仕様策定・計画立案・レビューを担うオーケストレーター役
開発の流れは、要件定義→計画→AIによる繰り返し生成・修正→最終レビューというプロセス
コードとの距離が広がり、人間の直接的な実装機会が減少
エージェントの非決定性によるシステム全体の複雑化が進行

コーディングエージェント活用のトレードオフ

AIの非決定性による曖昧さを補うため、周辺システムの複雑化
コーディングスキルの衰退が広範囲で発生
Claude Codeの障害などによるベンダーロックインのリスク
ツール利用コストの変動と増加（トークン課金モデル）
成功には高度な批判的思考力とアーキテクチャ設計力が必要

スキル衰退とパラドックス

AI活用の過剰がコーディングスキルの急速な劣化を招く
Junior開発者は実装経験が減り、レビューのみで学習機会が半減
Seniorエンジニアもアプリケーションの全体像把握が困難に
Anthropicの調査では「監督のパラドックス」：AI管理には失われつつあるスキルが必要
LinkedInの事例：クリティカルシンキングや問題解決力が養われにくい

抽象化とAI時代の違い

過去の新言語や抽象化導入時の懸念は理論的・予測的だった
AIツールは実際にスキル低下や混乱を生んでいる点で異なる
コードを直接書く摩擦が学習や深い理解を生む
AI主導のワークフローでは、十分な経験を積まずに高レベルな管理を求められる
Seniorエンジニアでも「精神的モデル」の喪失を感じ始めている

コーディング＝プランニングの重要性

コードを書く過程自体が思考や設計の一部
仕様書だけでなく、型定義や構造設計を通じて初めて理解が深まる
LLMは曖昧さを前提とし、意図しない出力や「幻覚」も頻発
レビューや修正の手間、トークン消費の増加が生じやすい
AIに依存しすぎると、開発物との距離感が拡大

ベンダーロックインとコスト問題

ClaudeなどのAI障害時、開発チーム全体が停止する事例
AIモデル提供者への依存が急速に進行
トークンコストの予測困難・増大リスク
Primeagenの指摘：「完全なエージェント型ワークフローではモデルプロバイダーに支配される」
産業全体のクリティカルシンキング能力の外部委託化が進む懸念

AI活用の落とし穴と今後の展望

Anthropicの調査ではデバッグスキルが47%も低下
AIの責任ある活用で学習やスキル向上に役立てる道も存在
自己学習や実験の効率化にはAIが有効
バランスをとったAI活用と人間のスキル維持が今後の鍵
産業全体でスキルの持続的育成とAI依存のリスク管理が必要

Hackerたちの意見

AIツールを使ってアイデアを出したり、コードを生成したりしてるけど、実際には自分でタイピングしてるんだ。そうすれば、時間が経ってもメカニクスやプログラミング言語を忘れにくいからね。

└

まさに私がやってることだ。私だけじゃないって知って嬉しいよ。

└

同じく。俺もシステムプロンプトを設定して、完全な解決策やコードを書かないようにしてる。だから質問すると、短い10行の例や擬似コードを出してくれる。これだと考えやすいんだよね。それでもAIの提案の50%以上は却下してる。理由もなくコードを移動させたり、単に間違ってたりするから。

└

一つのアプローチとして、コードを書かせないように頼むってのがある。そうすると説明を強いられるし、自分でコーディングしてアイデアを試すことで、より理解が深まる。俺はメンテナンスが必要なコードにこのアプローチを使ってる。時々、モデルが間違った情報を混ぜることがあって（過去には正しかったけど今は間違ってることが多い）、それが痛い目に遭わせることもある。捨てられるような簡単に検証できるスクリプトは生成してもらうけど、オーバーエンジニアリングやすべてのコーナーケースを考慮しないように頼んでる。スクリプトでは、エラーが出てもそれが失敗のステップとして理解される方がいいからね。読みづらい言語（パワーシェルとか）は避けて、モニターに収まる短いものを生成してもらうのが好き。だから、全部読んで理解できる（Python、Bash、Batchが俺の定番スクリプト言語）。

└

そもそも、AIが忘れたことを思い出させてくれるなら、忘れることに意味があるのかな？

└

同じく。俺がやることのほとんどは、実装プランを求めることで、最小限のコードか、コードなし、または擬似コードをもらって、実際のコードは自分で書くって感じ。これはオープンソースの作業で、楽しみの全ては自分でコードを書くことだからね。もし全てがLLMにコードを書かせて、それをレビューするだけだったら、オープンソースのメンテイナーになる意味はないと思う。それは全然満足感がない。もしこれが実際の有料の仕事だったら、LLMの使い方がどう変わるか気になるな。俺がソフトウェア開発者でいる理由は、クラフトが好きだから。アイデアをコードに変えるために頭を使って作る行為…それが楽しいんだ。もしただLLMにプロンプトを送るだけだったら、その仕事を続けるだろうか？わからないな。少なくともキャリアを変えることを考え始めるかもしれない。

結局、コードの質は最終的に自分次第ってことだよ。エージェントと何度もやり取りして、自分が書くのと同じ質のコードになるまでやればいいんだから。

└

そうだけど、結局時間を節約できてるわけじゃないよね。

└

「...エージェントとやり取りして、自分が書くのと同じ質のコードになるまで」って言ってるけど、私は自分のコードの質じゃなくて、AGIのコードの質が欲しいんだよ。それが約束されたことだし、ジェットパックや空飛ぶ車もね！

└

自分でコードを書く方が速いし、イライラしない。目標が自分の品質基準に合ったコードを得ることならね。

└

あなたを止めるものは何もないけど…それよりも自分で書いた方が早いよ。AIによる生産性向上なんて神話だね。

この記事はちょっと的外れな気がする。AIを多用するとスキルが失われるのは確かだけど、ここで言いたいのは、AIが人を早くさせすぎてるってこと。早い出力が悪いとは言わないけど、コードを生み出すことに対する深い理解や経験が伴ってないんだ。ビジネスバリューについて語る人が評価されて、ちゃんとした知識を持って安全な決定を下す人が評価されないのはおかしい。AIは確かに良い解決策を生み出すけど、結局何をしてるのか分かってないし、最良のケースでも強力なオーケストレーターが必要なんだ。今はビジネス主導の開発の泥沼にいて、悪い決定に対する厳しい罰が与えられてない。

└

> ビジネス主導の開発の泥沼にいるよね。これをやってるのは企業だけじゃなくて、オープンソースプロジェクトでも表面上は問題なさそうな大きなPRがマージされてるのをよく見るけど、実際には1000個の小さなバグが含まれてる（致命的じゃないけど、ちょっとイライラするやつ）。さらに、そのコードはこの特定のプロジェクトにおいてイディオマティックなC++じゃなかったし、LLMは利用可能なAPIを完全に無視してた。確かに修正はできるし、メンテナはそれを見つけるべきだったけど、生成されるコードの量はみんなにとってものすごいエネルギーを必要とするんだ。

└

それには同意するけど、厳しい真実はほとんどの企業の優先順位が常におおよそ、いい加減なビジネス主導の開発だったってことだと思う。人間のエンジニアリングプロセスは、その哲学の最悪の結果をチェックするための偶然の産物であって、意図的なものではなかった。

面白いことに、エージェントを使ったコーディングで、ここ数年で使っている言語やシステム、ツールについて、35年の職人プログラミングよりも多く学んだ気がする。システムや技術、アプローチについての判断力はエージェントツールよりもはるかに優れてるけど、彼らはすごくよく読書したインターンみたいで、細かいことには詳しいけど経験がほとんどない。彼らは熱心に間違いを犯すけど、フィードバックを受け入れるんだ。たとえ理解が不十分で、すぐに忘れちゃうことが多いとしてもね。「自分が関わるすべてのことについて知っているべきだ」って主張はすごくナイーブだと思う。チームで働いたことがあるなら、完全に理解していないことがたくさんあるはずだし、古いコードベースで作業しているなら、ほぼすべての部分が馴染みがない。数十年にわたって構築された巨大なモノレポで働いているなら、みんなが専門家だと思っている部分すら理解できるかどうか運次第だよ。こういう主張をする人たちは、たいてい自分がすごくジュニアか、基本的に一人で働いているか、20年間同じプロジェクトで働いている人だと思う。チームや大きな組織で働いている人は、自分のコードベースのすべてを知っているとは言えないし、エージェントプログラミングをしている人も同じだ。でも、少なくともエージェントに質問をすれば、答えてくれるからね。大人になってから他の人のコードを読んできたから、LLMのコードも絶対に読める。機械がクソみたいなコードを書いたことと人間が書いたことに対して、全く気にしないし、少なくとも機械は私のフィードバックを受け入れて行動してくれるから。

└

この投稿は「自分が関わるすべてのことについて知っているべきだ」とは主張していないんだ。コードを書くことと、効果的にコードを読むことが本質的に結びついているって主張しているんだよ。

└

そうだね。砂をトランジスタに変えることやアセンブリについては全然知らないけど、うまくやってる。だから自分のフルスタックもわからない。大事なのは、システムの残りを学ぶことを恐れず、インデックスを保つことだよね。何よりも、何にでもすぐに対応できることが大事。それが広い範囲に対応できる秘訣。必要な時には深く掘り下げて、必要な時には高く飛ぶ。目の前の問題に適したレベルで。昔、大学で教えてたCSの人たちは、エンジニアリング全般を教えてた。「化学工学やアナログ制御システムをいつ知る必要があるの？」って聞いたら、「必要ないよ。コードを書くために十分に理解できれば、あとは忘れてもいい。強固な基盤を提供してるから。」って言われた。それは大きなコードベースの中でも当てはまる。

└

「やあ！ちょっと顔を出して、エージェンティックコーディングが実際に素晴らしくて、あらゆる面で自分を向上させてくれてるって言いたかったんだけど、同時に実は他の何かとあまり変わらないとも言いたい。だから、批判は個人の無知や偏見に起因するってことにしておこう。」

└

学習の加速も感じてるけど、適用できる技術やテクニックがかなり増えたんだ。ただ、人としては、AIが「非常に知識豊富なインターン」に与える影響が心配だな。特定の分野について深く知っている人と話すのは面白いけど、今ではほとんどの人がAIを使ってその分野についての深い知識を模倣できるようになってる。生産性はあるけど、人とのつながりが欠けてる。

└

> 「自分が関わっているすべてのことについて、すべてを知っているべきだ」という主張は、非常にナイーブなものだ。記事の中にはその主張はなかったよ。

└

自分が直接コードベースにコミットするコードのメンタルモデルを持つのは大事だと思う。それがエージェントが書いたものであったら、そうはならないからね。

└

あなたは35年の経験があって、新しい知識を習得するための学習能力や一般的なフレームワークをすでに持ってる。エージェントコーディングを自分の仕事を補完するツールとして使う方法も知ってる。でも、今日始めたジュニアたちはそれがないから、エージェントコーディングに頼りすぎて、自分が知らないこともわからないんだよね。

└

> 自分が関わっているすべてのことについてすべてを知っているべきだという主張は、非常にナイーブだと思う。俺はこの見解には反対だ。個人的には、自分が関わっているコードベースを詳細に学ぶことに誇りを持っていて、時にはそのコードベースのリードよりもよく理解していることもある。みんながそうするべきだとは言わないけど、達成可能で全然ナイーブじゃないと思う。

> システム管理者がAWSに移ったとき、ネットワークを理解する能力を失ったとは感じなかった。待って、これって俺が使ってるAWSと同じ？

シニア開発者として25年以上の経験があるんだけど、最近「ちょっと5分だけ参加してくれない？」って会議に急に呼ばれたんだ。こういう、何も知らされずに引きずり込まれる会議は本当に嫌だ。質問が次々と飛んできて、導入もなしに始まったから、外部統合についての話だったんだけど、用語も全然違うし、余計に厄介だった。質問を理解するのにすごく苦労したよ。実際、こういう統合を作るのにはモデルに頼りきりだったから（超退屈な仕事＋外部からの詳細な仕様書があったし）。モデルを使わなかったら、10倍の時間がかかってたと思うけど、今は「おおっ」とか「なるほど」とかの記録をちゃんと作って、こういう気まずい瞬間が二度と起こらないように考えてる。会議でこんなに無知で恥ずかしい思いをしたのは初めてだよ。言えたのは「それについては後で連絡するね」とか「これも、あれも」って感じだった。認知的負債は本当に存在するし、個人的には技術的負債よりも痛い！技術的負債はチーム全体で共有されるけど、認知的負債は個人のものだから、作った本人としてはもっと理解しておくべきだよね！続く…でもこれからは、仕事が終わったとは言えないな。ちょっとした5分間のフラッシュカードみたいな「これは何？」とか「これはあれ？」っていう用語集を作らないと。

└

どんな職場で、会議の途中で引き込まれて、文脈もなしに技術的な質問を次々に投げられて、その場で答えなきゃいけないの？ぜひ教えてほしい。きっと多くの人がそんな職場を避けたいと思ってるから。「これらの質問に正しく答えるには、ドキュメントとコードを勉強する必要があります」っていうのは、そういう扱いに対する全然悪くない（しかもすごく外交的な）返答だよ。

└

> シニアデベロッパーとして25年以上の経験があるけど、最近「5分だけ参加してくれない？」って会議に投げ込まれた。これは医者がよく不満を言うことだね。患者が来て、何かの薬の処方が必要だと言う。良い医者は、状況をしっかり理解するまで薬やアドバイスを出さないことが多い。シニアデベロッパーなら、嫌な行動に対して反発する役割がある。権限があるからね。「うーん、面白い質問だね。私の意見を言う前に、もう少しコンテキストが必要だよ。システムアーキテクチャの概要を教えてくれる？このアプローチで解決しようとしている実際の問題を説明してくれる？」

└

AIネイティブな会社では、質問をする人たちが自分たちのAIを使ってコードベースをクエリするべきだと思う。あなたが説明している問題は、まだAIを完全には受け入れていない組織に関連しているように思える。

> 「批判的に考えられるスキルのある開発者だけが、生成されたコードの何千行の中から問題を見つけることができる。問題が起こる前に。」追加の要因として、生成されたコードの問題を見つけるには、開発者が気にかける必要がある。多くの開発者（特に大企業では）は、すでに仕事から深く離れていて、チケットを閉じて最低限の努力で他人に責任を押し付ける方法を探している。そういう開発者たち、たとえ有能な人でも、生成されたコードを理解するために努力することはない。特に今のAI主導のスピード狂の時代では。

└

例外もあるけど、大企業では多くのチームの開発者が、気にかけることで実際に罰を受けることがある。

└

確かに。生成されたコードは、すべての意味的期待を破ってしまうから、読むのが難しいよね。生成されたコードは言語的には妥当だけど、よくあるイディオムを無意識に模倣してしまって、実際のバグがまともな人間（たとえ下手なプログラマーでも）には思いつかないような形で隠れてしまうことがある。LLMには内部評価がないから、レビュアーはそれを考慮して、1行ずつ評価し、隠れた理由や暗黙の知識を再構築しなきゃいけない。そうしないと、無関係なことに惑わされて高い時間を浪費することになる。ここまでくると、最初から書くよりも投資が深くなってることが多い。

AIを使って早くするのは、間違ったことを最適化している。私が働いたどの場所でも、「コードを書く」部分は、機能を実装するために必要な他のすべてのことに比べて、最も短い時間で済む。例えば、1日でコーディングする機能を考えてみよう。まず、会社が使うアジャイルやウォーターフォールの計画手法を使って、すべてを計画しなきゃいけない。タスクの分解をして、JIRAのチケットを作成し、誰が作業をするかを決める。それだけで数日から数週間かかることもある。次に、提案したデザインを含む設計書を書いて、仲間やチームメイトにレビューしてもらう。これも、重要な機能ならまた1週間かかる。複数のチームが関わる場合は、そのチーム間で合意を得る必要があるから、さらに1週間追加。場合によっては、作業を始めるための承認が必要で、これも承認者のスケジュールによっては数日かかることがある。次に、1日かけてコードを書いて、テストに合格することを確認する。次はコードレビューの時間で、これにはチームとのやり取りが多く含まれるから、何度も繰り返しが必要になって、さらにコードレビューが増える。これもまた「数日から数週間」の伸びがある。大きな会社では、法務やプライバシー、パフォーマンス、アクセシビリティ、QAなど、他の部門からのさまざまなレビューを通過する必要がある。たとえ並行して行われても、保守的に2週間追加しよう。最後に、ステージングにプッシュして、内部でドッグフードを試してもらう時間が必要だから、動作しているかの自信を持つために1週間追加。そうして、ステージングから本番にプッシュする準備が整ったけど、真面目な会社で働いているから、何も100%本番にすぐには行かない。徐々に立ち上げて、フィードバックやメトリクスを確認して、ロールバックが必要かどうかをチェックする。完全にローンチするまでにさらに2週間かかることもある。だから、デザインからリリースまで2ヶ月かかる機能があるのに、たった1日で終わる部分を5分に最適化しようとして、みんなが躍起になってるってことだよね…。

└

どんな会社で働いているかによるね。例えば、こんな風にスタートアップを運営することは絶対にできないよ。

└

どの会社もそんな風に働いてるわけじゃないよ。大手テック企業にはそういう無駄が多いけど、小さい会社はもっと素早くて機敏に動けるからね。

└

それはエージェントの自動化の度合いや、どれくらいの時間動かすかによると思う。エージェントでソフトウェア全体を作ろうとする完全自動化は…まだ無理だね。少なくとも、メンテナンス性を気にするなら。短命で範囲が狭いエージェントは、比較的機械的な作業であれば、驚くほど徹底した高品質な知識作業ができるよ。例えば、Geminiの「深いリサーチ」ツールみたいなリサーチエージェントは、ウェブを掘り下げて情報をまとめるのに何時間も節約できる。注意深いプロンプトや十分な背景情報、良い自己評価ツールがあれば、エージェントループは非常に詳細なデータ分析や、真剣な統計・機械学習プロジェクトを実行し、高品質なデータビジュアライゼーションを作成し、便利なエグゼクティブサマリーをまとめることができる。たまに幻覚を見たり、道を外れたり、混乱したり、ミスをしたりするけどね。でも、彼らは過去200年間に英語で発表されたすべてのことを「知っている」し、疲れないし、書くコードは使い捨てのスクリプトには十分なクオリティだよ。エージェントがコードを書く本当の力は、こういうツリー構造やシーケンス構造の知識作業を非常に自立的かつ柔軟に実行できることなんだ。もちろん、これは「良いソフトウェアを設計する」こととは全然違う。設計にはツリー構造でもシーケンス構造でもない、LLMがまだできていないと思われるレベルの知性が必要だからね。でも、これは単にコードを書くこととは違って、コードが必要な作業をこなすためのものなんだ。

└

それとも、エージェントと会話して要件や計画の仕様を作り上げることもできるよ。既存のコードパターンを分析するように頼んでみて。エージェントが何をすべきか、どうするべきかをよく理解しているようなら、実装を頼んでみて、変更はローカルなスパイクとして保持する。エージェントに他のチームのコードについて質問して、答えられないことや確認が必要なことがあれば、彼らに連絡を取るようにする。今のエージェントの能力では、これは珍しいか、かなり非同期でできることだね。「これらのことを確認してください」とか。もしかしたら、自分のコードアーキテクチャが完全に間違っていることに気づくかも。もっとフィットする新しい抽象を手動でコーディングして、学びを仕様計画に書き込む。更新した抽象にほとんど合わない実装を取り除く。エージェントにコードを新しい構造に移行するよう頼む。スパイクが動作するまで繰り返して、使う抽象に満足するまで。エージェントとチャットして、スパイクのアプローチに関するデザインドキュメントを作成する。「Productionise CodeShmode's spike」のための単一のJIRAチケットを作成する。ステークホルダーからレビューやフィードバックをもらう。フィードバックをスパイクや元の仕様文書に統合して、全体を再生成する。ここで述べた儀式の多くは、大きな組織で役割が分かれていることからくるオーバーヘッドだね。一人の人がもっと多くのことをできるようになると、実際の作業量が減って、オーバーヘッドが支配的になる。でも、今は一人が多くの人の仕事をこなせるから、そのオーバーヘッドはもう必要ない。数日でスパイクを作り上げたこともあるけど、それはチーム全体で一ヶ月かかるような仕事だった。昔はそれが不可能だったから、どの人が何をするかを正当化する必要があった。でも今は、さっと作って、動作するデモを見せて「これを本番化すべき？」って聞けるんだ。

└

> AIを使って早くするのは、間違ったことを最適化している。私が働いてきた場所では、機能を実装するために必要な他のことに比べて、「コードを書く」部分が最も少ない時間を取る。1日かかる機能を考えてみよう。AIが今は計画を書く。私はそれをレビューして修正するだけだ。

└

> AIを使って速くするのは、間違った最適化をしてるってことだよね。俺が働いたところでは、"コードを書く"部分が、機能を実装するためにやるべきことの中で一番時間がかからなかった。これって、ソフトウェアエンジニアリングの格言を思い出させるな。「ソフトウェアを作るときは、それが問題に対する理解のスナップショットだってことを忘れないで。」それは、未来の自分を含め、みんなにアプローチや解決策の明確さ、適切さを示すんだ。発言は慎重に選ぼう。 > だから、デザインからリリースまで2ヶ月かかった機能があって、その中で1日かかった部分を5分に短縮するために必死になってるってわけだ。いいこと言ったね。

└

1. モデルは今、依存関係の更新やビルド/デプロイスクリプト、ユニットテストなどの面倒なタスクを完全に自動化するのが非常に得意になってる。昔は数日かかってたのが、今は数分で済む。これには簡単に50倍のスピードアップがある。これは、確立された会社のエンジニアの日常の中で非トリビアルな部分だった。「プラットフォームエンジニアリング」とか呼ばれてるものは死んだ。2. リスクと労力/報酬の観点から意味がなかった技術的にリスキーなアイデアが、今は手の届くところにある。これは「速く進む」ってわけじゃないけど、何かを試すスピードがエンジニアリングプロセスの性質を変える。

AIをすべてに使うわけじゃないけど、再現可能で監査可能なワークフローを作るために使ってる。DevOpsでは、AIに本番サーバーで問題を直してくれって頼むんじゃなくて、スクリプトを書いてもらって、それを監査して、ドライランして、テストして、最終的に承認して本番で実行する。HNで「show HN」を検索してたら、フィットネスやカロリー追跡アプリがたくさん出てきたんだ。多くは数ヶ月で消えて、1年持ったのもあったけど、ドメイン名が切れて終わっちゃった。人々は何かを作ってるけど、「オーディエンス」に届いてない。俺はhttps://macrocodex.app/を作って、2026年3月16日にローンチして、1万以上の月間アクティブユーザーを達成した。フィットネスやカロリー追跡は競争が激しい分野で、アプリやサービスがたくさんある。俺はページデザインができないから、そんなアプリを作ることはできなかった。デザイナーと話すことはできるけど、過去の経験から、彼らが市場のニーズを理解するのに時間がかかるんだ。小予算の会社は良い人材を見つけるのがすごく難しい。多くのプロジェクトは、ランディングページやアイコン、UIを作るのが嫌で出せなかった。AIを使ってランディングページやUIをうまく作ったとは言わないけど、たくさんの人が役に立ってるって言ってくれるから、成功したと思ってる。アプリ内にサポート用のチケットシステムも入れて、いくつかのバグ報告を受けて解決したよ。俺の他のサービスのレイテンシーはこれだよ: https://prnt.sc/6474F4gba_he もうAWSのマネージドサービスは使ってないし、コストもすごく低い。これで多くのユーザーにアプリやサービスを無料で提供できるようになった。

ちょっと前に、同じようなポイントに触れたことを書いたんだ（具体的にはベンダーロックインや、LLMが運用されているときのコスト予測の難しさについて）。関連する話題だけど、議論に参加するには十分な交差点があると思う。AIに全てのアウトプットやレビューを任せるだけだと（ある程度のしきい値は必要だけど、私たち人間はAIのスループットについていけないから）、最終的にはスキルが衰えてしまうことには同意するよ。ここで話が交差するんだけど、私は両方の良いところを活かす方法を考えてる。AIを使って大量のコードを生成することはできるけど、昔ながらのソフトウェアエンジニアリングを使ってそれを実現するんだ。私のプロジェクト（https://salesforce-misc.github.io/switchplane/）は、コントロールを逆転させるものだよ。LLMをランタイムとして使って全てをやるのではなく、判断が本当に必要なときだけLLMを使うLangGraphの制御フローを定義して書くんだ。基本的な原則はこうだ：決定的なものはコードで書く。判断が必要なものはLLMを使う。Switchplane自体はローカル専用だけど、この原則はデプロイされたエージェントサービスにも適用できる。コードファーストのアプローチなので、ベンダーに依存しない状態を保てる：グラフのどこでも好きなモデルを使えるんだ。一つがダウンしても問題なし。全体の制御フローに影響を与えずに設定を入れ替えられる。コストが問題になる？LLMのループを制限したり、アクセスを制約したり、好きなようにできる。更新が必要なのはただのコードだからね。ランタイムをコントロールするのはあなたであって、LLMじゃない。決定論的な動作が必要なときに、非決定論的な振る舞いが心配？心配しなくて大丈夫。コードの中にあるから。全てをLLMに任せてしまうことでスキルが衰えるのが心配？ここでは少し軽減されるよ。最初から実行グラフを構築するためには、システムを考える必要があるからね。LLMが実行するマークダウンファイルの数々と比べると、デモとしてはあまり目立たないかもしれないけど、長期的には確実に信頼できるアプローチだと思うよ。

ハクソク