## 概要 [[📚The Five Levels from Spicy Autocomplete to the Dark Factory]]で定義されているLV4 [[エンジニアチーム]]を目指すロードマップ、課題、達成状況をまとめる。 ## 目標と現状 ### 目標(LV4) 1. 『仕様』を入力とし、『Web・BFF・DB・E2Eテストを含めた実装計画を出力する』(AIと対話) 2. 『実装計画』を入力とし、『プロダクトコード』と『E2Eテスト結果』を出力する (AIが全自動) - 自動レビューもここに含める 3. 出力内容を確認し、問題なければ対応完了。問題があれば1か2のいずれかに戻る ### 今まで(LV3) 1. 『仕様』を入力とし、開発者がDBの設計を行う 2. 開発者が『BFF』の設計を行う 3. 開発者が『Web』の設計を行う 4. 🤖 AIが『BFFの設計』をもとに『BFFの実装』『ユニットテスト作成』を行う - 開発者が『BFFの動作確認』を行う 5. 開発者が『BFFのE2Eテスト』を作成する - 開発者が『BFFのE2Eテスト』を通す 6. レビュアーが『BFFの実装・ユニットテスト・E2Eテストのレビュー』をする 7. 🤖 AIが『Webの設計』をもとに『Webの実装』『ユニットテスト作成』を行う - 開発者が『Webの動作確認』を行う 8. レビュアーが『Webの実装・テストのレビュー』をする 9. 開発者が『WebのE2Eテスト』を作成する - 開発者が『WebのE2Eテスト』を通す 10. レビュアーが『WebのE2Eテストをレビュー』をする ## 1. 人的レビューの排除 正確には『人がレビューしなくても同等以上の品質がアウトプットとして出力されること』を保証できるようにする。(ただし、センシティブな機能除く) ### 対応内容 - 環境はLocal - [[git worktree]]を使って、他と干渉しないつくり - AIレビューは[[Docker]]コンテナ内の隔離環境で実行されるため安全性が高い - 以下をコンテキストとして読み込みレビューする - プルリクエストの説明 - 参照が必要なリポジトリ(1つ以上)の最新と、ブランチ分岐元の差分 - 結果は[[Slack]]に通知 - 指摘レベルは4段階 (CRITICAL, HIGH, MEDIUM, LOW) - 通知総数は `総括(1)` + `指摘数(N)` ### 対応後のフロー 1. 『仕様』を入力とし、開発者がDBの設計を行う 2. 開発者が『BFF』の設計を行う 3. 開発者が『Web』の設計を行う 4. 🤖 AIが『BFFの設計』をもとに『BFFの実装』『ユニットテスト作成』を行う - 開発者が『BFFの動作確認』を行う 5. 開発者が『BFFのE2Eテスト』を作成する - 開発者が『BFFのE2Eテスト』を通す 6. 🤖 **AIが『BFFの実装・ユニットテスト・E2Eテストのレビュー』をする** 7. 🤖 AIが『Webの設計』をもとに『Webの実装』『ユニットテスト作成』を行う - 開発者が『Webの動作確認』を行う 8. 🤖 **AIが『Webの実装・テストのレビュー』をする** 9. 開発者が『WebのE2Eテスト』を作成する - 開発者が『WebのE2Eテスト』を通す 10. 🤖 **AIが『WebのE2Eテストをレビュー』をする** ### 課題 どちらも対応が必要。 - レビュー対象コードの品質がそこまで高くないため、レビューと実装の往復回数が多い - **実装精度を上げる必要あり** - Custom Agent または Skill の内容を見直す - 『レビューの開始』『レビュー指摘に関する対応』のタイミングで人間の介入が必要 - **『レビューの開始』や『レビュー結果の対応』を連続実行できる仕組みが必要** - 選択肢 - 1. [[GitHub Copilot CLI]]の[[Rubber Duck (GitHub Copilot CLI)|Rubber Duck]]を使う - 2. [[cmux]]の `cmux` コマンドで[[ワークスペース (cmux)|ワークスペース]]の作成・読み取り・送信などを行う - [[#1. 人的レビューの排除]] の仕組みをそのまま組み合わせやすい - **PR作成前提という制約がある** - 3. [[サブエージェント (GitHub Copilot CLI)|サブエージェント]]にレビューさせる - 『実装時のレビュー』と『PR作成後のレビュー』はどちらも必要なのか？