Как менялась работа с AI-агентами: 4 этапа развития и что будет дальше

AI-агенты неизбежно развиваются, и это происходит по простой причине: бизнесу нужно быстрее принимать решения, дешевле выпускать продукты и делать меньше ошибок на повторяющихся задачах. За последние пару лет модели стали лучше понимать контекст, научились дольше держать фокус, могут аккуратнее следовать правилам и уверенно работать с инструментами. Это привело к смене привычки. Если раньше мы просили модель ответить на вопрос, теперь мы строим процесс и подключаем агента как участника команды с ролью, правилами и доступами.

Самое интересное в том, что прогресс идёт не только через рост качества моделей. Рывок дают методы работы. Структура промтов, правила проекта, инструменты, спецификации, автоматизация. То есть мы учимся управлять результатом, а не надеяться на вдохновение модели. В этой статье разберём, какие этапы мы прошли во взаимодействии с AI-агентами, и заглянем в недалёкое будущее. Чтобы было проще читать – сделали удобный словарь терминов.

Словарик AI-терминов

Модель LLM: Крупная языковая модель; основа для обработки и генерации текста.

Промпт: Входная инструкция или запрос для LLM, определяющий желаемый результат.

Токены: Базовые единицы текста (слова, части слов), используемые LLM для обработки информации и генерации ответов.

Контекст: Совокупность входных данных и предыдущих взаимодействий, которую LLM использует для формирования релевантного и связного ответа.

Окно контекста: Объем информации (текста), который LLM может одновременно обрабатывать и учитывать при генерации ответа.

Tools: Внешние программы или функции, которые модель может использовать для выполнения задач, выходящих за рамки её базовых возможностей (поиск в интернете, работа с API, консоль).

Агент: Программа на базе LLM, способная к автономным действиям, решениям и выполнению задач. Tools in a loop.

Skills: Предварительно определенные или обученные способности ИИ-агента, позволяющие ему эффективно решать определенные типы задач.

MCP: Протокол коммуникации агента с инструментами и другими агентами; правила обмена информацией и координации действий.

Мультиагент: Система из нескольких ИИ-агентов, взаимодействующих для решения сложных задач.

Plan mode: Режим работы ИИ-агента, при котором разрабатывает пошаговый план для достижения цели.

Workflow: Оптимизированный процесс создания ПО с помощью агентов. 

Этап 1. Первые попытки и интуитивный подход

На старте всё выглядело так: вы пишете промпт «как чувствуете». Что-то из серии сделай красиво, придумай стратегию, напиши ТЗ. Иногда получалось вау, иногда совсем мимо. Самая большая проблема была не в качестве текста, а в непредсказуемости результата.

Что происходило на практике:

• модель угадывала контекст вместо того, чтобы опираться на факты
• пользователь получал кардинально разные ответы на один и тот же запрос
• много времени уходило на ручную правку и уточнения.

Результат 1 этапа: пользователь получил дополнительный инструмент, который пока не давал стабильного результата, но порой мог помочь с вдохновением. До процессности здесь пока далеко, это ещё «Рубрика эээээксперименты».  

Этап 2. Системный промпт и появление структуры

Дальше команды быстро поняли простую вещь: моделью можно управлять, если задать рамки. Появился системный промпт как способ сделать результат предсказуемым. Этот этап состоял из 3 важных пунктов:

1. Определение роли. Чёткое указание контекста и экспертизы агента (вместо абстрактного «Сделай хорошо» начали задавать роль: «Ты сеньор-разработчик с опытом архитектуры систем...»)

2. Появление структурированных инструкций. Системные промты вводят последовательность действий, ожидаемый формат вывода и критерии качества. Это первый шаг к предсказуемости результатов. 

3. Учитывание контекста и прописывание ограничений. Явное определение границ задачи, технологического стека и требований к решению повышает релевантность ответов.

***

Важным моментом для команд стало внедрение кастомных правил под каждый проект. На уровне проекта правила создавали единообразие в кодовой базе и снижали когнитивную нагрузку на команду.

Например, к позитивным паттернам проекта можно отнести: 

• архитектурные принципы
• стандарты кодирования
• best practices для конкретного проекта.

К антипаттернам и запретам отнесём:

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

