Привет! Меня зовут Евгений, я инженер в JetBrains.
Долгое время я занимался разработкой Rider - IDE для .NET: от первых обсуждений идеи в 2014 году до роли тимлида команды в последние годы. Да-да, можете ругать меня в комментариях и в личке за те самые баги, которые висят открытыми по 7 лет ?
В середине прошлого 2025 года я оставил позицию тимлида Rider и перешёл в команду IntelliJ AI. Последнее время я много работаю с AI-агентами и агентской разработкой - мы занимаемся их интеграцией в IDE. Было бы странно не пробовать такие инструменты в реальной работе.
Агенты уже умеют делать «настоящую» работу
Сегодня передовые агенты способны решать реальные задачи в по-настоящему больших проектах. Буквально на днях Claude Code написал для меня почти рабочую фичу, на которую раньше я бы потратил два-три дня.
Нужна ли мне после этого IDE? Однозначно да. Рано или поздно наступает момент, когда приходится открыть сгенерированный код, внимательно его прочитать, поставить брейкпоинт и нажать старую добрую кнопку "Start Debugging".
То, что меня по-настоящему беспокоит - это соблазны, которые подстерегают нас по пути.
От написания кода - к его описанию
Работа программиста сейчас постепенно смещается от написания кода к беглому описанию задачи и последующему ревью огромных диффов.
Код сам по себе - это максимально точное описание наших намерений. В процессе его написания мы неизбежно обнаруживаем логические противоречия, неявные допущения, несостыковки в требованиях и архитектуре, а также краевые случаи, о которых изначально не задумывались. Это важнейшая часть процесса разработки, а не какой-то сайд-эффект.
В агентской разработке же появляется сильный соблазн: описать не реальную задачу со всей ее сложностью, а лишь поверхностное намерение - в надежде, что агент «додумает остальное» сам. Очень хочется верить, что одного короткого промта достаточно, чтобы получить желанный результат.
Но сложность программных систем никуда не девается. Код сложен не потому, что его исполняет машина, а потому что задачи, которые мы решаем, сложны, неоднозначны и полны скрытых допущений. Когда мы пишем код вручную, мы вынуждены сталкиваться с этой сложностью напрямую.
Ревью как акт веры
Допустим, агент сгенерировал новую фичу - ура! Но много ли вы знаете людей, которые искренне радуются ревью с диффом +2600 / −1400? А если таких ревью несколько в день?
В какой-то момент ревью перестаёт быть про понимание и превращается в акт веры: пролистать изменения, убедить себя, что «вроде всё нормально», и нажать большую синюю кнопку "Push".
Единственное, что стоит между мной и этой кнопкой - ответственность.
Ответственность никуда не исчезает
В обоих этих соблазнах - и в упрощенном описании задач, и в поверхностном ревью - есть общее. Они предлагают нам переложить ответственность: на инструмент, на модель, на умного агента - в обмен на скорость.
Но ответственность никуда не исчезает. Она всё ещё остаётся на нас, на инженерах. Именно мы будем разбираться с последствиями, которые когда-то «просто сгенерировались».
Я не считаю агентскую разработку злом. Напротив, это крутой инструмент. Вопрос в том, как сохранить нашу инженерную дисциплину в условиях, когда писать код стало значительно легче, чем его по-настоящему понять.
Вместо вывода
Возможно, в ближайшие годы изменится роль IDE и инструментов разработки - от ускорения написания кода (куда уж быстрее то) к помощи в осмыслении изменений, снижении когнитивной нагрузки и поддержке осознанных решений. Есть ощущение, что 2026 год будет для нашей профессии очень интересным.
Никаких ссылок на каналы не будет. С праздниками!
Комментарии (13)
poruchik
05.01.2026 14:03Допустим, агент сгенерировал новую фичу - ура! Но много ли вы знаете людей, которые искренне радуются ревью с диффом +2600 / −1400? А если таких ревью несколько в день?
В какой-то момент ревью перестаёт быть про понимание и превращается в акт веры: пролистать изменения, убедить себя, что «вроде всё нормально», и нажать большую синюю кнопку "Push".
Я часто практикую кросс-ревью другими моделями. В приципе, и та же самая, что делала доработку запросто может найти баги в своем же коде через 5 минут после его написания, но чем больше разных моделей посмотрит код, тем лучше. Это касается только объемных МР-ов, которые сам так легко не проверишь.
Небольшое лирическое отступление - любая статья или коммент про ЛЛМ-разработку в положительном ключе на хабре сразу получает кучу минусов. Мне аналогично заходят и тупо ставят минусы в карму. Из некогда передовой площадки он превратился в заповедник луддизма, поэтому публиковать подобные статьи здесь, просто нет смысла.
gabirx
05.01.2026 14:03Интересно, а как относится топменеджмент к этому? Знаю случаи , когда требуют от всех писать агентов...
evgeniy_kudinov
05.01.2026 14:03Аналогичные ощущения. Попробовал с 0 с помощью агента Crush CLI + Deepseek несложный CLI-чат AI реализовать, проверить, как будет процесс проходить. Если не следить, то может в тупик зайти и приложение почти рабочее сделать. Пришлось несколько раз дебагером пройтись и прекращать креативность агента, вручную исправляя неточности. Но всё равно вместо нескольких дней заняло несколько часов и без полного погружения и изучения библиотек. Цена вышла 3 доллара и личное время, одним глазом поглядывая за его диалогами и запросами на одобрение. Результатом доволен, получилось вполне в меру красивое и работающее приложение, как я и в самом начале задумал. Но точно без опыта нереально «вайбить» приложения более-менее нестандартные приложения, я думаю. А агенты — это станки для обработки болванок, и мы пока находимся в самом начале их формирования.
SwingoPingo
05.01.2026 14:03Какая у Вас, простигосподи, реальная ответственность? Не запушите Вы первым - запушит другой. Инвестор готов и рискует миллиардами вкладывая в то, что может не отбиться, с Вас то что взять при случае? Если это послелняя линия, то мы ее считай пересекли. Дело совсем не в инженерах.
ruomserg
А-а, коллега! Здравствуйте! Как хорошо что вы зашли! :-)
Я в последнее время немного воюю с ветряными мельницами в AI-разработке, в том смысле что призываю народ прекратить говорить лозунгами типа "инженер - несет ответственность за результат кодогенерации". Потому что пока мы его используем в документах которые никто не читает - типа Responsible AI principles in (подставьте название компании) - или хотим назначать виновных при факапах, то этого достаточно.
А если мы всерьез про AI-first development, то эти лозунги будут типа оградки на кладбище - вроде она есть, и вроде кладбище продолжает успешно функционировать. Соответственно, нужны бы какие-то мероприятия (технические, или организационные) чтобы декларация перетекла в изменения реальности...
В частности:
Очень нужны decision-traces для агентов. Мало просто получить diff, или сгенерированные файлы - а желательно бы сохранить в каком-то виде мотивацию, рассмотренные альтернативы, принятые решения и implementation notes. Чтобы рассматривать код не как "артефакт в вакууме", а как часть законченного процесса, в котором присутствует внутренняя логика, и самосогласованность. Но с другой стороны, это не должен быть аналог LLM invocation log - где деталей столько, что проще самому код писать, чем читать этот поток мыслей перемежающийся вызовом тулов...
Очень желательно получать изменения не гигантскими блобами, а так - как это бы делал грамотный разработчик: сначала реализация "крупными мазками" (например, основные интерфейсы и минимальные имплементации для доказательства что решение имеет право на существование). Потом ревью (и возможно, модификация) - и только потом наращивание "мяса" на этот каркас, опять же итеративно.
Жестко настаивать на принципе "одно-из-двух" (ИИ пишет либо код, либо тесты для него). Потому что написание кода и тестов одной и той же моделью - это опасно. Если модель сделала ошибку в коде - то никакие промпты типа "внимательно проверь" не повышают значимо вероятность нахождения ошибки в тестах. Ну и вообще практику написания тестов по коду я считаю глубоко порочной, и допустимой только в очень особых обстоятельствах.
Что-то нужно делать для того, чтобы агентские модели умели вовремя останавливаться. Потому что я видел как агент планомерно разносит проект, пытаясь побороть ошибку вне зоны своего контроля, или вообще несуществующую...
blackyblack
Хорошие наблюдения. Кроме первого пункта, все решается инструкциями для агента. Тесты можно попросить писать в режиме "красный"/"зеленый", то есть сначала пишем падающий тест, а после исправления проблемы он начинает работать (хотя для этого как-то хитро надо CI настраивать).
Итеративную разработку просим еще на этапе планирования фичи.
Останавливаться при проблемах можно попросить в инструкциях. Я иногда прошу остановиться, если вижу проблему в рассуждениях (если я за ними слежу). Или уже по факту вижу сломанный пулл реквест и по рассуждениям могу понять, чего не хватает агенту.
Andriljo
Если конечное решение за принятие кода, который сгенерил ваш ИИ копайлот лежит на вас, то и за это вы и отвечаете. Если вы прожали тап и приняли подсказку, если не глядя тыкнули комммит и мр, вы несёте ответственность как конечное ЛПР. Сори тут слезть с ответственности и переложить все на ИИ не выйдет. И я прошу разделить генерацию кода LLM тут вы конечно не виноваты, и принятием этой генерации как части вашего проекта, если код попал по вашему согласию из генерации в проект - ответ на вас.
И автору поста: агентный, а не агентский. Агентский в ру языке только договор, а подход агентный уже 30 лет в обед в СНГ - агентный. Вы же не переводите domestic как домашнский, а как домашний, не местнеческий, а местный. Также и agentic в ру языке это агентный.
ruomserg
Это очень тонкий момент. С одной стороны - безумием будет считать что за код сгенрированный ИИ - никто не отвечает (из кожаных). С другой - декларация "отвечает инженер" - дает только одну гарантию: что вы в любой ситуации найдете стрелочника. Потому что если с одной стороны LLM выдает экраны непонятного текста, а с другой - начальство давит - "у вас же LLM есть, давайте быстрее - кто медленный того уволим!" - то какие есть варианты у инженера ? Кроме как давить кнопку "одобрямс!", и надеяться что в этот раз пронесет ?!
Я поэтому и поднимаю вопрос сейчас - пока идет развитие инструментов. Две части: устройство самого инструмента, и практики его использования - должны быть адекватными и согласованными, чтобы использование инструмента было а) безопасным; и б) эффективным...
SwingoPingo
Что означает "никто не отвечает из кожанных"? Когда соглашение и так "as is", ответственности перед пользоваталем в привычном смысле и так нет и никогда не было. Ни за работоспособность, ни за стиль, ни за что. Сейчас то почему рука дрогнула? Потому что жать одну кнопку и робот может?
ruomserg
Зря вы всех под одну гребенку-то... Понятно что массовом секторе у потребителя действительно две возможности: "as-is" и "пшел-нах". Но в серьезном корпоративном секторе - где компании примерно одной весовой категории - еще как дерут за качество... Ибо даже если по лицензии убытки с тебя взыскать невозможно - подмоченная репутация и провал в будущих доходах - гарантируются.
SwingoPingo
Что бы прийти к конструктиву нам надо определить проблему ТС в строгих измеряемых дифинициях и если мы это сделаем, боюсь ТС решение не понравится.
Его работа выхолощилась к нажатию кнопки "верю" и технической возможности проверить все содержимое своей работы у него нет. И отказаться нажать он ее не может, потому что нет той крепости, которую не возьмет осел груженный золотом и его инвестор такого осла уже запустил. ТС не удержит этот рубеж ни в одиночку, ни в картельном сговоре с нами.
Решение проблемы ТС (и нашей с Вами тоже) не в его действии или бездействии. А те, в чьих руках находится хотя бы возможность что то поменять сейчас вливают сотни миллиардов в обострении этой проблемы. С этими сотнями миллиардов в отрасль вольются реки проходимцев, которые за все "возьмут ответственность и нажмут все, что надо".
ТС еще не осознал просто, что рубикон уже пересесен. Мы если уже не на той стороне, но и вернутся не выйдет.
DragonFire Автор
Спасибо, я почему-то при слове "агентный" вспоминаю как раз тех самых Смитов а никак не набор программ... Но замечание очень интересное!