Всем привет!
Меня зовут Шадрин Дмитрий.
Хочу поделиться собственными наблюдениями и практическим опытом использования AI в производственной разработке.
За последний год вокруг искусственного интеллекта в разработке появилось огромное количество материалов.
Кажется, что каждую неделю появляется новая модель, новый IDE-плагин или очередной инструмент, который обещает ускорить разработку в несколько раз. Вокруг этой темы накопилось огромное количество обсуждений. Кто-то сравнивает качество генерации кода у разных моделей, кто-то пытается посчитать, сколько процентов работы разработчика можно автоматизировать уже сегодня, а кто-то всерьёз задаётся вопросом, останется ли профессия разработчика через несколько лет в её нынешнем виде.
Эта тема вызывает много споров, эмоций и ожиданий.
Но, наблюдая за тем, как подобные инструменты используются в реальной разработке, я всё чаще прихожу к мысли, что самое интересное происходит совсем не там, где принято искать.
На мой взгляд, главный эффект современных AI-инструментов заключается не в генерации кода.
Самые серьёзные изменения происходят в работе с контекстом.
Современные AI-инструменты начинают автоматизировать задачи анализа требований, навигации по кодовой базе, поиска архитектурных зависимостей и оценки влияния изменений (impact analysis). Именно это сегодня начинает менять сам подход к инженерной работе.
Я с большим интересом наблюдаю за всеми этими дискуссиями. Мне самому близка тема инженерных инструментов.
За последние годы я успел поработать в разных компаниях, на разных ролях и с очень разными системами.
Сейчас я занимаюсь развитием корпоративных систем для оптовой торговли, франчайзинговых партнёров и интеграции с маркетплейсами в компании SM Lab. До этого был опыт работы в финтехе Яндекса, где приходилось проектировать и запускать сервисы, работающие под высокой нагрузкой и в условиях серьезных регуляторных ограничений.
Именно этот опыт заставляет меня смотреть на AI немного под другим углом.
Когда речь идёт о производственной разработке, особенно в больших системах, вопрос скорости написания кода далеко не всегда является главным. Гораздо важнее понимать, как изменение повлияет на систему, какие риски появятся после релиза, какие сервисы и бизнес-процессы будут затронуты. Фактически речь идёт о постоянном выполнении impact analysis ещё до начала реализации. Поэтому чем больше я работаю с современными AI-инструментами, тем сильнее убеждаюсь в одной простой мысли.
Самое интересное сегодня происходит не в генерации кода. Самое интересное происходит в работе с контекстом.
Почему написание кода занимает меньшую часть рабочего времени
Если посмотреть на разработку глазами начинающего инженера, может показаться, что основная работа программиста заключается в написании кода.
Действительно, на старте карьеры именно код занимает большую часть внимания. Нужно изучить язык программирования, разобраться с фреймворками, научиться писать поддерживаемые решения и понимать устройство системы.
Но по мере роста сложности проектов происходит любопытная вещь.
Количество времени, которое разработчик тратит непосредственно на написание кода, начинает уменьшаться.
Вместо этого появляются другие задачи.
Прежде чем открыть IDE и начать что-то реализовывать, нужно разобраться в требованиях. Часто задача приходит сразу из нескольких источников. Часть информации находится в Jira, часть в Confluence, что-то обсуждалось в комментариях, а какие-то важные детали существуют только в головах коллег.
После этого необходимо восстановить контекст самой системы. Нужно понять, какие сервисы участвуют в процессе, какие интеграции используются, как проходят бизнес-сценарии между компонентами, какие контракты API существуют между системами и какие архитектурные ограничения уже были приняты ранее. Дальше начинается проектирование. Даже если задача кажется относительно небольшой, всё равно приходится принимать решения. Где лучше реализовать изменение? Какой из вариантов развития системы выбрать? Что произойдёт через полгода, если сейчас пойти самым быстрым путём?
И только после этого начинается реализация.
На практике оказывается, что написание кода — это лишь один из этапов инженерного процесса. Причём далеко не самый дорогой с точки зрения времени.
Что происходит, когда в процесс приходит AI
Большинство разработчиков знакомы с AI в формате кодовых ассистентов.
Подсказки в IDE, автодополнение, генерация функций по комментариям — всё это уже стало привычной частью рабочего процесса. Но такие инструменты по-прежнему работают на уровне отдельных фрагментов кода. Разработчик остаётся главным исполнителем. Он определяет архитектуру, ищет нужные места в проекте, принимает решения и вручную связывает между собой все части контекста. Агентный подход работает иначе. Здесь инструмент начинает взаимодействовать не с отдельным файлом, а с задачей целиком. Он может изучить документацию, проанализировать кодовую базу, построить граф зависимостей между компонентами, найти связанные сервисы и подготовить карту потенциально затронутых областей системы.
На мой взгляд, именно здесь начинается самое интересное. Потому что большая часть времени разработчика уходит не на набор текста на клавиатуре, а на понимание системы.
Контекст как главная проблема больших проектов
Чем больше становится система, тем дороже обходится восстановление контекста. В распределённых системах эта стоимость дополнительно растёт из-за большого количества сервисов, интеграций, событийных потоков и накопленного технического долга.
В небольшом сервисе разработчик способен удерживать практически всю архитектуру в голове. Он знает основные сценарии работы, понимает структуру данных и быстро ориентируется в кодовой базе.
В больших продуктах ситуация совершенно другая.
Даже опытному инженеру приходится регулярно восстанавливать знания о системе. Нужно вспоминать, какие сервисы участвуют в процессе, где находятся нужные точки интеграции, какие ограничения существуют на уровне инфраструктуры и какие компромиссы были приняты раньше.
Во время подготовки доклада я решил посмотреть, насколько хорошо современный агент способен выполнять подобную работу.
Для экспериментов я использовал собственный pet-проект Hedgehog. Это небольшая система управления задачами, которая служит для меня площадкой для изучения технологий, архитектурных подходов и различных AI-инструментов.
Перед агентом была поставлена довольно простая задача.
Я попросил его не написать код и не исправить ошибку.
Я попросил его разобраться в системе.
Результат оказался гораздо интереснее, чем я ожидал.
Вместо поверхностного описания проекта агент начал восстанавливать архитектурную картину. Он определил основные сервисы, выявил зависимости между модулями, проанализировал используемые технологии, исследовал точки интеграции через REST API и восстановил основные бизнес-потоки системы. и даже начал подсвечивать архитектурные риски.
Например, обратил внимание на использование общей базы данных между сервисами, что создает высокий уровень связанности (coupling), указал на дублирование моделей данных и отметил потенциальные риски синхронного взаимодействия через OpenFeign.
Фактически я получил не просто обзор проекта, а первый черновик архитектурного анализа системы.
Именно в этот момент я впервые поймал себя на мысли, что польза инструмента заключается совсем не в генерации кода.
Польза заключается в том, что он помогает быстрее восстанавливать контекст.
Почему хороший промпт похож на хорошую постановку задачи
Одна из первых вещей, которую понимаешь при работе с агентами, заключается в том, что качество результата напрямую зависит от качества исходной постановки.
Сегодня термин «промпт-инжиниринг» успел обрасти большим количеством мифов. Иногда складывается впечатление, что существуют какие-то специальные секретные формулы, которые позволяют получать идеальные ответы от модели.
На практике всё гораздо прозаичнее.
Хороший промпт очень напоминает хорошую постановку задачи внутри команды разработки. Если аналитик приносит задачу в духе «сделайте фильтрацию», то разработчики неизбежно начнут задавать уточняющие вопросы. Какие поля участвуют в фильтрации? Как должны комбинироваться условия? Что делать при отсутствии данных? Как это повлияет на существующие сценарии?
С агентами происходит ровно то же самое.
Когда задача сформулирована поверхностно, результат получается таким же поверхностным. Когда в постановке появляется бизнес-контекст, ограничения, описание существующей архитектуры и ожидаемый результат, качество ответа начинает расти очень заметно.
В какой-то момент я поймал себя на мысли, что работа с агентами очень сильно напоминает работу с опытным инженером, который только пришёл в команду. Он способен решать сложные задачи, но для этого ему нужно предоставить достаточное количество контекста. Поэтому главный навык при работе с современными AI-инструментами — это не умение писать красивые запросы. Главный навык заключается в умении формулировать задачу таким образом, чтобы система могла принять правильное решение.
И это, если задуматься, всегда было одной из ключевых компетенций сильного инженера.
Что происходит, когда агент получает доступ к требованиям
Следующий интересный эксперимент был связан с анализом требований.
В большинстве реальных проектов информация распределена между множеством источников. Часть знаний находится в Jira. Часть — в Confluence. Какие-то детали зафиксированы в архитектурной документации. Некоторые договорённости вообще существуют только внутри командных обсуждений.
Когда разработчик получает новую задачу, ему приходится самостоятельно собирать единую картину из большого количества разрозненных источников.
Это занимает время.
Именно на этом этапе современные агенты начинают показывать интересные результаты. Особенно если им предоставить доступ не только к репозиторию, но и к Jira, Confluence или другим источникам знаний через MCP (Model Context Protocol).
Во время экспериментов я предоставлял агенту доступ к постановке задачи и связанным материалам. Вместо того чтобы просто пересказать требования, он начинал анализировать их на наличие противоречий и пробелов.
В одном из примеров речь шла о реализации фильтрации данных.
После изучения требований агент сформировал список вопросов, которые обычно появляются у опытного разработчика или аналитика во время проработки задачи. Он обратил внимание на отсутствие описания логики объединения фильтров, указал на неоднозначности в поведении системы при пустых результатах и поднял вопрос о том, на каком уровне должна выполняться сама фильтрация.
Особенно интересно было наблюдать за тем, что многие из этих замечаний полностью совпадали с вопросами, которые обычно возникают во время командных обсуждений.
Фактически агент начал выступать в роли дополнительного участника процесса анализа.
Конечно, это не означает, что он способен заменить аналитика или архитектора. Но он способен очень быстро подсветить места, которые требуют дополнительного внимания.
Почему проектирование становится самым интересным этапом
На мой взгляд, именно проектирование сегодня становится той областью, где агентный подход приносит максимальную пользу.
Когда речь идёт о написании кода, польза достаточно очевидна. Инструмент помогает быстрее реализовать известное решение.
Но гораздо интереснее наблюдать за тем, как агент участвует в поиске самого решения.
В классическом процессе разработчик обычно рассматривает несколько вариантов реализации, сравнивает их между собой и выбирает наиболее подходящий. Этот процесс требует времени, потому что необходимо учитывать множество факторов одновременно. Нужно понимать архитектуру системы, знать существующие ограничения, учитывать производительность, сложность сопровождения и влияние на другие компоненты.
Во время экспериментов я начал использовать агентов именно как инструмент для обсуждения вариантов.
Вместо запроса «реализуй задачу» я просил подготовить несколько возможных решений и объяснить последствия каждого из них.
Результат оказался очень полезным. Агент формировал сравнительные таблицы, описывал преимущества и недостатки подходов, анализировал потенциальные риски и оценивал объём изменений. Важно понимать, что он не принимал решение за меня. Окончательный выбор всё равно оставался за инженером. Но сам процесс анализа стал происходить значительно быстрее.
Планирование как обязательный этап работы
Одна из проблем больших языковых моделей заключается в том, что по мере увеличения сложности задачи возрастает вероятность ошибок. Частично это связано с ограничениями контекстного окна модели, потерей деталей при длинных цепочках рассуждений и склонностью LLM делать правдоподобные, но неверные предположения.
Чем больше изменений необходимо внести в систему, тем выше риск потерять часть контекста или сделать неверное предположение.
Поэтому со временем я пришёл к выводу, что этап планирования нельзя пропускать. Перед тем как начинать реализацию, агент должен сформировать понятный и детализированный план действий. Он описывает последовательность изменений, показывает зависимости между этапами и объясняет, каким образом будет достигнут конечный результат.
Для человека такой план становится дополнительной точкой контроля. Появляется возможность проверить логику ещё до того, как изменения попадут в кодовую базу. На практике именно на этапе просмотра плана удаётся обнаружить значительную часть потенциальных проблем.
Иногда оказывается, что агент неверно понял задачу. Иногда выявляются архитектурные ограничения, которые не были учтены в первоначальной постановке. Бывают ситуации, когда предложенный путь оказывается избыточно сложным.
Чем раньше это происходит, тем дешевле обходится исправление. Поэтому планирование постепенно стало обязательной частью моего рабочего процесса.
Когда реализация превращается в управление процессом
Самое заметное изменение происходит после того, как агент переходит непосредственно к реализации. Традиционно разработчик сам определяет список файлов, находит необходимые точки изменений и вручную вносит все правки. При использовании агентного подхода часть этой работы начинает выполняться автоматически. Инструмент анализирует проект, определяет связанные компоненты, вносит изменения в код и при необходимости корректирует тесты. Со стороны может показаться, что разработчик постепенно исключается из процесса. На практике происходит противоположное. Роль инженера не исчезает. Она меняется.
Основное внимание начинает смещаться с механического написания кода на контроль процесса реализации. Разработчик оценивает предлагаемые изменения, проверяет корректность решений, контролирует архитектурную целостность системы и отвечает за конечный результат. Чем сложнее система, тем важнее становится именно эта часть работы.
Почему отладка выглядит иначе
Интересно наблюдать за тем, как меняется процесс поиска ошибок.
Во время одного из экспериментов после реализации фильтрации система начала вести себя некорректно. На первый взгляд всё выглядело правильно. Код компилировался, логика казалась корректной, но результат не соответствовал ожидаемому поведению.
После передачи контекста агент начал анализировать проблему. Он последовательно исследовал структуру данных, проверил работу репозиториев, изучил используемые типы и начал сопоставлять фактическое поведение системы с ожидаемым. В результате выяснилось, что причина заключалась в сравнении разных типов идентификаторов.
Подобная ошибка легко могла затеряться среди множества других гипотез. Вместо длительного ручного анализа удалось достаточно быстро локализовать проблему и понять механизм её возникновения. Конечно, такие примеры не означают, что агент всегда находит правильный ответ. Но они хорошо демонстрируют, насколько сильно сокращается время исследования проблемы.
Код-ревью как следующая точка применения AI
После завершения реализации начинается этап проверки изменений. Здесь агенты также начинают приносить заметную пользу. Во время ревью инструмент способен сопоставлять реализацию с первоначальными требованиями, анализировать архитектурные последствия изменений и искать потенциальные проблемы. Особенно полезно использовать такой подход в больших задачах, когда объём изменений начинает измеряться десятками файлов. Даже опытный инженер может упустить детали просто из-за объёма информации. Дополнительный анализ помогает снизить этот риск. Понимаем, что речь идёт именно о дополнительном уровне проверки. Финальное решение всё равно остаётся за человеком, как и прежде, именно инженер отвечает за качество системы.
Что всё это меняет в профессии разработчика
Если посмотреть на весь процесс целиком, становится очевидно, что современные AI-инструменты меняют не столько разработку, сколько характер работы разработчика.
Мы постепенно движемся от модели, в которой инженер большую часть времени пишет код, к модели, в которой инженер управляет знаниями, контекстом и процессом принятия решений. Код остаётся важной частью работы, но он перестаёт быть её центром.
Центром становится понимание системы, понимание бизнеса, понимание архитектуры, способность принимать решения в условиях неопределённости.
Именно поэтому я не разделяю популярную точку зрения о том, что AI заменит разработчиков. Наоборот, мне кажется, что по мере развития подобных инструментов требования к инженерному мышлению будут только расти. Потому что ответственность за понимание системы, за архитектуру и за качество конечного решения по-прежнему остаётся на стороне человека.
А значит, главным навыком разработчика будущего становится не скорость написания кода, а способность эффективно управлять контекстом: связывать требования с архитектурой, оценивать последствия изменений, принимать технические решения и проверять результаты работы интеллектуальных инструментов. И именно в этом направлении сегодня происходят самые интересные изменения.