Агентная разработка с LLM: ускорение появляется не из магии, а из процесса

LLM уже не просто автодополнение

Первое знакомство разработчиков с LLM часто происходило через формат “умного автодополнения” или чата для вопросов. Модель могла дописать функцию, объяснить ошибку, предложить регулярное выражение, набросать тест. Это уже было полезно, но оставалось похоже на более быстрый справочник или помощника рядом с IDE.

Агентный подход меняет масштаб взаимодействия. LLM начинает работать не только с отдельным вопросом, а с задачей. Он может читать проект, искать связанные файлы, строить гипотезы, предлагать план, менять код, запускать проверки и возвращаться к задаче после ошибки. Разработчик перестает общаться только с “ответчиком” и начинает управлять рабочим циклом, в котором модель действует внутри инженерного контура.

Это важный сдвиг, но его легко неправильно понять. Агентная разработка не означает, что появился автономный программист, которому можно отдать задачу и забыть о ней. Скорее, появился новый способ организовать часть инженерной работы. Код действительно начинает появляться быстрее, но скорость генерации сама по себе не гарантирует результата. Настоящий выигрыш появляется там, где есть ясная постановка задачи, понятные границы, проверка и человек, который понимает, что именно принимает.

Что я называю агентной разработкой

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

Это не обязательно связано с конкретным продуктом или средой. Важен сам паттерн: задача, контекст, действие, проверка, корректировка. Разработчик задает намерение и ограничения. Агент исследует систему, предлагает путь, вносит изменение или готовит план. Затем результат проверяется: тестами, чтением diff, запуском приложения, ревью, сравнением с требованиями. Если что-то не сходится, цикл повторяется.

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

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

Пять практических эпизодов

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

Nullable Reference Types: агент как инструмент оценки масштаба

Первым примером стала задача оценки огромного монолитного проекта на возможность перехода к Nullable Reference Types. Это не та задача, которую хочется начинать «вслепую»: изменение затрагивает не одну фичу и не один модуль, а фактически весь способ работы с контрактами, null-значениями и предупреждениями компилятора.

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

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

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

Выгрузка данных: когда агенту не хватает карты проекта

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

Пока не была описана общая логика проекта через AGENTS.md, агент пытался решать задачу максимально в лоб. Он сразу формировал CSV, пропускал существующий контекст выгрузки, повторно загружал данные и фактически обходил те механизмы, которые уже были заложены в системе. Формально он двигался к результату: «нужно выгрузить данные — значит, надо собрать данные и записать CSV». Но с точки зрения проекта это было неправильное направление, потому что решение нарушало существующие границы разработки.

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

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

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

Но даже когда решение стало функционально правильным, качество кода оставалось средним. Попытки улучшить его общими командами вроде «сделай чище», «приведи к принципам чистой архитектуры», «раздели ответственность» давались агенту тяжело. Он либо делал слишком поверхностные правки, либо начинал менять не те границы. Часть кода пришлось переписывать руками, а часть — править через очень конкретные инструкции.

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

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

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

Расчет рейтингов: фича с ИИ от ТЗ до продакшена

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

Первый этап — написание ТЗ с помощью ИИ — показал ограничение, которое потом повторялось и в разработке. Модель легко генерирует длинный документ, но не всегда хорошо держит приоритеты. В тексте появлялось много воды, второстепенные детали могли получать такой же вес, как ключевые правила расчета, а важные ограничения приходилось вытаскивать и уточнять руками. В результате стало понятно, что ИИ полезен для черновика и структурирования, но не заменяет аналитическую работу по выделению главного.

Зато на этапе проектирования UI агент оказался очень полезен. За несколько часов удалось быстро договориться, как должна выглядеть форма: какие поля нужны, как пользователь загружает CSV, где видит результат, какие состояния должны быть на экране. ИИ генерировал HTML, команда смотрела на реальный результат, обсуждала его и сразу уточняла следующий вариант. Это сильно ускорило разговор, потому что обсуждалась не абстрактная формулировка в ТЗ, а видимый интерфейс.

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

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

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

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

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

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

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

