Технический контекст: что именно доказал «dog-game»
Я прочитал разбор Caleb Leak про «dog-game» и увидел не милую историю про собаку, а очень чистый эксперимент по инженерии процесса. Собака Момо генерирует случайные нажатия клавиш, Claude (через Claude Code) интерпретирует это как требования к игре и собирает полноценные проекты на Godot 4.6 с логикой на C#.
Ключ не в «магическом промпте», хотя framing там сильный: любой бред трактуется как "скрытые команды гениального дизайнера". Настоящая сила — в замкнутом 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-кодинг из импровизации в управляемую систему качества, я приглашaю обсудить ваш проект: разберу текущий SDLC, предложу архитектуру verification loop и помогу запустить внедрение в production без романтики и с измеримым эффектом.