Технический контекст
Я посмотрел выступление Matt Pocock не как зритель, а как человек, который постоянно упирается в одну и ту же проблему: AI implementation в разработке ломается не на модели, а на процессе. И вот тут его набор приемов реально попадает в боль.
Первое, что я сразу отметил, это /grill-me перед Plan Mode. По сути, я вижу в этом не «секретный промпт», а режим жесткой проверки постановки задачи. Я и сам часто упираюсь в то, что кодовый ассистент слишком охотно соглашается, а потом тащит неверные допущения дальше по цепочке.
/grill-me хорош именно потому, что заставляет ИИ спорить, искать дыры, уточнять ограничения и крайние случаи до того, как он начнет писать план или код. Для реальной разработки это дешевле, чем потом разгребать красиво оформленную, но неверную реализацию.
Второй сильный момент, на котором я кивнул почти автоматически, это TDD как обязательный минимум. Не как идеология ради идеологии, а как страховка от фантазий модели. Если я заставляю ассистента сначала формализовать поведение тестом, он меньше «творит» и лучше держится контракта.
Еще один полезный паттерн, который обсуждали, это /domain-model. По описанию это похоже на короткую выжимку доменной модели с накоплением знаний в CONTEXT.md и ADR. Мне такой подход нравится именно своей сдержанностью: без огромного DDD-алтаря, но с фиксацией решений, чтобы следующий проход ИИ не начинался с амнезии.
И да, /improve-codebase-architecture я бы тоже не воспринимал как волшебную кнопку. Это скорее способ направить ассистента в архитектурную ревизию, но дизайн интерфейсов я бы все равно не отдавал целиком машине. Чем интерфейс проще, тем меньше шансов, что модель «оптимизирует» его в монстра.
Влияние на бизнес и автоматизацию
Для команд тут практический вывод очень приземленный. Выигрывают те, кто строит automation with AI вокруг проверок, тестов и явного контекста. Проигрывают те, кто просит «сделай красиво» и потом удивляется лишней сложности.
Второй эффект, который я вижу у клиентов, это экономия на переделках. Когда доменная модель и архитектурные решения фиксируются коротко, AI integration в пайплайн становится стабильнее: меньше повторных объяснений, меньше дрейфа решений между итерациями.
И главный вывод мне тут вообще не кажется тревожным для разработчиков. Нет, это не выглядит как «ИИ заменит всех». Это выглядит как усилитель для тех, кто умеет держать рамку, а не как замена инженерного мышления.
Если у вас команда уже пишет код с Claude, Cursor или похожими инструментами, но результат плавает от отличного до странного, я бы начал именно с таких рельс. А если хотите собрать это в нормальный рабочий процесс без шаманства, в Nahornyi AI Lab мы как раз помогаем выстроить AI automation так, чтобы бизнес получал предсказуемую скорость, а не еще один источник хаоса.