Миграция интеграционных тестов на Testcontainers: где мультиагентный подход оказался не бесплатным

Следующий эксперимент был уже осознанно мультиагентным. Задача была знакомой: миграция интеграционных тестов на использование Testcontainers. Раньше похожую работу уже приходилось делать руками в другом проекте, поэтому было понимание, из каких этапов она состоит, где могут быть риски и какой результат в итоге нужен. Именно поэтому задачу захотелось решить не одним агентом, а через мультиагентный подход.

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

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

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

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

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

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

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

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

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

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

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

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

Собственный MCP-сервер на Roslyn: когда один агент оказался эффективнее мультиагентной схемы

После опыта с мультиагентной миграцией интеграционных тестов захотелось проверить другую гипотезу: можно ли экономить токены и улучшить поиск по C#-коду через MCP-сервер на Roslyn. Идея была практичной: вместо того чтобы каждый раз искать по файлам и читать лишний контекст, дать агенту инструмент, который понимает структуру решения, символы, проекты и связи в коде.

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

Для реализации был подготовлен план проекта с нуля, полностью под выполнение силами ИИ. Этот план уже учитывал предыдущий опыт с мультиагентами. Он был оптимизирован под более аккуратную схему: ревью запускалось только в критических местах, а отчет субагента иногда сводился к короткому результату вроде «тесты зеленые». Не было идеи ревьюить каждый маленький шаг отдельным агентом, потому что предыдущий опыт показал, насколько дорого стоит постоянная синхронизация.

Разработка шла итеративно. Сначала цель была минимальной: MCP-сервер через stdio, который умеет загрузить проект и с которым агент может успешно взаимодействовать. Это позволило быстро проверить базовую гипотезу: можно ли вообще встроить Roslyn-анализ в агентный рабочий процесс. Через несколько часов появилось полноценное рабочее решение: сервер запускался, загружал проект, отвечал на запросы, и агент мог использовать его как инструмент для анализа кода.

После этого стали видны ограничения первого варианта. stdio-модель была удобна для старта, но плохо подходила для сценария, где сервер нужно заранее поднять, дождаться индексации большого репозитория и потом быстро отдавать результаты. Поэтому следующим шагом сервер был переписан под HTTP stream. Это изменило модель использования: сервер можно запустить отдельно, дать ему время на загрузку и индексацию, а затем обращаться к уже готовому инструменту без повторного старта тяжелого процесса.

Итоговый код получился рабочим, но по качеству я бы описал его как среднестатистический GitHub-проект. Он решал задачу, был покрыт тестами, его было удобно автоматически ревьюить, но архитектура оставалась довольно прямолинейной. Много статичных классов и методов, мало выразительных границ, минимум архитектурной глубины. Это не был плохой код, но он был «заезженный»: функциональный, понятный, местами механический, без ощущения хорошо выстроенного внутреннего дизайна.

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

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

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

Сравнение с MCP-сервером Rider тоже оказалось полезным. Кастомный MCP-сервер в базовых сценариях работал не хуже: он мог находить нужные элементы кода, использовать Roslyn-контекст и помогать агенту точнее ориентироваться в проекте. Но у Rider было больше готовых инструментов, шире набор возможностей и зрелее интеграция.

Самый важный вывод был про экономию токенов. Оказалось, что поиск по файлам и поиск через MCP-сервер по затратам токенов примерно сопоставимы. Основной потребитель токенов — не сам поиск, а чтение содержимого найденных классов. Даже если инструмент точнее находит символ, агенту все равно нужно читать код, чтобы понять поведение, зависимости и контекст изменения.

Но у MCP-сервера есть другой важный плюс: точность результата. Обычный поиск по файлам иногда приводит к «мертвым» или неиспользуемым участкам кода. Агент тратит время и токены на анализ файлов, которые формально совпадают с запросом, но не участвуют в реальном сценарии. Roslyn-инструмент лучше понимает структуру проекта и связи между символами, поэтому чаще приводит к релевантному месту. Это не обязательно радикально снижает расход токенов, но повышает качество навигации.

