«AI даёт 100x в разработке». Эту фразу слышно из каждой ленты.
На практике большинство команд получили 0x. Не потому что AI не работает — а потому что полноценная интеграция AI-агентов требует менять процессы внутри команды. Любые процессные изменения болезненны: принятие, притирка, ошибки, откат, новая итерация. Месяцы. Это отдельная большая тема — про неё я пишу отдельно.
Эта статья — про другой путь.
Год назад я мягко встроил AI в свои проекты и в проекты, где консультирую. Процессы команды не трогал. Скорость выросла. Делюсь тремя приёмами, которые сработали.
Вектор: от простого к сложному
AI широк. Учить всё сразу не нужно и нельзя.
Маршрут такой: сначала три точечных приёма на уровне инструмента — никакой команде это не мешает, никто никого не ждёт. Когда привычка устаканится — идёте дальше: переиспользуемые процедуры (skills), компактная обвязка вокруг модели (thin harness), полноценные agents. К ним вернёмся в конце.
Эта статья — про первый шаг. Три приёма для трёх позиций: разработка, QA, продукты с админкой.
Приём 1. Спецификация раньше кода — spec-driven разработка
В чём идея. Модель пишет код заметно лучше, когда задача сформулирована до начала кодинга. Не «давай сделаем фичу», а «вот спека: что, зачем, как — теперь реализуй».
Инструмент. GitHub Spec Kit — открытая утилита для spec-driven разработки. Она оформляет цикл из четырёх шагов:
/specify— описать что и зачем/plan— собрать технический план/tasks— разбить на задачи/implement— реализовать
Работает поверх Claude Code, Codex, Cursor и Copilot. Внутри команды никто не обязан про неё знать — это инструмент конкретного разработчика.
Что меняется. Вы перестаёте «программировать в чате». Сначала формулируете требование, получаете план, проверяете глазами — и только потом отдаёте AI в реализацию. Меньше переписываний, меньше расхождений между задуманным и сделанным.
Скорость растёт не оттого что AI печатает быстрее. А оттого что вы не выкидываете в корзину каждую вторую попытку.
Кому. Разработчику. Особенно — на задачах от средней сложности и выше.
Приём 2. MCP — даём AI доступ к рабочим инструментам
В чём идея. AI-ассистент по умолчанию работает в своей песочнице. Дайте ему доступ к Jira, базе, метрикам и логам — болталка превращается в рабочий инструмент.
Инструмент. MCP (Model Context Protocol) — стандарт, по которому AI-ассистенты подключаются к внешним системам. Под него уже есть готовые серверА для всех ключевых инструментов разработки.
Что я использую и что это даёт:
Jira MCP. «Возьми описание проблемы из чата → собери валидный тикет с acceptance criteria, шагами воспроизведения и проверкой».
Тикеты становятся понятнее. Не потому что разработчики научились писать лучше. А потому что AI не ленится дописать критерии приёмки и шаги воспроизведения. Менеджер, аналитик, разработчик — каждый ставит у себя, никто никого не ждёт.
Postgres MCP. «Подготовь БД к тест-кейсу 1».
AI читает описание кейса, накатывает нужное состояние таблиц, после прогона — «сбрось обратно».
Тестирование не занимает часы и дни — занимает минуты, потому что создание и сброс тестовых данных делается быстро.
Grafana / Kibana / Victoria Metrics MCP. «Достань p95 latency сервиса checkout за последние 24 часа и сравни с предыдущей неделей». «Найди ошибки в логах сервиса payments за последний час и сгруппируй по типу».
Сам пока не пробовал — но в теории жить должно стать проще дежурным и саппорту. Не нужно держать в голове синтаксис каждой системы: описываете задачу словами, AI собирает запрос, вы проверяете результат.
Что меняется. Контекст рабочей системы перестаёт жить только в голове человека. Часть рутины — формулировка запросов, сборка тикетов, сидинг данных — уезжает в AI. Процесс команды тот же. У каждого исполнителя просто стало меньше переключения контекста.
Кому. Разработчикам, QA, дежурным, тимлидам. Каждая роль настраивает свой набор MCP-серверов под свои задачи.
Оговорка. Доступы к production системам — это вопрос безопасности и приватности. Начинать стоит со стейджинга и тестовых окружений. Production-доступы — отдельный разговор внутри команды.
Приём 3. DESIGN.md — генерируем интерфейс админок без дизайнера
В чём идея. Дизайнерский ресурс ценный и ограниченный. Тратить его нужно там, где живёт целевой пользователь — на основном продукте. В админках, бэк-офисах, операционных панелях целевого пользователя нет. В лучшем случае там сидит оператор поддержки или контент-менеджер.
Просить дизайнера придумать каждую внутреннюю страницу — нерациональная трата ресурса. Но собирать админку «как получится» — значит каждый раз изобретать стиль заново и получать визуальный беспорядок.
Инструмент. Файл DESIGN.md в репозитории — спецификация дизайн-системы продукта. Что в нём:
- палитра цветов и токены
- типографика: размеры, начертания, межстрочные
- сетка, отступы, радиусы
- состояния компонентов: hover, disabled, focus, error
- паттерны: формы, таблицы, модалки, фильтры, состояния пустоты
- примеры существующих экранов как референс стиля
Дизайнер собирает эту спеку один раз — буквально за день-два, опираясь на уже существующий продукт. Дальше разработчик пишет AI задачу: «сделай страницу управления пользователями с поиском, фильтром по ролям и таблицей с пагинацией — стиль возьми из DESIGN.md».
AI генерирует интерфейс в том же визуальном языке, что и основной продукт. Не идеальный, но связный и узнаваемый.
Что меняется. Дизайнер не отвлекается на каждую внутреннюю страницу. Команда разработки не блокируется в ожидании макета. Админки выглядят как часть продукта, а не как набор экранов из разных миров.
Кому. Продуктам, где есть админка, бэк-офис, операционные интерфейсы, внутренние дашборды — то есть почти всем зрелым продуктам.
Что объединяет три приёма
Все три встроены на уровне инструмента отдельного исполнителя. Не процесса команды.
- Никто не ждёт перестройки.
- Никто никого не блокирует.
- Эффект виден за дни, а не за кварталы.
- Каждый приём можно откатить за минуты, если не зашло.
Это и есть мягкая интеграция. Не революция, не «100x», не «AI заменит разработчика» — а три точки контакта, в которых AI снимает повторяющуюся рутину с конкретного исполнителя.
Бонус: spec-interviewer — челлендж спеки до плана
Speckit-цикл начинается с /specify. Но первая версия спеки всегда оставляет слепые зоны: непрописанный UX, не разобранные edge cases, не названные технические трейдоффы. Идти в /plan с такой спекой — значит получить план плотный по форме, но дырявый по сути.
Поэтому я добавляю один шаг между /specify и /plan — челлендж спеки. Под него у меня лежит небольшой скилл spec-interviewer.
Что она делает: читает файл со спекой, берёт AskUserQuestion и допрашивает меня неочевидными вопросами — про реализацию, UX, риски, трейдоффы — пока спека не уплотнится. Финал — переписанная спека обратно в файл.
Сама скилл 20 строк. Положите в .claude/commands/spec-interviewer.md:
---
allowed-tools: AskUserQuestion
argument-hint: [file]
description: Helps to develop a specification through non-obvious questions
model: claude-opus-4-7
disable-model-invocation: true
---
Read $1 and interview me in detail using the AskUserQuestion tool about literally anything
- Technical implementation details
- UI & UX
- Concerns
- Tradeoffs, etc.
**Always ask questions in Russian (на русском).** Every question text, option label, and option description passed to AskUserQuestion must be in Russian. Headers stay short (≤12 chars) but should also be Russian when natural. Reply to me in Russian throughout the interview and in the final spec write-up.
But make sure the questions are not obvious.
Be very in-depth and continue interviewing me continually until it's complete, then write me spec to the file.
Использование: /spec-interviewer specs/feature-x.md. Дальше — серия неочевидных вопросов (строка про русский язык — моя личная преференция, можно убрать).
Что меняется. В /plan идёт спека не «как мне показалось правильно», а «как пережила 5-10 неочевидных вопросов». Шансы попасть в реализацию с первого захода резко растут.
Куда дальше
Когда три приёма становятся привычкой — обычно через 1–2 месяца — появляется ощущение, что хочется большего. Это нормальный момент для следующего шага.
Дальше идёт более системный слой:
skills— переиспользуемые markdown-процедуры. Берёте повторяющийся приём (например, «напиши мне smoke-тесты, чтобы я проверил фичу руками перед тем, как отдавать QA»), оформляете как файл, AI вызывает его по запросу. Знание перестаёт жить только в голове.thin harness— компактная обвязка вокруг модели. Несколько правил, хуков, проверок и шаблонов, которые делают работу с AI воспроизводимой, а не разовой удачей.agents— AI с задачей, правилами, контекстом и инструментами, который выполняет работу по шагам. Не реагирует на каждое сообщение по отдельности, а ведёт работу.
Эта траектория — отдельная тема. Здесь важно одно: к агентам и harness-инженерии можно прийти через мягкую интеграцию. Не обязательно сразу перестраивать команду.
Итог
100x от AI — маркетинговое обещание этого месяца.
Реальное и стабильное ускорение на ежедневных задачах, без боли для команды, дают три приёма:
- spec-driven разработка через
speckit— ясность задачи до кода - MCP для рабочих систем — Jira, Postgres, Grafana, Kibana, Victoria Metrics в одном диалоге с AI
DESIGN.mdдля админок — интерфейс в стиле продукта без отвлечения дизайнера
Каждый встраивается на уровне инструмента отдельного исполнителя. Процессы команды не трогаем. Результат получаются за дни.
Когда привычка сформируется, можно говорить про skills, thin harness и agents. Но сначала — три простых шага.
Пробовали один из этих приёмов и где-то стопорилось? Напишите. Соберу типичные затыки в следующий материал.