ハクソク

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

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

2026年5月26日原文(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にバグを見つけさせる」っていうプロンプトを提案してて、それをみんなにやるように勧めてる。仕事でも個人のサイドプロジェクトでもこれらのツールを使ってるけど、見て学ぶことを期待してたんだ。でも、こういう意見記事は例がないと本当に多すぎる。

Hacker Newsで議論の続きを見る