Как устроен Amplicode MCP: от кувалды к скальпелю

Эта статья дополняет предыдущую. Там мы зафиксировали проблемы. Здесь разберем, что именно мы сделали со стороны Amplicode, чтобы агент начал работать как опытный software engineer: опираясь на структуру проекта, детерминированные генераторы и понятные высокоуровневые операции.

Если коротко, в первой статье было несколько основных болей:

– LLM часто обучены на слегка устаревшем мире, и это вылезает в мелочах (и не только).
– Галлюцинации и нехватка контекста идут рука об руку: «кажется, в этой библиотеке должен быть такой метод» и пошло-поехало.
– Переизбыток контекста тоже зло: агент прочитал половину репозитория, потратил деньги, запутался, а потом еще и забыл начало чата.
– Типичный агентный workflow: «сгенерил простыню кода, оно не компилится, давай чинить, ой теперь сломалось другое».

И на этом фоне появляется логичный вопрос: а можно сделать так, чтобы агент работал не с сырыми файлами, а с моделью проекта и сущностями фреймворка? Чтобы он не гадал, где DTO, как принято именовать контроллеры и какие миграции у вас используются?

Собственно, Amplicode MCP про это.


Читать: https://habr.com/ru/companies/haulmont/articles/976872/?utm_campaign=976872

@a_cup_of_java | Другие наши каналы