概要
https://blog.tolki.dev/posts/2025/08-07-llms/
詳細内容
## The current state of LLM-driven development
https://blog.tolki.dev/posts/2025/08-07-llms/
本記事は、多数のAIコーディングツールを徹底的にテストし、LLMを活用した開発の現状における実用的な限界と最適なユースケースを評価します。
**Content Type**: ⚙️ Tools
**Scores**: Signal:4/5 | Depth:4/5 | Unique:4/5 | Practical:5/5 | Anti-Hype:5/5
**Main Journal**: 88/100 | **Annex Potential**: 87/100 | **Overall**: 88/100
**Topics**: [[LLM-driven development, AIコーディングツール, 開発ワークフロー, LLMの限界, コード品質]]
著者は約4週間にわたり、GitHub Copilot、Claude Code Pro、Gemini CLI、AI-first IDEsなど、さまざまなLLM駆動型開発ツールを試用した経験を共有しています。その結論は、これらのツールが魔法ではなく、単なる「ツール呼び出し」の繰り返しに過ぎないというものです。特に、Webアプリケーション開発者にとって重要なのは、LLMがコードの安定性、特に価格変動や頻繁なアップデートに起因するワークフローの不安定性という大きな問題を抱えている点です。
具体的には、LLMはFlutterのトークンフィールドのような複雑なUIコンポーネントや、これまでに何百万回も書かれていないようなニッチなコードの生成には著しく失敗します。一方で、Rustのような強力な型付け言語や、ボイラープレートコード、統合テストの記述、新しい技術スタックの学習、小規模なユーティリティツールの作成においては非常に役立つと指摘されています。しかし、アプリケーションのコア機能にLLMを用いると、不要な複雑性やコードの重複を招き、結果的に開発者自身のスキルを低下させる可能性があると警鐘を鳴らしています。
市場のツールの中では、GitHub Copilotがコストパフォーマンスとカスタマイズ性で推奨されるものの、そのVSCodeへの強い依存性や機能過多による使いづらさも指摘されています。著者は、「最大のLLMですべてをまかなう」という現在のAI開発アプローチに疑問を呈し、現実的な利用シーンの理解と、必要に応じてLLMを活用しない選択肢も重要だと強調します。AIの過剰な期待に惑わされず、その真の価値と限界を理解し、効率的な開発ワークフローに統合することが、私たちWebアプリケーションエンジニアには求められます。