Результат 2 этапа: AI перестал быть лотереей и стал управляемым инструментом. За счёт роли, структуры и ограничений ответы стали стабильнее, ближе к задаче и заметно проще в применении. Команда начала получать не просто текст, а предсказуемый формат результата, который можно быстро проверить, согласовать и превратить в задачи. Параллельно появились проектные правила как общий язык для людей и агента. В итоге снизились разночтения, стало меньше переделок, и в кодовой базе появилось единообразие, которое экономит время на каждом следующем изменении.  

Этап 3. Эволюция системных промтов

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

1. Комитет и способы мышления вместо архаичных профессий

Вместо одного голоса появилось несколько перспектив:

• критик ищет риски и слабые места
• архитектор следит за целостностью решения
• исполнитель делает быстро и по шагам
• редактор приводит к ясному виду.

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

2. Открытая форма вместо закрытой

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

• есть ядро правил
• есть блок контекста
• есть задача
• есть требования к выходу.

3. Обязательный этап сонастройки

Перед большой задачей агенту дают прогрев

• уточнить вводные
• назвать риски
• предложить план
• согласовать формат результата.

Такая калибровка поведения агента перед основной работой резко повышает качество и снижает количество переделок.

Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

Заполнить заявку 13470 тендеров
проведено за восемь лет работы нашего сайта.

4. Этап проверки намерений

Появилась ещё одна полезная привычка: валидация целей и направления работы агента перед выполнение задач. 

Результат 3 этапа: системные промты перестали быть просто набором правил и превратились в управляемый процесс работы. Вместо одной заданной роли команды начали включать несколько способов мышления, как мини-команду в одном агенте. Параллельно промты стали модульными и гибкими, их стало проще переиспользовать и адаптировать под разные задачи без переписывания с нуля. А добавление обязательной сонастройки и проверки намерений перед выполнением работы убрало главную боль ранних этапов: агент перестал «бежать не туда».  

Этап 4. LLM-специфичные правила и разработка на основе спецификаций

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

Ключевая идея – не один универсальный промпт на всё, а набор модулей и файлов, которые подключаются к проекту и делают поведение агента стабильным именно в вашей среде. Создают экосистему знаний.

Набор практик на уровне проекта:

1. AGENTS.md и CLAUDE.md

Оптимизация под агента: структура тегов, длинные контексты. 

2. .cursor/rules

Конфигурация IDE: интеграция правил в процесс разработки.

3. css.md и typescript.md

Технологические спецификации: стандарты по языкам и фреймворкам. 

4. common.md

Общие принципы: кросс-проектные соглашения и паттерны.

Spec-Driven Development SDD

В какой-то момент пришло осознание того, что работа с агентом отлично ложится на один из давно существующих подходов – Spec-Driven Development. SDD трансформирует разработку через детальное документирование до старта физической реализации.Это в целом снижает хаос, потому что решение сначала становится понятным, проверяемым и согласованным, а уже потом уходит на реализацию.

Инструменты для использования SDD с AI 

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

Spec Kit – набор инструментов для создания и управления спецификациями.

OpenSpec – открытый стандарт описания системных требований.

GSD Framework – Get Spec Done как подход доводить спецификацию до реализации.

Cursor Memory Bank – интеграция знаний проекта в контекст AI-ассистента.

Результат 4 этапа: работа с агентами стала по-настоящему промышленной. Команды перешли от универсальных промтов к LLM-специфичным правилам, закреплённым прямо в проекте через набор файлов и модулей, технологических спецификаций и общих принципов, чтобы агент стабильно работал именно в вашей среде и накапливал знания как часть репозитория. Укрепился подход Spec Driven Development, при котором сначала создаётся проверяемая и согласованная спецификация, и только потом начинается имплементация с агентом, что снижает хаос и переделки.  

SDD workflow на примере Github Spec Kit

Шаг 1. Подготовьте среду разработки

Установите инструмент, следуя официально документации https://github.com/github/spec-kit. Данный пакет работает со всем популярными агентами и ассистентами.

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

Шаг 2. Запускайте основной процесс Spec Kit по шагам

1. speckit.constitution. Начните с конституции проекта. Это короткий документ с ключевыми принципами и рамками. Тут фиксируются архитектурные решения, ограничения, стандарты, подход к качеству, правила изменения требований. 
2. speckit.specify. Далее делается спецификация. На этом шаге вы описываете функциональность и требования так, чтобы их можно было проверить. Добавляете сценарии, роли, данные, интеграции, ограничения, критерии готовности. В хорошем виде это документ, который одинаково понимают бизнес, дизайнер и разработчик.
3. speckit.plan. После спецификации строится план. Агент или команда разбивает работу на этапы и зависимости, определяет порядок реализации, риски, точки контроля и артефакты на каждом этапе. На этом шаге удобно договориться про MVP и релизы.
4. speckit.tasks. Дальше план превращается в задачи. Каждая задача получает понятный результат и критерии приемки. Это снижает недопонимание и ускоряет разработку, потому что команда не угадывает что считать готовым.
5. speckit.implement. Только после этого начинается имплементация. Код пишется на основе спецификации и задач, с соблюдением правил проекта. Агент помогает генерировать код, тесты, документацию, но ориентируется на спецификацию как на источник правды.

