Перейти до основного вмісту

Частина 8: Зробіть це командним стандартом

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

Основний принцип, який слід пам'ятати: AI підсилює інженерну культуру, в яку потрапляє. Команда з міцними тестами, чіткими стандартами та здоровим рев'ю отримує значно більше від цих інструментів. Команда без цього пришвидшується у виробництві проблем. Сенс стандартизації — зробити хорошу культуру шляхом найменшого опору.

Ставтеся до харнесу як до коду​

Файли правил, системні промпти, набори евалів і бібліотеки навичок — це не особиста конфігурація, а спільна інфраструктура. Ставтеся до них точно як до коду:

  • Версіонуйте їх разом із проєктом.
  • Переглядайте їх у pull requests — як будь-яку іншу зміну.
  • Призначайте іменованих власників, щоб їх підтримували навмисно, а не занедбували.

Без цього агент кожного розробника поводиться трохи інакше, і ніхто не може відтворити результати іншого.

Ставте умовою евали, а не демо​

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

Зробіть покриття евалами передумовою випуску — так само, як ви б ставили сервіс в залежність від покриття тестами. Але евал без чіткого рубрику нічого не вимірює — тому визначте, що ви оцінюєте:

  • Успішність завдання
  • Якість використання інструментів
  • Відповідність траєкторії
  • Рівень галюцинацій
  • Якість відповіді

CI-гейт робить це реальним:

# ci: block merge if the agent's eval suite regresses
agent-evals:
  run: eval-suite --rubric rubric.yaml --min-score 0.9
  on: [pull_request]
  required: true

Переформатуйте код-рев'ю для генерованого коду​

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

Чітко визначте межу між прототипом і продакшном​

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

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

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

Будуйте харнес один раз, вдосконалюйте багато разів​

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

Наймайте та просувайте тих, хто здатний приймати рішення​

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

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

Налаштуйте власний робочий процес​

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

Джерело: The New SDLC With Vibe Coding (Google) — https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding