Способности LLM писать код растут очень быстро. А вот инженерные практики вокруг них – заметно медленнее. Поэтому на рынке одновременно существуют две реальности.
В одной AI действительно ускоряет разработку: команда быстрее выполняет задачи, реже тонет в рутине и, что немаловажно, не проигрывает в качестве. В другой – тот же самый AI плодит тонны кода, который потом приходится дольше ревьюить, переписывать и отлаживать.
Именно поэтому главный вопрос сегодня состоит уже не в том, насколько мощную модель вы смогли себе позволить, а на каком уровне зрелости находится ваша работа с агентами.
Однако на пути к автоматизации становится заметнее другой тренд: AI выходит за пределы автодополнения и простого чата и движется в сторону более автономной работы. Но с ростом автономности ключевым становится уже не сам факт генерации кода и не интерфейс как таковой, а инженерный контур, в котором агент видит контекст задачи, понимает ограничения, проходит проверки и может оценивать последствия своих действий. На этом фоне меняется и роль самой IDE: она постепенно становится не просто местом редактирования кода, а рабочей средой, где агентами управляют и где им задают рамки для работы.
Удобную рамку из восьми уровней agentic engineering предложил Bassim Eledath: от tab completion и агентов в IDE до асинхронных AI-помощников и даже систем из нескольких AI-агентов:
1–2. Копилоты помогают быстрее писать и править код, но почти не меняют сам процесс разработки.
3. Инженерия контекста задает, какой контекст агент видит в конкретной задаче и в каких границах работает.
4. Накопление практик превращает удачные решения и типичные ошибки в постоянные артефакты команды.
5. Навыки и интеграции дают агенту оформленные способы работы и доступ к инструментам проекта.
6. Контур проверок подключает review, инспекции, ограничения и сигналы качества, чтобы агент видел последствия своих действий.
7. Фоновые агенты позволяют делегировать заметный блок работы, а не управлять каждым действием модели вручную.
8. Системы из агентов раскладывают работу между несколькими специализированными ролями вместо одного универсального ассистента.
Ниже разберем, как эта логика работает в реальной командной разработке и как она проявляется в Veai.
Почему вообще стоит говорить об уровнях
Когда в команде появляется AI, почти все сначала измеряют локальное удобство: быстрее ли пишется бойлерплейт код, помогает ли он быстрее разобраться в незнакомом API, легче ли накидать тест. Да, это полезно, но это далеко еще не вся эффективность команды.
Командная эффективность начинается там, где сокращается полный цикл работы: от постановки задачи до коммита, прошедшего проверки и не создающего лишний техдолг. Если AI нагенерил код, но при этом увеличил очередь на ревью, да еще и накидал спорных моментов, то вы просто перенесли нагрузку дальше по цепочке.
Именно поэтому идея уровней полезна. Так попросту становится проще отличить простую автоматизацию от настоящего инжиниринга.
Уровни 1–2. Копилоты: автодополнение и чат в IDE
Итак, начнем. Первые два уровня в наше время стали почти бытовухой.
Сначала был tab complete. Модель подсказывает следующую строку, добивает однотипные конструкции, экономит время на рутинных фрагментах. Затем пришел целый агент в IDE: чат прямо внутри среды разработки, который видит часть кодовой базы, умеет объяснять код, помогать с рефакторингом и предлагать изменения сразу в нескольких файлах. Именно так выглядит стартовая ступень зрелости почти у всех команд.
Почему этот уровень важен:
он снижает психологический барьер;
дает быстрый первый результат;
показывает, что часть рутины действительно можно отдать модели.
Но у него есть потолок.
Да, копилот ускоряет набор текста. Чат в IDE ускоряет отдельные операции. Но ни то ни другое само по себе не делает процесс предсказуемым. У вас, конечно, появится больше автоматизации, но одновременно и больше шума, спорных решений и мелких исправлений после агента.
Самая частая ошибка на этом этапе звучит примерно так: «мы уже внедрили AI». Внедрили. Но по факту команда просто научилась быстрее производить черновой код.
Уровень 3. Context engineering: агенту мало быть умным – ему нужно видеть правильное
Вот тут уже начинается настоящий инжиниринг.
Сегодня под context engineering обычно понимают не суперкруто проработанный промпт, а более широкую задачу: какую именно информацию модель видит, в каком виде, в какой момент и с какими ограничениями. Тот же Anthropic прямо описывает это как работу с оптимальным набором токенов и контекста, а вот Martin Fowler – как курирование того, что модель видит, чтобы получить лучший результат.
Для агентов, работающих с кодом, это обычно означает:
rules-файлы и системные инструкции;
описание архитектурных ограничений;
правила по стилю, тестам, библиотекам, безопасности;
ограничение того, какие части проекта агент вообще должен менять.
На самом деле это довольно недооцененный уровень. Большинство раздражающих ошибок агента возникает не потому, что с моделью что-то не так, а потому что ей либо не дали нужный контекст, либо дали слишком много мусора.
На этом уровне AI перестает быть универсальным помощником на все случаи жизни и начинает вести себя как инструмент конкретной команды с конкретной кодовой базой.
В Veai это поддерживается в том числе благодаря так называемому Edit Scope. Edit Scope ограничивает область, где агент вообще может править файлы:
Сюда же стоит отнести расширение контекста в части предоставления агенту доступа к инспекциям самой IDE: тем самым предупреждениям и замечаниям, которые сама среда показывает по коду.
Получается, что агент опирается не только на рассуждения модели, но и на встроенный анализ кода IDE, который помогает находить типовые проблемы и подозрительные места в коде.
И вот здесь происходит важный психологический сдвиг: разработчик перестает быть единственным файрволом качества.
Уровень 4. Compounding engineering: команда учится вместе с агентом
Если context engineering делает лучше текущую задачу, то compounding engineering делает лучше следующую, потом еще одну и еще одну. Здесь команда начинает не просто пользоваться агентом, а систематически превращать его ошибки и удачные решения в постоянные артефакты проекта.
Это один из самых важных поворотов в мышлении. Когда агент ошибся, можно просто поправить его руками и забыть. А можно превратить этот кейс в новое правило, skill, сценарий или ограничение. Тогда эта ошибка будет реже повторяться в будущем.
На практике compounding engineering выглядит так:
удачные подходы сохраняются в правилах (rules);
типичные ошибки превращаются в защитные ограничения;
все это хранится рядом с кодом, ревьюится и версионируется.
У Bassim Eledath этот уровень занимает отдельное место не случайно. Так он отделяет понятие «вроде прикольно помогает» от системного роста производительности.
Вот здесь уже появляется очень приятный для команды эффект, что AI начинает работать не только на скорость одного разработчика, но и на коллективную память.
Уровень 5. Переход от “агент понимает” к “агент умеет делать”
Следующий уровень – это момент, когда агент получает не только текстовый контекст, но и оформленные единицы поведения. Если уровни 3 и 4 отвечают за качество контекста и накопление практик, то уровень 5 отвечает уже за возможности агента.
Речь идет о MCP и Skills. Смысл в том, что агент перестает каждый раз изобретать способ работы заново и начинает опираться на переиспользуемые навыки и подключенные инструменты. MCP и кастомные Skills дают LLM доступ к вашей базе данных, вашему API, CI-пайплайну, дизайн-системе и прочему инструментарию, который может быть полезен на проекте.
В 5.5 мы представили Skills как полноценную поддержку открытого стандарта: они хранятся в проекте, переиспользуются между задачами и могут подключаться автоматически. Там же есть разделение между Rules, Skills и агентскими режимами, то есть между глобальными ограничениями, переиспользуемыми задачными инструкциями и ролями.
На этом уровне агент начинает быть инженерным исполнителем по принятым правилам. Чат можно попросить написать тесты. Skill`ы же позволяют закрепить, какие именно это должны быть тесты, в каком стиле, с какими ограничениями и каким ожидаемым результатом.
Уровень 6. Harness engineering: агент должен видеть последствия своих действий
Anthropic в материалах про long-running agents прямо пишет, что harness design – это ключевой фактор эффективности агентной разработки. Martin Fowler тоже описывает смещение роли человека. Здесь пользователь перестает контролировать каждую строчку и строит непосредственно сам контур, в котором агент работает, получает сигналы качества и корректирует поведение.
Проще говоря, хороший агент “хорошеет” не от изобилия свободы, а от качественной обратной связи.
На этом уровне в систему встраиваются:
автоматические проверки;
ограничения на область редактирования;
безопасные режимы работы;
сценарии дополнительной самопроверки до того, как изменения увидит человек.
В Veai мы постарались и над этим. У нас есть несколько режимов работы агента. Подробнее ознакомиться с ними можно тут. Но для наглядности мы рассмотрим 3 из них.
Например, режим Plan, в котором агент сначала показывает подробный пошаговый план выполнения запроса. План можно корректировать прямо в процессе, чтобы пользователь мог управлять ходом работы на каждом этапе. Такой режим особенно удобен, когда перед началом сложной задачи важно согласовать порядок действий – например, при миграции на новую версию фреймворка или разработке микросервиса с нуля.
Тот же самый Review-режим полезен в случаях, когда нужно проверить изменения, внесенные агентом или другим человеком. Агент может дополнительно запускать проверки на типичные антипаттерны – например, отслеживать, чтобы в try/catch не использовался слишком общий базовый тип исключения, такой как Throwable.
Конечно же, все изменения хорошо было бы отревьюить. Здесь уже нам на помощь придет режим Auto Review. Запускается отдельный чат с Review-агентом, в который передаются исходная задача пользователя и все изменения, внесенные агентом.
Если подытожить, то это уровень, когда агент не просто умеет действовать, а умеет получать backpressure и сам исправляться в рабочем контуре.
Отдельно стоит отметить Debug Mode из последнего релиза. Теперь агент умеет сам дебажить: ставит брейкпоинты, запускает код под отладкой, смотрит на состояние переменных и последовательно проверяет гипотезы о том, где именно возникла проблема. Иными словами, делает ровно то, что разработчик обычно делает руками каждый день.
Уровень 7. Background agents: не ассистент по запросу, а асинхронный исполнитель
Когда у вас уже есть правила (rules), навыки (skills) и feedback-loop, можно переходить к самому интересному: к фоновым агентам.
Это режим, в котором человек не ведет модель за ручку через каждую мелочь. Он формулирует цель, задает ограничения и ожидаемый результат, а дальше агент выполняет заметный кусок работы самостоятельно.
Именно такой этап Bassim выделяет как отдельный уровень – background agents. Не потому, что это эффектно выглядит на демо (хотя так оно и есть), а потому что здесь меняется сама единица делегирования. Теперь мы просим не дописать метод, а сделать некий осмысленный пул работы и вернуть результат.
На практике это может быть:
подготовка миграции;
повышение уровня покрытия тестами;
генерация и ревью документации;
локальный рефакторинг модуля;
подготовка PR с отчетом о сделанных шагах.
Согласитесь, это очень приятный уровень зрелости, потому что именно он впервые дает ощущение того, что AI не просто помогает кодить, а реально снимает часть инженерной нагрузки.
Уровень 8. Системы из агентов: следующий шаг, к которому индустрия только подбирается
Наконец, последний уровень – автономные агентные системы. Это уже не один универсальный агент, а набор специализированных ролей: один генерирует, другой проверяет, третий документирует, четвертый следит за ограничениями. Такой контур все чаще обсуждается как естественное продолжение развития agentic coding.
На 7-м уровне тоже могут быть разные агенты с разными ролями, но ими все еще управляет центральный orchestrator или человек.
Здесь же агенты:
координируются друг с другом напрямую,
распределяют задачи,
передают находки,
договариваются о зависимостях,
решают конфликт без постоянного присутствия человека.
Очень хорошо. Однако рынок пока что только подбирается к этому уровню. Но сама траектория уже хорошо видна, ведь чем лучше у команды оформлены правила, навыки, роли, границы доступа и feedback-циклы, тем легче ей перейти от одного ассистента в IDE к модульной системе агентов.
Мы, конечно, следим за трендами. Это можно заметить по уровню архитектурных шагов последних релизов. Например, мы предоставляем пользователю возможность добавлять свои режимы работы агента:
Говорить о полноценной команде автономных агентов пока было бы слишком смело, но это направление у нас уже вышло за пределы экспериментов. Мы отлаживаем сабагентов на реальном коде и уже получаем очень неплохие результаты. Сабагенты будут выглядеть примерно так, но подробнее о них поговорим в следующих статьях.
Вместо вывода
Если совсем упростить, логика роста такая: сначала AI помогает писать код, затем начинает видеть кодовую базу, потом получает правильный контекст, затем учится на прошлых сессиях, после этого получает доступ к инструментам, дальше — контур самопроверки, потом — возможность выполнять целые куски работы в фоне, а в перспективе — координироваться с другими агентами как часть общей системы.
И здесь важно не сделать ложный вывод.
Да, рынок движется в сторону более автономных агентов. Но сама по себе автономность еще не гарантирует результат. Для команды важнее другое: есть ли у нее управляемый инженерный контур, в котором агент получает правильный контекст, работает в заданных границах, проходит проверки и накапливает практики между сессиями.
Мы видим, что IDE в эпоху agentic engineering постепенно перестает быть просто местом, где человек пишет код. Она превращается сразу в две вещи – в центр управления агентами и в harness для их работы. С одной стороны, разработчик работает уже не только с кодом, но и с самими агентами: запускает их, распределяет задачи, следит за их состоянием и управляет выполнением. С другой – агент получает не абстрактную свободу, а полноценный инженерный контур с доступом к проверкам, отладке, рефакторингам и другим инструментам качества.
Именно поэтому в Veai мы делаем ставку не на абстрактную “самостоятельность ради самостоятельности”, а на среду, где агентная разработка становится управляемой инженерной практикой. Для нас важно не просто дать модели возможность что-то сгенерировать, а собрать вокруг нее такой рабочий контур, в котором можно делегировать заметные куски работы, видеть состояние агентной системы и при этом сохранять контроль над качеством, последствиями и эволюцией изменений.
Но главный вопрос в конечном счете не в том, какой интерфейс использовать. Важнее, на каком уровне агентной инженерии находится ваша команда и какой следующий шаг даст вам не больше автоматизации, а больше реального результата.
Потому что между «AI пишет код» и «команда стала работать эффективнее» лежит пропасть. И наша задача как инженеров – построить через нее надежный мост.
