# Мэтт Покок: почему спецификации убивают код, а ИИ-агентам нужен тормоз

Источник: https://www.youtube.com/watch?v=Z8lf5oWKfj0&feature=youtu.be
Канал: Nate Herk | AI Automation
Опубликовано: 16.10.2026

---

В эпоху стремительного развития генеративного искусственного интеллекта традиционное написание кода вручную уступает место оркестрации автономных агентов. Эксперт по TypeScript Мэтт Покок в беседе с Нейтом Херкельманом рассказал, почему фундаментальные инженерные практики стали важнее синтаксиса, как правильно выстраивать рабочую среду для ИИ-разработчиков и почему популярная концепция разработки на основе спецификаций (Spec-Driven Development) оказалась тупиковой на практике.

## ⚡ Переломный момент: от скептицизма к 300 коммитам в день
[[JUMP:01:50]]

Мэтт Покок самостоятельно освоил программирование и писал код вручную около десяти лет, из которых порядка восьми лет занимался этим профессионально [02:07]. На протяжении долгого времени он относился к хайпу вокруг искусственного интеллекта с глубоким недоверием, сравнивая первые волны генеративных инструментов с шумихой вокруг Web3 и криптовалют [07:17]. Переломной точкой для инженера стал релиз модели Opus 4.5 и появление инструмента Open Claw в декабре 2025 года [02:19]. 

Именно тогда качество работы автономных агентов преодолело порог практической полезности. По словам Покока, в этот момент он принял принципиальное решение: больше не писать ни единой строчки кода руками [02:19]. 

Масштаб изменений в повседневной работе разработчика:

*   В период ручного программирования продуктивным результатом считалось создание порядка 20 коммитов за рабочий день [31:41].
*   После перехода на делегирование задач агентам суточный объем коммитов в GitHub-репозиториях вырос до 200–300 [31:41].
*   Вместо самостоятельного написания функций Покок управляет четырьмя параллельными агентами, перед каждым из которых ставит долгосрочные цели, выступая в роли руководителя команды разработчиков [31:03].

## 🛠️ Среда решает всё: почему важна культура кодовой базы
[[JUMP:04:24]]

Ключевая проблема взаимодействия человека с большими языковыми моделями заключается в коммуникационном барьере [04:42]. Модель не способна читать мысли инженера и не знает по умолчанию, какие аспекты архитектуры или функционала являются приоритетными [04:55]. Если запустить ИИ-агента в запущенный, неструктурированный репозиторий, результат окажется плачевным: модель начнет воспроизводить низкокачественные решения [05:20].

По убеждению Покока, наилучший результат достигается через системную подготовку рабочего окружения [05:07]. Инженер проводит аналогию с управлением штатом из ста живых программистов: чтобы поднять базовый уровень самого слабого специалиста, компания выстраивает строгие процессы и внедряет стандарты качества [05:48]. Классические книги по архитектуре программного обеспечения двадцатилетней давности сегодня звучат актуальнее, чем когда-либо [06:00].

Инструменты создания поддерживающей среды для ИИ-агентов:

*   Написание надежных автоматических тестов, моментально блокирующих некорректные архитектурные отклонения [06:12].
*   Внедрение линтеров и аудитов кода для отсечения целых классов типовых ошибок [06:25].
*   Оснащение агента инструментами обратной связи: например, предоставление возможности взаимодействовать с браузером через клики и анализировать скриншоты работающего интерфейса [33:21].

## 🧭 Предметно-ориентированное проектирование и «допрос» агента
[[JUMP:14:55]]

Одной из фундаментальных сложностей проектирования систем Мэтт Покок считает концепцию «неизвестных неизвестных» (unknown unknowns) — скрытых требований, о которых разработчик или заказчик изначально даже не задумывается [16:35]. Если не озвучить эти детали явно, ИИ-агент либо додумает архитектурные решения самостоятельно, либо проигнорирует ключевые аспекты безопасности и деплоя [17:42].

Для решения этой проблемы Покок создал специализированный навык под названием «Grill Me» [17:02]. Рабочий процесс устроен следующим образом:

1. Разработчик формулирует общую задачу или идею нового функционала.
2. Агент в рамках сценария «Grill Me» начинает методично и непрерывно задавать пользователю уточняющие встречные вопросы [17:02].
3. В ходе диалога вскрываются скрытые ограничения, нюансы безопасности и граничные случаи до того, как будет написана первая строка реализации [17:15].
4. С помощью расширенной версии «Grill with Docs» формируется структурированная проектная документация [24:52].

В основе этого метода лежит классическая методология предметно-ориентированного проектирования (Domain-Driven Design, DDD) [23:49]. Покок настаивает на внедрении «единого языка» (Ubiquitous Language): бизнес-сущности (например, сущность «Заказ») должны называться абсолютно одинаково в пользовательском интерфейсе, базе данных, программном коде и в устном диалоге с заказчиком [24:14]. Синхронизация понятий исключает критические расхождения между замыслом и реализацией [24:39].

## ❌ Крах Spec-Driven Development: почему спецификации не заменили код
[[JUMP:26:03]]

На конференции AI Engineer Шон Гроув из компании OpenAI выступил с популярным тезисом: «Спецификации — это новый код» [26:46]. Сторонники этой теории утверждают, что программистам больше нет нужды работать с исходным кодом: достаточно детально описывать требования в текстовых документах (спецификациях), а генерацию и обновление кодовой базы целиком возложить на нейросети [27:00].

