面白いね。どのモデルとツールを使ったの？CursorやVSCode Copilot（gpt5使用）でも、比較的小さなリファクタリングを監視しなきゃいけない似たような失敗パターンを見たことがあるよ。

記事が言ってたことに関連してるかも。AIはカット＆ペーストができない。コードを削除して、別の場所で再生成するから、当然生成されたコードは削除されたものから少しずれてしまう。

小さなプロジェクトでパーサーをリファクタリングしたかったんだ。この式木パーサー（TypeScriptからSQLクエリビルダー - https://tinqerjs.org/）は手書きのコードがゼロ行なんだよ。CodexとClaudeを使って、2週間（パートタイムで）で作ったんだ。以前ORMに携わっていたから、同じ状態に到達するのに4倍から10倍の時間がかかってたと思う（しかもテストが何百もあって、一部は重複してるし）。これは時間の大幅な節約だよ。LLMを全く監視する必要もなかったしね。だから、使う目的や使い方によると思う。どんなツールでも、自分に合ったプロセスを見つけるのにはかなり時間がかかるから。LLMを広く使っている他の開発者との会話でも、みんな独自のカスタムワークフローを持ってる。ただ、全員がテストスイート、ドキュメント、メソッドレビューのプロセスには注力してるね。

クラスZに対してXとYの変更を加えて、クラスAを削除するように正確に指示しないといけない気がする。その時点で、LLMに無監視で作業させることができなくなる。これがLLMにやらせる理由の半分なのにね。むしろ「ステップバイステップで高レベルの指示を与えれば、私よりも早く作業できる」っていう理由に変わってしまう。

LLMが厳格なツールにアクセスできるようになれば、例えばGeminiがPythonライブラリを使うことで、信頼できる結果が得られると期待してたんだ。だから今日、Geminiにsympyを使って数学的な式を簡略化するように頼んだんだ。結果は出たし、式の一部を2つの因子の積として素晴らしく簡略化できると説明してくれた。でも、それは全部嘘だった。sympyを使うように明示的に頼んだのに、また自分の欠陥のある推論を使って、完全に間違った結果を出してきた。LLMはまだ信頼できない。これが問題なんだ。

大きなコンテキストモデルをツールコールで使えるかもしれないね。Geminiチャットのすごいところは、GitHubのリポジトリ全体を取り込めることなんだ。だから「新しいユーティリティやヘルパー関数を実装する前に、コードベースに既にあるかどうかを『発明されていないツール』に聞いてみる」っていうのもいいかも。もちろん、今は誰かがこれをやっているか確認しなきゃ。

まあ、これは他のエンジニアと一緒に働いているシニアエンジニアにとっては日常の話だよね。

それがclaude.mdとかの役割だよ。自分の基準に従わせたいなら、それを文書化しなきゃね。

これが私がよく直面することなんだ。今週の初めに、Cursorを使って新しい機能をゼロから実装するためのコードレビューをしたんだけど、200行くらいは本当に必要な行だったと思う。でも、まあ、承認したよ。既存の関数をユーティリティライブラリから探すのに一日中かかるのは面倒だからね。5年前なら、そんなPRは新しいチームメンバーがコードベースをよく知らない状態で提出することが多かったから、時間をかけて手伝ってたと思う。新しいチームメンバーのオンボーディングは大事な仕事だから。でも、今はスタッフエンジニアがCursorを使ってコードベースを膨らませてるだけで、管理者がそう決めたから仕方ないって感じ。LLMは何も学ばないし、来週また同じことを繰り返すだけだし、スタッフエンジニアはもっと良いことを知ってるけど、知らないフリをして給料をもらってるんだ。