Как устроен Amplicode MCP: от кувалды к скальпелю
Эта статья дополняет предыдущую . Там мы зафиксировали проблемы. Здесь разберем, что именно мы сделали со стороны Amplicode, чтобы агент начал работать как опытный software engineer: опираясь на структуру проекта, детерминированные генераторы и понятные высокоуровневые операции. Если коротко, в первой статье было несколько основных болей: – LLM часто обучены на слегка устаревшем мире, и это вылезает в мелочах (и не только). – Галлюцинации и нехватка контекста идут рука об руку: «кажется, в этой библиотеке должен быть такой метод» и пошло-поехало. – Переизбыток контекста тоже зло: агент прочитал половину репозитория, потратил деньги, запутался, а потом еще и забыл начало чата. – Типичный агентный workflow: «сгенерил простыню кода, оно не компилится, давай чинить, ой теперь сломалось другое». И на этом фоне появляется логичный вопрос: а можно сделать так, чтобы агент работал не с сырыми файлами, а с моделью проекта и сущностями фреймворка? Чтобы он не гадал, где DTO, как принято именовать контроллеры и какие миграции у вас используются? Собственно, Amplicode MCP про это.
https://habr.com/ru/companies/haulmont/articles/976872/
#mcp #llm #java #kotlin #spring #spring_framework #intellij_idea #сезон_ии_в_разработке