У меня уже есть инструкции для AI. Есть порядок работы: исследовать, составить план, реализовать, проверить. Есть второй агент, которому можно отдать результат на ревью. На бумаге всё выглядит вполне прилично.
Теперь мысленно закроем чат.
Где лежит согласованный объём задачи? Как понять, что действительно проверено? Почему мы оставили этот странный кусок кода? Следующий агент должен продолжить работу или сначала попросить меня пересказать предыдущий разговор?
Вот об эту часть организации разработки я сейчас и думаю. В августовской заметке я описал, как дошёл от отдельных запросов до команды AI-разработчиков. Следующий вопрос оказался довольно приземлённым: где эта команда хранит дела.
Процесс описан. А конкретная задача где?
Когда я писал, что всё меньше составляю промпты и всё больше строю workflow, меня занимали повторяемые действия. Незачем каждый раз объяснять порядок исследования или вспоминать команду тестов. Это можно вынести в правила, skills и команды.
Но инструкция «перед реализацией составь план» ничего не говорит о том, какой план мы приняли вчера. А правило «проверь результат» не хранит результат проверки.
И тут у меня появляется весьма знакомая должность: человек, который помнит всё за всех. Только вместо коллег — несколько агентов. Одному перескажи постановку, второму объясни ограничения, третьему принеси замечания с ревью. Потом сам вспомни, на чём остановились.
Для этой работы я собрал внутренний плагин devflow. Выкладывать его я не собираюсь: делаю под собственный способ разработки и свои проекты. Поэтому здесь не будет инструкции по установке. Мне интереснее рассказать, какие вещи я решил в нём зафиксировать.
У задачи появился адрес
Основа получилась скучной: один Markdown-файл на задачу. Постановка, объём, критерии, план, проверка, результат. Рядом — индекс со статусами.
Скучной в хорошем смысле. Файл можно открыть без плагина, прочитать в редакторе, сравнить изменения через git. Если завтра я передам работу другому агенту, у неё останется тот же адрес.
В devflow источником статуса считается файл задачи. Индекс отражает его состояние, а отдельная команда находит расхождения. Мне нравится, что здесь есть однозначный ответ на вопрос «чему верить», когда в двух местах написано разное.
Для примера возьмём экспорт заказов. Фраза в чате «добавь выгрузку» быстро обрастает подробностями: какие поля нужны, чьи заказы видит пользователь, что делать с большим объёмом, нужен ли фоновой процесс. Если эти решения остались только в переписке, при следующем запуске часть задачи придётся придумать заново. В файле они становятся условиями, с которыми можно сверить реализацию.
Конечно, агенту всё равно нужно прочитать код. Постановка не заменяет исследование. Зато я могу показать, что именно мы собирались получить.
«Код написан» и «я принял работу» получили разные последствия
Внутри плагина этапы разнесены: создание постановки, подготовка плана, выполнение, закрытие. После реализации агент заполняет результат и перечисляет проверки. Финальное закрытие оставлено человеку.
Это видно даже в механике: команда смены статуса требует явного флага подтверждения для перехода в done, а перед закрытием проверяет, заполнены ли разделы результата и проверки. Пустой шаблон за отчёт не считается.
Тут легко обрадоваться раньше времени. Программа может проверить наличие текста. Она не знает, правильно ли я принял продуктовую работу, и сам флаг не доказывает, что человек действительно посмотрел результат. Это соглашение процесса с техническими проверками вокруг него. Ответственность оно с меня не снимает.
Зато фразе «готово» приходится соответствовать чему-то более определённому. Я открываю задачу и вижу, что поменялось, какие команды запускались, что осталось проверить руками. У меня есть материал для приёмки.
Мне нужен повод спросить про лишний файл
В том же экспорте можно незаметно увлечься. Поправить соседний сервис. Заодно выровнять конфигурацию. Раз уж открыли старый модуль — немного его почистить. Каждая правка по отдельности выглядит разумно, а общий diff уже трудно соотнести с исходной просьбой.
Поэтому в devflow есть сверка изменённых путей с разделом «Объём». Если файл туда не попал, это нужно объяснить. Иногда план действительно неполон: понадобился ещё один тест или общая настройка. Тогда объём обновляется с обоснованием. Иногда агент просто ушёл в соседнюю задачу.
Проверка путей довольно грубая. В разрешённом файле тоже можно сделать лишнее. Но она даёт конкретный повод остановиться: почему ради экспорта мы меняем вот это?
Это хорошо дополняет ревью другим агентом. У проверяющего появляется исходная договорённость, по которой можно оценить diff. Одного вопроса «хорошо ли написан код» мне уже мало.
У каждого проекта остаётся своё окружение
Ещё одна причина собрать всё в инструмент — мои PHP-проекты отличаются друг от друга. Разные фреймворки и версии, разные команды проверки, где-то выполнение внутри Docker. Общая инструкция быстро начинает обрастать оговорками.
В devflow я разделил общий порядок работы и сведения о конкретном проекте. Инициализация собирает информацию о стеке, способе запуска команд и формате задач. Адаптеры дают правила под обнаруженную версию. Профиль процесса описывает, где искать постановки и какие статусы использовать.
Это продолжение мысли о том, что контекст оказался важнее модели, только теперь часть контекста можно получать программно. Версию PHP незачем угадывать по стилю кода, если она указана в конфигурации проекта.
Автоопределению я при этом не приписываю всеведение. Нестандартный compose-файл может потребовать явной настройки. Чужую систему задач с досками и эпиками мой файловый процесс тоже внезапно не освоит. Мне достаточно, чтобы привычные проекты перестали требовать одинаковых ручных объяснений.
«Запомни это» стало записью, которую можно пересмотреть
Самая интересная для меня часть — память проекта. В отдельные короткие файлы попадают ловушки, соглашения и причины решений. У записи есть связанные пути, источники и отметка, когда её проверяли.
Допустим, при работе с экспортом выяснилось, что синхронная обработка большого набора данных упирается в таймаут. Полезная запись объяснит, почему экспорт идёт через очередь, укажет соответствующий код и способ проверки. Совет «будь осторожен с большими экспортами» следующему исполнителю почти ничего не даст.
Такие записи лежат в репозитории и могут проходить обычное ревью. Агент получает относящиеся к его файлам сведения, а не весь архив наших разговоров. Я уже писал инструкции для AI; теперь хочется сохранять ещё и причины, по которым эти инструкции появились.
Есть и обратная сторона: старое решение способно превратиться в убедительную дезинформацию. Поэтому devflow умеет отмечать записи, под которыми изменился код, исчез источник или давно не было проверки. Он не устанавливает, что мысль стала неверной. Он показывает место, куда пора вернуться.
Мне гораздо спокойнее видеть такую отметку, чем бесконечно накапливать «память», которую никто больше не перечитывает.
Ещё один проект, который придётся поддерживать
Конечно, я вполне способен увлечься и этим. Добавить ещё статус, ещё отчёт, ещё обязательный раздел. В какой-то момент на исправление опечатки понадобится постановка с архитектурным обоснованием. Очень организованно. Работать только некогда.
Поэтому я стараюсь держаться простого критерия: запись должна помогать следующему действию. Объём нужен для проверки diff. Результат — для приёмки. Память — чтобы не расследовать ту же ловушку снова. Если документ никто не использует, его автоматическая генерация не делает процесс лучше.
Пока я не готов рассказывать, сколько часов всё это экономит. Наличие плагина ещё не доказывает, что разработка стала быстрее. Он сам требует внимания, а аккуратно заполненная задача вполне может содержать неверное решение.
Зато у меня появился понятный способ проверить, туда ли я двигаюсь. Закончить работу сегодня. Завтра открыть задачу в другом разговоре. И посмотреть, сколько мне придётся объяснить заново.
Хочется однажды начать такое утро сразу с дела.
