AIコーディングで品質が落ちるなら、品質管理のやり方が間違っている
If AI coding is lowering your code quality, you're not managing quality right
AIコーディングエージェントの導入でコード量が増えても、盲目的にマージすれば品質は当然落ちる。しかしspec-driven developmentやAIによる要件レビュー、TDD、E2Eテスト、複数のAIコードレビュー、本番エラーの自動診断といった多層的な防御策を組み合わせれば、バグを減らしつつ出力を2〜3倍にできる。筆者の実体験に基づく具体的な手法を紹介する。
適切な防御層を備えれば、出力の増加が信頼性の低下を招く必要はない。むしろコーディングエージェントのおかげで、以前より多くの、より深いチェックを安価に追加できるようになった。
HNでの議論
103- zug_zug
これはちょっと単純化しすぎた考え方だと思う。確かに「エンジニアが結果に責任を持つ、AIはただのツール、自分が保証できないものはリリースするな」という話はたくさん見てきた。
しかし、それは現実的ではないと思う。著者にいきなり編集者になれと言っているようなものだ。コードを書く人に、他人のコードを読んでデバッグしろと言っているようなものだ。
厄介なコードのバグを見つけるのは、自分で正しいコードを一から書くよりも難しいことだってある。自分の個人プロジェクトでは、AIがいつもありとあらゆるバグを持ち込んでくる。自分なら絶対に入れないし、テストしようとも思わないようなバグ、特にグラフィック関連ではそうだ。
- axegon_
ああ、また「スキル不足」論か。5、6年前にみんながMuskを崇拝していたときと同じたわごとだ。今回はdarioとaltmanがclaude/chatgptの仮面をかぶっているだけ。クラッシュは早ければ早いほどいい。
- chadash
エージェントがまともなコードを生成できることには同意する。一般的に、エージェントのコードを美しいとは思わないが、自分が書くコードのほとんども美しくはない。ETLパイプラインにCSVファイルを取り込むコードは美しい必要はなく、動けばいい。
もっと大きな問題は（ソフトウェアエンジニアリングの多くのことと同様に）マネジメントの問題だと思う。かつては、プロジェクトの最終成果物を眺めて、外見がFerrariのように見えれば、内部に良いエンジンがあるとある程度信頼できた。もちろん常にそうとは限らなかったが、見た目が良いとか、パフォーマンスが良いとかいうのは、内部のコードが良いことのかなりの代理指標だった。そして賢い人間なら、付随するものもあった。20時間かけて何かをコーディングすれば、マネージャーやプロダクトチームが考えなかったエッジケースについてもおそらく考え抜いただろう。
AIでは、誰の成果物もFerrariのように見えるので、内部がどうなっているか分かりにくい。
多くの人はこれを見て「もっと良いマネジメントが必要だ」と言うだろうが、ソフトウェアエンジニアリングにおいて良いマネジメントは常に得難いものだった。さらに、AIが生成したコードをレビューするのは魂を削る作業で、誰がやりたいと思うだろうか。
私の推測では、優れたエンジニアリングマネージャーの数は実際にはごくわずかで、実際に私が見てきた最高のマネージャーは、自分が良いマネージャーだと思っていない人たちだ。だから採用基準を非常に高く設定し、あまり手のかからない人材を雇うのだ。
- fishfasell
AIエージェントが一貫して良いコードを書くには、多くのセットアップとコンテキストが必要だと思う。一度エージェントにこうしたガードレールが整えば、たいていは素晴らしい品質が得られる。多くの場合、自分が書くよりはるかに良い。
問題が厄介になるのは、あらゆる言語で書けるようになるときだ。私は流暢ではない多くの言語やフレームワークでコードを書き、レビューしているので、動くコードと素晴らしいコードの区別がつきにくい。基本的なロジックが間違っているのは見抜けるが、「最適な」選択に関してはお手上げだ。
- Havoc
ステップ0は、自分のオーディエンスを知ることだと思う。
私は自分のおもちゃのプロジェクトを楽しくvibeコーディングしているが、病院の技術がvibeコーディングされるのは避けたい。
そして、その二つの間のギャップが「まあ、正しく使えばいいだけだよ」で埋まるとは思えない。
- teliskr
claudeからは本当に良い結果が得られている。我々には22年物のレガシーシステムがある。システムは安定しているが、どのレガシーシステムにもあるような問題を抱えていた。Claudeはコードベースのモダナイズ、依存関係の更新、セキュリティ監査、新機能の迅速な追加に非常に役立っている。既存のコードスタイルやパターンともうまく機能した。時々少し脱線するが、全体的にはかなり驚くべきものだ。
新機能を実装したり、大規模なリファクタリングを行うときは、superpowers:brainstormingスキルを使っている。一貫したプロセスで、非常によく機能している。マージ前に必ずコードをレビューするが、ほとんどの場合、修正すべき問題はほとんどない。
95%のカバレッジはやっていないが、65%から80%以上に引き上げており、それで十分だ。
- moltar
もっと単純な話だと思う。要は「気にかけるかどうか」だ。
長距離ドライブ中に同僚と長々と議論したことがある。
そこで気づいたのは、コードを書くことに対する我々の姿勢の違いだ。
私はこれを工芸として捉えている。最近はコーディングの100%をエージェントで行っているが、それでも結果が高品質で保守可能であることを気にかけている。スケーラブルなシステムをエージェントが作れるよう、システム設計の知識を使って導いている。
彼はただの仕事として扱っている。十分良ければ出荷する。エッジケースやバグは問題ではない。後で直せばいい。
しかし私の考えではそれは誤りだ。明らかな欠陥でユーザーが苦情を言わない限り、物事は後で直されないことは誰もが知っている。
代わりに、全体的な品質が徐々に低下していく。そうした小さな問題が積み重なり、デバッグや保守が難しい脆いシステムが生まれる。
私のソフトウェアエンジニアリングのメンタルモデルはこうだ。各コミット/PRは小さなLEGOブロックのようなものだ。うまく作ればしっかり噛み合い、力に耐えられる安定した構造を作る。作るLEGOブロックの一つ一つが少しずつずれていれば、構造は不安定になり、常に欠陥があり、予測不能な環境圧力の下で常に失敗するだろう。
- oefrha
AIコーディングでコード品質が下がっていないなら、あなたの出発点が低いだけだ。