AIを使って、より良いコードをよりゆっくり書く

 (nolanlawson.com)
8 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • 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に分類し、その後、結果を統合して誤検知を除いた最終レポートを作成する
  • 「バグ」の範囲はプロジェクトの基準に合わせて広げられる
    • KISSとDRY原則への違反
    • アクセシブルなHTML/JSXになっているか
    • SQLクエリで適切なインデックスを使っているか
    • そのほかのプロジェクト固有の品質基準

実際のワークフローと判断基準

  • この方法では、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-me skillを使える
  • コード行数ベースの「生産性」は増えないかもしれず、多くのトークンを使った末に最初の計画が間違っていたという結論に至ることもある
  • この方法は、LLM以前から志向されていた慎重で体系的で、品質に執着するプログラミングをより強力にした形に近い

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Lobste.rsの意見

  • 私の職場では、AIでもっと速く進めるという夢はあきらめた。私たちの場合、コーディングがボトルネックではないからだ。
    それでもコーディングエージェントが良いのは、ずっとなりたかったエンジニアのように働かせてくれる点だ。
    たとえば、コードをもう少し攻めて進められるようなちゃんとしたテストハーネスを作ったり、生成コードが元のものと一致するかを検証するCIステップを追加したり、変更のデプロイをきちんと監視したりすることだ。
    以前ならGitLab CIのマニュアルを読んで条件の合わせ方や、うちの会社のややこしい流儀を理解しなければならず、スケジュール的に無理だったようなことが、今は可能になった。これが未来だと思う。

  • LLMをAPIに詳しいスパイク相手や機械的なリファクタリング装置として使うとかなりうまくいった。特に型の強い言語で効果が大きい。テスト作成にも向いているが、そのテストが実際に制約として機能しているかを確認する多層的な手順が必要だ。
    ミューテーションテストはかなり役に立ったし、元記事が提案していたように複数回のレビューも必要だ。
    以前はLLMにずっと否定的で、振り返ると不合理なほどだったが、その大半はLLMが大量に吐き出していた低品質なソフトウェアのせいだった。
    実際に深く触れてみると、段ボール製のプロトタイピングツールであり、はるかに速いタイピストとして扱うのが正しかった。たとえば「このLeanプロジェクトのすべての定理からこのパターンを見つけてあのパターンに置き換え、すぐにうまくいかない箇所には印を付けて残りの一覧を出してくれ」と頼むと、私がvim、sed、awkとその場しのぎを混ぜて最初の1、2回を試している間に、100個を超える定理をチャンク単位で修正してくれる。
    Leanは言語の性質と自分の作業内容の関係で、「コンパイルできる」と「動く」の間の隔たりが小さいので特に相性がいい。Rustでも良いテストスイートとミューテーションテストを組み合わせると、似た感触がある。
    こうしたツールの長い裾野は、「ボタンを押せば製品が出てくる」という話ではなく、優れたエンジニアがそれを受け入れて重要な仕事にエネルギーを集中し、以前なら雑務だったことのかなりの部分を機械に委ねる方向だと思う。

    • 私も最初はLLMをとても否定的に見ていたが、今では邪魔より役に立つ水準まで良くなったと思っている。
      例が興味深い。以前JavaScriptフレームワークのチームで働いていたとき、アップグレードやマイグレーションのために自分でcodemodを書いていた。ASTを書き換える骨の折れる作業だった。
      今ならLLMに任せて、90%くらいまでは到達できそうだ。

  • この見方は良いと思う。ツールは柔軟で、必ずしも低品質な結果を生む必要はないというのは当たり前に見えるが、賛成派も拒否派もこの視点をしばしば無視している。
    まだLLMでコードレビューはしていないが、やることリストに入れてみようと思う。これまではアイデア出しやSQL、VimScriptの補助くらいに使っていて、コード自体は自分で書いている。
    一つのリスクは、コードレビューも技能なので、モデルに頼りすぎるとその能力が衰えるかもしれない点だ。ただ、商業環境では最高のコードレビューですら普通は「妥当な時間」と「この人を信頼できるか」の組み合わせであって、数学的な正確さに近いものではない。

    • その話ももっともだが、このワークフローはむしろ自分のコードレビュー能力を高めてくれると感じた。というのも、「バグ」が本当に起こりうるのか、それとも理論上だけなのかを見極め、その修正に価値があるか、次のPRに回すべきかまで判断しなければならないからだ。
      複雑なバグは自分で最後まで考え抜くようにしている。1) まだ幻覚が混ざることがあるし、2) どうせシステムをエンドツーエンドで理解する価値があるからだ。

  • メタな話だが、この記事に付いたフラグが理解できない。オフトピック1件、スパム3件というのは妙だ。
    1ページ目の最上部の記事もLLMの使用に関する内容で、一般的な文章執筆についての話だから、コーディングに焦点を当てたこの記事よりむしろ話題との関連性が薄く見えるのに、フラグは付いていないようだ。

    • たぶん自己宣伝だと見なされてスパムフラグが付いているのだと思う。

  • Lobstersでこういう見方を見るのは新鮮だ。一律の反AI感情にはだんだんうんざりしてきた。低品質な成果物を好む人がいない、という点には誰もが同意できるはずだ。
    ただ、AIを完全にボイコットして独善的な態度を取った人たちは、より実用的な態度を取った人たちよりも未来を受け入れにくくなるだろう。
    最初から、AIは電動工具の発明に近いと言ってきた。手回しレンチでタイヤを替えたいならそれでもいいが、インパクトドライバーが登場したときに整備士たちはボイコットしなかった。文脈的には最高の比喩ではないかもしれないが、それでもそう思う。
    ドキュメントを読むときより、AIを使っているときのほうが多くを学んだ。ドキュメントには、追加の文脈や説明、例が必要なときに質問できないからだ。「何か作って、間違えるな」と頼むこともできるが、実際に学ぶためにはゆっくりしたアプローチのほうが好みだ。

    • ここで一律の反AI感情は見ていない。例をリンクしてくれる？
      私が見たのは、LLMで数百万行のコードを一度に変更し、人間のレビューなしでデプロイするような変化への批判だった。具体的には、BunのZigからRustへの移植スレッドのようなケースだ。
      この記事もそれは批判している。