Дмитрий Грицан
Если развивать дальше мысль о том, что можно управлять требованиями непосредственно в репозитории проекта, то слово "монорепозиторий" начинает играть новыми красками.
И на первый взгляд всё выглядит прям прикольно:
- продакт написал требования, сделал Pull-Request;
- LLM'ка его обработала, проверила консистентность с другими требованиями и текущей реализацией, предложила варианты, как именно это запилить;
- я уточнил план реализации и запустил агентов его имплементить.
🤖 На практике первый же вопрос, который вводит меня в лёгкий ступор: а какой флоу выбрать в этом случае для работы с гитом?
Второй вопрос связан с первым, но ещё более практический: а где гонять и как управлять теми агентами, которые должны обрабатывать пулл-реквесты?
Пока у меня в голове есть два варианта:
🔧 Костыльный:
- каждый член команды работает в своей ветке;
- не реже, чем раз в неделю, коммитит изменения в GitHub;
- я (ну не прям ручками, а, например, локальным курсором и скриптами) раз в неделю собираю всё в Pull-Request в основную ветку и на нём уже гоняю агентов.
⚙️ Системный:
- объяснить команде концепции веток, push/pull, ревью и CI/CD;
- настроить автоматизацию в GitHub.
С технической точки зрения мне второй путь ближе. С практической — выглядит как два отдельных больших проекта (обучение коллег и реализация всей этой системы) вместо того, чтобы заниматься непосредственно развитием продукта.
Собственно, у меня к вам два вопроса:
1. Какой бы путь выбрали вы? Или, если уже выбрали, — поделитесь с чем столкнулись
2. Как вы решаете, сколько времени тратить на автоматизацию и настройку процессов, а сколько — на текущие задачи? ⚖️
388 ·