Брал отпуск на неделю. Подходит к концу. Рассказываю про эксперимент с Фёдором: как он устроен, что получилось, что пока нет, и каковы шансы на продолжение истории.
1. Для старта я начал сессию с Codex на компьютере, в codex cli. Мы быстро обсудили архитектуру будущего решения (ничего мы не обсудили), вместе узнали о возможности использовать локальный codex через специальный codex app-server — сервис, разворачиваемый локально, к которому можно обращаться по какому-то заготовленному API, а не через CLI. Удобно.
Мы также сразу решили, что интерфейсом взаимодействия должен стать Telegram, чтобы я мог пользоваться этой штукой с телефона. Ну и накатали это всё.
Примерно в первый же день я смог обращаться к одному codex-агенту из Телеграма. Заперли его в WSL под отдельным пользователем.
2. Сформулировали базовые роли и принципы:
- я хочу, чтобы 100% работы я мог выполнять с телефона посредством Телеграма;
- хочу, чтобы работа была максимально автономной, а на меня эскалировались только отдельные виды нерешаемой неопределённости;
- хочу иметь широкую наблюдаемость — не чтобы следить за процессом и курировать его 24/7, но чтобы иметь возможность проверить, что всё идёт нормально: такая наблюдаемость включает в себя разные группы метрик, дашборды, интеграции с GitLab и Телеграмом, а также ведение задач.
3. Коль скоро мы не заложили эту логику заранее, ближайшей целью стало добавление возможности для агента перезапускать самого себя — чтобы изменения в коде сразу применялись и были доступны мне в Телеграме и GitLab.
Разделили сервис на две части: тонкую и неизменяемую, и толстую, высокоэнтропийную. Заодно предусмотрели автоматический откат неудачных обновлений — чтобы система была устойчива к падениям.
4. Это позволило мне управлять всем этим вообще не подходя к ноутбуку. Но спустя день, утром, бот упал — ушёл в спящий режим, пришлось перезапускать.
Добавили проверку доступности и настроили фоновую работу WSL.
5. Стало понятно, что я не хочу по 30 минут ждать ответа. Добавили делегацию. Теперь я стал общаться с единственным менеджером (мы обозвали его Improver), а все задачи он делегировал Implementator’ам.
Параллелизацию устроили через новую для меня технологию git-worktrees — это когда ветки существуют не просто в закрытой папке .git, а в контролируемых извне.
Таким образом основная локальная директория всегда оставалась на master, и при этом агенты могли работать полностью локально, на разных ветках — это оказалось очень удобно.
Итог: мы могли общаться в чате почти непрерывно, и я мог задавать новые issues, пока по другим шёл рабочий процесс.
Спойлер — он пережил отпуск и после него тоже не умер.
6. Итак, у нас был менеджер-завхоз (Improver) и был исполнитель (Implementator). Они неплохо друг с другом ладили: множество имплементёров делали свою работу, я получал от них непонятные мне отчёты о завершении, писал Фёдору «они закончили» — он делал ревью, мёржил, отписывался мне.
Но потом стали появляться баги. И я решил, что нам нужен ревьер — тот, кто посмотрит на результат и проверит, что всё сделано ок. Мы его добавили. После этого мы добавили мёржера.
7. Потом я просил завхоза объяснить, почему случился баг. А он начал задвигать мне гипотезы, абсолютно не заземлённые на проект и реальность.
Стало понятно, что чтобы ответить на мой вопрос, нужна роль разведчика (Scout) — который возьмёт проблему и с чистым контекстом, без вводных (и уводящих в сторону) предположений, пойдёт, найдёт реальную причину и просто выставит нам факты. Это сработало.
Разведчик оказался идеальным помощником в огромном спектре задач, далеко за пределами багов.
Так же сработала роль архитектора — для похожей задачи, но не чтобы исправить баг, а чтобы понять, куда лучше воткнуть то или иное новое свойство системы.
Со временем мы также ввели роль контекстного архитектора — который должен был следить за непротиворечивостью документации и адекватностью должностных инструкций.
8. Количество ролей разрослось довольно быстро. Мне надоело выполнять механическую работу вида: «этот твой подопечный закончил — толкай работу дальше».
Поэтому мы завели систему событий и триггеров и стали строить событийные сценарии:
- если имплементёр закончил — запустите тестера;
- если тестер перенёс задачу в validated — вызывайте мёржера;
- если в in_progress — отправьте разработчика править свои косяки;
- если пачка делегаций завершилась — зовите менеджера думать следующие шаги.
9. Мы также завели ночные джобы, которыми любят хвастаться OpenAI и прочие вайбкодеры.
Каждую ночь у меня вызывается анализатор рабочей среды — он читает диалоги с Codex за день, ищет места, где я больше всего матерился, и актуализирует базу знаний, чтобы я в этих местах больше не матерился.
Я не знаю, насколько удачно работает эта практика, потому что она кладёт свои отчёты в отдельные ветки, и никто их не мёржит.
Мы также запускали ежечасового тестера, который проверял наличие правок в репе, проводил ad-hoc тестирование и улучшал автотесты (а до этого архитектор автотестера создал систему smoke-тестов и тегирования).
Удалось не всё, но что-то удалось.
10. Наконец, мы завели автоимпрувера — того же менеджера, только запускается он автоматически раз в полчаса и пытается разгребать бэклог полностью автономно.
Пока не завелось. Он всё может, но ему не хватает какого-то стремления к жизни, мотивации самоулучшаться, инициативности.
Думаю, с Клодом или Дипсиком такой проблемы бы не возникло, но GPT показался мне очень унылым.
Впрочем, когда я накричал на него за это, дело пошло получше.
Продолжение следует (возможно).