AI меняет не профессии. AI меняет процессы

Все вокруг обсуждают новые модели. За кофе, в лифте, на конференциях и в рабочих чатах сравнивают, какая лучше пишет код, какая точнее генерирует интерфейсы, какая быстрее думает и у какой больше контекстное окно.

Но чем больше я работаю с AI, тем меньше итоговый результат упирается в выбор модели. Разница между сильным и слабым результатом всё чаще находится уровнем выше — в том, как устроен процесс вокруг модели.

Модель — только один слой

Даже самая сильная модель начинает ошибаться, если не знает архитектуру проекта, использует устаревшую документацию или не понимает, где лежит источник правды. Она может сгенерировать аккуратный экран, но создать ещё одну кнопку вместо компонента дизайн‑системы. Может написать рабочий код, который не проходит внутренние правила команды. Может убедительно пересказать решение, которого никто не принимал.

Поэтому сегодня мне интереснее не только «какую модель выбрать», а другие вопросы:

как хранится и обновляется контекст проекта;
где находится память о решениях;
какие Skills подключены к агенту;
какие MCP‑серверы и рабочие системы ему доступны;
какие действия он может выполнить самостоятельно;
где обязательно требуется подтверждение человека;
чем проверяется результат перед тем, как он попадёт в продакшен.

Модель отвечает за способность рассуждать и генерировать. Процесс отвечает за то, чтобы это происходило на правильных данных, в допустимых границах и с предсказуемой проверкой.

Один специалист становится мультитулом

Раньше цифровой инструмент обычно усиливал одну часть профессии. Figma помогала дизайнеру проектировать интерфейсы, IDE — разработчику писать код, Jira — команде вести задачи. AI‑агент способен захватить целую последовательность действий: прочитать задачу, найти контекст, изменить файлы, запустить проверки и подготовить результат к ревью.

Из‑за этого меняется роль специалиста. Он не обязательно делает каждый шаг руками. Всё чаще он формулирует цель, собирает контекст, распределяет работу, задаёт ограничения и оценивает результат. Получается человек‑мультитул, который управляет сразу несколькими способами производства.

Это не значит, что один человек внезапно становится экспертом во всех профессиях. Наоборот: чтобы правильно поставить задачу и заметить ошибку агента, по‑прежнему нужна предметная экспертиза. Меняется не ценность знания, а точка его приложения — от ручного исполнения каждого шага к проектированию всей системы работы.

Не один универсальный агент, а несколько ролей

Один длинный промпт быстро превращается в кашу. В нём смешиваются постановка задачи, реализация, визуальная проверка, документация и тесты. Агенту приходится одновременно быть автором и ревьюером собственной работы.

Гораздо понятнее разделить процесс на роли:

Агент‑исследователь собирает контекст, находит существующие решения и формулирует ограничения.
Агент‑разработчик пишет код в рамках выбранной архитектуры.
Агент дизайн‑системы собирает интерфейс из реальных компонентов и токенов.
Агент‑ревьюер проверяет diff, правила, доступность и пограничные состояния.
Агент документации обновляет спецификации и примеры после изменения API.
Агент проверок запускает тесты, сборку и визуальное сравнение.

Не обязательно запускать шесть отдельных моделей. Важно само разделение ответственности: у каждого этапа есть конкретный вход, ожидаемый выход и критерий готовности. Тогда процесс можно улучшать по частям, а ошибку проще локализовать.

Как может выглядеть один такой процесс

Представим обычную задачу: добавить новое состояние в сложный компонент.

Первый агент читает задачу и связанные решения, находит компонент в коде и макет в Figma.
Он проверяет документацию дизайн‑системы, доступные токены и существующие паттерны.
Агент реализации меняет компонент и добавляет состояние, не создавая параллельный API.
Отдельная проверка сравнивает результат с макетом, ищет raw values и проверяет keyboard navigation.
Тестовый этап запускает type‑check, unit‑тесты, accessibility checks и сборку.
После успешных проверок обновляется документация компонента и формируется короткое описание изменений.
Человек просматривает решение, спорные места и финальный diff.

Ценность здесь не в том, что агент умеет написать JSX. Ценность в связанной цепочке, где контекст не теряется между этапами, а результат одного шага становится проверяемым входом для следующего.

Контекст становится инфраструктурой

