Пост Романа Севаста про AI-native розробку — розбір

Роман Севаст (засновник Awesomic) перебудував свою розробку так, що AI для нього — не помічник, а команда, яка працює над фічею кілька днів поспіль. Його цифри: іноді 500+ комітів за день; на планування йде до 75% усього часу; одна фіча розлітається на 5–50 паралельних пул-реквестів; бували складні пул-реквести, які автоматичний рев'ювер завертав понад 100 разів. Каже, що головна проблема тепер не «чи зможе AI», а ліміти — за день згорає одна-дві підписки.

Ланцюг, який він описує

1. Спершу глибоке дослідження продукту й коду — поки не зрозумів контекст, ніхто нічого не пише.
2. Детальний план-документ, а не список тасок. Потім план сам себе критикує: окремі агенти шукають дірки в логіці, зайву складність, непокриті випадки.
3. Агенти мають «захистити» план: що буде, якщо дані криві, якщо сервіс упаде, як відкочувати.
4. Робота ділиться на команди та спринти — бекенд, фронт, інфраструктура, дизайн, окремий координатор.
5. Тести описуються до коду й на рівні продукту: що бачить юзер, що натискає, що має статись. Тестове середовище максимально повторює бойове, агент проходить фічу як реальна людина.
6. Виконання — паралельно, багато пул-реквестів одночасно.
7. Кожен пул-реквест окремо проходить незалежний рев'ю іншими моделями. Рев'ювер не знає, як саме писався код: читає задачу, план і різницю з нуля.
8. На виході — не технічне полотно, а звіт: що зроблено, що протестовано, що неочевидного знайшли, скріни, прохід по сценарію, ризики.
9. Після викатки агенти повторюють ключові тести вже на бойовому, дивляться логи й реальну поведінку.
10. Це не один мегапромпт, а весь сетап разом, який він щодня доточує маленькими покращеннями.

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

Є Тести до коду У тебе це сформульовано жорсткіше за пост: перевірки пишуться до реалізації і мають упасти з правильної причини — «фічі ще немає», а не «одрук». Перевірка, що зеленіє на порожньому коді, вважається браком. Плюс окремий довгий список правил гігієни, як не написати перевірку, що нічого не перевіряє.

Є Звіт замість технічного полотна Те, що ти зараз читаєш, і є цей формат. Плюс дошки, які показують стан замість того, щоб примушувати тебе читати логи.

Є, і сильніше за пост Нагляд після викатки У автора це «агенти повторюють тести на бойовому й дивляться логи». У тебе стоїть більше: перевірки інваріантів на кожному тику, які звіряють незалежний факт, а не звіт агента; сторож живості самого сторожа; нічний прогін усіх перевірок; монітори свіжості; сторожі, що ловлять задачу, яка померла посеред роботи. Але все це стежить за життям органів, а не за тим, чи нова фіча реально поводиться правильно.

Частково Детальний план і критика плану Машинерія є: важке дослідження з окремими ролями — скептик, дослідник, переформулювач — плюс експертна панель із премортемом. Але вона свідомо заряджена як рідкісний інструмент, «кілька разів на квартал, коли помилка дорога». Тому переважна більшість білдів у тебе йде взагалі без критика плану. У автора цей крок стоїть на кожній фічі.

Частково Розбиття роботи на команди й сесії Аналог у тебе інший, але робочий: велика робота стає мапою рішень, мапа — спекою, спека ріжеться на наскрізні тікети, кожен рівно в одну сесію білдера. Плюс тонкі адміни, що народжують працівників. Чого немає — ролей «бекенд/фронт/інфра» з координатором: у тебе координує сама черга тікетів, і це дешевше.

Частково Незалежний рев'ю Наприкінці білду в тебе стоїть перевірка у дві осі: одна звіряє результат зі спекою, друга свідомо не читає спеку й дивиться лише на стандарти й межі — саме щоб не заякоритись. Гірша з двох перемагає. Це вже той принцип, що в пості. Чого немає — циклу «завертаю, поки не чисто»: твоя перевірка дає вердикт один раз, а не ганяє результат по колу.

Немає — і це свідомо Паралельне виконання багатьма пул-реквестами У тебе прямо записано протилежне правило: ніколи два виконавці одночасно всередині однієї арки. Паралель різних тікетів дозволена лише під заявкою на тікет — і сама ця заявка тримається текстом правила, а не воротами; це записано як визнаний борг. Плюс у тебе немає шару пул-реквестів як такого: коміт іде прямо в дерево, а рев'ю стоїть перед комітом.

