Не автономний AI-розробник: чому CRUX залишає людей у циклі

Обіцянка: призначте задачу й отримайте pull request

Популярний тип AI-інструментів працює так: ви призначаєте задачу агенту, він піднімає пісочницю, читає репозиторій, пише код і відкриває pull request. Дехто обіцяє випускати в рази швидше. Для маленької, добре описаної задачі (одруківка, тест, що падає з чітким stack trace, оновлення залежності) це справді працює.

CRUX виріс із протилежного відчуття. Ми щодня працюємо з AI-агентами, і що більше дозволяли їм діяти самостійно, то більше часу потім витрачали, шукаючи, де саме вони нас не так зрозуміли.

Де «автономність» ламається

Опис задачі рідко містить усю задачу. Ось що в нас постійно йшло не так до CRUX:

• Агент не знав, чому код написаний саме так. Ми вставляли текст задачі в сесію. Агент бачив код, який здавався дивним, «виправляв» його і ламав функціональність, яку інша задача додала з причини, якої агент не бачив.
• Кожна сесія починалася з нуля. Агент забував, про що проєкт. Доводилося або пояснювати все заново, або дивитися, як він спалює купу токенів, розбираючись сам.
• Ніхто не міг відрізнити вимогу від здогадки. Колеги теж пишуть задачі з AI. Розробник читає три екрани згенерованого тексту і мусить зрозуміти, які рядки попросив клієнт, а які вигадав чийсь асистент. Автономний агент цього теж не відрізнить, тож будує здогадки так само старанно, як вимоги.
• Агент з усім погоджувався. «Чудова ідея!», навіть коли сьогоднішня ідея суперечила тому, що ми вирішили три дні тому.
• Великі фічі не мали доброї форми. Одна довга сесія давала величезний pull request, у якому накопичувалися помилки й галюцинації. Розбити роботу на нотатки означало самому стежити, який агент що зробив і в якому порядку.

Справа тут не в слабкій моделі. Справа в контексті та зворотному зв'язку: агент знає замало, а його хибне припущення ніхто не бачить аж до pull request, коли виправлення коштує найдорожче.

Ідея CRUX: люди залишаються в циклі, а цикл стає дешевим

«Людина в циклі» часто звучить як гальмо. Ми вважаємо навпаки: найдешевше виправити непорозуміння одразу після того, як воно сталося, а люди, які можуть його помітити, вже є в команді. Тому CRUX не намагається їх прибрати. Він намагається зробити кожну перевірку короткою і поставити її в правильне місце.

1. Агент знає проєкт, а не лише задачу

Агент CRUX не отримує весь проєкт, вставлений у контекст. Він отримує доступ до нього: задачу в трекері, попередні задачі й рішення, записані в них, заплановані наступні задачі і вікі проєкту, яка описує, як система працює сьогодні. Що читати для конкретної задачі, агент обирає сам. Саме такого балансу ми прагнемо: контексту достатньо, щоб добре розв'язати задачу, але не стільки, щоб агент у ньому потонув і почав ігнорувати інструкції. (Докладніше: Вікі, трекер і граф коду замість RAG і як ми ведемо вікі.)

Це змінює результат сильніше, ніж ми очікували. Агент, який знає, навіщо існує старий код, його не чіпає. Агент, що працює над задачею A і бачить за нею у черзі A1 та A2, будує рішення так, щоб вони потім лягли на нього. А агент, який читає минулі рішення, може зробити те, що робить добрий колега:

Агент: У понеділок у батьківській задачі вирішили, що гроші за повернення йдуть лише на картку, з якої платили. Ця задача просить повертати їх бонусами магазину. Рішення змінилося, чи залишити понеділкове правило?

Одне таке запитання варте більше, ніж будь-яка кількість «чудових ідей».

2. Запитання йдуть до людини, яка знає відповідь

У CRUX кожен статус на дошці належить певній ролі, і в кожної ролі свої агенти. Тож запитання потрапляють до того, хто має знати відповідь: бізнесові — до власника запиту, технічні — до розробника, щодо тестування — до QA. (Див. AI-агенти для PM, QA і клієнтів і клієнт відповідає просто в задачі.)

