Эта статья дополняет предыдущую. Там мы зафиксировали проблемы. Здесь разберем, что именно мы сделали со стороны Amplicode, чтобы агент начал работать как опытный software engineer: опираясь на структуру проекта, детерминированные генераторы и понятные высокоуровневые операции.
Если коротко, в первой статье было несколько основных болей:
LLM часто обучены на слегка устаревшем мире, и это вылезает в мелочах (и не только).
Галлюцинации и нехватка контекста идут рука об руку: «кажется, в этой библиотеке должен быть такой метод» и пошло-поехало.
Переизбыток контекста тоже зло: агент прочитал половину репозитория, потратил деньги, запутался, а потом еще и забыл начало чата.
Типичный агентный workflow: «сгенерил простыню кода, оно не компилится, давай чинить, ой теперь сломалось другое».
И на этом фоне появляется логичный вопрос: а можно сделать так, чтобы агент работал не с сырыми файлами, а с моделью проекта и сущностями фреймворка? Чтобы он не гадал, где DTO, как принято именовать контроллеры и какие миграции у вас используются?
Собственно, Amplicode MCP про это.
Краткий обзор Amplicode MCP
MCP (Model Context Protocol) можно воспринимать как стандартный взаимодействия между LLM и внешними системами.
На практике MCP делает две важные вещи:
Дает модели инструменты (tools): не “прочитай файл и придумай”, а “вызови функцию с понятными параметрами и получи структурированный ответ”.
Нормализует контекст: чтобы контекст был не просто огромным текстом на 50К токенов, а ровно тем, что нужно для текущего шага.
Amplicode MCP – это тот набор инструментов, который нужен LLM для эффективной, корректной, быстрой и комфортной (как бы это не звучало :D) работы с проектом на Spring. Без MCP от Amplicode вы по сути заставляете LLM писать код на листочке, когда рядом с ней стоит свеженький MacBook на M5. Модель работает с сырыми файлами, простым текстом и т.д.
У Spring Boot проекта есть структура. У persistent слоя есть закономерности. У DTO есть типовые формы. У миграций есть правила. У проектов есть принятые подходы и ограничения.
Amplicode много лет делает одну и ту же штуку: строит модель проекта и поверх нее предлагает детерминированные операции, которые:
учитывают структуру Spring-приложения,
понимают различные слои приложения от persistence до deployment,
помогают генерировать код с учетом best practices
Идея Amplicode MCP: давать агенту не “файлы”, а “элементы фреймворка” и высокоуровневое представление, которое до появления MCP мы предоставляли разработчикам.
Если посмотреть на картинку, то там видно, что инструменты у агента в целом бывают двух типов. Первый тип, “базовый IDE-шный”: поиск и чтение файлов, grep по проекту, рефакторинги, навигация, запуск конфигураций и команд.
Второй тип, ради которой и написана эта статья – это специализированные инструменты Amplicode: Spring Boot сущности и зависимости, список бинов (контроллеры/сервисы/репозитории), REST endpoints с деталями, конфигурация (application.yml/properties), security и профили, тесты, база данных (entities, repositories, миграции), а также инфраструктурные штуки вроде Docker Compose и Kafka. И ключевое отличие тут не в том, что это “удобнее”, а в том, что это семантически ближе к задаче.
Когда агенту нужно понять проект, “прочитать весь репозиторий” это как лечить зубы кувалдой: вариант рабочий, но пациент будет недоволен. Tool “покажи мне эндпоинты” или “покажи бины и зависимости” сразу отдает структурированный ответ, без лишнего "мусора". Это снижает и вероятность галлюцинаций (агент меньше додумывает), и стоимость контекста (мы не тащим простыни кода), и количество неверных итераций агента “ой, я не туда посмотрел”, "ой, не заметил вот этот эндпоинт".
Работает это дело следующим образом:
Ну или бывает еще так:
Планы: что улучшаем дальше
Первое и самое очевидное: UX. Сейчас любое “умное” взаимодействие с проектом упирается в один неприятный факт: если мы хотим надежности, то нам иногда нужно уточнять детали. А уточнения почти всегда выглядят как “ответь на N вопросов”.
Поэтому наш фокус на ближайшее время такой: уменьшать количество обязательных вопросов, не теряя качества. Во многих диалогах у нас уже есть дефолты, которые “прекрасно подходят всем” в большинстве проектов: стандартные имена, типовые схемы DTO, ожидаемые места для классов, шаблонные настройки. Мы хотим чаще использовать эти дефолты автоматически, а дергать пользователя только там, где цена ошибки реально высокая.
Вторая важная вещь: пока что многое из того, о чем мы говорим, основано на наших субъективных оценках “стало лучше” и “стало быстрее”. Поэтому дальше будут бенчмарки.
Мы хотим публично описать, что именно мы измеряем (успешность выполнения задач, количество итераций, стабильность компиляции/тестов, расход токенов, затраченное время разработчика на правки и ревью), как это измеряется, и показать цифры. В качестве ориентира по формату нам нравится подход DP-AIA. Если вы знаете вариант лучше – будем рады услышать его в комментариях :)
Как попробовать?
На данный момент, Amplicode MCP ближе остальных готов к релизу, и в скором времени мы покажем, что сделали.
Но ждать необязательно! Вы можете скачать и попробовать Amplicode прямо сейчас. Пока мы не предоставляем широкому кругу доступ ко всем нашим наработкам в области ИИ-разработки, но уже доступный функционал действительно снижает когнитивную сложность там, где это возможно, и помогает писать код, который, с большой вероятностью, пройдет код-ревью.
Но если вы уже внедряете ИИ в ваши процессы разработки, не ждите, напишите нам на info@amplicode.ru. Мы с радостью покажем вам Amplicode MCP, предоставим сборку и поможем настроить ваше окружение.
Актуальные новости о продукте проще всего получать, подписавшись на наш телеграм канал. Получить актуальную версию Amplicode можно на нашем сайте.