Технічний контекст: що саме довів «dog-game»
Я прочитав розбір Caleb Leak про «dog-game» і побачив не милу історію про собаку, а дуже чистий експеримент з інженерії процесів. Собака Момо генерує випадкові натискання клавіш, Claude (через Claude Code) інтерпретує це як вимоги до гри і збирає повноцінні проєкти на Godot 4.6 з логікою на C#.
Ключ не в «магічному промпті», хоча фреймінг там сильний: будь-яка нісенітниця трактується як "приховані команди геніального дизайнера". Справжня сила — у замкнутому verification loop: згенерував → зібрав → прогнав інструменти → отримав вимірюваний зворотний зв'язок (скриншоти, сценарії вводу, перевірки сцен/шейдерів) → виправив.
Друга опора — boundaries (межі). Leak фіксує рушій (Godot 4.6), мову (100% C# логіка), і тим самим суттєво звужує простір помилок. Для мене це виглядає як архітектурний контракт: модель може «фантазувати», але тільки всередині заздалегідь визначених меж і з обов'язковою перевіркою результату.
Технічно це дуже близько до того, як я будую контури надійності в корпоративних асистентах: ми не "просимо написати код", а змушуємо код пройти вимірювані гейти. У dog-game ці гейти прості (скрин/лінтер/авто-ввод), але вони перетворюють генерацію на керований цикл якості.
Вплив на бізнес та автоматизацію: хто виграє, хто платить
Якщо ви сьогодні практикуєте вайбкодинг у продуктовій розробці, ви фактично перекладаєте ризик на команду: “потім полагодимо”. У реальному секторі це швидко перетворюється на прострочені релізи, деградацію якості та зростання вартості супроводу. Я бачив це в проєктах, де ШІ використовували як «прискорювач», але не додали контрольні цикли — швидкість на вході оберталася хаосом на виході.
Виграють компанії, які вкладаються не в «ще одну модель», а в ШІ автоматизацію навколо розробки: тести, статичний аналіз, збірки, перевірку міграцій, sandbox-середовища, політики доступу. Саме так «впровадження ШІ» перестає бути іграшкою і стає виробничим процесом.
Програють ті, хто купує "AI coding" як підписку і вважає, що цього достатньо. Підписка не створює контроль якості; його створює архітектура пайплайну. У термінах AI-архітектури я б сформулював це так: модель — не виконавець, а генератор гіпотез, а виконавець — ваш verification loop.
У Nahornyi AI Lab ми зазвичай починаємо з питання: які артефакти результату можна перевіряти автоматично вже завтра? Це може бути unit/integration тестування, контрактні тести API, лінт, SAST/secret scanning, прогін UI-скриптів, порівняння метрик продуктивності. Щойно з'являються гейти, «інтеграція штучного інтелекту» в SDLC стає передбачуваною за ризиками та бюджетом.
Стратегічне бачення: boundaries як нова “спека” для ШІ
Мій неочевидний висновок із dog-game: boundaries — це нова форма специфікації. Раніше ми писали вимоги в Confluence і сподівалися, що розробка їх “приблизно” втілить. Тепер межі можна формалізувати так, щоб модель фізично не могла повести проєкт убік: дозволені файли, припустимі залежності, заборона на мережеві виклики, суворе API-ядро, незмінні контракти.
Я спостерігаю схожий патерн у корпоративних впровадженнях: найкращі результати дає не «найрозумніший агент», а система, де агент постійно стикається з вимірюваннями. Якщо вимірювання відсутнє (немає тестів, немає спостережуваності, немає критеріїв приймання), ШІ буде впевнено генерувати сміття — і виглядатиме переконливо.
Наступний крок, який я прогнозую на 2026 рік: verification loops стануть продуктом, а не самописною інженерією. З'являться стандартні “цикли” під типові домени (ERP-кастомізації, ETL, RPA, фронтенд), але конкурентна перевага залишиться в тих, хто вміє спроєктувати їх під свій контекст, дані та регуляторику.
Якщо вам потрібне не демо, а розробка ШІ рішень для бізнесу, я б ставив завдання так: побудувати мінімальний контур boundaries+verification навколо найдорожчих помилок. Це дає швидкий ROI та дисциплінує команду сильніше за будь-які “правила використання ШІ”.
Що я рекомендую зробити на практиці
- Зафіксувати boundaries: стек, залежності, зони редагування, заборони, формат PR.
- Зібрати verification loop: збірка, тести, лінт, security-сканування, мінімальні e2e перевірки.
- Зробити “зворотний зв'язок машинним”: щоб модель читала звіти інструментів, а не думки людей.
- Ввести метрики: відсоток проходження гейтів, час на виправлення, дефекти після релізу.
Цей розбір підготував я, Вадим Нагорний — провідний експерт Nahornyi AI Lab з AI-архітектури, ШІ автоматизації та впровадження ШІ в реальні процеси. Якщо ви хочете перетворити AI-кодинг з імпровізації на керовану систему якості, я запрошую обговорити ваш проєкт: розберу поточний SDLC, запропоную архітектуру verification loop і допоможу запустити впровадження в production без романтики та з вимірюваним ефектом.