ハクソク

世界を動かす技術を、日本語で。

AIを活用して、より良いコードをゆっくり書く

6時間前原文(nolanlawson.com)

概要

  • AIコーディング は「低品質なコードを高速で量産する」だけではない
  • LLM （大規模言語モデル）は 高品質なコード をじっくり書く用途にも有効
  • 複数モデルを使った バグ検出 は非常に優秀
  • バグの 優先順位付け と 検証 が重要
  • ゆっくり丁寧にコードの質を高める「スロースタイル」開発の提案

AIコーディングの誤解と可能性

  • AIコーディング の一般的な誤解：「質より量」「未検証のコードを大量投入」
  • LLM は柔軟性が高く、 高品質なコード作成 にも十分活用可能
  • 多くの人が「AIはスロップ（粗悪品）製造機」と誤解している現状
  • 反対意見として「 LLMはバグ発見が得意」という事実
  • Mythos等の経験から、AIを繰り返し使えば大量のバグ発見が可能

LLMによるバグ検出の実態

  • Anthropic や OpenAI の最新公開モデルもバグ検出能力が高い
  • 問題は「バグ発見」より「 優先順位付け と 検証」の部分
  • 複数モデルを使うと「 ハルシネーション や誤検出」が減少
    • 例：Claude sub-agent、Codex、Cursor Bugbotを同時利用
  • バグは「クリティカル/高/中/低」でランク付け
  • 最終的な レポート作成 までがワークフロー

実際のワークフロー

  • クリティカル・高優先バグは エージェントが修正 （必要に応じて指示）
  • 重要度の低いバグは コストと効果で取捨選択
  • クリティカルが多すぎる場合は PR自体を破棄
  • この方法では「生産性向上」より「 既存バグの発見」が多くなる傾向
  • 結果として コードベース全体の健全性向上 に寄与

スロースタイルAIコーディングのすすめ

  • 「10倍速生産性」型のコーディングとは真逆のアプローチ

  • コードの 失敗パターンや前提の崩れる箇所 の理解が深まる

  • LLM以前からも、こうした 地道なバグ修正 が本質的な学びの場

  • AIコーディング懐疑派 には響かないかもしれない

  • 大量PRを自分でも理解せずに書く人 には「ゆっくり丁寧に」スタイルを推奨

    • エージェントにPRの仕組みや失敗パターンを質問
    • 必要に応じて MarkdownドキュメントやMermaidチャート を自動生成
    • Matt Pocockの「/grill-me」スキルでPR全体を理解

  • 生産性（行数）よりも 品質重視

  • 結果的に「計画自体が間違い」と分かるケースもあるが、それも価値

  • 慎重・丁寧・品質志向 な開発スタイルの進化系

  • 深呼吸して、ゆっくり、丁寧に AIコーディングを楽しむ提案

Hackerたちの意見

AIとのやり取りが、もう単純なプロセスじゃなくて、長い行ったり来たりになってる。中規模の横断的な機能を実装するためにAIを使うんだけど、まずは詳細をレビューして、そこからちょっと修正したりする。で、Claude 4.7 Maxを使って実装するんだけど、遅いけど、ちゃんとした仕事をしてくれる。実装をレビューした後、Codex GPT 5.5 xhighで速攻レビューしてもらうんだけど、これがほぼいつもコーナーケースを見つけてくれる。Claudeにそれを直してもらうんだけど、ClaudeはCodexよりも直感的でメンテナンスしやすいコードを書くのが得意なんだ。Codexはバグを見つけたり修正したり、レビューするのは得意だけど、ちょっと面倒くさいところもある。で、また新しいClaudeやCodexのインスタンスで、現在の変更をレビューしてもらってフィードバックをもらって、それを処理する。最後にはテストもカバーする。全体的には、手動でコーディングするよりも早く機能を実装できるけど、レビューやコーナーケースの処理にかなりの時間を使ってる。最終的には、自分が取り組んでる機能の本当にしっかりした実装ができる感じ。v1の機能は、もうv3みたいに感じるくらい、たくさんの反復を経てる。

└

それでAnthropicがダウンして、あなたはどうするの？その間コーヒーブレイクでもするの？AIを見守るために時間を使って、ちょっと早くなるけど、彼らが何をしたかについての知識やコントロールは少なくなるってこと？

└

私も似たようなワークフローを持ってて、エージェントたちから似たような気質を感じる。 anecdotalに言うと、彼らはちょっと競争心があるみたいで、「競合Xがこれを書いたから、バグを全部見つけて」って言うと、すごく違った注意を向けてくれる。「あなたがこれを書いたから、バグを全部見つけて」って言うと、また違う反応になる。