Главный урок этого эксперимента для меня такой: инструменты вокруг агента важны, но они не отменяют стоимость понимания. MCP-сервер может точнее привести агента к нужному коду, но дальше все равно начинается самая дорогая часть — чтение, интерпретация и проверка. А мультиагентность стоит применять только там, где работа действительно делится на независимые атомарные части. Если задача требует цельной линии проектирования, один сильный агент может оказаться быстрее, дешевле и надежнее.

Что повторилось во всех кейсах

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

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

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

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

Наконец, почти во всех кейсах решающим становился быстрый способ проверки. Тесты, smoke-check, понятная команда запуска, критерии приемки, карта связанных модулей, понятные тест-кейсы для нестандартной бизнес-логики — все это превращает агентный diff из догадки в проверяемое изменение. Без этого агент ускоряет не поставку ценности, а производство вариантов, которые еще нужно долго разбирать.

Как я вижу трансформацию роли разработчика

Самое заметное изменение не в том, что разработчик пишет меньше кода руками. Это следствие, но не суть. Суть в том, что меняется центр тяжести работы.

Разработчик все чаще формулирует намерение, а не набирает каждую строку. Он задает границы задачи: какие файлы можно менять, какие контракты нужно сохранить, какие сценарии важны, как проверить результат. Он читает не только код, который написал сам, но и diff, который предложил агент. Он оценивает не только синтаксис, но и предположения, стоящие за изменением.

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

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

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

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

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

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

Как должна меняться организация кода

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

Первое изменение — файлы должны становиться более ограниченными по контексту. Большие универсальные модули, где смешаны бизнес-логика, интеграции, валидация, маппинг и побочные эффекты, плохо подходят для агентного процесса. Агенту сложнее понять границы изменения: где можно править, а где начинается неявный контракт. Чем больше файл, тем выше шанс, что модель ухватит локальный фрагмент и пропустит важную связь.

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

Второе изменение — проекту нужны базовые маршруты для понимания системы. В обычной разработке многое передается устно: «начинай смотреть отсюда», «эта папка отвечает за платежи», «этот слой лучше не трогать без ревью». Для агентной разработки такие маршруты лучше делать явными. Это могут быть короткие README в ключевых директориях, архитектурные заметки, описание основных потоков данных, соглашения по слоям и границам модулей.

Идея простая: агент не должен каждый раз заново угадывать карту проекта. У него должны быть точки входа. Где начинается обработка запроса. Где лежит доменная логика. Какие модули считаются стабильными. Какие части legacy требуют особой осторожности. Какие тесты запускать после изменения конкретного участка. Такая навигация полезна и людям, но с агентами ее ценность становится еще выше.

Третье изменение — у каждого важного участка должен быть быстрый способ проверить работоспособность решения. Если агент внес изменение, недостаточно посмотреть, что код выглядит правдоподобно. Нужен короткий путь к проверке: конкретный тест, команда, сценарий, локальный smoke-check, минимальный набор действий для подтверждения гипотезы.

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

В итоге агентная разработка подталкивает проект к более явной архитектуре. Меньше неформальных знаний, больше видимых границ. Меньше больших файлов, где все связано со всем. Больше локальных контекстов, понятных маршрутов и быстрых проверок. Это не только помогает LLM-агентам работать точнее. Это делает кодовую базу здоровее для самой команды.

Как меняется роль аналитика и подход к техническому заданию

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

Агент очень быстро превращает формулировку в действие. И если формулировка размыта, он так же быстро превращает размытость в код. Там, где человек-разработчик мог остановиться и спросить: «А что здесь имеется в виду?», агент может выбрать наиболее вероятную интерпретацию и уверенно пойти по ней. В результате проблема проявляется не как спор на этапе обсуждения, а как готовый diff, который выглядит осмысленно, но реализует не то поведение.

Поэтому аналитик в агентном процессе становится не просто автором требований, а человеком, который снижает неопределенность до уровня, пригодного для исполнения. Его задача — не описать «что нужно бизнесу» в общем виде, а подготовить задачу так, чтобы ее можно было безопасно отдать в разработку: человеку, агенту или их связке.

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

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

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

