AIを使って、より良いコードをよりゆっくり書く
(nolanlawson.com)- AIコーディングは、低品質なコードを高速に大量生成する用途だけでなく、PRを深くレビューして高品質なコードをゆっくり作るためにも活用できる
- LLMエージェントはコードベースでのバグ検出に強いが、実際の難所は見つけた項目の優先順位付けと検証にある
- 複数モデルを併用するClaude skillは、Claude sub-agent、Codex、Cursor BugbotでPRをレビューし、誤検知を減らした最終レポートを作成する
- 処理フローは、critical/highの問題を反復的に修正し、コストに見合う効果が低い項目は飛ばし、致命的な問題が多ければPRを断念するというもの
- この方式は速度よりもコードベースの健全性を重視し、失敗モードと既存バグを理解する慎重なプログラミングを強化する
AIコーディングをゆっくり使う方法
- AIコーディングを低品質なコードを高速に大量生成するためだけのものと見る考え方は、LLMの柔軟性を過小評価している
- LLMは高速なコード生成だけでなく、高品質なコードをよりゆっくり書くためにも効果的に使える
- slop cannonsのように未検証の巨大なPRを量産するやり方とは逆に、PRをより深くレビューし、失敗の可能性を執拗に確認するやり方も可能である
バグ検出より重要な検証と優先順位付け
- Mythosは、LLMエージェントがコードベースでバグを非常によく見つけられることを示している
- 別の事例でも、Mythosではないモデルが未レビューのコードベースから多くのバグを見つけられる
- 最新の公開AnthropicモデルとOpenAIモデルは、微妙なバグ検出や誤検知の回避能力には差があるものの、十分な数のバグを見つけ出せる
- 実際の難しさは、バグを見つけること自体よりも優先順位付けと検証にある
複数モデルでPRをレビューするClaude skill
- 複数モデルを比較・議論させるAIコードレビューのアプローチは、異なるモデルを多く投入するほど、幻覚や誤ったバグ報告の可能性を減らせることに焦点を当てている
- 使用中のClaude skillは、PRレビューのためにClaude sub-agent、Codex、Cursor Bugbotを実行する
- 各ツールはPR内のバグをcritical/high/medium/lowに分類し、その後、結果を統合して誤検知を除いた最終レポートを作成する
- 「バグ」の範囲はプロジェクトの基準に合わせて広げられる
実際のワークフローと判断基準
- この方法では、PRから多くのバグを見つけられ、誤検知率もほぼ0に近い水準まで下げられる
- 発見される問題は、セキュリティ・正確性に関わる致命的なバグから性能問題、「コメントが誤解を招く」といった低深刻度の問題までさまざまである
-
一般的な処理フロー
- criticalとhighの項目はエージェントに修正させるが、適切な解決策は人が案内する
- critical/highがなくなるまで繰り返す
- 修正コストに対して効果が低いhigh/mediumの問題はスキップする
- 狭いエッジケースを直すために100行のコードが必要になる場合が典型例である
- criticalな問題が多すぎて全体のアプローチが誤っていると判断したら、PRを断念する
生産性よりコードベースの健全性に焦点
- この手法が必ずしも開発速度を上げるわけではない
- レビュー過程でPR以前から存在した既存バグが見つかり、単体テストの作成や微妙な欠陥の修正につながることがある
- いわゆる「vibe coding」で連想されがちな「10倍生産性」型の開発とは、むしろ正反対に近い
- 複雑なアーキテクチャでは正常系よりも失敗モードのほうが興味深く、その失敗箇所を理解して直す過程がコードベースに習熟する方法になりうる
- コードベース全体の健全性を改善しながら、あまり知られていない部分を学ぶのに役立つ
遅いvibe codingのための実践法
- エージェントで自分でも完全には理解していない数百行規模のPRを作っている開発者なら、もっと遅い方法を試してみてもよい
- エージェントに、そのPRがどう動くのか、どこで失敗しうるのかを尋ねられる
- 必要なら、Mermaid chartsを含むMarkdown文書を書かせることもできる
- PRを最初から最後まで理解するまで、Matt Pocockの
/grill-meskillを使える - コード行数ベースの「生産性」は増えないかもしれず、多くのトークンを使った末に最初の計画が間違っていたという結論に至ることもある
- この方法は、LLM以前から志向されていた慎重で体系的で、品質に執着するプログラミングをより強力にした形に近い
2件のコメント
Hacker Newsの意見
AIで作業していると、もはや単純な一回限りの工程ではなく、長い往復レビュー・ループになる
中規模で複数領域にまたがる機能は、まずAIで実装設計を固めて詳細を確認し、その後、遅いが結果の良いClaude 4.7 Maxで実装する
その後に実装を見直し、Codex GPT 5.5 xhigh fastで再レビューさせると、ほぼ常に境界条件を見つけてくれる。修正はClaudeにやらせるが、Codexはバグ探しとレビューには強い一方で、コードが過剰設計になったり安易な近道が混ざったりしがちで、Claudeのほうが直感的で保守しやすいコードを書く
その次に新しいClaude/Codexインスタンスでstaged変更を再確認させ、フィードバックを反映したうえでテストまで付ける。手で書くよりは依然として速いが、時間の大半はレビューと境界条件の処理に使われ、結果としてv1の機能なのに、すでに何度も反復したv3のような実装に感じられる
生産的に感じるしAIの出力も良く、コードもだいたい理解したまま残る。ロボットと一日中、設計やアーキテクチャについて議論していると、こここそがAI革命によって自分がより良いエンジニアになれた部分だと感じる
自分のやり方では、調査/計画/テスト計画を5ラウンド回し、重要な意思決定ごとに自分がループに入る。大きな形から始めて細部へ下りていき、計画だけで自分の時間を2〜3日使うこともあり、実装エージェント（Opus 4.7）にも数時間かかる
実装は複数の段階/コミットに分かれ、各段階ごとにコードレビュー修正ループがある。最後の深いコードレビューにも1〜2時間かかることがあり、PRを開くとGeminiがレビューし、その内容を読んで対応する
プロジェクトはそれでも数日から数週間かかるが、全部を一人でやるよりは5倍速い
追記: そのskillはhttps://github.com/scosman/vibe-craftingにある
場合によってはAIが作ったものを捨てて、結局自分でやった。これは人々が学ぶべきスキルだと思う。ある時点では見切りをつける必要がある。特に単純な変更で、同僚がLLMと延々と言い争いながら何かをやらせようとしているのを見たことがある
AIをずっと世話して少し速くなる代わりに、AIが何をしたのかについての知識と統制力は減るのではないか
LLM同士に互いのコードレビューを批評させた記事[1]、magpieツール[2]、Cloudflareの最近のコードレビュースタックの記事[3]はかなり説得力がある
自分はAIに懐疑的だが、その理由は「動くかどうか」よりも「世の中にとって良いか」の側にある。こうしたレビュー作業は、珍しく思考の外注や労働者の能力低下につながらない例のように感じる。AIにコードを書かせたり、AIが見つけた問題をAIに修正させたりするのとは、同じ警報は鳴らない。もちろん環境問題やその他の倫理的懸念は依然として大きく残っている
最近のAIコードレビューの品質には感心しているが、GitHub PRでAIレビュアー3つと別々にやり取りする体験はひどい。もっとローカル志向で、jj/rebaseを理解するレビューラウンドがあればいいと思う
文脈: かなり大きなPHP/LaravelバックエンドとVueフロントエンド
[1]: https://milvus.io/blog/ai-code-review-gets-better-when-model...
[2]: https://github.com/liliu-z/magpie
[3]: https://blog.cloudflare.com/ai-code-review/
LLMのレビュー/修正ループに使う時間は、平均すると手で直接コードを書くより長くかかる
自分が波に乗ると非常に速くコードを書けるし、時には思っていた以上の速さでコードがあふれ出るからでもある。また、LLMが最初の数回で出してくるコードはだいたい本当にひどい
それでも興味深いのは、自分で確認し、何度もレビューと修正を指示すると、平均的には同じ時間で自分が書いたコードより品質が高くなる結果が出ることだ。他人のコードが何度も反復されるのを見ていると、没入状態で飛び出した成果物よりも、自分が達成しようとしている目標をより全体的に理解できるようになる気がする
この記事はAIでコードを書く話ではなく、コードレビューだけを扱っている
エージェント型コーディングで自分が感じる問題は、プログラミング中に無数のミクロなアーキテクチャ判断を下していることだ。最初から完全な仕様があることはほとんどなく、書いていくのを見ながら仕様を作っていく
Claude CodeやCodexを使うと、その過程が消えてしまう。Claude Codeは目標地点に到達しようとする意欲が強すぎて、一緒にコーディングする体験が熱にうなされた夢のように感じられる。結局、境界条件やプロジェクトのアーキテクチャ/設計目標にどれだけ合っているのかについて自信が持てなくなる
しかも自分はプログラミングやリバースエンジニアリングなどを楽しんでいる。LLMは問題を解いたり機能を届けたりはできても、その楽しさを奪うように感じる。自信を持って使える流れを見つけようと努力しているが、結局その流れはチャット、検索、そして自分の考えのラバーダック役程度なのではないかと心配している
逆に、一部の企業は、エンジニアが人間のフィードバックをループに組み込んだ自己評価エージェント・パイプラインを堅牢化し、エージェントに本番コードの大半を書かせるべきだと強く推している
CreaoのCEOは、今年1月に本番システム全体を2週間で再アーキテクトしたと語っている。エージェントがあまりに多くの機能をあまりに速く実装したため、事業開発側が追いつくのを待たなければならなかったとも主張している
AIでアウトプットを100倍に増やす選択肢と、AIで自分の技量を伸ばす選択肢を、どう評価できるのか気になる
一方で、AIによる生産性向上は現実のものでもある。たとえばSnowflakeのあるエンジニアリング組織は、会社の歴史上初めて第1四半期にすべてのOKRを前倒しで達成した。通常は計画したOKRの70%を達成しても成果と見なされていたので、こうした結果を見たエンジニアたちが感じるストレスは想像に難くない
この記事のタイトルはもっと深みがありそうに見え、実際のコード例を期待していた
だが、ほかの意見記事と似たようなものだった。筆者に効くプロンプト、つまりAIにバグを見つけるよう指示するやり方を提案し、みんなにもそうするよう勧める程度にとどまっている
仕事でも個人のサイドプロジェクトでもこうしたツールを使っているので、見て学べることを期待していたが、例のない意見記事はもう多すぎる
筆者がそのためのコードハーネスを作る、あるいはさっと組み上げることもできるだろうが、現時点ではそうした道具立ては実務者であるあなた側の領域により近く見える。自動化して実験したいなら、彼のコードを扱うより、自分が望むものを直接仕様化するほうが、正直もっと速い可能性が高い
これを読んでいる間、かなり密度の高い機能に取り組んでいたが、相当な反復が必要だった
最終結果は、途中のコードよりむしろずっと少ないコードになった。だから、AIが本当に役に立ったのか疑問に思った。反復にかけた時間があれば、自分でコードを書けたはずだからだ
ただ、AIのおかげで気に入らない機能バリエーション4つを素早く雑に作ってみることができ、そのぶん素早く捨てるのも苦ではなかった
以前は新機能の実装に入る前に本当に多くの時間をかけて計画を考え、既存コードとの不整合はかなり書き進めてからようやく見つかることがよくあった。今ではAIに詳細な実装計画を求めることで、こうした細かな問題を数時間、あるいはそれ以下で見つけられる
ここ数年で興味深かったのは、自分のコーディング上の怠惰の境界を追跡することだった
コーダーとして、私はボイラープレートコードが嫌いだ。書くのも嫌だし、保守するのも嫌だ。だからそうした好みを中心に設計やアーキテクチャを組み立てることがあり、ときには賢明だったが、ときにはそうでもなかった。いずれにせよそれは自分の好みであり、自分がやりづらいことを避けていた
数年前にLLMがコーディングである程度使い物になり始めたとき、実質的にボイラープレートには非常に優れており、2023年ごろにはほぼそれしか得意ではないことに気づいた。そこで、設計やシステムアーキテクチャにおいて、私たちが一緒に働く人たちの強みと弱みを暗黙に理解し、どれほど多くの配慮をしてきたかを考えさせられた
最新のモデルは人間と比べてかなり異なる強みと弱みを持っており、それをどう配置するかは、別種のアーキテクチャとエンジニアリングの技術を要する興味深い訓練だ。楽しくやっているし、このまま続いてほしい
何が出てくるかわからないままLLMにプロンプトを投げるより、
django-admin startproject、npm init、meteor createで決定的な出力を得るほうがずっとよい成熟したWebエコシステムではボイラープレートは最小化されている。今やこの作業をLLMに渡してしまったことで、
startproject系のCLIや優れたデフォルトを作る開発努力が減ってしまうのではないかと心配している気に入った。自分も似たralph-loopアプローチを使っている
承認済みの計画から始めてコーディネーターに渡し、単純化するとビルドとレビューという2つのセッションにまたがって処理し、各セッションには別のモデルを割り当てている
コーディングエージェントを使ううえで自分の障害になっているのは、有料の外部サービスに依存しなければならない点だ
コーディングに使える程度にまともなローカルモデルはあるのか？
これも役に立つかもしれない: https://hnup.date/hn-sota
Qwenモデルは今週の自分の日常用モデルだ
Lobste.rsの意見
私の職場では、AIでもっと速く進めるという夢はあきらめた。私たちの場合、コーディングがボトルネックではないからだ。
それでもコーディングエージェントが良いのは、ずっとなりたかったエンジニアのように働かせてくれる点だ。
たとえば、コードをもう少し攻めて進められるようなちゃんとしたテストハーネスを作ったり、生成コードが元のものと一致するかを検証するCIステップを追加したり、変更のデプロイをきちんと監視したりすることだ。
以前ならGitLab CIのマニュアルを読んで条件の合わせ方や、うちの会社のややこしい流儀を理解しなければならず、スケジュール的に無理だったようなことが、今は可能になった。これが未来だと思う。
LLMをAPIに詳しいスパイク相手や機械的なリファクタリング装置として使うとかなりうまくいった。特に型の強い言語で効果が大きい。テスト作成にも向いているが、そのテストが実際に制約として機能しているかを確認する多層的な手順が必要だ。
ミューテーションテストはかなり役に立ったし、元記事が提案していたように複数回のレビューも必要だ。
以前はLLMにずっと否定的で、振り返ると不合理なほどだったが、その大半はLLMが大量に吐き出していた低品質なソフトウェアのせいだった。
実際に深く触れてみると、段ボール製のプロトタイピングツールであり、はるかに速いタイピストとして扱うのが正しかった。たとえば「このLeanプロジェクトのすべての定理からこのパターンを見つけてあのパターンに置き換え、すぐにうまくいかない箇所には印を付けて残りの一覧を出してくれ」と頼むと、私がvim、sed、awkとその場しのぎを混ぜて最初の1、2回を試している間に、100個を超える定理をチャンク単位で修正してくれる。
Leanは言語の性質と自分の作業内容の関係で、「コンパイルできる」と「動く」の間の隔たりが小さいので特に相性がいい。Rustでも良いテストスイートとミューテーションテストを組み合わせると、似た感触がある。
こうしたツールの長い裾野は、「ボタンを押せば製品が出てくる」という話ではなく、優れたエンジニアがそれを受け入れて重要な仕事にエネルギーを集中し、以前なら雑務だったことのかなりの部分を機械に委ねる方向だと思う。
例が興味深い。以前JavaScriptフレームワークのチームで働いていたとき、アップグレードやマイグレーションのために自分でcodemodを書いていた。ASTを書き換える骨の折れる作業だった。
今ならLLMに任せて、90%くらいまでは到達できそうだ。
この見方は良いと思う。ツールは柔軟で、必ずしも低品質な結果を生む必要はないというのは当たり前に見えるが、賛成派も拒否派もこの視点をしばしば無視している。
まだLLMでコードレビューはしていないが、やることリストに入れてみようと思う。これまではアイデア出しやSQL、VimScriptの補助くらいに使っていて、コード自体は自分で書いている。
一つのリスクは、コードレビューも技能なので、モデルに頼りすぎるとその能力が衰えるかもしれない点だ。ただ、商業環境では最高のコードレビューですら普通は「妥当な時間」と「この人を信頼できるか」の組み合わせであって、数学的な正確さに近いものではない。
複雑なバグは自分で最後まで考え抜くようにしている。1) まだ幻覚が混ざることがあるし、2) どうせシステムをエンドツーエンドで理解する価値があるからだ。
メタな話だが、この記事に付いたフラグが理解できない。オフトピック1件、スパム3件というのは妙だ。
1ページ目の最上部の記事もLLMの使用に関する内容で、一般的な文章執筆についての話だから、コーディングに焦点を当てたこの記事よりむしろ話題との関連性が薄く見えるのに、フラグは付いていないようだ。
Lobstersでこういう見方を見るのは新鮮だ。一律の反AI感情にはだんだんうんざりしてきた。低品質な成果物を好む人がいない、という点には誰もが同意できるはずだ。
ただ、AIを完全にボイコットして独善的な態度を取った人たちは、より実用的な態度を取った人たちよりも未来を受け入れにくくなるだろう。
最初から、AIは電動工具の発明に近いと言ってきた。手回しレンチでタイヤを替えたいならそれでもいいが、インパクトドライバーが登場したときに整備士たちはボイコットしなかった。文脈的には最高の比喩ではないかもしれないが、それでもそう思う。
ドキュメントを読むときより、AIを使っているときのほうが多くを学んだ。ドキュメントには、追加の文脈や説明、例が必要なときに質問できないからだ。「何か作って、間違えるな」と頼むこともできるが、実際に学ぶためにはゆっくりしたアプローチのほうが好みだ。
私が見たのは、LLMで数百万行のコードを一度に変更し、人間のレビューなしでデプロイするような変化への批判だった。具体的には、BunのZigからRustへの移植スレッドのようなケースだ。
この記事もそれは批判している。