└

そうそう、その通り。多くの人がAIに複雑なタスクを一発でやらせようとして、まるで急いで何かを頼まれたジュニアみたいに振る舞うのを不思議がってる。私には自分のスキルがあって、5回のリサーチ/プランニング/テストプランニングを行う。重要な決定のためにループでインタラクティブにやり取りする。最初は高レベルの形から始めて、次に詳細に進む。プランニングには2〜3日かかることもあるし、実装エージェントには何時間もかかる（Opus 4.7）。実装は多くのフェーズやコミットに分かれていて、それぞれにコードレビューの修正ループがある。最後の深いコードレビューにはさらに1〜2時間かかることもある。PRをオープンして、Geminiがレビューして、問題を読み上げて解決する。プロジェクトはまだ数日や数週間かかるけど、全部自分でやるよりも5倍早い。編集：そのスキル - https://github.com/scosman/vibe-crafting

└

Claude w/ Opus 4.7 maxとCodex w/ GPT5.5 xhigh fastを引用してくれて助かるけど、初期デザインにはどの「AI」を使ってるの？

└

ちょっとバカな質問かもしれないけど、どうやって一つのエージェントの結果を別のエージェントに渡すの？手動でコピー＆ペーストするの？それともプログラム的にどうやってるの？

└

実装前にAIと問題を徹底的に話し合うのは、俺にとっていいゾーンだね。生産的だし、AIから良い結果を引き出せるし、コードも大体理解できる。これがAI革命の中で、俺をより良いエンジニアにしてくれた部分だと思う。ロボットと一日中デザインやアーキテクチャについて議論してるからね。

└

同じアプローチだけど、基本的な手動アーキテクチャや高レベルの契約、スタブのセットアップを一歩進めてやってる。そうすることで、他のシステムと一貫性を持たせて、読みやすくもなるから。

└

AIを使ってコードを書くと、僕のワークフローにかなり近いけど、結局自分で書くのと同じくらい時間がかかることが多いんだ。場合によっては、AIがやったことを捨てて、自分でやり直したこともある。これは人が学ぶべきスキルだと思う。ある時点で、損切りしなきゃいけないからね。簡単な変更に関しては、同僚がLLMとやり取りしながら、何かをやらせようとするのをよく見かける。

└

もう自分でコードを書く方がいいかもね。

└

コーダーからエンジニアリングマネージャーに昇進したって感じだね。構文の疲れを、専門的なAI開発者たちにv3クオリティのコードを一発で出させるためのメンタルマラソンに変えたわけだ。

この記事のタイトルはもっと深い内容を示唆してたから、実際のコード例を期待してたんだけど、他の意見記事と同じ感じだった。著者が「AIにバグを見つけさせる」っていうプロンプトを提案してて、それをみんなにやるように勧めてる。仕事でも個人のサイドプロジェクトでもこれらのツールを使ってるけど、見て学ぶことを期待してたんだ。でも、こういう意見記事は例がないと本当に多すぎる。

└

彼の提案したワークフローを試してみた？これは役に立つワークフローだと思うし、もし私がこういうワークフローを見つけてなかったら、指摘してくれたことに感謝してたかも。彼はこれを実現するためのコードハーネスを書くか、すぐに作ることができると思うけど、今の時代、その手のツールは実践者であるあなたの領域のように見える。自動化したいなら、彼のコードを扱うよりも、あなたが試したいことを仕様書にする方が正直早いと思う。

LLM同士にコードレビューをさせることについてのリンク記事[1]や、マグパイツール[2]、それにCloudflareの最近の記事[3]は、どれもかなり興味深い。私はAIに対して懐疑的だけど、「機能するかどうか」じゃなくて「世界にとって良いかどうか」で考えてる。AIにこういうレビュー作業をさせるのは、思考を外注したり、作業者のスキルを下げたりしない珍しいケースだと思う。AIにコードを書かせるのとは違って、同じような警鐘が鳴らないんだ（AIが見つけた問題を修正するのも含めて）。環境問題や他の倫理的な懸念はまだ重要だけどね。最近のAIコードレビューの質には感心してるけど、GitHub PRを通じて3つの別々のAIレビュアーとやり取りするのは本当にひどい体験だ。もっとローカル志向で、jj/rebaseに気を使ったレビューラウンドがあればいいのに。*コンテキスト：かなり大きなPHP/LaravelバックエンドとVueフロントエンド

