MonkeyCode：共有された AI 開発基盤であり、もう一つの自動補完ツールではありません。

製品の考え方が最も強いところ、そうでないところ。

有用なレビューは、利点と同じくらいに見送りの理由も見つけやすくします。

• 強み · エージェント作業を共有されたエンジニアリング作業として扱います。実行環境は後付けではなくワークフローの一部です。
• 強み · 要件、タスク、プロジェクト、レビューをつなげたままにできます。
• 強み · オープンソースであることが監査性と展開の統制を高めます。
• 強み · モデル選択を個人の開発者アカウントを超えて管理できます。
• 限界 · ホスト型 Web はローカル IDE や自動補完ツールではありません。デスクトップのローカルエージェントも IDE の完全な代替ではありません。
• 限界 · セルフホストには容量、アップグレード、ログ、バックアップ、インシデント責任が必要で、モデルの送信は展開ごとに確認が必要です。
• 限界 · AGPL-3.0 は改変やネットワーク利用の計画に影響し得ます。
• 限界 · 公開資料は性能試験やセキュリティ試験の代わりにはなりません。

1 つの基盤、4 つの評価視点。

• 開発者 · この作業を検査し修正できますか？ファイル、ターミナル、diff、ログ、ビルド、preview、フォローアップの流れを試します。
• エンジニアリングリード · チームはエージェント作業を調整できますか？要件、状況の可視性、レビュー品質、人から人への引き継ぎを試します。
• プラットフォームチーム · 予測可能に運用できますか？環境ライフサイクル、image、並行数、アップグレード、指標、コストを試します。
• セキュリティ · コードと認証情報はどこへ行きますか？モデル経路、送信、token の範囲、ログ、分離、保持、監査イベントを試します。

証拠が残る 7 日間のパイロット。

見栄えのするデモ用タスクは避けてください。実在のリポジトリ 1 つ、制限した権限、チームがすでに理解してレビューできる作業を使います。

• DAY 0 · 代表的な 3 つのタスクを決める：不具合、小さな機能、明確な受け入れ基準のあるテストまたは文書タスクを使います。
• DAY 1 · すべての信頼境界を図にする：リポジトリ権限、環境のネットワークアクセス、secret、モデルエンドポイント、保持されるデータを記録します。
• DAY 2–4 · 実際の作業を走らせ、失敗も残す：起動時間、タスク完了、ビルドとテストの結果、レビュアーの修正、誤った前提からの復旧を測ります。
• DAY 5 · 現在のワークフローと比較する：比較単位はレビュー時間と受け入れられた成果であり、生成されたコード行数ではありません。
• DAY 7 · 採用・縮小・中止を決める：対応するタスク種別、運用責任者、未解決のリスク、展開のゲートを記録します。