Мечтают ли ИИ-агенты об удобных IDE?

О программировании с помощью AI-агентов трубят из-за каждого угла. Последнее время появилось достаточно много инструментов, которые буквально пишут код за разработчика. Наша команда следит за индустрией ИИ в разработке достаточно давно. Помимо внедрения ИИ в сам процесс разработки наших продуктов, мы активно занимаемся интеграцией Amplicode с современными AI-агентами и не только. И у нас есть свои мысли на этот счет) Текущее положение дел Сейчас на рынке доступно большое количество инструментов, которые пишут код за разработчика. Тут можно вспомнить Cursor, Windsurf, Cline, Replit, JetBrains Junie, Claude Code. Подходы у них достаточно похожие. Разработчику доступен чат, в котором он пишет свой запрос, после которого LLM буквально начинает ковыряться в вашем проекте. И первое время это буквально выглядит как магия. Агент начинает изучать проект, смотрит содержимое файлов, предлагает правки и даже вносит их в проект! После чего агент может запустить код, посмотреть на ошибки компиляции, иногда даже посмотреть на результат выполнения. Например Например, мы разрабатываем web-приложение, агент запускает сервер и в терминале дергает curl. Мало кто знает, но технология, которая позволяла делать такие вещи, появилась более двух лет назад и называется Function Calling и Structured Output (OpenAI). Однако, на тот момент она не приобрела очень большой популярности, потому что LLM не очень охотно эти функции вызывали. По всей видимости, вендоры занимались дообучением моделей, заставляя их вызывать эти самые функции (tools) тогда, когда это нужно, и с правильными параметрами. И они в этом преуспели! Прошло некоторое время, клиенты, работающие с LLM продвинулись, появился MCP (Model Context Protocol) — стандарт взаимодействия ИИ с внешним миром. Теперь предоставить управление какой-либо системой напрямую LLM не составит большого труда. Вспоминаем фильм «Терминатор» и нервно курим) Но я сам придерживаюсь точки зрения, что если ИИ и уничтожит мир, то не в результате злого умысла, а по глупости. Родовые травмы LLM При этом у LLM все еще есть большое количество проблем, которые за последние два года все так и остались не решенными — ну или, во всяком случае, решенными не полностью. Проблема устаревших данных Обучать модели очень дорого и долго. И хотя индустрия активно работает над этим, большого прогресса здесь не видно. Смотрите, ChatGPT уверяет меня, что ее учили на данных, которые собрали больше года назад! Да, отчасти это решается через RAG. Да, агенты умеют гуглить, но делают это не всегда и с большим удовольствием продолжают выдумывать факты. Кроме того, в обучающих датасетах наверняка будет большой дисбаланс между новыми и старыми данными, притом в пользу последних. Попробуйте создать новую JPA-сущность с помощью ChatGPT/Claude. Вы удивитесь, насколько часто они будут пытаться использовать javax.persistence вместо jakarta.persistence. Галлюцинации/нехватка контекста Вообще это разные проблемы, но они идут рука об руку. Галлюцинации LLM — это ошибки, при которых модель уверенно генерирует недостоверную, вымышленную или логически некорректную информацию, хотя на вид она может быть правдоподобной и грамматически правильной. В разработке мы видим такое, когда агент пишет код, который использует не существующие библиотечные функции. Вообще, это сама по себе интересная ситуация. Можно рассматривать LLM как великий усреднитель, и она действительно может «ожидать», что какие-то такие функции и интерфейсы действительно должны присутствовать в этой библиотеке или классе. Может, когда-нибудь мы начнем учитывать «желания» LLM при проектировании API? Надо заметить, что разработчики тоже прекрасно галлюцинируют. Как правило, если постановка задачи допускает двоякое толкование, то разработчик выберет либо самое простое, либо самое интересное с инженерной точки зрения решение… и сделает не совсем то, что мы от него просим. Иными словами, додумает за нас, возьмет из головы, опираясь на свой внутренний контекст. Благо, работая с людьми в команде в течение определенного времени, хороший руководитель примерно понимает контекст своих подчиненных и корректирует степень детализации поставленной задачи. Представьте шарик, который находится на вершине горы. Он может скатиться буквально в любую сторону и привести к решению любой степени бесполезности. Задача оператора LLM руководителя учесть ландшафт горы (внутренний контекст разработчика) и добавить дополнительные перегородки (постановка задачи), чтобы шарик скатился именно туда, куда мы хотим. Проблема среднего кода Помните, я говорил про желания и ожидания LLM. С другой стороны, а точно ли желания LLM имеют право на жизнь? Зависит от качества этих желаний. LLM видела весь интернет и весь публично и не очень доступный код. Уверены ли мы в его качестве? Сколько технического долга мы намеренно оставляем в своем коде, на котором потом учится ИИ? Да, эти проблемы стараются решать с помощью фильтрации датасетов для обучения. Но все на свете не отфильтруешь, для каждой задачи бенчмарк не построишь. Хотя исследователи стараются, составляют бенчмарки и даже учат состязательные модели для оценки качества генерации. Проблема переизбытка контекста С приходом эры агентов LLM могут сами изучать контекст проекта. В простейшем случае они могут пофайлово изучать код. Легко додумать, что они также будут (а они уже могут), смотреть тикеты в баг-трекере и читать внутреннюю документацию из knowledge base. Как я выше уже писал, это прямо таки похоже на магию. Это действительно огромный шаг вперед по сравнению с временами (ха-ха, еще и года не прошло), когда приходилось копипастить большие куски файлов в чат, а потом копипастить из чата обратно. Но все равно, если задача поставлена не идеально (знал бы кто, как эту идеальность померить), то результат работы приходится все время поправлять. Иногда в режиме чата, иногда редактируя код руками. Что при этом происходит? История чата стремительно разрастается, а модель начинает путаться. На эту тему даже есть исследование, которое говорит, что лучше всего модель учитывает то, что находится либо в начале контекста, либо в конце https://arxiv.org/abs/2307.03172. А еще не забываем, что все эти файлы тарифицируются, и денежки с нашего счета в консоли улетают очень быстро) LLM пишут код как джуны Уверен, вас тригернет эта фраза, но позвольте пояснить. Я говорю не про качество кода, а про процесс рождения этого кода. Как работает профессионал? Либо решает задачу с конца, либо решает ее методом прогрессивного джипега. Видит цель, определяет некоторые рамки (тесты может написать), разбивает задачу на подзадачи, двигается от одного «суб-рабочего» состояния к другому, пока не дойдет до вершины. Иными словами, у профессионала есть методология. Как правило, джуны начинают путь и рассчитывают, что он их куда-то приведет. Если вы разрабатывали с клодом или курсором, то вы наверняка наблюдали ситуацию, когда агент выдает огромные «готовые» файлы и классы, которые используют другие файлы и классы, еще не написанные, но, как ожидается, будут написаны этой моделью в будущем. Насколько это плохо? Может и не плохо, но только если модель действительно невероятно умна, и построила себе «в голове» целостную картину. Но, зная как работают современные LLM, это скорее всего не совсем так. И эту проблему тоже решают всяческими хаками, вроде принудительного составления плана решения задачи (что в общем то неплохо). Возможно, вы видели как агент попадает в цикл исправление-компиляция-исправление в попытке сделать код рабочим. Не похоже на работу сеньора, правда? И со всем этим работают далеко не идеальные люди! И когда я это говорю, я, конечно, имею ввиду и себя в том числе. У нас есть свой внутренний мир, свои установки, представления о прекрасном, когнитивные искажения. И мы используем инструменты, которые имеют свои искажения, о которых мы можем даже и не знать. К каким результатам это может привести? Лично я уверен, что тут нужно развивать некоторые методологии работы с ИИ-инструментами и повышать общий уровень понимания работы этих инструментов. Amplicode спешит на помощь Так получилось, что наш продукт Amplicode часто сравнивают с LLM. Мы тоже помогаем автоматизировать процесс написания кода и тоже помогаем снизить когнитивную нагрузку на разработчика. Однако, делаем это мы только там, где точно знаем, что сделаем это хорошо. Любое Spring Boot приложение имеет определенную структуру, бины, контроллеры, DTO, доменные сущности, ивенты, Spring конфигурации, тесты, скрипты версионирования базы данных. Наш плагин строит модель проекта, используя которую мы, во-первых, помогаем пользователю ориентироваться в самом проекте. Во-вторых, помогаем генерировать большое количество кода, который разработчик может написать и сам. Но разработчик не всегда видит в голове целостную картину, к тому же постоянно отвлекается на звонки и емейлы разной степени важности. Мы помогаем разработчику меньше переключать контекст своего внимания. Достаточно давно в нашей команде витала идея, что наш инструмент может работать вместе c LLM. И на эту тему у меня тоже был доклад год назад. Благодаря протоколу MCP это становится вполне реально! Даем LLM качественный контекст Помните, как агенты шерстят по проекту в попытке собрать ценные крупицы информации? А точно ли им нужна такая точная детализация этого контекста? Что нужно знать агенту для качественной разработки? Не забываем, что много «лишнего» контекста это тоже плохо и часто дорого. Вообще, большое благо именно Spring Framework в том, что он позволяет очень точно структурировать код. Все составные части Spring приложения я выше уже описал. Почему бы LLM не брать в качестве контекста именно структуру Spring проекта? Конечно, нет смысла выдавать ему скопом полный граф бинов. Но можно дать ему ручки для порционного запроса именно тех объектов, которые ему нужны для решения текущих задач. Предоставляем LLM методологию решения задачи При разработке той или иной функциональности наша команда долго изучает предметную область. Чтобы получить качественную генерацию, мы должны правильно задать пользователю вопрос, собрать часть входных данных, которые от пользователя, на первый взгляд, скрыты. Иногда результатом этой работы получаются такие диалоги: По сути, каждый диалог (и некоторый контекст проекта) — это минимальная необходимая информация, которая позволяет качественно решить поставленную перед пользователем задачу и при этом неплохо подсказать пользователю, где он может ошибиться. Фактически, каждый такой диалог и каждая функциональность по генерации кода по его результатам это и есть методология решения задачи. Как правило, LLM упускает огромное количество важных деталей, и одним лишь промпт-инжинирингом достичь приемлемого качества сбора данных и генерации может быть крайне тяжело (если вообще возможно). Да и вообще, множество задач в разработке имеют более-менее описываемый алгоритм решения. Именно этим мы занимаемся, разрабатывая Amplicode Agent, но больших деталей пока предоставить не могу. В том числе эту задачу решает компания Anthropic с помощью Subagents и Skills. Пишем код вместе с LLM На самом деле можно пойти еще дальше и буквально вызвать нашу детерминированную генерацию, которая уж точно все учтет и будет использовать подходы, принятые в конкретном проекте. Часть кода может написать Amplicode, но далеко не весь. А вот тут нам поможет LLM, допишет какие-то методы, дополнит бизнес логику. Особенно это актуально со скриптами версионирования, генерация которых требует учета большого количества данных: тип базы данных, текущее состояние БД, структуру доменных сущностей. При этом часть скриптов все равно требует оценки со стороны пользователя и уточнение со стороны LLM. Или скажем, мы добавляем новый атрибут в сущность, а в базе уже есть такая колонка! Классическая задача по Обратному проектированию, которая уже реализована в Amplicode, но достаточно сложна для LLM https://amplicode.ru/ide-dlya-raboty-s-persistentnym-sloem-prilozheniya/#reverse_engineering. Получи апрув у пользователя! Я уже говорил, что LLM очень много додумывают и очень мало спрашивают. Вызывая функциональность Amplicode по генерации того или иного объекта, LLM как раз дает возможность пользователю дать ей обратную связь и внести корректировки. Особенно это актуально для сложных структур, таких как DTO. LLM предзаполнит входные данные по своему усмотрению, а пользователю остается нажать ОК. Конечно, модальные диалоги в чате — это не самый приятный UX. Наш собственный агент встраивает часть диалогов. Наша цель — перенести большую часть наших диалогов буквально в окно ввода в чате. Выводы Однозначно ИИ агенты для написания кода это прорыв. Если уметь правильно их готовить, то можно на порядок быстрее решать задачи. Однако мы хотим быть уверены, что качество этих решений будет приемлемым. Возможно, профессия разработчика трансформируется в профессию ревьювера-постановщика задач. Но лично я не хочу часами ругаться на LLM, заставляя ее решить задачу именно так, как нужно мне. Написание кода переходит в написание промптов. А ситуация, когда размер промтов больше, чем размер кода на выходе, мне совсем не нравится. В конце концов, кто кому служит, LLM мне или я LLM? LLM не спрашивает нас, то ли она имела ввиду, зачастую, LLM не знает как правильно, и без правильной постановки вопроса, мы получаем какой-то средний ответ. А как вы знаете, правильная постановка вопроса это уже половина ответа) К счастью, эти недуги можно если не вылечить, то хотя бы смягчить. А вот средняя когнитивная нагрузка на разработчика, скорее всего вырастет. Ведь простые задачи мы дать LLM можем. А вот действительно сложные… По моему опыту, с этим связано разочарование разработчиков в агентах. Ожидали, что все станет куда проще, а теперь сиди, разбирай код, который написал не ты, который местами не работает, а местами использует откровенно вредительские практики. Но это уже совсем другая история) Тем не менее, прогресс остановить невозможно. Я все еще уверен, что IDE нам будут нужны не меньше. В конце концов, нужен удобный инструмент для того, чтобы отсматривать код. Но кажется, что основным потребителем IDE может стать не разработчик, а LLM агент. Вот так) Наши планы Наша команда занимается исследованием ИИ в трех направлениях: изучение и выведение лучших практик внедрения ИИ в разработку ПО; разработка MCP-серверов для повышение эффективности кодинг-агентов; разработка самих агентов. Я думаю, что мы будем делиться с вами своими мыслями и результатами по каждому из них в будущем. На данный момент, Amplicode MCP ближе остальных готов к релизу, и в скором времени мы покажем, что сделали. Но ждать необязательно! Вы можете скачать и попробовать Amplicode прямо сейчас. Пока мы не предоставляем широкому кругу доступ ко всем нашим наработкам в области ИИ-разработки, но уже доступный функционал действительно снижает когнитивную сложность там, где это возможно, и помогает писать код, который, с большой вероятностью, пройдет код-ревью. Но если вы уже внедряете ИИ в ваши процессы разработки, не ждите, напишите нам на info@amplicode.ru. Мы с радостью покажем вам Amplicode MCP, предоставим сборку и поможем настроить ваше окружение. Актуальные новости о продукте проще всего получать, подписавшись на наш телеграм канал. Получить актуальную версию Amplicode можно на нашем сайте.