Поэтому хорошее ТЗ для агентной разработки должно отвечать на несколько вопросов. Как понять, что задача выполнена? Какие сценарии нужно проверить вручную или тестами? Какие существующие сценарии не должны измениться? Какие ограничения системы важны для реализации? Где находятся связанные участки продукта или кода? Какие спорные решения уже приняты, а какие еще требуют обсуждения?

При этом ТЗ не должно превращаться в огромный бюрократический документ. Скорее наоборот: оно должно быть компактнее, но точнее. Меньше общих формулировок, больше проверяемых условий. Меньше «сделать удобно», больше «в таком состоянии пользователь видит это действие, в таком — не видит». Меньше надежды на то, что разработчик сам достроит недостающий смысл, больше явных решений там, где раньше оставалась серая зона.

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

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

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

Хороший аналитик в такой системе помогает команде не просто «загрузить агента работой», а дать ему правильную рамку. Он превращает бизнес-ожидание в проверяемую инженерную задачу. А это становится одним из ключевых условий, при котором LLM действительно ускоряет разработку, а не просто быстрее производит варианты неправильного решения.

С ИИ проблемы процесса видны лучше

Один из самых интересных эффектов агентной разработки связан не с кодом, а с процессом.

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

Пока разработчик долго разбирался и писал вручную, многие проблемы процесса маскировались. Требования успевали уточняться по ходу дела. Спорные решения откладывались. Неясные договоренности растворялись в общем времени выполнения задачи. Казалось, что “разработка идет долго”, хотя часть задержки была не в кодинге, а в принятии решений и коммуникации.

Агентная разработка подсвечивает это. Если агент может быстро подготовить реализацию, но непонятно, какой вариант считать правильным, проблема не в скорости разработки. Если diff готов за час, а ревью зависает на несколько дней, узкое место смещается. Если агент задает вопросы, на которые команда не может ответить, это часто говорит не о слабости агента, а о слабости постановки.

В этом смысле LLM-агенты становятся диагностическим инструментом. Они показывают, где команда раньше компенсировала процессные проблемы ручной медлительностью. Ускорение кода не всегда сразу ускоряет поставку ценности. Иногда оно сначала показывает, что процесс не был готов к такой скорости.

Что из этого следует для разработчиков

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

Нужно лучше формулировать задачи. Не “сделай красиво” или “почини это”, а что именно должно измениться, какие ограничения есть, какие сценарии важны, как проверить результат. Нужно точнее дробить работу, потому что агенту проще помочь, когда задача имеет ясные границы. Нужно читать diff, а не только радоваться, что он появился.

Еще важнее становится умение замечать неверные предположения. Агент может быстро построить логичную цепочку, но разработчик должен понять, где эта цепочка опирается на неверный контекст. Иногда лучшая реакция на результат агента не “принять”, а “стоп, ты исходишь из предположения, которое в нашей системе не выполняется”.

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

Что из этого следует для тимлидов

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

Если дать людям доступ к LLM-агентам, но не договориться о процессе, результат будет случайным. Кто-то начнет использовать инструмент как ускоритель черновиков. Кто-то будет принимать слишком много сгенерированного кода без проверки. Кто-то, наоборот, будет относиться к агентам как к игрушке и не встроит их в работу. В итоге команда получит не процесс, а набор индивидуальных привычек.

Нужны новые договоренности. Как ставить задачи агенту. Какие изменения можно принимать только после тестов. Где обязательно читать diff. Когда уместно просить агента исследовать архитектуру, а когда лучше сначала обсудить решение с человеком. Как фиксировать принятые решения. Где проходит граница доверия.

Отдельно нужно договариваться о параллельной работе. Если несколько разработчиков с ИИ делают одну фичу, задача должна быть нарезана так, чтобы области изменений не мешали друг другу. Иначе ускорение одного участника превращается в ожидание, конфликты и повторное чтение чужого diff. Для тимлида это означает, что планирование фичи должно учитывать не только людей, но и связку «разработчик + агент» как более быстрый, но более шумный исполнитель.

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

Вместо заключения

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

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

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