AIのコーディングは2050年の感覚だが、デバッグは依然として1999年の感覚だ

多くの人はすでにこの感覚を感じていると思います、たとえそれをはっきり言わないことがあるとしても。

AIは現在、コードを速く書き、コードを速く説明し、速くリファクタリングし、パッチを速く生成できます。

しかし、ワークフロー、エージェント、ツール、契約、トレース、状態、引継ぎ、デプロイの奇妙さ、そして静かな副作用といった要素が現実のプロジェクトで増えてくると、デバッグは依然として全体を遅くする場所になります。

そして最も痛い部分は、デバッグが難しいだけではないということです。

それは、AIが誤った修正を正しく聞こえるようにしてしまう点です。

それが私が狙っていた部分です。

多くのAIデバッグの痛みは最終的な障害で始まるわけではありません。

それはもっと早い段階、最初の誤った切り分けで始まります。

何かが幻覚のように見えることもありますが、実際の問題は「接地のずれ」から始まります。

何かが推論の崩壊のように見えることもありますが、実際の破綻は形式的なコンテナにあります。

何かが記憶や安全性の問題のように見えることもありますが、早期の障害は観測性の欠如、実行完了の破損、または連続性の漏れです。

最初の診断が誤った層に行ってしまうと、修復の全体的な流れが漂い始めます。

間違ったものを修正し、複雑さを増し、新しい副作用を生み出し、活性に見える修正に時間を費やしますが、実際には事例を完了へ向かって動かしていません。

これを作った理由がそれです：

Problem Map 3.0 トラブルシューティング・アトラス

これは、AIを使って構築する人々のための故障ルーターです。

魔法の修復エンジンではありません。

ベンチマークの主張でもありません。

地球上のすべての難解なシステム障害を1つのTXTファイルで解決すると約束するものでもありません。

目標は限定的ですが、非常に実用的です：

AIが被害が拡大する前に最初の適切な切り分けを行えるようにする

現在のランディングページはこちらです：

https://github.com/onestardao/WFGY/blob/main/ProblemMap/wfgy-ai-problem-map-troubleshooting-atlas.md

このプロジェクトを最も短く説明する方法は、たぶんこの一文です：

TXTを一度読み込み、通常どおりビルドし、AIに最初に正しいレイヤーでデバッグさせる

それがコアアイデアです。

私は人々の作り方を置き換えようとしているわけではありません。

ChatGPT、Claude、Gemini、Cursor、Copilot、または現在のワークフローの使用を止めるよう誰もに求めていません。

考え方はそれよりもシンプルです。

ルート優先のTXTルーターを導入し、通常通り作業を続け、モデルがより良い構造的切り口でデバッグに臨むのを許します。

無作為なパッチに直接飛び込むのではなく、ルーターはより正直な最初のパスを強制しようとします：

• 最初に何が失敗するか
• そのケースが属するファミリは何か
• 近接するファミリがそれを誤って吸収する可能性は何か
• 実際に壊れている不変条件は何か
• wha