TL;DR Muse замінює саморобні консолі оркестрації агентів чотирма інструментами, які вже відкриті в будь-якій софтверній команді: Slack, Linear, GitHub і Claude Code. Жодної панелі керування, жодного SPA, жодного рядка коду, написаного людиною. Кожен PR проходить сім бар'єрів CI та панель ШІ-рецензування із трьох персон за політикою злиття з нульовою кількістю зауважень. Зібрано 40 000 голосів, оцінювання базових моделей пришвидшилося на 80%.
Muse, скорочення від Meshy Universal System for Evaluation, — це наша внутрішня платформа оцінювання моделей. Команди в Meshy щодня користуються нею, щоб з'ясувати, чи нові чекпойнти моделей працюють краще за попередні.
Одного дня щойно завершилося "дозрівання" нового перспективного чекпойнта моделі. Йому потрібен був матч на арені, щоб визначити наступну стратегію тренування. Команда зрозуміла, що для цього потрібна нова функція Muse.
"@Linear, створи задачу в Muse щодо цього"
сказав продакт-менеджер у Slack.
Через хвилину в Linear з'явилася задача MES-12345.
Власник платформи Muse — тобто я — побачив цю задачу. Її треба було випустити якнайшвидше, щоб розблокувати задачу з оцінювання. Тоді Claude надійшло повідомлення:
"Розберися і виправ MES-12345"
Claude проглянув задачу, а тоді підняв два дизайн-рішення на обговорення. Рішення були ухвалені, і я відійшов від терміналу, щоб зайнятися іншими справами.
Через півтори години нова версія Muse була розгорнута в продакшн. Готово.
Автономна розробка ПЗ не мусить означати вишукані консолі оркестрації агентів чи дашборди. І в цій статті я поясню, як ми це реалізували.
Галерея, переглядач і кнопка голосування
Питання, на яке відповідає Muse, оманливо складне: чи справді новий чекпойнт моделі кращий? Звісно, для кожного циклу тренування є кількісні метрики, які можна відстежувати, але вони й близько не відображають точно, як виглядає "добре" у 3D-генерації. Тож Muse робить просту, але дієву річ: подвійне сліпе тестування. Він ставить результати двох моделей поруч, з тим самим вхідним зображенням, у випадковому порядку зліва направо, і дає колегам проголосувати наосліп.
Оцінювання — це пакет таких пар. Хтось вказує Muse на два набори згенерованих мешів і папку референсних зображень, а далі застосунок бере все на себе: пов'язує моделі в пари, приховує, яка модель де, і показує по одному порівнянню за раз. Голоси накопичуються щоразу, коли в людей є вільна хвилина. Весь інтерфейс побудований так, щоб ним можна було користуватися "на бігу", і майже повністю керується гарячими клавішами. Той, кому доводиться тягнутися до миші, голосує рідше.
Інтерфейс голосування Muse: два згенеровані меші, те саме вхідне зображення, випадковий порядок зліва направо.
Ось і весь продукт. Галерея, переглядач і кнопка голосування. У функціоналі Muse немає нічого складного, і саме тому це такий чистий приклад для розбору. Незвичним є лише те, як його будують.
Архітектура, у якій орієнтуються агенти
Проєкт Muse стартував наприкінці 2025 року, коли "вайб-кодинг" (vibe coding) щойно перетворився на новий модний термін. Окрім обслуговування зростаючих потреб Meshy в оцінюванні під час циклів тренування та релізів, Muse мав і амбітну мету: побудувати софт для всієї компанії, не написавши власноруч жодного рядка коду.
Сьогодні результати вражають:
- Зібрано понад 40 000 голосів із моменту першого запуску Muse, і понад 30 проєктів з оцінювання щомісяця
- Понад 4 команди активно використовують Muse у щоденній роботі
- Перша внутрішня кодова база, у розробку якої активно долучається щонайменше 1 нетехнічний член команди
- Перша внутрішня кодова база, що досягла повністю автономної розробки
Загалом, за нашими оцінками, Muse пришвидшив оцінювання наших базових моделей щонайменше на 80% і скоротив щонайменше 10 людино-днів роботи під час кожного релізу моделі. Без Muse підтримувати нинішній темп розробки та релізів колекції генеративних моделей Meshy — таких як геометрія, текстура та smart topology — було б майже неможливо.
З першого дня Muse проєктували так, щоб він був максимально "читабельним" для агентів. Ще у 2025 році ми помітили, що для реалізації одного й того ж кейсу агенти в одних аспектах мучилися, а в інших — справлялися з одного заходу. Численні такі ітерації врешті вилилися в навмисно нудний технологічний стек, який ми маємо сьогодні. Бекенд написаний на Python: FastAPI, Postgres для записів, S3 для мешів і зображень. Фронтенд рендериться на сервері: шаблони Jinja2, HTMX для часткового оновлення сторінок, Tailwind для стилізації, і лише один справжній клієнтський компонент — WebGL-переглядач 3D, що рендерить меші. Немає ні SPA, ні окремого фронтенд-модуля. Зв'язок між двома стеками — найстаріший в вебі: бекенд рендерить HTML, браузер його показує. Коли сторінці потрібно змінитися, HTMX запитує фрагмент, і сервер рендерить і його теж.
Ось архітектура основного застосунку оцінювання в Muse:
Шарова архітектура основного застосунку оцінювання Muse. Залежності спрямовані лише вниз.
Для агентів важливі дві властивості цієї форми. По-перше, стан фронтенду живе на сервері. HTML, який бачить користувач, — це HTML, згенерований бекендом, тож тест (чи агент) може перевіряти його напряму, не змушуючи клієнтський фреймворк відтворювати те, що побачив користувач. По-друге, кожна залежність примусово перевіряється машиною і спрямована лише вниз. Папка фічі не може імпортувати сусідню; якщо дві фічі потребують одна одну, composition root впроваджує одну можливість в іншу, тож залежність видно рівно в одному файлі. Кожен шар має одне завдання, і ці завдання записані саме там, де агент на них натрапить:
| Шар | Роль | Чому агент може безпечно тут працювати |
|---|---|---|
main/ | Тільки монтаж (wiring). Реєструє URL-маршрути кожного фіче-модуля. | Нова фіча — це одна папка плюс один рядок include. Мало простору для галюцинацій. |
apps/<feature>/ | Одна папка на фічу: маршрути, сторінки, сервіс, стор, тести. | Радіус ураження від правки обмежений папкою. Сусідні імпорти — це збій білда, а не зауваження в рев'ю. |
adapters/ | Зовнішній світ: рендеринг вебу, база даних, об'єктне сховище. | Увесь I/O проходить через один шов на систему. Для кожного шва є фейк. |
libs/ | Спільні встановлювані бібліотеки. | Версіонуються, як сторонній код. Зміна будь-якої з них — навмисно "гучна" подія. |
Залежності завжди спрямовані вниз за цим списком, і цей напрямок примусово перевіряється білд-чеком, а не є просто домовленістю.
Ще три властивості навмисно роблять кодову базу "читабельною" для агентів:
- Кожна директорія має власну документацію (що робить сервіс, які в нього правила шарування, точні команди, що блокують злиття), тож агент, який заходить "з холодного старту", може зорієнтуватися, не питаючи і не вигадуючи щось на власний розсуд.
- Нетривіальні модулі мають докстрінги зі зворотними посиланнями на дизайн-документи, тож чому зберігається поруч із що.
- Жоден файл не може перевищувати 500 рядків, із храповим механізмом для кількох винятків. У винятках файли можуть лише зменшуватися, але ніколи не рости знову. Контекстні вікна скінченні — архітектура це враховує.
Прогрес не повинен жити в маленькій кімнаті
Сьогодні, коли LLM-агенти набагато потужніші, ніж у 2025 році, ми хочемо, щоб розробка Muse була повністю автономною. Тобто людина лише вказує агенту на задачу. Агент сам орієнтується в кодовій базі та контексті задачі, проходить шлях реалізації, CI та рев'ю коду, і зрештою самостійно доводить pull request до злиття. Людина лише визначає пріоритетність задач і ухвалює ключові дизайн-рішення.
Перша думка про повністю автономну розробку зазвичай — це індивідуальні платформи: консолі оркестрації, робочі простори "нативні для агентів", застосунок за застосунком, що обіцяють керувати вашим "флотом". Ми подивилися і відмовилися. Не тому, що це погані продукти, а знову ж через читабельність.
Ми хочемо, щоб робота агентів була читабельною для людей, так само як кодова база має бути читабельною для агентів. Ми доволі велика компанія. Помісти автономну розробку в кастомну консоль — і її прогрес стає видимим лише тим кільком людям, які живуть у цій консолі.
Тому, знову ж таки, стек інструментів для співпраці й розробки навмисно нудний. Усе в цій історії працювало на чотирьох інструментах, які вже відкриті в будь-якій софтверній компанії: Slack, Linear, GitHub і Claude Code. Це робить прогрес, якого досягає агент, так само спостережуваним і доступним для пошуку, як і прогрес будь-якого члена команди. Продакт-менеджер відкриває задачі в Linear і перевіряє статус фічі так само, як завжди. GitHub bug bot чи security review читають треди PR так само, як завжди. Будь-хто, хто повідомляє про баг, вставляє скріншот у той самий канал Slack, що й завжди, і виправлення з'являється як звичайний pull request. Нікому не потрібно нічого вчити, щоб наглядати за "машиною".
Ось форма однієї автономної задачі, від початку до кінця:
Одна автономна задача, від початку до кінця. Людина торкається циклу рівно у двох місцях.
Людина торкається цього циклу рівно у двох місцях: вказує агенту на задачу в Linear і ухвалює ту жменьку рішень, яку агент піднімає перед тим, як писати код. Усе інше між цим — реалізація, перевірки, обговорення в рев'ю, злиття та деплой — виконується без нікого "за кермом". Коли перевірка провалюється або рецензент заперечує, агент читає причину збою, виправляє її й знову пушить, і цикл просто робить ще одне коло. Він завершується лише тоді, коли гілка зелена, кожне зауваження вирішене, а черга злила її.
Це стає можливим не завдяки якійсь індивідуальній інтеграції. Річ у тому, що ці три інструменти вже надають командні поверхні, якими агент може керувати напряму, — ті самі, якими користується людина:
- GitHub, через його CLI. Агент відкриває pull request, зчитує статус і логи кожного CI-завдання, відповідає в тредах рев'ю та позначає їх вирішеними, і додає гілку в чергу на злиття — і все це через звичайні команди
gh. - Linear, через його MCP-сервер. Агент читає задачу, на яку йому вказали, переходить за посиланнями на пов'язані задачі для контексту, змінює статус і заводить нові задачі-продовження для роботи, яку виявляє по дорозі, — і все це як повноцінні виклики інструментів.
- Власний monitor-цикл Claude Code. CI триває хвилини, а черга злиття — довше, і жодна людина за цим не стежить. Натомість стежить агент, і саме те, як він стежить, перетворює запуск без нагляду на щось практичне, а не на багаття з токенів.
Коли агент відкриває pull request, він не сидить, оновлюючи сторінку; він фіксує, чого саме чекає — запуск CI, треди рев'ю, запис у черзі злиття, — а потім завершує хід. Функція Monitor у Claude Code повторно викликає його лише тоді, коли цей відстежуваний стан змінюється: завдання стає червоним, панель рев'ю публікує зауваження, черга зливає гілку. Оскільки агента "будять" повідомлення від Monitor про кожне оновлення статусу, він відповідно робить наступний крок — наприклад, дістає лог провального завдання й пушить виправлення, відповідає в треді рев'ю та позначає його вирішеним, або додає гілку в чергу, щойно всі бар'єри стають зеленими.
Жодна з цих речей не специфічна для Muse. Будь-який репозиторій, доступний через ці три інструменти, можна вести так само, і саме тому ми їх обрали.
Довіра — це артефакт білда
Ми не довіряємо самій LLM. Ми довіряємо LLM-агенту всередині обв'язки, і цю обв'язку можна спроєктувати як вартового надійності. Конкретно, обв'язка — це наш CI/CD-пайплайн плюс шар рев'ю поверх нього. Через це проходить кожен pull request, без винятків:
Кожен pull request проходить ту саму обв'язку: спочатку автоматичні перевірки, потім панель ШІ-рев'ю.
Окремі завдання з типовим часом, виміряним на нещодавніх реальних запусках PR:
| Завдання | Що перевіряє | Типовий час |
|---|---|---|
| Guardrails | Шарування (без сусідніх імпортів), форма папок, стеля розміру файлу, іменування | ~60 s |
| Lint | Формат і правила лінту ruff | ~30 s |
| Перевірка типів | pyrefly, по всьому проєкту | ~20 s |
| Юніт- та інтеграційні тести | pytest проти справжнього Postgres, побудованого зі схеми | ~90 s |
| Візуальні тести | Скріншоти Playwright, звірені з зафіксованими еталонами (goldens), у власному рендерері CI | ~140 s |
| Безпека | Статичний аналіз semgrep плюс сканування секретів | ~40 s |
| Тест завантаження контейнера | Застосунок має завантажитися, а він відмовляється це робити, якщо не кожен маршрут декларує, хто може його викликати | ~215 s |
Guardrails — це описана нами архітектура, перетворена на машини. Сусідній імпорт тут — не зауваження в рев'ю, а червоний білд. Візуальні еталони фіксуються у власному рендер-середовищі CI, тож "у мене на машині працює" ніколи не може бути аргументом для злиття бага в main.
Шар ШІ-рев'ю — ось де стає цікаво. Кожен PR читає наша власна панель із трьох агентів-рецензентів коду, які розглядають той самий diff у світлі задокументованих принципів дизайну репозиторію, кожен зі своєю призначеною персоною. Тут ми покажемо схему промптів, які отримує кожен рецензент.
Провідний інженер:
Персона: Провідний інженер, дизайн-рев'ю, великий масштаб
Ти оцінюєш на рівні системи: чи належить ця зміна тут, чи вписується вона в архітектуру, чи перевикористовує наявне і залишається адитивною, а не чи охайний якийсь рядок.
Ти бачиш diff + Гайди, а не весь репозиторій. Оцінюй перевикористання та узгодженість патернів ...; не претендуй на пошук по всьому репозиторію, який ти не можеш виконати.
Твій ракурс: Оціни diff за цими частинами наданих Гайдів ...
Лакмус: "Якби я був провідним інженером цієї кодової бази, чи повернув би я це назад через те, що воно живе не в тому місці, дублює наявну можливість, або додає другий спосіб робити вже вирішену задачу?" Якщо ні — поверни
[].
Старший інженер:
Персона: Старший інженер, логіка / реалізація / якість
Ти оцінюєш у межах зміни: чи логіка правильна, чиста, тестована й безпечна. Це найретельніше рев'ю — простеж шляхи виконання коду, не проглядай по діагоналі. Зосередься на diff і файлах, яких він торкається (прочитай їх повністю).
Твій ракурс: Оціни diff за цими частинами наданих Гайдів ...
Лакмус: "Чи схвалив би я цю логіку, чи знайшов би баг, нетестований шов або помилку безпеки при уважному читанні?" Будь конкретним щодо вхідних даних або шляху коду, які призводять до збою. Якщо логіка правильна — поверни
[].
QA-інженер:
Персона: QA-інженер, чи це працює, чи це протестовано, чи це зламається
Ти оцінюєш поведінку та ризик: чи ця зміна робить те, що заявлено, чи вона покрита тестами, і чи може вона зламати щось у роботі чи в продакшні? Прочитай заголовок і опис PR, а тоді перевір, чи diff це реалізує.
Твій ракурс: Відповідність наміру ...; Покриття тестами ...; Ризик регресії ...; Пастки продакшну ...
Лакмус: "Якби я був QA, що підписує реліз, чи заблокував би я це через те, що воно не робить заявленого, через постачання непротестованої поведінки, чи через зміну, що ламає прод?" Якщо це безпечно й покрито — поверни
[].
Окрім розгляду того самого diff коду під різними кутами, усі 3 рецензенти також спираються на спільний набір правил, які керують розробкою всієї кодової бази, тобто на Гайди:
- Речі, що змінюються разом, живуть разом; непов'язані речі залишаються розділюваними. Зміна чи видалення однієї відповідальності торкається одного місця.
- Бізнес-логіка не залежить від деталей зовнішнього світу. Функція бізнес-логіки виконується в тесті з переданими фейками, без реального I/O. Заміна бекенду не торкається бізнес-логіки. Застосунок ніколи не викликає власні HTTP-ендпоінти.
- Перевикористовуй, а не винаходь заново. Кожна можливість має одну реалізацію; новий споживач викликає наявний інтерфейс замість того, щоб копіювати його.
- Додавай фічі додаванням, а не редагуванням. Додавання фічі — це "нові файли + один рядок реєстрації", а її видалення не торкається жодної іншої фічі.
- Один усталений спосіб робити кожну річ. Новачок копіює наявний патерн замість того, щоб обирати, а тестам не потрібен ні сервер, ні БД.
- Видаляй код тієї миті, коли він перестає використовуватися. Не постачається нічого, що ніхто не викликає; "залишити про всяк випадок" — не причина, бо git пам'ятає.
- Обирай найпростіше, що працює; додавай складність лише тоді, коли змушений. Кожна абстракція заслуговує своє місце конкретною поточною потребою. Зміна — найменша з тих, що вирішують проблему.
Панель публікує кожне блокувальне зауваження як inline-коментар, прив'язаний до точного рядка, і ці коментарі блокують злиття, доки їх не вирішать.
Ось як виглядає рев'ю з нещодавнього PR із фічею:
[medium] Ризик регресії. Ця функція — спільна вузька точка створення й синхронізації; тепер вона згортає файли з суфіксами view в один згрупований рядок. Будь-який наявний датасет, завантажений за старою схемою, під час наступної синхронізації буде мовчки перегрупований, видаляючи старі ідентичності зразків, на які досі посилаються активні оцінювання. Жоден тест не покриває повторну синхронізацію наявного датасету через нове групування.
Це зауваження було правильним. Код пройшов повний набір тестів і перший зелений раунд CI. Тести були правильними для коду, як його написали. Рецензент побачив, що написаний код був неправильним для даних, які в нас насправді є. Claude виправив це, додав відсутній регресійний тест, відповів у треді і вирішив зауваження. Увесь обмін публічний у PR, точнісінько так само, як ти наставляв би молодшого інженера через рев'ю коду.
Це був один PR. Запускаючи агента з часом, ми змогли виявити ще кілька типових патернів:
- Виправлення, що спричиняє нову проблему. Діагностичний інструмент, який ми випустили, вимірював швидкість завантаження. Рев'ю виявило, що в математиці використовувалися MB (1 000 000 байтів), тоді як сервер надсилав MiB (1 048 576 байтів), тож будь-яка швидкість показувалася б на 5% нижче реальної. Через кілька пушів рев'ю зазначило, що виправлення залишило дві константи, синхронізовані вручну. Тож воно вимагало натомість обчислювати швидкість із реально отриманих байтів. Рецензент виявив баг, який створило виконання його ж попередньої вимоги.
- Глухі кути в сценаріях використання. Та сама сторінка вийшла з посиланням, видимим для кожного зареєстрованого користувача, хоча сама сторінка вимагала окремого дозволу. Будь-хто без цього дозволу натиснув би і отримав помилку 403. Жоден тест не провалився, бо посилання з'являлося, а бар'єр дозволів працював. QA-рецензент зіставив ці дві речі й заблокував злиття, доки посилання не почало показуватися лише тим, хто справді міг відкрити сторінку.
- Хакання заради проходження тестів. Тест одного виправлення сам штучно створював саме той виняток, який мав ловити, тож він проходив, навіть якщо реальна обробка помилок була зламана, — бо тест отримував "правильне" повідомлення винятку. Панель це помітила, і переписаний тест тепер проганяє реальні помилки через реальний код. У тому самому PR також був тест, що проходив на машині розробника, але провалювався в CI, бо він мовчки покладався на файл облікових даних, який існує лише на нашій dev-машині. Обидва були багами в самих тестах, виявленими шаром, що стоїть над ними.
Наша політика злиття — 0 зауважень від ШІ-рев'ю. Кожне зауваження виправляється або спростовується доказами, перш ніж черга забере PR. Ми зробили спростування життєздатною опцією, тому що панель рев'ю надлишково позначає з прийнятною частотою. Записуючи, чому зауваження помилкове, іноді вдається виявити помилку і в міркуваннях самої панелі рев'ю.
Після перевірок черга злиття повторно валідує кожну гілку відносно рухомого вершка main, і злиття автоматично розгортається в продакшн без жодної людини в циклі.
Пройшовши кожен бар'єр, черга злиття повторно валідує гілку, і злиття розгортається в продакшн.
Кількість рядків коду — це мала частина історії
Протягом багатьох самокерованих PR ми виявили разючий, але цілком логічний патерн: час, витрачений на ітерації з перевірками й рев'ю, набагато більший за час, витрачений на написання першої реалізації, і це співвідношення також дуже сильно варіюється залежно від типу задачі. Тут ми порівнюємо два типи задач розробки за один і той самий тиждень.
Кейс А: зняти з експлуатації мертву фічу. Невелика застаріла фіча пішла в офлайн; її посилання, діалог підтвердження, переклад, тести та скріншот-бейзлайн — усе мало зникнути. Від подання задачі в Linear до злиття PR у main пройшло лише 16 хвилин, із них перші 2 хвилини — написання коду. Рев'ю мали лише дорадчий характер.
Кейс Б: суттєве покращення функції мережевої діагностики. Це була зміна подібного розміру за кількістю рядків, перша версія якої була готова за 5 хвилин, тоді як загальний час до злиття становив близько 3 годин. За цей час агент опрацював 5 раундів рев'ю і 7 блокувальних зауважень.
Часові шкали теж суттєво відрізняються:
| Кейс А: зняти з експлуатації мертву фічу | Кейс Б: покращити діагностичний інструмент | |
|---|---|---|
| Розмір зміни | +10 / -125, 8 файлів | +439 / -19, 9 файлів |
| Перша робоча версія | 2 хв | 5 хв |
| Від подання задачі до злиття | 16 хв | 3 години |
| У скільки разів довше до злиття, ніж перша версія | 8x | 36x |
| Блокувальні зауваження рев'ю | немає (лише дорадчі) | 7, у 5 раундах |
| Найгірший сценарій, якщо код помилковий | посилання, на яке нікому не варто клацати | кожен користувач довіряє неправильному числу |
Дві задачі з порівнянною кількістю рядків, яким приділили зусилля верифікації пропорційно ризику.
Друга задача триває в одинадцять разів довше не тому, що код було важче написати, а тому, що ризик був іншим, і зусилля верифікації витрачалися пропорційно. Кейс А був видаленням: найгірший результат — зламане посилання, яке й так не мало відвідуватися. Кейс Б був інструментом вимірювання: найгірший результат — кожен користувач довіряє неправильному числу. Панель рев'ю знайшла помилки, а тоді витратила ще три раунди, відмовляючись від часткових виправлень, доки обробка помилок не стала типізованою, повною і ретельно протестованою. Кожен раунд робив реалізацію строго суворішою. Жоден із цих дефектів не провалював тест, і всі вони пішли б у продакшн.
Ось де одноразова (one-shot) генерація коду помиляється за самою своєю конструкцією. Одноразова генерація оптимізує метрику, яку найлегше побачити: час від промпту до коду, що компілюється й запускається. Обидва наші кейси досягли цієї метрики за лічені хвилини, і якби ми зупинилися на цьому, Кейс Б був би готовий за кілька хвилин після старту — і помилковим протягом місяців.
Той самий пайплайн, що пропустив видалення за 16 хвилин, тримав інструмент вимірювання 3 години, і жодна людина не вирішувала, якого ставлення заслуговує кожен випадок. Коли люди питають, чи можна довіряти написаному ШІ коду в продакшні, ось відповідь: код настільки ж заслуговує на довіру, наскільки заслуговує на неї верифікація, що його огортає, а глибина верифікації тепер — це те, що купується годинами агента, а не днями інженера. Неправильний звіт про швидкість коштує більше трьох годин уже першого разу, коли хтось спрямує скаргу на мережу за цим числом.
Що ми зрозуміли і що далі
Сьогодні автономність — це радше властивість обв'язки, ніж властивість моделі. Кожне оновлення моделі робило наших агентів кращими; однак сама можливість моделі не постачається з гарантією, що агенту можна довірити вільно зливати свої pull request'и. Замість того щоб вкладати більше людської уваги або наосліп використовувати найдорожчу передову модель, ми обрали побудувати "руки" й "очі", щоб агенти мали все необхідне для створення правильного продакшн-коду. А з розвитком можливостей моделей це також дає нам змогу осідлати цю хвилю, а не перебудовувати каркас, щоб компенсувати обмеження моделей.
Роль людини концентрується, а не зникає. Те, що залишається, — це незвідне ядро: вирішувати, що варте побудови, викласти це достатньо чітко на письмі і застосовувати судження в ті моменти, які машини позначають як неоднозначні. Смак у дизайні та якість специфікацій тепер — найвпливовіша інженерна навичка в цій команді.
А найцікавіший висновок про команди агентів у тому, що цінність команди походить із конфлікту, а не зі співпраці. Може мати сенс розбити full-stack задачу на фронтенд- і бекенд-агентів. Менше сенсу в тому, щоб фронтенд-агент і бекенд-агент розмовляли один з одним просто заради завершення задачі. Перевага команди проявляється тоді, коли в учасників конфліктні цілі. Наш агент розробки Muse хоче поставити код. Наші ШІ-агенти рев'ю хочуть знайти, де код неправильний або погано спроєктований. Саме їхнє напруження робить результат заслуговуючим довіри і чесно розкриває справжній обсяг роботи над задачею розробки.
Що важливіше, ми бачимо, що наші дослідження ведуть нас до нового способу розробки софту, що зароджується: автономної інженерної організації. Хоча ми продемонстрували, що агенти можуть автономно виконувати окремі задачі за допомогою наявних інструментів, кілька відсутніх шматочків і відкритих питань запрошують до майбутніх спроб:
- Наскільки ми здатні масштабувати такі системи? Коли автономні організації працюють над дедалі більшими задачами й проєктами з більшою кількістю паралельних агентів, які нові проблеми виникнуть?
- Як власні результати обв'язки, такі як відсоток проходження CI з першого разу і зауваження ШІ-рев'ю, можуть стати сигналами оцінювання? Як нам вимірювати продуктивність агента в організації і як зробити її саморозвивальною?
- Як людський смак у дизайні й продукті можна вбудувати в такі системи? Якщо інженерію можна зробити автономною за мінімальної кількості людських рішень, як далеко ми можемо це зайти, щоб вирішити питання того, для кого нам варто будувати софт і яким він має виглядати?
Насамкінець, дякуємо, що дочитали аж до самого кінця. Список справ для пошуку відповідей на ці питання цілком закономірно живе в Linear, де наш наступний агент — або ви — можете його підхопити.
