Подготовка спецификации, acceptance criteria, декомпозиции и списка рисков с AI-агентом укладывается в 30-60 минут вместо одного-двух вечеров. Это самый стабильный выигрыш из этапов цикла разработки, который описал автор разбора на Хабре по опыту личных проектов. Агент хорошо находит противоречия в требованиях и сценарии, которые легко пропустить вручную.
С генерацией кода картина неровная. CRUD, API-интеграции, миграции, тесты и рефакторинг ускоряются примерно в 2,5-4 раза. Новая бизнес-логика и архитектурные решения - только в 1,3-1,8 раза, а в части случаев агент замедлял работу.
Цифры ниже отражают опыт одного разработчика на личных проектах, а не контролируемый эксперимент. Это ориентир для собственных замеров, отраслевым бенчмарком он не был.
Где AI-агенты реально ускоряют разработку: краткий ответ
Выигрыш от AI распределяется по этапам неравномерно, и это главное, что стоит помнить перед любыми оценками экономии времени.
| Этап | Ускорение по опыту автора | Что это значит на практике |
|---|---|---|
| Планирование | 30-60 минут вместо 1-2 вечеров | Спецификация, acceptance criteria, декомпозиция, черновик архитектуры, список рисков |
| Типовые задачи | примерно 2,5-4 раза | CRUD, API-интеграции, миграции, тесты, рефакторинг |
| Новая бизнес-логика и архитектура | примерно 1,3-1,8 раза | Иногда агент замедлял работу |
| Безопасность | замедление | Уязвимости приходится искать и устранять вручную |
Главная иллюзия продуктивности - ощущение, что агент написал 70-80% готового кода. Значительная часть времени уходит на понимание результата, исправления, интеграцию и проверку качества, и именно там выигрыш тает.
Безопасность стала главным узким местом. Даже в pet-проектах агенты регулярно предлагали SQL-инъекции, XSS, hard-coded секреты и некорректную обработку данных. К этому добавляются риски agentic-систем: prompt injection через входные данные, утечки через логи агентов и supply-chain риски зависимостей.
Что измерять вместо скорости генерации: время до рабочего, поддерживаемого и безопасного результата.
Планирование: самый стабильный выигрыш от AI-агентов
Рабочая последовательность выглядит так. Агент получает постановку задачи и готовит спецификацию, acceptance criteria, декомпозицию, черновик архитектуры и список рисков. Человек проходит по черновику, вычеркивает лишнее, дописывает контекст. После такого ревью план занимает 30-60 минут вместо одного-двух вечеров.
Почему здесь эффект устойчивый? Планирование - работа с текстом и структурой. Агент быстро перебирает варианты, находит противоречия между требованиями, предлагает edge cases и забытые сценарии. Пример: постановка на новую фичу описывает happy path, а агент возвращает список вопросов про пустые состояния, конкурентные запросы и поведение при ошибке внешнего API.
Соотношение усилий выгодное: человек тратит мало времени на проверку, но этот шаг определяет, сколько времени уйдет на код. Ошибка в acceptance criteria стоит дороже остального, потому что дальше размножается в коде, тестах и документации.
Генерация кода: где ускорение 2,5-4×, а где 1,3-1,8×
Разрыв между категориями задач объясняется просто. На типовых задачах у модели много паттернов в обучающих данных: CRUD-эндпоинт, миграция, обертка над внешним API, набор unit-тестов. Агент воспроизводит знакомую схему, и проверка занимает минуты.
Пример: сгенерировать CRUD-эндпоинт с валидацией и тестами получается быстро, потому что это стандартный шаблон. Проектирование новой доменной модели с агентами может занять больше времени, чем без них: приходится перепроверять связи, границы ответственности и переписывать предложенную структуру под существующий код.
На новой бизнес-логике ускорение падает до 1,3-1,8 раза, иногда уходит в минус. Причина в отсутствии контекста: агент не знает, как устроен проект, какие решения уже приняты и почему отвергнуты альтернативы. Каждый ответ приходится перепроверять целиком.
Иллюзия продуктивности: почему 70-80% кода - это обманка
Метрика «доля кода, написанного агентом» выглядит впечатляюще и ничего не говорит о скорости выпуска фичи. После генерации начинается работа, которую эта метрика не считает: чтение и понимание кода, поиск ошибок, приведение стиля к проекту, интеграция с существующими модулями, проверка качества.
Схематичный пример. Агент выдал модуль на 200 строк за пять минут. Дальше выясняется, что одно из решений не подходит архитектуре проекта, часть проверок пропущена, а два метода нужно переписать под принятые в проекте контракты. На разбор и правку уходит пара часов, и реальная экономия оказывается куда скромнее заявленной.
Есть и второй эффект: чем больше кода появляется без разбора, тем хуже команда понимает собственную кодовую базу. Этот механизм разобран в материале про когнитивную ловушку AI-агентов: скорость набора строк растет, а понимание системы падает.
Типичные ошибки агентов: что чаще всего ломается
Список повторяющихся дефектов из опыта автора разбора:
- несуществующие методы и API, о которых агент рассказывает уверенно;
- код, плохо вписывающийся в архитектуру проекта;
- пропущенные проверки и уязвимости;
- чрезмерно уверенные, но ошибочные объяснения собственных решений.
Самая коварная категория - последняя. Агент может предложить метод, которого нет в текущей версии фреймворка, и подробно объяснить, как он работает и какие параметры принимает. На ревью это выглядит убедительно, пока не проверишь документацию. Алгоритм проверки плана, diff и runtime-сценариев разобран в статье о том, почему важно проверять код, который пишет AI-агент.
Безопасность как главное узкое место AI-разработки
Безопасность стала главным ограничением скорости. Агенты регулярно предлагали небезопасные решения даже в pet-проектах, где нет требований комплаенса и внешних аудитов.
Классические уязвимости в сгенерированном коде
SQL-инъекция появляется, когда агент собирает запрос конкатенацией строк вместо параметризации:
query = "SELECT * FROM orders WHERE user_id = " + user_id
cursor.execute(query)XSS возникает там, где пользовательские данные попадают в DOM без экранирования:
element.innerHTML = userCommentHard-coded секреты агент оставляет прямо в коде, потому что так короче и работает сразу:
API_KEY = "sk-live-9f2c..."Четвертая категория - некорректная обработка данных: пропущенная валидация входа, отсутствие проверки прав, доверие к данным от клиента.
Специфические риски AI-агентов: prompt injection, логи, supply chain
Классических уязвимостей мало, потому что у агента есть собственный контур выполнения. Prompt injection через входные данные: инструкции злоумышленника попадают в текст, который агент читает как задачу, например в тело issue, комментарий или содержимое внешней страницы. Утечки через логи: агент может записать в лог полный запрос с токенами, персональными данными или внутренними путями. Supply-chain риски: предложенная зависимость может быть заброшенной, уязвимой или подмененной похожим по имени пакетом.
Эти риски определяются тем, как агент запущен: какие у него права, что попадает в логи, есть ли изоляция среды. Разбор этой части с чек-листом из семи шагов есть в материале про аудит безопасности AI-агентов.
Как выстроить защиту: security-checklist и отдельный security-ревью
Рабочая мера из опыта автора: security-checklist в skills агентов плюс отдельный security-ревью. Порядок проверок перед мержем:
- запросы к базе идут только через параметризацию, конкатенация строк запрещена;
- вывод пользовательских данных экранируется на стороне шаблона или фреймворка;
- в коде нет ключей, паролей и токенов, они берутся из переменных окружения и секрет-хранилищ;
- входные данные валидируются по схеме, права проверяются на сервере, а не на клиенте;
- новые зависимости проверяются на поддержку, возраст и известные уязвимости.
Критичные участки - безопасность, архитектуру и сложную бизнес-логику - автор всегда просматривает вручную, независимо от того, насколько уверенно агент объяснил свое решение. Общая рамка запуска агентов с разграничением прав и гейтами в CI/CD собрана в статье о том, как запускать AI-агентов в разработке без риска для продакшена.
Ревью и тестирование: как компенсировать отсутствие code review
В одиночной разработке нет полноценного code review, поэтому проверку приходится строить из нескольких независимых слоев:
- отдельный AI-ревьюер с правилами проекта, который ищет расхождения с архитектурой и контрактами;
- статический анализ, который ловит уязвимости и опасные конструкции;
- автотесты на основной сценарий и границы значений;
- property-based тестирование, которое проверяет инварианты на случайных данных.
Unit-тесты агенты пишут неплохо: они шаблонны и хорошо ложатся на знакомые фреймворки. Сложные сценарии и e2e требуют значительного участия человека, потому что там важны состояние окружения, порядок действий и данные, которых у модели нет.
Как правильно измерять продуктивность AI в разработке
Метрика, которую стоит взять за основу: время до рабочего, поддерживаемого и безопасного результата. Она включает генерацию, но не заканчивается на ней: считаются часы на понимание кода, исправления, интеграцию, тесты и устранение уязвимостей.
Пример арифметики. Агент сгенерировал код за 5 минут, но на доведение до рабочего состояния ушло 2 часа. Если без агента та же задача занимала 1,5 часа, ускорение отрицательное, хотя локально генерация выглядела мгновенной.
Второй уровень - переход от output eval к system eval. Первый проверяет только финальный ответ, второй оценивает весь путь системы до него. Для production-агентов этого требует автор разбора на vc.ru: правильный ответ модели сам по себе ничего не говорит о корректности работы системы.
Специфические риски agentic-систем: что скрывается за правильным ответом
Агент может дать верный финальный ответ, пройдя при этом неверный путь, и разбор на vc.ru описывает это как отдельный класс сбоев. Внутри агент мог выбрать не тот инструмент, передать неправильный ID, уйти не тому специалисту, сделать действие до подтверждения человека или повторить несколько ненужных вызовов.
Цепочка обработки запроса выглядит так: USER REQUEST → ROUTING → TOOL → ARGUMENTS → ACTION → HANDOFF → APPROVAL → FINAL RESULT. Почти каждый переход может сломаться отдельно, и финальный ответ об этом не сообщит.
Отдельный класс сбоев - ошибка boundary. Агент правильно подготовил действие, но выполнил его сразу, не остановившись на approval boundary и не дождавшись человека. Side effect произошел раньше, чем система получила право его сделать. Разница в эффективности тоже видна: один агент доходит до результата за четыре необходимых вызова, второй делает восемнадцать, перепроверяя одно и то же.
Инструменты из опыта автора: чем работали
Стек из опыта автора выглядит так: Cursor с Claude, GPT-4o и GigaCode для основной работы в редакторе, локальные Qwen2.5-Coder и DeepSeek-Coder через Ollama, LangGraph и OpenHands для более автономных задач.
Разделение по задачам простое. IDE-ассистенты вроде Cursor с подключенными моделями удобны для правок в контексте открытого проекта. Локальные модели через Ollama дают приватность и работу без сети, что важно для кода, который не хочется отправлять наружу, но качество на сложных задачах у них ниже. Фреймворки вроде LangGraph и OpenHands позволяют собирать более автономные сценарии, и именно там появляются риски из предыдущего раздела: лишние вызовы, выход за approval boundary, действия без проверки.
Категоричных рекомендаций тут нет: выбор зависит от того, сколько контекста проекта допустимо отдавать наружу, какие требования по приватности и сколько времени вы готовы тратить на ревью.
Выводы: ключевой навык - поставить задачу и строго проверить результат
Что дает опыт на личных проектах, если сжать его до нескольких пунктов:
- стабильный выигрыш - планирование: спецификация, acceptance criteria, декомпозиция, список рисков;
- типовые задачи ускоряются примерно в 2,5-4 раза, новая логика и архитектура - в 1,3-1,8 раза, иногда с замедлением;
- ощущение, что агент написал 70-80% готового кода, не выдерживает проверки временем;
- безопасность - главное узкое место, критичные участки нужно смотреть вручную;
- метрика - время до рабочего, поддерживаемого и безопасного результата.
Ключевой навык смещается в сторону постановки задачи и строгой проверки. Чем точнее сформулированы критерии приемки и ограничения, тем меньше времени уходит на переделку. И наоборот: чем туманнее задача, тем дороже обходится уверенный ответ модели.
Полезно померить свой цикл: взять одну типовую задачу и одну новую, зафиксировать время до рабочего результата с агентом и без. Такие замеры на своем коде дают больше, чем любые общие цифры, включая приведенные выше.