- AIエージェントがコード作成の中心に入り込むにつれて、テスト、ドキュメント化、静的タイピングなど、これまで「任意」だったベストプラクティスが今や必須要素へと変わっている
- 100%のコードカバレッジを求めることで、すべてのコード行が実際に検証され、実行可能な例によって裏付けられるようにしている
- ディレクトリ構造とファイル命名を明確にし、LLMがコードベースを探索しやすくするとともに、小さな単位のファイル構成を推奨している
- 高速・一時的・同時実行可能な開発環境を構築し、複数のエージェントが並列で作業できるようにする
- 静的型システムと自動化された品質管理ツールによって、AIが信頼できるコードエコシステムを維持することが核心である
AIと「良いコード」の必然性
- 長い間、開発者はテスト、ドキュメント化、小さなモジュール、静的タイピングなどを良いコードの基準として認識してきたが、現実にはしばしば省略されてきた
- しかしAIエージェントは自力でコードをうまく整理できないため、こうしたベストプラクティスが不可欠になる
- エージェントが誤った方向に進まないようにするには、明確なガードレールの設定と強制実行が必須である
- 堅牢なガードレールがあれば、LLMは正しい経路にのみ収束し、不完全な環境では問題を増幅させる
100%コードカバレッジ
- チームは100%コードカバレッジを義務化しており、これは単なるバグ防止ではなく、エージェントが書いたすべてのコードの挙動を検証するためである
- 95%や99.99%のカバレッジでは、テストされていないコードの出所が不明確だが、100%なら未検証の行をすべて明確に特定できる
- カバレッジレポートはテストすべき項目の一覧として活用され、LLMがコード変更時に必ず実行可能な例を提示しなければならない
- このアプローチには、到達不能コードの削除、エッジケースの明示、コードレビュー効率の向上といった副次効果もある
名前空間とファイル構造
- エージェントはファイルシステムを通じてコードベースを探索するため、ディレクトリ構造とファイル名が重要なインターフェースとして機能する
- ./billing/invoices/compute.ts のような明確なパスは、./utils/helpers.ts よりはるかに多くの情報を伝える
- 小さく明確に定義されたファイル単位を好むべきであり、これによってLLMはファイル全体を文脈として読み込めるため、性能低下を防げる
- このような構造化は、エージェントの探索速度と精度の向上につながる
高速・一時的・同時実行可能な開発環境
- 従来の単一開発環境に代わり、エージェントベースの開発では複数のプロセスを並列管理する形へと移行している
- Fast: テストと検証手順は高速に実行される必要があり、チームは10,000件以上のアサーションを1分以内に完了するよう最適化している
- 高度な並列化、強力な分離、サードパーティ呼び出しのキャッシュレイヤーによって速度を確保する
- Ephemeral:
new-feature <name> コマンドで1〜2秒以内に新しい環境を生成し、自動設定とエージェント実行まで行う
- 手動設定が必要だと利用頻度が急減するため、完全自動化が鍵となる
- Concurrent: 複数の開発環境を同時に実行できるように、ポート、DB、キャッシュなどの競合防止設定が必要である
- Dockerを活用したり、環境変数ベースで分離構成を行う
エンドツーエンドの型システムと自動化された品質管理
- 可能な限り多くのベストプラクティスを自動化し、LLMの自由度を下げて一貫した品質を維持する
- 自動リンターとフォーマッターを厳格に設定し、LLMが作業を終えるたびに自動修正を適用する
- 静的型付け言語の使用を推奨し、特にTypeScriptを中心に強力な型システムを活用する
UserId, WorkspaceSlug, SignedWebhookPayload のような意味のある型名によって、コードの意図を明確に表現する
- OpenAPIを通じてフロントエンドとバックエンド間の型整合性を維持する
- Postgresの型システムとトリガーを活用してデータ整合性を確保し、Kyselyで型安全なクライアントを生成する
- すべてのサードパーティクライアントも正確な型定義を備えるか、ラップして利用する
結論: AI時代のコード品質の再定義
- エージェントは疲れを知らない優秀なコーダーだが、その性能は環境の品質に依存する
- 「良いコード」はもはや選択肢ではなく、AIが正しく機能するための前提条件である
- 初期設定は負担に感じられるかもしれないが、これは長年先送りしてきた必須の投資である
- 開発リーダーシップの支援のもと、AIフレンドリーなコードベースの構築を目指すべきである
1件のコメント
Hacker Newsの意見
100%カバレッジを達成する際の落とし穴は、コードとテストを同じエージェントが書くと自己矛盾した検証に陥りうることだ
エージェントが誤ったロジックを作り、それを検証するテストまで誤って書けば、テストは通るが実際にはバグを含むコードになってしまう
こうしたカバレッジに意味があるのは、コードより先にテストが書かれるか、人間が厳密に検証する場合だけだ
そうでなければ、単に幻想の信頼性を作り出しているにすぎない
複数の異なる思考様式の人たちが互いの盲点を検証することが核心だ
AIモデルが複数あっても、結局はひとつの「心」として扱うべきだ
人間のコードにAIのテスト、AIのコードに人間のテスト、あるいは相互にコードレビューする形がよい
ただし人間同士でも権力関係のせいで一人の意見しか反映されないことがあり、AIがそれを防いでくれるわけではない
わざとバグを入れて失敗するか確認しなければならない
これはAI固有の問題ではなく、人間でも同じだ
それでもAIのおかげで、多くの開発者がまともなエンジニアリング原則を学ぶようになったのはよいことだ
SQLiteや航空ソフトウェアはこうした水準を目標にしている
ただしこれは、まだ学術的に検証された仮説ではない
だから統合テストやUI自動化テストで実際のユーザーシナリオを検証すべきだ
本番環境から持ってきたデータや、シャドー環境でのテストも役に立つ
LLM以前はセットアップが面倒だったが、今ではROIがよくなった
Uncle Bobが強調したように、テストの構造化に投資することが重要だ
LLMは反復的なテストを書くが、頼めばDRY原則やファクトリーパターンもきちんと適用する
昨日から試している方法だが、まずTLA+/PlusCalで仕様を書き、その仕様どおりにCodexへ実装させている
創造性は出さず、仕様にだけ忠実であるよう指示している
出てくるコードは不格好だが正確で、自分で翻訳するよりずっと速い
ただし最適化が足りなかったり、あまりに汚かったりすると一部手直しする
特にロックフリーなデータ構造を試しているのだが、Codexはまだロックを使いたがるので自分で修正する必要がある
結局、自分は数学的論理に集中し、AIは実装の細部を担う形で進めている
これこそ「仕様先行、コード後行」の理想的な流れだ
Martin Kleppmannの文章に共感する
最新モデルでは実際にかなりうまく機能し、費用対効果も10〜100倍よくなった
これは幻覚かセールストークのように思える
実運用のバグや保守負担が良いコードを強制できないなら、AIにもできない
今のレベルのAIは、むしろコードをさらに悪くする可能性が高い
メソッドの長さひとつ取っても合意がない状況で、普遍的な品質基準など存在しない
テストカバレッジのような指標も簡単に操作でき、誤って適用すればむしろ有害だ
特にAIがテストを書く場合、偽りの自信を与えかねない
私はソフトウェア開発がLLMの唯一の実質的な応用分野かもしれないと思っている
他の分野よりフィードバックループを速く作れるからだ
LLMと計画を立て、数時間後に失敗を確認すると、LLMが「だからそうしてはいけないんだ」と言う
まるで米国式の電気規格で家を建てて、あとからカナダ式の食洗機を設置しようとして問題に気づくようなものだ
ソフトウェアは比較的安全だったので匿名の開発も可能だったが、今は責任ある署名文化が生まれつつある
今後は高リスクで革新的なコードを書く人だけが高い報酬を得るのかもしれない
AIがひたすら見当違いのコードを出し、こちらがデバッグし、また別の見当違いなものを出す無限ループに陥るだけだ
ただし電流規格だけ合わせれば安全だ
それでも自分は、単体テストで現実との接点を確認できるのはありがたいと思う
私はLLMでRLC回路とinerterを勉強している
多くの人はLLMが高速にコードを生成するのを見て驚くが、速度や量は品質のボトルネックではない
AIが人間より正確なコードを作れるようになったとき、本当の革新が起こるだろう
本当の価値は、コードがどう動くかを知っていることから生まれる
会議の場で推測ばかりしていたエンジニアたちの中で、一人が実際のコードを開いて見せる瞬間こそ最も価値がある
「良いコード」とは、もしかすると人間の限られた作業記憶に合わせて最適化されたコードなのかもしれない
モデルはすべての文脈を一度に見られるので、そうした制約がない
コンテキストウィンドウが100倍になれば、こうした議論はそれほど重要でなくなるかもしれない
LLMに100%カバレッジを求めると、誤った前提が固定化されるのではと心配だ
それでも人間のレビューがあれば、「これは間違っているからテストを消して書き直そう」と言えるのでは？
LLMがインタビューするようにPRDを一緒に作り、範囲と期待値を明確にしている
「ベストプラクティス」は技術環境によって変わる
コードを書くことが簡単になった今、100%カバレッジはLLMにとってより有用かもしれない
テストはLLMに明確な目標を与え、その後のやり取りをより安全にする
各テストが過去のバグチケットを参照し、修正が維持されることを保証する
LLMにシナリオを与えれば、大半は似た品質のコードを生成する
創造的な芸術と違って、ソフトウェアは自動化に特化した産業なのだ
この記事を見て、「AIが効果的であるには、私たちが良いコードを書かなければならない」という話だと思った
実際、Claudeは曖昧な変数名や非論理的なコードでよくミスをする
変数名が「iteration_count」なのに合計値を入れていたら、AIは騙される
結局、きれいなコードはAIにも人間にも役立つ
AIが社内文書を学習資源として使うため、今では更新された文書が必須だと見なされている
以前は優先度が低かったが、今はモデル品質に直接影響するからだ
ただ、時間がたてばこの点も改善されるだろう
そうすればLLMが一度で正確に実装できる確率が高くなる
この記事はプロンプト企業の浅いエンジニアリング理解を露呈している
100%カバレッジではすべての入力組み合わせを検証できない
単にいくつかの例で全行を実行したにすぎない
結局は形式的証明が必要だが、そのコストは天文学的で、LLMは役に立たない
むしろテストによって反応的な開発環境を作ることが、新たな黄金時代を開くかもしれない
カバレッジに問題があるなら、あとで拡張すればよい
最初からできるだけ徹底的にテストを整備するのがよい
すでにproof assistantとつないで使う試みは多い
仕様に多少の誤りがあっても、大半は実用になる結果を出す