Vibe Coding Go¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
Go の設計原則を守りながら AI とコードを書くため、事前制約、開発プロセス、事後検証を仕組み化する資料。
CLAUDE.md や Cursor Rules を設計契約書として使い、GitHub Issue 起点で Plan Mode / Spec-Workflow を使い分ける。
pre-commit、golangci-lint、go test、gitleaks、markdownlint によって、人間も AI も同じ品質ゲートを通す。
本文¶
資料の問題意識は、AI が生成するコードへの不安。 一貫性のない architecture、動くだけで test がない code、Go idiom を無視した実装が混入する懸念がある。
解決策は、AI を設計意図を汲んでコードを書く partner に育てること。 そのために 3 段階の仕組みを置く。
- 事前制約
- 開発プロセス
- 事後検証
事前制約では CLAUDE.md を設計契約書として使う。
Clean Architecture の依存方向、coding rule、error handling、命名規則、禁止事項、開発 command を明記する。
Cursor Rules では file pattern ごとの詳細 rule を分ける。
開発プロセスは GitHub Issue 起点。
小から中規模の変更は Plan Mode で、AI が計画を作り、人間が承認して実装する。
複数 feature にまたがる大規模変更は Spec-Workflow にし、requirements.md、design.md、tasks.md を人間が承認しながら進める。
事後検証では pre-commit を使い、golangci-lint、go test、go fmt / imports、gitleaks、markdownlint を実行する。
--no-verify 禁止を CLAUDE.md に明記し、AI も品質 gate を迂回できないようにする。
実践パターンとして、feature-first の Clean Architecture、DI、type-safe domain model、Port / Adapter pattern、testcontainers-go を使う test strategy が挙げられている。
要点¶
- AI に設計を守らせるには、事前制約と品質 gate が必要。
CLAUDE.mdは project 固有の設計契約書になる。- 変更規模に応じて Plan Mode と Spec-Workflow を使い分ける。
- pre-commit と CI で人間と AI を同じ品質基準に乗せる。
- AI-friendly な設計は、人間にとっても読みやすい設計になりやすい。