Мэтт Покок попытался применить разработку на основе спецификаций (SDD) к собственному масштабному проекту — кастомному видеоредактору со встроенными ИИ-инструментами генерации сценариев и обложек, напоминающему Descript [27:38]. Инженер экспериментировал с методологией несколько месяцев, но результат оказался отрицательным [28:16].

Причины отказа от разработки на основе спецификаций:

*   Качество кодовой базы неуклонно деградировало по мере накопления скрытых компромиссов [28:04].
*   Агент выдавал все менее стабильные результаты, пытаясь интерпретировать разрастающуюся документацию [28:04].
*   Спецификация отрывалась от реальности, тогда как именно исходный код является непосредственной средой обитания агента [28:29].

По итогам эксперимента Покок вернулся к парадигме, в которой код остается главным артефактом [28:29]. Хорошая кодовая база, по его определению, обязана быть максимально легкой для внесения изменений, где любая правка агента не способна разрушить непредусмотренные связи [28:55].

## ⚙️ Настройки и модели: почему высокий уровень усилий вредит
[[JUMP:30:48]]

В техническом стеке Мэтта Покока центральное место занимает связка из консольного клиента Claude Code и флагманской модели Opus 5.5 [32:06]. При этом эксперт придерживается контринтуитивного подхода к параметрам рассуждений: большинство пользователей выкручивают параметр усилий (effort level) на максимум, полагая, что долгие размышления нейросети всегда улучшают ответ [32:19].

Покок использует Opus 5.5 строго на среднем уровне усилий (medium effort) и рассматривает переход на низкий (low effort) [32:31]. Логика разработчика опирается на следующие факторы:

*   Низкий уровень усилий обеспечивает значительную экономию токенов и ускоряет отклик системы [32:31].
*   Если кодовая база оснащена строгими тестами и проверками типов, модели не требуется тратить вычислительные ресурсы на глубокие абстрактные размышления [32:43].
*   Ошибки мгновенно отлавливаются средой исполнения, а не предотвращаются дорогостоящими рассуждениями [32:43].

Параллельно Покок тестирует мета-навык «Chief of Staff» («Руководитель аппарата»), который распределяет задачи между подчиненными под-агентами, создавая виртуальную команду из восьми инженеров под единым контролем [31:16].

## 🪜 «Лестница доверия» и практический старт для нетехнических специалистов
[[JUMP:35:27]]

Для новичков и разработчиков, испытывающих тревогу перед масштабом ИИ-инструментов, Покок рекомендует концепцию «лестницы доверия», сформулированную разработчицей Лорен Тан (известной в соцсетях под псевдонимом Potato) [36:31]. 

Главная ошибка начинающих — немедленно поручать автономным системам глобальные задачи или слепо доверять сгенерированному тексту. Процесс освоения технологии должен напоминать обучение вождению:

1. **Освоение тормоза:** прежде чем давить на газ, необходимо научиться вовремя останавливать агента, чтобы не исчерпать лимиты запросов и не допустить повреждения файлов [36:56].
2. **Изолированный старт:** создание чистой пустой директории, запуск редактора кода (например, VS Code) и передача агенту одной атомарной задачи [37:09].
3. **Пристальный контроль:** наблюдение за каждым шагом и действием агента в терминале, формирование интуитивного понимания границ его возможностей [37:47].
4. **Постепенная автоматизация:** подключение внешних API, автоматизация повседневной рутины (списков задач через голосовые заметки смарт-часов, сортировки входящей почты Gmail) [38:24].

Покок категорически не согласен с распространенным советом технологических лидеров — Илона Маска, Сэма Альтмана и Бориса Черны — отдавать моделям самые амбициозные и сложные цели [39:41]. По мнению эксперта, агентам следует поручать самую скучную, механическую работу: подготовку черновых ответов на письма, форматирование данных и рутинные скрипты [40:06]. В этих сценариях результат легко измерить, а цену возможной ошибки можно легко нивелировать [40:18].

## 🔮 Будущее индустрии: «фабрики софта» и открытые модели
[[JUMP:41:31]]

Размышляя о горизонте развития технологий, Мэтт Покок признается, что скептически относится к футурологическим прогнозам кремниевой долины, предпочитая фокусироваться на инструментах, работающих прямо сейчас [42:00]. Главным технологическим вызовом ближайших лет он называет создание «фабрик программного обеспечения» (software factories) — полностью автоматизированных пайплайнов, способных инициировать проекты и поддерживать качество репозиториев на дистанции [42:50].

Сегодня агенты плохо справляются с долгосрочным планированием структуры проектов: они склонны выбирать быстрое решение проблемы в ущерб качеству архитектуры [43:02]. Покок стремится научить агентов вести себя как консервативные старшие инженеры, требующие соблюдения стандартов ради будущих поколений разработчиков [43:15]. 

Вторым мощным драйвером трансформации инженер видит развитие моделей с открытым исходным кодом [43:40]. Появление открытой альтернативы, сопоставимой по качеству с Opus 5.5 и обладающей высокой эффективностью расходования токенов, кардинально изменит ландшафт независимой разработки ПО [43:53].