Comments 18
А не думали добавить ещё Code Review + Refactor Loop на Шаге 5?
Типа такого: https://pastes.io/python-zer
def _review_and_refactor_cycle(self, code_files: Dict[str, str], module_state: ModuleState) -> Dict[str, str]:
"""Review and refactor code iteratively."""
for iteration in range(self.config.max_refactor_iterations):
self.logger.info(f" Review/Refactor iteration {iteration + 1}")
review = self.code_reviewer.run(code_files, module_state)
module_state.review_results = review
if review.approval_status == "approved" or review.overall_score >= self.config.min_code_quality_score:
self.logger.info(f" ✓ Code approved (score: {review.overall_score}/10)")
break
if self.config.enable_refactoring:
code_files = self.code_refactorer.run(code_files, review, module_state.implementation)
return code_files
Частично Code Review закрывается на "Шаге 2. Перепроверка" в https://github.com/vendelev/MyDrevo/blob/master/.ai/commands/ra-php-implementation.md
Но можно и отдельного агента для этой цели создать и добавить ему какие-то доп проверки.
Мне кажется, или Вы изобрели плюс-минус BMAD Method?
Спасибо за ссылку, к сожалению, не нашел такой подход раньше.Буду изучать в деталях.
Но я не изобретал что-то новое. Я в статье старался сказать, что надо брать текущие процессы в компании и под них затачивать своих агентов.
Это просто пример, как можно сделать, не более.
Да конечно, если есть время и желание делать под себя - это всегда прекрасно. Просто там тот же подход с кучкой агентов разных специальностей, даже на совместные обсуждения их можно собирать. И проект живенький, в отличие от, похоже, умершего (после ухода мейнтейнера из MS) GitHub Spec-Kit.
Вообще из всех SDD-фреймворков мне на первый взгляд (в бою, конечно, всё не пробовал) понравился GSD как более простой вариант и BMAD - как более замороченный. Хотя, подозреваю, в итоге все эти наработки включат в свои инструменты основные игроки рынка. Что уже потихоньку происходит (в чуть большей степени продвинулись в Kiro, но и у остальных уже plan mode + мультиагентность есть, осталось немного).
https://docs.bmad-method.org/reference/workflow-map/ - выглядит прям очень круто.
Тема интересная, но откровенно говоря, текст вызывает ощущение "из пушек по воробьям", потому как промты огромные, плюс ещё много всего, а проект - генеалогическое дерево!?
Но вот несколько интересных деталей:
Контекст всё равно заканчивается
Прям хочется выразить это известным стихом - "как много в этом звуке Для сердца русского слилось! Как много в нем отозвалось" Потому как это происходит у всех и каждый раз. Но с таким объёмом spec это уже ожидаемо.
"Если после 2-х циклов ошибки остаются — передать человеку" или "Повторяй перезапуск не более 2-х раз".
Вот это очень неплохая идея записать именно в промт. Единственное, что я бы давал 3 попытки.
Разные агенты — разный стиль... Но большей частью я просто принимал это как неизбежность
Между прочим глубокая тема. Не столько в том, что разный стиль, а в том, что есть определённая неизбежность. Причем даже если код пишется без ИИ.
создать отдельного агента, который будет проверять на оверинжиниринг.
Тоже хорошая идея: добавить в список задач, кроме ревью, рефакторинга, поиска багов, ещё и проверку на оверинжиниринг
Человек по-прежнему: ... Проводит code review
А вот это непонятно. У вас что, агенты не делают ревью?
Тут нет пушки и птичек. Это учебный проект для апробации идеи.
Я немного параноик, и не доверяю агентам :)))
Лучше я всё своими глазками просмотрю.
А еще здесь проявляется другая проблема "Владение кодом".
Ревью частично закрывает это, а без него - это код, который ты купил и поддерживать вряд ли сможешь. Его проще по новой спеке заново сгенерить.
Тут такое исследование вышло:
Главные выводы:
Больше агентов - не всегда лучше
Добавление агентов помогает, когда задачу можно распараллелить.
Но в задачах с последовательной логикой это может даже ухудшить результат. Надо быть очень аккуратным при добавлении новых ролей.
Спасибо большое за такой гайд! Хочу начать разработку с нейросетями на таком продвинутом уровне, но никак не мог найти готовые шаблоны. Вы сделали нам просто невероятный подарок! Я, конечно, больше на питон ориентирован, нежели PHP, но два агента переписать уже не так сложно будет. В замен от себя хочу вам посоветовать хороший mcp для ваших агентов: beads. Эта система позволяет эффективно наладить параллельную работу нескольких агентов. Видел много хороших отзывов, да и сам согласен с автором этой штуки, что подход действительно хороший. Надеюсь, вам он тоже поможет. Еще раз спасибо за такой полный курс с примерами и шаблонами!
Это фундаментально не будет работать. На каждом шаге разработки ты принимаешь десятки микрорешений, которые не описаны ни в какой спеке. Это не формализуемо. Ты принимаешь эти решения на основе опыта, знания кодовой базы, понимания бизнеса и интуиции.
Эти мультиагентные пайплайны это waterfall, переизобретённый на промптах. Сначала полная спека, потом полный план, потом полная реализация. Индустрия уже 20 лет назад поняла, что это плохо работает для людей. А тут предлагают то же самое для AI, у которого ещё и с пониманием контекста проблемы. Ещё и общаться эта куча агентов будет через текстовые саммери проделанной работы, то есть величина любой ошибки с каждым этапом/агентом будет экспоненциально расти.
Единственное, где AI реально полезен это когда человек рядом и рулит процессом. А это какой то новый уровень прокрастинации. Эти мультиагентные пайплайны решают несуществующую проблему.
Сильно, что вы упёрлись в спецификации — это реально лечит “агентный хаос”. Из практики: лучше всего работает раздельный контур spec → patch → checks: спецификация как “истина”, патч как предложение, проверки как доказательство. Даже простое правило “одна гипотеза — один PR/изменение” + автоматический smoke (линтер/юнит/миграции) резко снижает дрейф. Ещё помогает лимит на “массовые правки” без явного разрешения (например, ≤N файлов за проход), иначе агент чинит одно и ломает пять. Какой у вас минимальный acceptance-gate перед тем, как вы доверяете агенту применять изменения?
Я не понимаю как вы решаете орудовать агентами. Их отпускать в свободную разработку даже с планом невозможно. Максимум ещё час или два обсудить могу в чате с опусом, чтобы оно план составило в корне в файле, а потом по шагам прошу выполнять каждый шаг останавливая и контролируя следующие часа 4-6 и план корректируя. И это крупная задача. Раз в пару недель может. Остальное время просто дал контекст, какие-то пара файлов с правилами по проекту и технической части лежат и все. Все в одном чате. Контекст забивается ну пару раз в неделю.
Как можно их просить сделать что-то крупнее, чем пофиксить баг, который все равно перефикшивать (допоправить) раза 2-3 анализируя их код. Не понимаю всех вас. Свой проект вечерами иногда делаю недолго если что уже давно.
Я так же не доверяю агентам выполнить всё и сразу, они почти как прокачанный джун - такого могут натворить. За ними надо следить и направлять в нужную сторону.
Я каждую команду запускаю самостоятельно. Агенты работают на втором мониторе и я постоянно вижу, что они делают. В это время могу ревьюить описание следующей задачи.
Если что-то идет не так, торможу и принимаю решение: удалить и начать заново или самому закончить.
Мультиагентная разработка: от хотелок до продакшена