Для такой работы недостаточно каждый раз вставлять в чат кусок задачи. Агенту нужна карта проекта: структура репозитория, принятые решения, API компонентов, правила именования, команды проверки и границы допустимых изменений.

Часть этого контекста статична и может жить рядом с кодом:

AGENTS.md или project rules с картой репозитория;
документация дизайн‑системы и компонентов;
машиночитаемые токены;
Skills с повторяемыми рабочими сценариями;
тесты и линтеры, которые формализуют ограничения.

Другая часть постоянно меняется: статусы задач, решения со встреч, ответственные и актуальные цели. Её нельзя один раз записать в Markdown и забыть. Нужен живой слой рабочей памяти, который собирает данные из исходных систем и возвращает их со ссылками и датами.

Именно поэтому я параллельно делаю Halo: хочу проверить, как один контекстный слой может помогать и человеку, и агенту.

Skills превращают опыт в повторяемый сценарий

Промпт часто остаётся одноразовой инструкцией. Skill — это попытка упаковать рабочий способ решения задачи: когда его применять, какие источники прочитать, в какой последовательности действовать, что считать готовым результатом.

Например, Skill для изменения компонента может требовать сначала найти существующие варианты, затем проверить токены и доступность, а после реализации запустить определённый набор тестов. Это не делает агента безошибочным, но убирает необходимость заново объяснять один и тот же процесс в каждом чате.

Последние недели я как раз занимаюсь такой инфраструктурой: собираю LLM‑ready документацию, описываю правила дизайн‑системы, пишу Skills и проверяю их в Cursor и Claude Code на реальных проектах.

MCP связывает рассуждение с рабочими системами

Документации в репозитории недостаточно, если задача зависит от Figma, Tracker, Wiki или результатов сборки. MCP‑серверы дают агенту стандартизированный доступ к инструментам и данным: он может не только прочитать заранее подготовленный текст, но и получить актуальную структуру макета, найти задачу или вызвать разрешённое действие.

Но больше подключений не всегда означает лучший процесс. Для каждого инструмента нужно определить:

какие данные агент может читать;
какие изменения он может вносить;
что требует явного подтверждения;
как наследуются права пользователя;
где сохраняется источник выполненного действия;
что произойдёт при ошибке или неполных данных.

Без этих границ агент с большим количеством инструментов становится не полезнее, а опаснее и менее предсказуемым.

Предсказуемость важнее красивого демо

Почти любую современную модель можно эффектно показать на одной заранее выбранной задаче. Гораздо сложнее добиться, чтобы процесс стабильно работал на десятках обычных задач команды.

Для этого нужны обратные связи:

автоматические проверки кода и интерфейса;
evals на реальных сценариях;
ссылки на источники в ответах;
наблюдаемая история действий агента;
понятный handoff человеку;
разбор ошибок и обновление правил после них.

Хороший AI‑процесс не обещает, что модель никогда не ошибётся. Он делает ошибку заметной, ограничивает её масштаб и не позволяет ей незаметно пройти дальше.

Что особенно меняется в дизайне

В дизайне это видно особенно хорошо. Уже недостаточно попросить модель «нарисовать экран». Она должна понимать структуру продукта, использовать реальные компоненты, знать паттерны, работать с семантическими токенами и учитывать состояния, доступность и адаптивность.

Дизайн‑система при этом становится не только библиотекой для людей, но и интерфейсом для агентов. Чем яснее описаны компоненты, решения и ограничения, тем меньше агент импровизирует там, где команде нужна консистентность.

Поэтому работа над AI‑ready дизайн‑системой — это не попытка заменить дизайнера. Это способ сделать накопленный опыт команды доступным в новом рабочем процессе.

Новый базовый навык

Скоро умение пользоваться AI, вероятно, станет таким же базовым навыком, как работа в Figma, IDE или Jira. Сам факт использования модели перестанет отличать сильного специалиста.

Отличие будет в другом: умеет ли человек собрать контекст, разложить работу на роли, определить границы автономности, подключить нужные инструменты и построить проверку результата. То есть спроектировать процесс, в котором человек и несколько агентов работают как одна система.

AI меняет не только набор инструментов внутри профессии. Он меняет сам способ, которым производится работа. И именно этот уровень сейчас кажется мне самым интересным.