概要
https://antropia.studio/blog/to-ai-or-not-to-ai/
詳細内容
## To AI or not to AI
https://antropia.studio/blog/to-ai-or-not-to-ai/
AIによるアプリケーション開発実験の2週間が、LLMを活用した開発ワークフローにおける深刻な課題を浮き彫りにし、特定のタスク以外での全面的なAI導入にはまだ不十分であると結論付けている。
**Content Type**: Opinion & Commentary
**Scores**: Signal:4/5 | Depth:3/5 | Unique:4/5 | Practical:4/5 | Anti-Hype:5/5
**Main Journal**: 75/100 | **Annex Potential**: 81/100 | **Overall**: 80/100
**Topics**: [[AIコーディング, LLM開発ワークフロー, 開発者生産性, AIの限界, コードの保守性]]
Antropia Studioは、Facebook Ads APIを活用したシンプルなアプリ「adbrew」を開発する2週間の実験で、生成AI（Claude CodeとRemix）をフル活用しました。しかし、この試みは多くの課題を浮き彫りにし、完全なAIによる開発には現状では限界があるという結論に至りました。
実験では、問題を定義し、AIに実装させ、コードをレビューし、デプロイするというサイクルを繰り返しました。しかし、コンテキスト不足によりAIはしばしば誤った仮定に基づき、適切なフィードバックを要求しませんでした。また、コードの保守性にも問題があり、AIは既存のコンポーネントを再利用せず、類似のコードを繰り返し生成するため、プロジェクトが肥大化し、整理された抽象化が不可能になりました。
開発フローも滞り、AIがコードを生成する間、人間は間違いを早期に発見しようと画面を監視する必要があり、開発の勢いを失いました。さらに、Facebook APIのような文書化が不十分で型定義が曖昧な環境では、AIは自信満々に存在しないパラメーターやエンドポイントを「幻覚」として作り出し、深刻なバグの温床となりました。
最も重要なのは、AIがソリューションの80%を比較的容易に達成する一方で、残りの20%（エッジケース、機能間の相互作用、横断的なタスクなど）を解決するために、依然として多大な時間（全体の80%）が必要だったことです。これは、AIが表面的なタスクには優れるものの、システム全体の整合性や品質維持には不向きであることを示しています。
結果として、コードは肥大化し、開発プロセスは楽しくなくなり、品質も期待に沿いませんでした。彼らは従来のワークフローに戻り、AIは「強力な検索エンジン」「ラバーダッキング（アイデア出し）」「コードスニペットの生成」「テスト作成」「言語関連タスク（コミットメッセージの校正など）」といった特定の役割で使うべきだと提言しています。特に、人間が作成したものをAIにレビューさせるという逆転した関係性を推奨しており、これはウェブアプリケーション開発者にとって、AIを効果的に活用し、その限界を理解するための重要な指針となります。