Рабочий процесс ИИ-разработки: от вайбкодинга к инженерной дисциплине
Видео: Рабочий процесс ИИ-разработки
Набор скиллов Мэтта Покока построен вокруг знакомой проблемы: агенты быстро пишут код, но при слабой обратной связи проект становится сложнее менять. Время, сэкономленное на генерации, потом уходит на разбор технического долга.
В русском видео разбирается набор инженерных скиллов Мэтта Покока. Описанный в них процесс хранится в файлах и командах, поэтому одинаковые напоминания не приходится повторять в каждом запросе.
Что устанавливает скилл
Установщик skills.sh копирует инструкции, скрипты и вспомогательные файлы скилла в репозиторий. Для набора Мэтта Покока используется команда npx skills@latest add mattpocock/skills. Эти файлы хранятся вместе с проектом, и команда может менять их под свои правила.
Одни скиллы запускает только человек, например /grill-me. Другие агент может выбрать сам, когда задача соответствует их описанию. Так явные процессы остаются под контролем человека, а для повторяемых инженерных приемов не приходится каждый раз писать отдельный запрос.
Сначала выяснить требования
Скилл /grill-with-docs расспрашивает о предстоящем изменении до начала работы над кодом. Он уточняет требования, термины, пограничные случаи и нерешенные вопросы. Реализация начинается, когда требования понятны, а значимые решения зафиксированы в документах проекта.
Так снижается риск, что агент заполнит нерешенный вопрос первым правдоподобным ответом. Иначе код может выглядеть связным, но решать задачу, которую команда не ставила.
Память проекта должна жить вне чата
Длинный диалог плохо подходит на роль проектной документации. В CONTEXT.md хранится общий словарь команды и агента. ADR фиксируют архитектурные решения и причины их принятия. Отвергнутые варианты добавляются, только если их стоит запомнить.
В репозитории есть пример с термином “materialization cascade”, или “каскад материализации”. После точного определения в CONTEXT.md он заменяет целый абзац о создании файла для урока курса. Универсальной цифры экономии токенов здесь нет. Практическая польза в том, что следующей сессии не нужно заново читать полное объяснение.
Обсуждение должно стать понятной задачей
После ответов на вопросы /to-spec собирает разговор в одну спецификацию. Затем /to-tickets делит ее на небольшие сквозные задачи и записывает зависимости между ними. Для каждой задачи процесс рекомендует новую сессию.
Так работу проще передать дальше. Для следующей задачи агент запускается в новой сессии и явно читает CONTEXT.md, нужные ADR и спецификацию. Полная история реализации предыдущей задачи ему не нужна.
Проверка без объяснений автора
Скилл code-review отправляет изменения двум проверяющим параллельно. Один сравнивает их со спецификацией, другой с правилами проекта. Они работают в разных контекстах и не получают объяснения агента, который написал код.
Тесты задают еще одну проверяемую границу. Скилл tdd начинает с падающего теста, затем требует написать только код, необходимый для его прохождения. Прошедший тест не доказывает правильность всей спецификации, но дает проверяющему результат, который можно воспроизвести.
Источники: исходное видео на русском и mattpocock/skills на коммите bfdaef8.