概要
https://news.ycombinator.com/item?id=46292682
詳細内容
## 既存のコードベースでLLMを活用したコーディングはどのように行われていますか？
https://news.ycombinator.com/item?id=46292682
**Original Title**: Ask HN: How are you LLM-coding in an established code base?
スタートアップは、GitHub CopilotやCursorなどのLLMベースのツールを既存のモノレポ型コードベースに積極的に統合し、その具体的な開発ワークフロー、得られた生産性向上、およびインフラテストやモデルの限界といった課題を共有しています。
**Content Type**: ⚙️ Tools
**Language**: en
**Scores**: Signal:4/5 | Depth:4/5 | Unique:4/5 | Practical:5/5 | Anti-Hype:5/5
**Main Journal**: 100/100 | **Annex Potential**: 100/100 | **Overall**: 88/100
**Topics**: [[LLM-assisted coding, 開発ワークフロー, モノレポ開発, AIコードレビュー, 統合テスト]]
あるスタートアップは、Pythonデータワークフローと2つのNext.jsアプリケーションを含むモノレポ環境において、LLMをコーディングに積極的に活用しています。各エンジニアにCursor Pro、Gemini Pro、OpenAI Pro、オプションでClaude Proを提供し、月額約1000ドルのコストで1.5人分のジュニア・ミッドレベルエンジニアに相当する生産性向上を実現していると報告されています。
彼らのワークフローは、静的解析、テスト、フォーマットを含む厳格なpre-commitフックに大きく依存しています。GitHub Enterpriseを利用し、全てのGitHub IssueをCopilotに割り当ててプルリクエスト（PR）を自動生成させます。生成されたPRの約25%はそのままマージ可能で、コメントを数回加えることで約50%がマージ可能になるといいます。個人の開発ループとしては、外出先ではGitHub IssueからCopilotにPR生成を依頼し、デスクではCursorをエージェントとして利用し、テスト作成やコードレビューをLLMに任せることで効率化を図っています。
しかし、既存のシステムでLLMを大規模に導入する上での課題も浮き彫りになっています。特に、複数のサービス（Temporal、Next.jsアプリ、Python/Nodeワーカーなど）からなる複雑な統合環境でのテストは、Docker化されているものとそうでないものが混在するため、手動検証やデータベース操作が絡むと、全てのインフラを立ち上げてPlaywrightなどの自動テストを実行し、手動でシステムを操作できるようなサービスは存在しない点が指摘されています。また、CopilotのIssueアサインやコードレビュー機能で利用されるモデルは選択できず、性能が劣ることが問題とされています。
コメント欄では、他の開発者からも様々な意見が寄せられています。LLMは特定のユニットテストや自己完結型の関数実装、定型的なコード作成に非常に有用である一方で、複雑なレガシーコード、大規模なコードベースにおけるコンテキスト管理、システム全体のアーキテクチャ理解、微妙な競合状態の検出などには依然として課題があると認識されています。一部のユーザーは、LLMを「ジュニアのペアプログラマー」として扱い、タスクを細分化し、計画を立てながら、人間が主導するアプローチが最も効果的だと述べています。Superconductor.devのような、複雑なテスト環境の自動プロビジョニングを謳うサービスも提案されており、この分野の課題解決に向けた動きも見られます。一方で、LLM生成コードの品質の低さや幻覚問題から、その利用を完全に禁止しているケースも報告されており、LLMコーディングの成熟度や適用範囲については意見が分かれています。