Шаг 3. Используйте вспомогательные команды, когда нужно

1. speckit.clarify. Применяйте, когда вводные неполные или есть противоречия. Команда или агент задаёт вопросы, фиксирует ответы и обновляет спецификацию, прежде чем двигаться дальше.
2. speckit.analyze. Используйте, когда есть существующий код или архитектура. Команда оценивает текущее состояние, находит риски, предлагает варианты изменений и точки, где лучше не ломать.
3. speckit.checklist. Подключайте, чтобы держать качество. На выходе получаете чек-листы для ревью, тестирования и деплоя, привязанные к конкретной фиче и вашим стандартам.

Итог. Что получится на выходе если всё сделать правильно?

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

Самый практичный подход сейчас – использовать LLM-специфичные правила для максимизации качества AI-генераций, и Spec-Driven Development (SDD) в аналитических задачах.

Комбинация этих подходов обеспечивает баланс между гибкостью исистематичностью, позволяя эффективно решать сложные инженерные задачи с помощью AI-агентов. 

А что будет дальше? Этап 5. Агент как часть операционной системы компании

Если этап 4 про то, чтобы стабилизировать агента внутри проекта через правила и спецификации, то следующим логичным шагом будет этап, на котором AI-агент перестаёт «жить» внутри одного репозитория и становится частью корпоративного контура. Он работает не только с кодом, но и с процессами, знаниями и ответственностью, а качество обеспечивается не промтами, а инфраструктурой, правами и наблюдаемостью.

Что будет отличать этап 5?

1. Единая память и знания компании, а не отдельного проекта. Агент будет опираться на живой корпоративный граф знаний, где связаны продукты, клиенты, решения, ошибки, архитектурные выборы, инциденты, договорённости. Не папка с md файлами, а система, где знания обновляются автоматически из трекеров, репозиториев, документации и аналитики.
2. Агенты с полномочиями и управлением рисками. Появится чёткое разделение прав и зон ответственности. Агент сможет выполнять действия сам, но в рамках политики доступов, лимитов и трассировки. Всё, что критично, будет требовать подтверждения человека, как в банковских платежах.
3. Наблюдаемость и управляемость, как у продакшн сервиса. У агентов появятся метрики качества, стоимости и времени, логирование решений, причины ошибок, контроль дрейфа, автосигналы о деградации. Будет видно, где агент экономит время, а где генерирует шум и риски.
4. Стандартизация рабочих процессов уровня компании. Workflow станет не локальным соглашением команды, а стандартом. Спеки, планы, задачи, тесты, релизы и документация будут собираться в единую цепочку, где агент выполняет часть работы, но результат проходит встроенные проверки и понятные гейты.
5. Мультиагентные фабрики под функции бизнеса. Не один универсальный агент, а «цеха» из специализированных агентов под продажи, поддержку, аналитику, разработку, безопасность, контент. Они будут собирать результат совместно, проверяя друг друга, и выпускать готовые артефакты отчёты, спецификации, изменения в коде, релизы, обновления базы знаний.

Вывод

Мы уже продвинулись в работе с AI-агентами так далеко, как никто не рассчитывал. И в ближайшем будущем неизменно наступит момент, когда AI-агент станет не просто помощником в чатике и даже не ускорителем разработки, а управляемым слоем компании, который снижает стоимость операций и повышает скорость изменений при контролируемых рисках. 

Если вы хотите подготовиться к этому уже сейчас, двигайтесь в сторону единого источника данных по каждому проекту, строгих правил изменений, инструментов контроля качества и прозрачных workflow. Тогда переход от этапа 4 к этапу 5 будет естественным, а не болезненным. А мы как и всегда будем сопровождать вас в этом и делиться практиками реальной IT-компании.

Больше полезного про разработку для бизнеса в нашем тг-канале Свои в IT – подписывайтесь, чтобы быть в курсе всего, что нужно знать заказчику!