Споры о том, должно ли вообще существовать полностью автоматизированное ИИ-создание ПО, наконец-то вылились в открытый конфликт. Поводом стало то, что
@yetone поддерживает magpie, а коллеги раскритиковали проект как «фастфуд» и «слишком рискованный для использования».
Большинство согласно: разработка софта с помощью ИИ — это тренд. Но как именно magpie воплощает его на практике? Я склонировал magpie, проанализировал 2862 коммита за последние десять дней и сравнил результаты с OpenClaw.
https://x.com/wquguru/status/2109458639501271530
1204 версии за 19 дней
magpie — это локальный шлюз для LLM, который подключает кодинг-агентов вроде Claude Code, Codex и Gemini CLI к любой модели или подписке. С момента первого коммита 22 сентября и до сегодняшнего дня он собрал 9474 звезды всего за 19 дней. Из 2862 коммитов 85% приходятся на аккаунт yetone, который смержил 383 PR от сообщества.
Количество тегов (то есть версий) за 19 дней достигло 1204 — в среднем более 60 релизов в день. Такую частоту человек физически не способен поддерживать вручную. Для сравнения: у OpenClaw за первые 19 дней было 1423 коммита, 99% из которых сделал сам Peter Steinberger, и около 10 тегов.
У magpie в два раза больше коммитов, но версий — более чем в сто раз больше.
Меня интересовало одно: как именно ИИ замыкает цикл разработки в этом проекте?
Таблица маршрутизации и тетрадь ошибок
В CLAUDE.md проекта magpie упоминаются только два файла: AGENTS.md и LESSONS.md.
AGENTS.md — это таблица маршрутизации. Она не содержит правил сама по себе, а лишь указывает агентам, какие документы нужно изучить перед началом работы: проверять docs/subsystems/ перед изменением подсистем, следовать docs/code-standards.md при написании и ревью кода, а также заглядывать в docs/contributors.md при проверке PR от сообщества.
Первое же предложение в LESSONS.md отвечает на наш главный вопрос:
Код magpie пишется, проверяется, мержится и выпускается агентами. (код magpie пишется, проверяется, мержится и выпускается агентами)
Написание, ревью, мерж, релиз — всё делают агенты. Почему без человеческого контроля всё не падает? Ответ кроется в этом файле. Его 479 строк — по сути, тетрадь ошибок, которую агент заполняет каждую ночь.
Каждую ночь агент просматривает все коммиты за день, обращая внимание на три вещи:
- Какие исправления пришлось переделывать?
- Что вообще не следовало мержить?
- Где проверка оказалась слишком халтурной?
Для каждой найденной проблемы он записывает правило, причину и прикладывает номера коммитов и issue в качестве доказательств. Например:
Прежде чем считать баг исправленным, воспроизведи точный кейс автора на том интерфейсе, которым он пользуется.
Issue 834 возвращался 4 раза (v0.1.920 → .925 → .931 → .938). В каждом раунде чинили только того агента, что был на скриншоте. Замечено 1× (2026-10-05).
Issue 834 переделывали четыре раза, и каждый раз чинили только того агента, которого показали на скриншоте. Отсюда правило: прежде чем закрыть задачу, нужно воспроизвести проблему точно так, как её видит автор.
Главное здесь — последняя строка: «Замечено 1×». Если один и тот же урок всплывает при ревью в три разных дня, он переезжает из LESSONS.md в code-standards.md, превращаясь из опыта в железное правило. После этого каждое новое ревью PR обязано сверяться с этими правилами пункт за пунктом.
Таким образом уже повысили восемь правил. Например: похожие баги чинить вместе (замечено по разу 5, 6 и 7 октября); упавшие тесты в main — это критичные баги, требующие немедленного исправления; перед мержем нужно четко указать, что именно протестировано и на каком коммите.
Разумеется, в тетради фиксируются и успехи — они помечаются как Done right. Так агенты читают не только «не делай так», но и «делай вот так».
Тетрадь ошибок появилась ранним утром 6 октября
Была ли эта система заложена изначально? Если посмотреть историю коммитов LESSONS.md, первая версия (коммит 303819c5) была создана 6 октября в 3:10 ночи.
За день до этого, 5 октября, magpie выпустил 168 версий.
Первая версия LESSONS.md зафиксировала именно тот день. При 220 коммитах и примерно 170 релизах около 40 были исправлениями версий, выпущенных в тот же или предыдущий день. CI почти всегда отменялся следующим пушем. Тест, падавший только на Linux, оставался красным с v0.1.877 по v0.1.892, и никто этого не заметил.
294 тега за 51 час не дали завершиться ни одному прогону. (294 тега за 51 час означали, что ни один прогон CI не мог завершиться)
Поэтому в первой версии появилось правило: перед созданием тега CI для этого коммита должен отработать до конца и стать зеленым. Прогоны, отмененные из-за новых пушей, не считаются.
168 релизов в первый день, 42 во второй, 15 в третий, а затем стабилизация на уровне 15–26.
Никаких созвонов, никаких уведомлений. Ночные ревью находили проблемы, добавляли правило в тетрадь ошибок, работающие агенты его читали — и частота релизов снижалась.
Так что те двадцать с лишним релизов в день, которые недавно называли проблемой, — это скорость уже после того, как ударили по тормозам.
Критерии приемки PR
Теперь посмотрим на реальные PR:
В code-standards.md перечислены шесть критериев приемки. Все они должны быть соблюдены до мержа или релиза. Если опустить стандартные проверки вроде компиляции на трех платформах и тестирования в песочнице, три из них крайне редко встречаются в обычных проектах:
- Регрессионный тест: верните старый код — новые тесты должны явно упасть, указывая, какое именно поведение работает неправильно. Ошибки компиляции или пропущенные тесты не в счет.
- Реальное использование: если меняется интеграция с вендором, проверяйте её на реальных аккаунтах, конфигурациях и ответах API. То, что не протестировано, нельзя использовать как базу для других фич или заявлять пользователям о работоспособности.
- Непроведенные проверки нужно перечислять:
Проверка, которая не запускалась, указывается как незапущенная, а никогда не просто опускается. (Невыполненные проверки должны быть указаны как невыполненные, их нельзя просто пропускать)
Я случайно выбрал #1339, чтобы посмотреть комментарий, оставленный перед мержем:
Red check означает регрессионный тест, Break check — намеренную поломку кода, чтобы проверить, поймают ли её тесты, а последняя строка Not run значит, что проверка на реальном железе не проводилась.
Команда мержа включает --match-head-commit <reviewed sha>. Если кто-то сделает пуш во время ревью, мерж не пройдет — непроверенный код не попадет в ветку.
Человек в цикле
Конечно, люди всё равно участвуют в работе, как минимум в следующих аспектах:
- Продуктовые решения: «Не отменяйте осознанные решения». Такие вещи, как поведение скролла или курсоры на кнопках, нельзя менять через PR.
- Контроль безопасности: если срабатывают проверки на риски, нужно ждать одобрения мейнтейнера.
- Предложения сообщества: в названиях 474 коммитов упоминаются авторы репортов из X или Discord, например JonahFu из X или Jeremy.Zhou из Discord.
Короче говоря, люди задают направление и стоят на страже; написание, ревью, мерж и релизы выполняют агенты.
Что-то скрывает yetone?
На этом месте кто-нибудь спросит: а не скрывает ли yetone чего-то? Мне тоже стало любопытно, и я копнул глубже.
Действительно, некоторых вещей в репозитории нет:
- Как запускаются ночные ревью — не задокументировано. Ни один из 4 workflow не настроен по расписанию.
- Я вытащил время 7 обновлений LESSONS.md: 03:10, 03:49, 00:23, 23:46, 03:48, 14:24, 05:26. Оно разбросано, что меньше похоже на cron-задачи и больше — на ручной запуск локально или кастомные скрипты.
- Промптов для ночных ревью там тоже нет. Какой агент используется, сколько параллельных сессий — ничего не указано.
Попутно я обнаружил еще два интересных момента:
Во-первых, методология опирается на вклад сообщества. Документация подсистем и ревью семантических изменений появились благодаря PR #889 от участника сообщества Junjie Zhou. Две таблицы в начале code-standards.md, согласно коммиту 926bcaa3, прямо основаны на шести правилах ревью, предложенных Junjie Zhou в Discord.
Во-вторых, диалоги yetone с агентами сохраняются в коммитах. В 52 названиях коммитов в скобках оставлены оригинальные цитаты yetone:
1(владелец: Это выглядит слишком уродливо)2(владелец: Почему здесь нативный селектор вместо нашего абстрактного ComboBox?)3(владелец: Почему это снова вернулось? Мы же договорились, что оно должно появляться только при наведении? Постоянно торчать — это ужасно)4(владелец: Во время pr-preview иногда нет данных для теста. Можешь сгенерировать фейковые?)
В основном это жалобы в одну строку; остальное дописывает агент, из-за чего тело коммита часто разрастается до сотен слов. Просьба о фейковых данных позже превратилась в набор mock-данных, используемый для записей CI.
Люди указывают, что не так; агенты превращают это в проверяемые изменения. Эти несколько десятков названий коммитов объясняют методологию лучше любого документа.
Если захотите повторить
Написать таблицу маршрутизации может каждый. По-настоящему ценно скопировать систему тетради ошибок. Запись в LESSONS выглядит так:
1**<Правило в одно предложение>**2- <Какой коммит/issue вызвал проблему, каковы были последствия>3- <Коммит с исправлением>4- Done right: <Пример правильного выполнения>5- Seen N× (ГГГГ-ММ-ДД, ГГГГ-ММ-ДД).
Пусть агент каждую ночь проверяет дневные коммиты, выискивая только переделки, плохие мержи и слабые проверки. Если одна и та же проблема появляется в три разных дня — переносите её в стандарты кода. При приемке перечисляйте регрессионные тесты, реальное использование и непроведенные проверки в телах коммитов и комментариях к PR.
Изучив весь репозиторий, больше всего меня впечатлил порог «Seen 3×». Ошибки записываются, агенты читают их при старте, а троекратное повторение одного и того же промаха возводит его в статус жесткого правила. Идеальная иллюстрация принципа «третий раз — решающий» (или, скорее, три страйка — и ты出局).
И напоследок...
Еще год или даже полгода назад возможностей моделей редко хватало для автоматизации уровня production. Но сейчас, особенно после выхода Opus 5.5, мы видим: будущее уже наступило.
Это напоминает мне Yoyo от @yuanhao — агента, который самостоятельно итерируется уже более 200 дней: https://yoyo-gasp.yolog.dev/, тоже стоит взглянуть.
