- LLM がコードを継続的に代わりに書いてくれるとしても、重複した条件文や暫定実装をそのままマージすると、その後に生成されるコードがその慣行をプロジェクトのルールのように踏襲してしまう可能性がある
- アクセス権限の確認ロジックを route handler、background job、API endpoint、webhook などに繰り返し入れると、テストは通っても保守負担はそのまま残る
- モデルは開いているファイル、既存のパターン、最近の変更を見て次のコードを作るため、コピーされた条件文が4つあることは、5つ目のコピーを呼び込む合図になる
- 後からリファクタリングを依頼しても、LLM が既存のコピーをすべて正しく整理してくれるとは保証しにくく、悪いパターンは一回限りのミスというよりコードベースのスタイルに近くなる
- 重複した条件文、「god」関数、「後で整理する」マージが積み重なると、プロンプトだけで元に戻すのは難しくなり、結局は人間が直接直さなければならなくなる
LLM が参照するのは現在のコードベース
- LLM はコードを「真空状態」で書くのではなく、ユーザーのコードベースを読む
- 開いているファイル
- すでに存在するパターン
- 最近の変更
- コードベースにマージされた近道は、「ここではこうする」という学習シグナルになる
- 同じアクセス制御条件が複数の場所で繰り返されることがある
if (user.isActive && user.hasPermission('read') &&
!user.isSuspended && account.status === 'open') {
// do a thing
}
- この条件文は共有ヘルパーとして抽出できるが、LLM が作ったコードが動作し、テストに通るという理由でそのままマージされることがある
- 同じルールを持つ5つ目のエンドポイントを依頼すると、モデルは最初から設計するよりも、リポジトリ内の既存のコピーに従う可能性が高くなる
保守を LLM に任せるという錯覚
- 「後で変更するときも LLM がやってくれる」という考えは、重複やコードスメルを放置させる
- いくつかの重複条件文は致命的ではないかもしれないが、こうしたコードスメルは蓄積し続ける
- 重複した条件文
- 「god」関数
- 「後で整理する」ことにしたマージ
- 悪いパターンが増えると、次のプロンプトの結果にも影響し、後からすべてのインスタンスを LLM が漏れなく直してくれるとは信じにくくなる
- 保守を LLM にアウトソースしているつもりでも、実際には悪化していく習慣を繰り返させる状況になり得る
- 人間が保守するつもりでコードを書くべきであり、LLM が吸収して返してくるコードパターンは良い状態に保つ必要がある
1件のコメント
Hacker News のコメント
.claude/commands/review.mdに空の Markdown ファイルとして /review コマンドを作り、エージェントが確認すべきチェックリストを入れておくのがよいコードレビューが必要なときに
/reviewと入力すると、そのチェックリストを見て修正すべき項目を計画し、その後に質問してくる自分のファイルは「計画モードに入れ。このブランチと main の差分を見ろ。考慮事項: ...」で始まり、コードレビュー中に見つけてエージェントに直させた項目を追加し続けた結果、今では 200 項目くらいある
エージェントは一般的なフィードバックの壁を受け取っても気にせず項目を1つずつ見ていき、「新しく作ったものが既存コードと重複していないか確認しろ」を入れたところ、実際に整理作業を計画し始めて驚いた
まだ表面をなでている程度で、ツールがより良いツールになるよう ツールのためのツール を与える必要がある
今でもかなり単純な指示しか使っていないのに、Claude は「許可なく git にコミットしないこと」「コミットメッセージに署名しないこと」といった最初の指示をよく破る
尋ねると「そうだ、その指示があったのに無視した」と答え、セッション内で丁寧に修正すると理解はするが、その後は今度はまったくコミットできなくなることもある
200 項目のチェックリスト を見直させると、そのうちかなりの数を黙って見落としている可能性が高い
人間のエンジニアなら、既存の 200 個のテストが使っているアサーションライブラリがあるのに、新しいテストでまったく別のライブラリを使ったりはしないはずだが、Claude はそういうことを何度もやった
そのため「書く前に テストの慣例 を確認しろ」といった項目を追加し続けることになった
一方で、関数が何かとか、テストが変更 diff を扱うべきだといった基本は、わざわざ言わなくてもよいはずなのに、どちらを言うべきでどちらは大丈夫なのかという明確な一覧がなく、試行錯誤で使えるやり方を作っている感覚がある
自分の場合はエージェントと往復しながら「自分の目と好みにとって十分によく見えるまで」整えることが多いが、まだそうしたリストは作っていない
プロジェクトによっては些細な問題やマジックナンバーを許容することもあるし、別のプロジェクトでは
SECONDS_IN_A_DAY = 24 * 60 * 60のような意味のある名前の定数を強制することもあるので、文脈依存 だhttps://github.com/alibaba/open-code-review
https://layandreas.github.io/personal-blog/posts/beyond-vide...
たとえば Senior Engineer、Security Engineer、WCAG specialist のような長い役割リストの中から、変更に最も適した N 個の役割を選ばせる
Claude はそのレビューを並列で実行し、その後フィードバックを統合してくれる
仕様駆動開発をしているので、見つかったイシューを仕様に追記して、イシューと判断の履歴を残している
ここで多くのエンジニアがさらに別のプロンプトを重ねているのが不思議なくらいだ
私の経験では、そうするほど悪化し、抽象化はするものの誤った抽象化を作り、コメントを付けすぎて後続のLLM呼び出しまで混乱させる
良いコードベースではそれなりに動くが、コードを徐々に悪くしていき、使い続けてある時動かなくなると、その間自分で作ってこなかった代償を払って修正することになる
新しいコードベースにエージェントを入れると、たいていコードに対するメンタルモデルがあり、コードもある程度簡潔だが、反復が積み重なるとその両方が失われ、LLMの性能も落ちる
だからLLMは探索とレビューに使い、コードは自分で書く
コーディングはそれほど時間のかかる作業でもなく、いちばん楽しい部分なのに、なぜ避けたがるのか理解しにくいし、ときどき
/bugプロンプトでAIと同時にデバッグ競争をしてみても、AIが常に速いわけでもないここ数年でソフトウェアの仕事は、好奇心旺盛ないじり屋やパズル中毒者のための実践的な工学の避難所の一つから、金融・法律・医療のように金を目当てにした賢い人たちのキャリアパスへと変わった
今「ソフトウェアエンジニア」という肩書きを持っている多くの人は、そもそもその作業を楽しんだことがなく、賢くて責任感があり、雇用主から与えられたほどほどの目標を達成してきただけだ
そういう人たちは、AIエージェントが厳密な設計やパズル的な作業を引き受け、生まれつきの要領の良さをもっと怠惰に活用させてくれることを最も望んでいる
コーディングや工学原則を内面化できていないため、同じ考え方の同僚に囲まれると、このやり方が今後どんな結果を生むのか予測しにくい
コーディングそのものが最初から非常に苛立たしく摩擦の多い体験だったなら、AIのほうが速いと感じやすい
コードは読むだけでは十分ではなく、苦しみながら経験してこそ内面化される
エージェントは既存の経路がまだ必要かを問うより、古いコードを防御的に包み込むことが多く、その結果、膨大な量の防御コードがロシア人形のように何重にも積み重なる効果が生まれる
https://softwaredoug.com/blog/2026/07/09/write-code
Opus 4.8が転換点で、特に複雑な問題では、今ではOpus 4.8相手にあまり勝てなくなった
みんながあらゆる作業や質問にOpus 4.8以上を使うようになれば、全体の空気はずっと変わり、AI懐疑派もあまり残らない気がする
いまもコードは手で書いており、全部ではないが一部はOpusが生成する
とんちんかんな考えかもしれないが、単にコードを自分で書けばいい
AI時代には信じがたい概念のように聞こえるかもしれないが、人が読んで保守しなければならないコードなら、その人たちのために自分で書くほうがいい
過度に冗長でコピペされたコードを読めば腹が立つだろうし、他の人も同じだ
自分で書けば、自分で直せるし、他人が保守するのに筋の通った形で書くようになる
あるいは、将来の保守担当者が期待するコードの形をエージェントとループに理解させるため、複雑に張り巡らされたMarkdownファイル群をなだめるように作ることもできる
長期的にどちらの道が楽かは分からないし、ループベースのエージェント主導コードベースを引き継いで理解してみた人がいるのか気になる
「次に同じアクセス規則を持つエンドポイントをLLMに頼むと、モデルは最初から考えず、リポジトリにすでにある4つのコピーから始める」という話がどれほど当たっているのかはよく分からない
実際には、基本構造を反復し、再利用や抽象化をあまりしない方向への内蔵バイアスがあるように思える
既存パターンがそうであればそれに従っているように見えるが、実際にはどちらにせよそうしていた可能性が高い
厳格な抽象化と使用例を先に用意し、特定の抽象化APIだけを使い、私が書いたやり方までコピーするよう明示的に指示しても、最新のLLMがどちらもやらず、下から基本構造を再実装して抽象化を部分的または完全に無視することが多かった
なぜそうなるのか正確には分からないが、学習データのコードにこういう形のコードが多すぎて、重みがこのやり方で結果を出す方法をよりよく「知って」いるのではないかと思う
それでもLLMを高速な実装エンジンとして使うのは問題ないと思う
課題は、モデルが間違った方向に走り出す前に、こうした実装上の判断を先に表に出させることだ
大きな変更の後では、次のプロンプトで良い結果が得られた
「では最終コード点検を行え。すべてが整理されており、コンポーネントが関心の分離の原則に従っているか。理解可能で保守可能な状態か。もはや真ではないかもしれない前提を置いていないか。以前の編集や実験の残骸コードがコードベースに入っていないか。ドキュメントは依然として現在のコードの状態を反映しているか。」
すると上で述べたことと、それ以上のこともたいてい推論してくれる
ただし、継続して明示しなければならないのは、「進捗追跡」用のコメントをすべて消し、長期保守に適したコメントだけを残せという点だ
Claudeは「ボタンクリックが保存を引き起こすようになり、もうonBlurは使っていない」といったコメントを残すが、実際のコードではonBlurを使ったことはなく、同じ作業・ブランチでClaudeがさっきやろうとして私が差し戻したことの痕跡にすぎない場合がある
モデルは勝手な解釈をするだろうが、それでも何もしないよりは良いことが多い
AIにすべて教え、きちんと学んだかを尋ねるやり方で、結果は意外に良い
この文章と似た手順に従っている
https://www.lucasfcosta.com/blog/backpressure-is-all-you-nee...
昔からある格言がある
「次の保守担当者はお前の住んでいる場所を知っている殺人鬼だと思って、コードにコメントを付けろ」
最近のPRレビューでそれに何度目か遭遇し、腹を立ててコメントを書いたのだが、自分でも驚いた
自分がそんな反応をするとは思っていなかった
つまり、コード自体が明確ではないからコメントがあるという意味で、そういう場合もあるが、一般的にはコメントは少ないより多いほうがよいと思う
特に、コードが実際のビジネス要件や機能要件とどう結びつくのかを説明し、単にコードの動作を言い換えるだけでないならなおさらよい
数年前はコメントを先に書くことがあった
全体の目標を説明し、ルーチンと作業手順に分け、それで納得できたらコメントの間にコードブロックを埋めていくやり方だった
一種の文芸的プログラミングのようだが、その用語を知る前からやっていた方法であり、目標に向かって自分自身にプロンプトを与えることに近かった
欠点は、コメントが結局はコードの動作を英語で説明するだけのレベルになりがちで、将来の保守担当者にはあまり役に立たないかもしれないという点である
コードは自己説明的であるべきで、コメントはここぞという場所に書くものだ
似た文脈で、私が好きなプロンプトは「あなたが書いたテストを見直してくれ。このテストは本当に意図したものをテストしているか？ コードが壊れたらテストも失敗するか？」である
LLMが何も検証していない空っぽのテストをどれほど頻繁に書くかには驚かされる
いまだにこういうことを真面目に議論しなければならないのかと思う
LLMであれだけ「実験」をしてきたのなら、もう当然のこととして受け入れるべきではないかと思う
いつになったら手書きコーディングをまたタブーのように扱わずに話せるようになるのだろうと思う
LLMはいろいろな意味で有用だが、人々がソースコード全体のタイピングをエージェントに委ねているのを見ると、指針
Webは良いものなのだから私たちは幸せであるべきだ、と言われるのと似た感覚がある
コードベースを複数のモデルに継続的に回して、重複コードのような悪臭を見つけさせている
かなり効果的だったし、時間が経っても継続的に管理しないと汚い塊になり、それが蓄積していく気がする
ビルドパイプラインに組み込むこともできるし、トークンもまったく使わない
それとも、レビューの過程とコンテキストの初期化のほうが重要なのだろうか？
人々が20年間保守してきたコードにも、こうした重複やそれ以上にひどいものをたくさん見てきた
正直に言えば、今LLMが作るものより、人間が書いて保守してきたコードのほうが悪い場合のほうが大半だった
経験不足のこともあれば、意図的な怠慢のこともあるが、たいていは厳しい納期と、とにかく今すぐ終わらせなければならないという圧力のせいだ
人はもっとよくやる方法を知っているが、実際にそうする時間と予算がない
LLMもそれを学んだ