Немає Бойово-подібне середовище й прохід як юзер Найближче, що є, — ворота, які не пускають коміт у сторінку без свіжого скріншота, і правило перевіряти ознаку фічі на живій адресі. Але окремого середовища, що повторює бойове, немає: перевірка відбувається на живому. Автоматичного проходу «відкрий, натисни, заповни, звір результат» теж немає.

1. Прохід як юзер на середовищі, схожому на бойове Це закриває твій найдорожчий клас дефектів — той, де все зелене, а на сторінці нуль. У твоєму ж журналі є пакет із дев'ятьма зеленими перевірками і сімома наскрізними, який не дав жодного ефекту на сторінці; і живий сервер, що після рестарту продовжував віддавати стару версію сторінки. Обидва випадки — не помилки в коді, а відсутність кроку «подивись на це так, як дивиться людина». Половина інструменту в тебе вже лежить: браузер з окремим профілем, який ходить і робить знімки. Бракує сценарію-проходу й місця, куди він кладе вердикт.

2. Критика плану як дешевий обов'язковий крок Не важка машинерія на кожен білд — це вб'є швидкість. А один свіжий агент, який бачить тільки план і має мандат шукати дірки, зайву складність і непокриті випадки. Дешево, застосовно завжди, і б'є саме туди, де твоя нинішня конструкція має провал: важкий інструмент занадто дорогий, щоб кликати його щоразу, тож зараз між «нічого» і «повна панель» немає нічого посередині.

3. Рев'ю, що завертає повторно, а не ставить оцінку У автора найсильніша деталь — не «є рев'ювер», а «рев'ювер може завернути сто разів і це прекрасно». У тебе перевірка наприкінці білду виносить вердикт, і на цьому цикл зупиняється. Різниця між оцінкою і циклом — це різниця між «ми знаємо, що там проблема» і «проблеми там більше немає».

500 комітів за день як орієнтир Твоє вузьке місце — не швидкість написання коду, а твоя увага на перевірці. Твоя ж конституція про це прямо попереджає: що більше кроків проходить зеленими, то гірше працює людська перевірка — вона тихо з'їжджає з «я перевірив» на «я підтвердив». Більше комітів за день при одному наглядачі означає рівно одне: більше речей, яких насправді ніхто не подивився. Це не обережність, це твоє власне записане правило.

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

Окрема роль «AI-технічний директор» Те, що в пості робить ця роль — зрозуміти контекст, скласти план, поділити на шматки — у тебе вже роблять мапа, спека й нарізка на тікети. Додавати зверху ще одну координуючу роль означало б купити те, що вже стоїть.

gstack від Гаррі Тана Автор двічі згадує, що перевикористовує його і для написання, і для рев'ю, і рекомендує. Це відкритий набір із приблизно двох десятків готових команд для того самого середовища, в якому ти працюєш — ролі на кшталт технічного директора, дизайнера, менеджера релізів, контролю якості. Ліцензія вільна, тобто дивитись і брати шматками можна без домовленостей. Це найдешевший конкретний крок із усього посту: не переробляти свій процес, а прочитати чужий набір команд і забрати те, чого в тебе бракує — насамперед цикл рев'ю, що завертає.

Живі воркшопи Наприкінці посту автор пише, що в серпні почне безкоштовні live-воркшопи, де покаже сетап наживо. Дати в пості немає. Якщо тема цікава — це дешевший спосіб побачити деталі, ніж відновлювати їх із тексту.

Найсильніше заперечення

Про роздування коду

Питання, яке я б поставив і собі

Про ціну

Ще два — про складність Oleksandr Tokmakov питає, чи глибокий ресерч робиться справді на кожну таску. Viktor Panasiuk коротко: «не тяне плюс мінус більше менш складний проект самостійно». Обидва — про межу застосовності, і обидва лишились без видимої відповіді автора в тому, що я побачив.

Чесно про повноту Текст посту я прочитав повністю. Коментарі — лише частково: сторінка віддає їх обрізаними, тож у мене сім коментарів, більшість із них уривками, і жодної відповіді автора. Якщо якийсь із них важливий — його треба дочитати вручну за посиланням.