LLMのレビューや解決ループにかかる時間が、手でコードを書くよりも平均して多くなってる。流れに乗るとすごく早く書けて、時には書くよりも早くコードが出てくることもある。でも最初の数回のLLMコードは、一般的に本当にひどいからね。面白いのは、個人的にレビューしてLLMを何度も修正するのに時間をかけると、平均して同じ時間でより高品質なコードが書けるってこと。これは私特有かもしれないけど、他の誰かのコードのいくつかの反復を見ることで、自分の目的をより全体的に理解できるようになるんだ。

└

あなたのAIが悪いコードを書いているなら、AIを変えるべきだよ。現在のハイエンドAIが悪いコードを生成することはないはず。

ここ数年で興味深かったのは、自分のコーディングの怠惰さの限界を探ることだね。コーダーとして、ボイラープレートコードを書くのが嫌いで、メンテナンスも面倒だし。だから、その好みに合わせて設計やアーキテクチャを考えてた。時にはそれが賢明な選択だったり、時にはそうじゃなかったり。でも、それが自分の好みで、苦手なことを避けてたんだ。数年前にLLM（大規模言語モデル）がコーディングに役立つようになって、特にボイラープレートを書くのが得意だってわかった時、デザインやシステムアーキテクチャでの調整について考えさせられた。現代のモデルは人間とは全く違う強みと弱みを持っていて、それを活用するのは本当に面白い挑戦だと思う。楽しんでるし、これからも続けられたらいいな。

└

ボイラープレートについて言えるのは、良いライブラリやフレームワークがあれば、それがオプションになったり、自動で書かれたりするってこと。LLMにプロンプトを出して、何が出てくるかわからないより、django-admin startprojectやnpm init、meteor createで決定的な出力を得る方がずっといい。成熟したウェブエコシステムでは、ボイラープレートは最小限だよね。今、LLMにこのタスクを任せるようになったことで、startproject的なCLIや良いデフォルト設定にかける開発努力が減ってしまうのが心配。

この記事はAIを使ったコードの書き方については触れてなくて、コードレビューだけだね。エージェント的なコーディングに対する俺の問題は、プログラミング中にたくさんのマイクロアーキテクチャの決定をすることなんだ。最初に完全な仕様を持っていることはほとんどなくて、書いていることを考えながら仕様を作っていく感じ。Claude CodeやCodexを使うと、それが全部なくなっちゃう。Claude Codeは目標にすごく早く到達しようとするから、コードを書くのが夢の中みたいに感じる。結局、エッジケースやプロジェクトのアーキテクチャやデザイン目標に合っているかどうかに自信が持てない。さらに、プログラミングやリバースエンジニアリングが好きだから、LLMは問題を解決したり機能を提供したりできるけど、その楽しさを奪ってしまう気がする。自信を持てるワークフローを見つけようと頑張ってるけど、そのワークフローはチャットや検索、思考のためのラバーダックになってしまうのが怖い。

現在の結論として、AIは今まで以上に重要だと思ってる。何が重要なのかはよくわからないけど、なんとなく感じるんだ。質とか本物感、職人技みたいなものかな。高い道具と安い道具の違いって、簡単には説明できないけど、なんか分かるよね。これにぴったりな言葉ってあるのかな？日本語かドイツ語にはあると思う。今はAIをたくさん使ってるけど、少しずつ進めてる感じ。AI自体は職人ではないけど、職人になる手助けはしてくれる。

└

それを表現するのに「センス」って言葉を使うよね。

└

ピルジグが『禅とオートバイ修理技術』で言っていたように、質だね。

これを読んでる間に、かなり密度の高い機能を作ってるんだけど、何度も試行錯誤した結果、最終的には半分のコード量になったんだ。AIが本当に助けてくれたのか疑問に思ってたけど、同じ時間でコードを書けたはずだし。でも！AIのおかげで、気に入らない機能のバリエーションを4つもすぐに作れたし、すぐに捨てることにも抵抗がなかった。

└

これがAIを使って得られた最も大きな改善の一つだよ。以前は新しい機能の実装に入る前に計画をしっかり考えなきゃいけなかったし、実装のかなりの部分を書いた後でしか既存のコードとの互換性の問題に気づけなかった。今はAIに詳細な実装計画を聞けるから、数時間で細かい問題を見つけられるんだ。

└

で、結論はどうなの？やった価値あった？

コードの質を重視して、出力速度を最適化するのは素晴らしいアプローチだね。ゆっくり書くことで「失われた」時間は、後でデバッグやメンテナンスにかかる時間を節約することで簡単に取り戻せるから。

完全に同意！プロダクション向けのプラットフォームをゼロから作ったけど、3〜4ヶ月かかったよ。AIがなかったら、3人のチームでは絶対に完成できなかった。ひとつ言っておくと、AIはフロントエンドが苦手だから、フロントエンドは全部AIなしでやったんだ。