• Слова людей і здогадки агентів не змішуються. Початковий запит зберігається таким, як його написали, а агент прямо каже, де він здогадується, поки людина не підтвердить. Нікому не треба гадати, чи цей рядок від клієнта, чи від чийогось чат-бота.
• Менше мітингів. Замість дзвінка, на якому вся команда перебирає відкриті питання, кожна людина проходить коротку сесію, де агент питає лише її частину. На спільне обговорення лишається тільки те, що справді потребує всіх.

Відповіді потрапляють у трекер, яким команда вже користується, тож будь-хто бачить, що написав агент, і може виправити це раніше, ніж на цьому збудують наступні кроки.

Добрий приклад — QA. Агент може підготувати тест-кейси із задачі та схвалених відповідей. А QA-інженер витрачає час на те, що агент оцінює погано: ризиковані сценарії, нетипового користувача, перевірку «тут щось не так».

3. Робочий процес замість нагляду

Велика фіча стає впорядкованим набором задач, і кожна проходить ті самі кроки: інтерв'ю, реалізацію, рев'ю, документацію. Кожен крок стартує з готового шаблону, тож не треба щоразу набирати «використай цей skill, потім перевір, потім відкрий PR», і видно, яка сесія над чим працює. (Докладніше: Досить писати промпти.) Наш робочий процес — лише один приклад. Команда пише власний, зі своїми статусами, ролями й перевірками.

4. Артефакти: контекст, який можна передбачити й покращити

Кожен крок завершується артефактом: структурованим коментарем у задачі. На контрольних точках (розуміння, план, результат) його схвалює людина, а між ними робота йде без того, щоб хтось стежив за кожним кроком. Наступний крок читає артефакти, а не чужу історію чату.

• Передбачуваний контекст. Чат весь час змінюється, а опублікований артефакт — ні. Запускаючи наступну сесію, ви точно знаєте, що вона прочитає.
• Інструкції, які можна покращувати. Історія артефактів показує, де агенти раз у раз помиляються, тож ви виправляєте skill чи промпт, що за цим стоїть, а не ту саму помилку вручну щоразу.
• Проблеми, які можна відстежити. Ретроспектива за спринт читає дошку й артефакти. Коли робота сповільнюється або багів стає більше, можна знайти, коли це почалося і чому, та усунути причину, а не розгрібати наслідки.

Для тимлідів і CTO

Автономні інструменти обіцяють «потрібно менше людей». Ми пропонуємо інше: ті самі люди витрачають менше часу на передавання повідомлень і переробки.

• Видимий процес. Кожне рішення, запитання і схвалення лежить у задачі вашого трекера, під іменем людини, яка його зробила.
• Менше мітингів на всю команду, бо запитання йдуть до того, хто знає відповідь.
• Процес, який можна виміряти й налаштувати, через ретроспективи та історію артефактів.
• Ваші агенти, ваш трекер. CRUX підключається через MCP-сервер, тож кожен розробник лишається з тим coding-агентом, яким уже користується (Claude Code, Codex чи інший MCP-клієнт), і на тому тарифі, за який уже платить. CRUX не перепродує токени моделей і не бере плату за години роботи агента. Він працює поверх трекера, який у команди вже є: Plane, Jira, Linear або GitHub Projects.

Коли автономність доречна

Ми не проти агентів, які працюють самі. Для однорядкового бага з чітким відтворенням перевірка на кожному кроці зайва, і ваш робочий процес може дати таким задачам короткий шлях. Питання в тому, які саме це задачі. Для більшості продуктової роботи справжня задача ще не записана: вона в головах людей навколо неї, і агент, який їх питає, працює швидше за того, що вгадує.

Коротко

• «Призначте задачу й отримайте PR» працює, коли опис містить усю задачу. Зазвичай не містить.
• Агенти CRUX мають доступ до всього проєкту через трекер і вікі, зокрема до минулих рішень і запланованої роботи, і самі обирають, що їм потрібно для задачі.
• Запитання йдуть до людини, чия роль знає відповідь, а слова людей і здогадки агентів не змішуються.
• Кожен крок завершується артефактом, а люди схвалюють його на контрольних точках, де хибний поворот ще дешево виправити. Це дає передбачуваний контекст, інструкції, які можна покращувати, і проблеми, які можна відстежити.
• Ви лишаєтеся зі своїм coding-агентом і своїм трекером.