Суперечка про те, чи має взагалі існувати повністю автоматизована ШІ-розробка програмного забезпечення, нарешті вибухнула. Приводом стало те, що
@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 комітів на акаунт yetone припадає 85%, а також злито 383 PR від спільноти.
Кількість тегів (що еквівалентно версіям) досягла 1204 за 19 днів — у середньому понад 60 версій на день. Таку частоту людина фізично не здатна підтримувати вручну. Для порівняння: OpenClaw мав 1423 коміти за свої перші 19 днів, 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 як докази. Наприклад:
Відтворюй точний кейс автора звіту, на тому інтерфейсі, яким він користується, перш ніж називати проблему вирішеною.
834 повертався 4 рази (v0.1.920 → .925 → .931 → .938). Кожного разу виправляли лише того агента, якого було видно на скріншоті. Помічено 1× (2026-10-05).
Issue 834 переробляли чотири рази, і щоразу виправляли лише того агента, що був на скріншоті. Тому правило таке: перш ніж казати, що все працює, відтвори проблему точно так, як її бачить автор звіту.
Головне — останній рядок: Seen 1×. Якщо один і той самий урок з'являється під час ревʼю в три різні дні, він переходить із LESSONS.md до code-standards.md, стаючи жорстким правилом, викарбуваним із досвіду. Після цього кожне наступне ревʼю PR має перевірятися за цими правилами пункт за пунктом.
Вісім правил уже отримали такий статус. Серед них: виправляти схожі баги разом (по одному випадку 5, 6 та 7 жовтня); якщо тести падають у main — це негайний баг, який треба фіксити; а також чітко вказувати, що саме тестувалося і на якому коміті, перед злиттям.
Звісно, зошит помилок фіксує й те, що зроблено правильно, з позначкою Done right. Тож агенти читають не лише «не роби так», а й «роби ось так».
Зошит помилок з'явився рано-вранці 6 жовтня
Чи була ця система задумана від самого початку? Якщо глянути історію комітів LESSONS.md, перша версія — це коміт 303819c5, створений о 3:10 ранку 6 жовтня.
За день до того, 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 іноді немає даних для тесту. Можеш допомогти створити трохи фейкових даних?)
Здебільшого це короткі скарги в один рядок; решту дописує агент, часто розширюючи тіло коміту до сотень слів. Запит на фейкові дані згодом перетворився на набір мок-даних, який використовується для записів CI.
Люди вказують, що не так; агенти перетворюють це на перевірювані зміни. Ці кілька десятків назв комітів пояснюють методологію краще за будь-яку документацію.
Якщо хочеш побудувати власне
Написати таблицю маршрутизації може кожен. Справжня цінність, яку варто скопіювати, — це система зошита помилок. Запис у LESSONS виглядає так:
1**<Правило в одне речення>**2- <Який коміт/issue спричинив проблему, які були наслідки>3- <Коміт із виправленням>4- Done right: <Приклад правильного виконання>5- Seen N× (РРРР-ММ-ДД, РРРР-ММ-ДД).
Нехай агент щовечора переглядає денні коміти, шукаючи лише переробки, невдалі злиття та слабкі перевірки. Якщо одна й та сама проблема з'являється в три різні дні — перенось її у стандарти коду. Під час приймання перелічуй регресійні тести, реальне використання та непроведені перевірки в тілах комітів і коментарях до PR.
Переглянувши весь репозиторій, найбільше мене вразив поріг Seen 3×. Помилки записуються, агенти читають їх під час запуску, а повторення тієї самої помилки тричі підвищує її до жорсткого правила — ідеальна ілюстрація приказки «третій раз — вирішальний» (або радше «три страйки — ти вибув»).
Насамкінець...
Рік тому, чи навіть пів року тому, можливості моделей рідко дотягували до автоматизації продакшн-рівня. Але зараз, особливо після появи Opus 5.5, ми бачимо: майбутнє вже настало.
Це нагадує мені Yoyo від @yuanhao — агента, який самостійно ітерується вже понад 200 днів: https://yoyo-gasp.yolog.dev/, теж вартий уваги.
