Ділюся своєю моделлю AI-native розробки: напівавтоматизація, human-in-the-loop і контекст як ресурс. Покритикуєте?

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Я розробив підхід до роботи, який називаю:

Напівавтоматизований AI-native процес розробки з людиною в контурі.

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

1. Напівавтоматизований

Якщо завдання можна надійно виконати простим скриптом, його не варто доручати AI.

• Хочете, щоб код завжди був відформатований однаково? Налаштуйте Prettier.
• Потрібні власні правила неймінгу, обмеження на імпорти чи архітектурні правила? Налаштуйте ESLint або напишіть власне правило.
• Хочете однакове форматування в різних редакторах? Додайте EditorConfig.

Не змушуйте AI витрачати контекст і когнітивну здатність на перевірку відступів, крапок з комою чи правил неймінгу. Детерміновані проблеми повинні мати детерміновані рішення.

Ось менш очевидний приклад.

Для свого поточного проєкту я написав кілька тисяч юніт-тестів. Як перфекціоніст і колишній QA-інженер, я дуже уважно ставлюся до того, як саме елементи вибираються в тестах.

Де це можливо, тести насамперед повинні використовувати доступні селектори — наприклад, ролі та accessible names. Test ID має використовуватися лише як запасний варіант.

Спочатку я вважав, що AI просто повинен пам’ятати це правило, а помилки я виправлятиму під час код ревʼю.

Але з часом помітив, що надто часто виправляю одну й ту саму проблему.

Тоді я поставив собі запитання:

Навіщо мені постійно перевіряти вручну те, що можна перевірити автоматично?

Я написав власне lint-правило.

Кілька рядків коду назавжди вирішили цю проблему.

Тепер лінтер знає потрібний пріоритет селекторів і автоматично повідомляє про порушення.

І найкраще те, що AI виправляє такі проблеми практично в кожному випадку.

Чому?

Тому що запуск процедур валідації проєкту є обов’язковою частиною мого workflow. Навіть якщо AI припускається помилки, він запускає лінтер, отримує точне повідомлення про помилку й виправляє код.

Саме це для мене означає «напівавтоматизований»:

• AI виконує завдання, які потребують міркування.
• Скрипти виконують завдання, які потребують стабільності та повторюваності.

2. AI-native

Репозиторій можна структурувати переважно для зручності людей. А можна організувати його так, щоб і люди, і AI могли ефективно в ньому орієнтуватися.

AI-native репозиторій ставиться до контексту як до обмеженого інженерного ресурсу.

Деяким розробникам знайома гра code golf — розв’язання задачі за допомогою мінімально можливої кількості символів.

AI-native розробка — це не зовсім про неї, але базове обмеження схоже:

Кожен токен має свою ціну.

Це не означає, що код потрібно стискати до стану, коли його неможливо читати. Йдеться про баланс між читабельністю, послідовністю та ефективністю використання контексту.

Велику роль тут відіграє стандартизація проєкту.

Один компонент не повинен використовувати повністю іншу структуру, стиль або парадигму порівняно з іншим без вагомої причини.

Перевикористовувані абстракції повинні бути чітко визначені й використовуватися послідовно.

Завдяки цьому AI може знайти вже наявну реалізацію, зрозуміти її як стандарт проєкту та використовувати як надійний референс.

Ще один важливий принцип я називаю сегрегацією контексту.

Фічу варто розділяти на змістовні файли так, щоб AI міг завантажувати лише той контекст, який потрібен для поточного завдання.

Наприклад, реалізація тестів може містити:

• сам файл із тестами;
• fixtures;
• mocks;
• setup-утиліти.

Іноді setup за обсягом навіть більший за сам набір тестів.

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

Для цього я використовую суфікс-файли. Велика фіча може мати кілька допоміжних файлів поруч із нею, а їхні суфікси чітко описують призначення. Приклад: newFeature.unit.spec.ts та newFeature.unit.fixture.ts

Залежно від задачі я можу дати AI саме ті файли, які йому потрібні, — і нічого зайвого.

І, будь ласка, використовуйте індекс експорти там, де це має архітектурний сенс.

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

3. Людина в контурі

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

Можливо, я старомодний, але ставлюся до такого підходу дуже скептично.

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

Але є одна проблема, важливіша за всі інші:

Якщо ви прибираєте себе з процесу, ви перестаєте ВЧИТИСЯ.

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

А головне — ви втрачаєте дані, необхідні для покращення власного фреймворку розробки.

Ось мій улюблений приклад.

У певний момент я створив те, що вважав ідеальним процесом AI-розробки.

Я багато разів переглядав кожну інструкцію. Уточнював кожну деталь. І був переконаний, що фреймворк спроєктований винятково добре.

Потім я почав використовувати його в продакшені.

За два місяці процес пройшов через п’ять поколінь фундаментальних змін — і це без урахування десятків дрібніших покращень.

Чому?

Тому що реальне використання генерує зворотний зв’язок.

Я бачив, що не працює, що створює зайву роботу, що AI інтерпретує неправильно і що можна автоматизувати ефективніше.

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

Саме тому в моєму воркфлоу людина залишається в контурі.

Не лише для того, щоб схвалювати код, згенерований AI.

А щоб вчитися на кожній ітерації та безперервно покращувати систему, яка цей код створює.