Comments 9
"Claude, make my vibecoded app prod-ready. Fan out subagents. Use best practises, don't make mistakes"
О, у меня почти такая же схема, только с ревьюером наоборот — он не постоянный, а каждый раз новый. Специально. Свежая сессия с одним и тем же чеклистом на каждый PR: у неё нет «вчера», она не привыкает к коду и не замыливается. Пару раз ревьюверы ловили мои собственные баги, которые я в упор не видел. А контекст проекта живёт не в ревьюере, а в репозитории — есть реестр правил, сессия читает его перед ревью.
А у постоянного ревьюера не замечали эффекта привыкания?
Логика такая: если он один раз пропустил какой-то сомнительный паттерн, дальше этот паттерн сидит у него в контексте уже как норма — и он будет пропускать его всегда. Я из-за этого страха и ушёл на свежие сессии, но живого сравнения двух схем у меня нет — интересен ваш опыт.
Ну у меня контекст хранится только в пределах одного батча ревью - тоесть на примерно 40 фаз (иначе очень много времени уходит на бутстрап ревью на каждую фазу - чтобы агенту погрузиться в проект). При повторном перезапуске контекст новый. Можно запустить несколько раз по очереди и это будет как дать на доработку проект 3-м разным специалистам по очереди.
Тогда наши подходы ближе, чем я думал — «дать проект трём разным специалистам по очереди» у меня оформилось в отдельную практику: периодические проходы по всему корпусу (документации, кода, дизайн системы и тд) несколькими агентами с разными фокусами (код, доки, хозяйство репозитория). Работает неожиданно хорошо — последний такой проход нашёл дыру, которую ревью на PR не поймало бы в принципе, потому что она жила между диффами.
Единственное, что добавил бы к вашей схеме из своего опыта: конвертировать находки прогона во что-то. У меня это реестр правил — каждая находка становится строкой, и следующие сессии читают реестр перед работой. Иначе «специалист №3» тратит бутстрап на переоткрытие того, что №1 уже находил. У вас находки батча оседают куда-то между перезапусками, или каждый прогон с чистого листа?
У меня на каждую фазу ревью, если найдены блокеры сразу запускается воркер, который создает план исправлений всех блокеров и вторым шагом (/goal) исправляет их, потом управление возвращается ревьюверу и он проверяет за воркером. И так пока не будет блокеров или исчерпается количество ревью на фазу. Потом ревьювер переходит к следующей фазе. Тоесть у меня не только ревью, а сразу с исправлением.
Вот полный список ревью фаз:
Foundation
Immediate Risk Triage
Reproducible Local Run
Core Scope & Critical Journeys
Critical Smoke Baseline
Architecture
System Shape & Dependency Boundaries
Data Model & Persistence
Dead Code & Dependency Cleanup
Simplification & Deduplication
Correctness
Type Safety
Runtime Contracts
Error Handling
Failure Diagnostics
Data Integrity & Migrations
Consolidation & Cleanup
Product
UX Completeness
Accessibility
Interaction & UI Cleanup
Verification
Core Unit & Invariants
Integration
Contracts & Compatibility
End-to-End Critical Journeys
Test Suite Cleanup & Stability
Static Analysis & Formatting
Operations
Observability
Reliability & Operability
Performance & Resource Efficiency
Instrumentation & Runtime Cleanup
Assurance
Application Security Hardening
Privacy & Sensitive Data
Legal & Compliance Readiness
Cleanup
Dead Code & Unused Surface
Dependencies, Scripts & Configuration
Duplication & Consolidation
Temporary, Legacy & Debug Artifacts
Owned Code Reduction
Delivery
CI Quality Gates
Release Artifact Integrity
Secure Supply Chain
Deployment Readiness
Staging Verification
Documentation & Repository
Список фаз впечатляет!
Особенно то, что цикл «ревьювер → воркер с планом исправлений → перепроверка» замкнут автоматически — у меня этот шаг пока ручной.
Пару фаз из вашего списка утащу себе в чеклист (Dead Code & Dependency Cleanup и Test Suite Stability — ровно мои болевые точки).
Спасибо за развёрнутые ответы, удачи с инструментом — выглядит круто!
Можете подсмотреть промпты для фаз. Я их пока не вылизывал, но как начальная точка - норм: https://github.com/vv-bogdanov/pre2prod/blob/main/resources/phases.yaml
Как я автоматизировал превращение вайбкодерского PoC в production-ready MVP