«Галлюцинации LLM — это не баг»: профессор математики объясняет, почему ИИ не перестанет врать 2/2 __Владимир Крылов, профессор математики, научный консультант Artezio и один из самых глубоких русскоязычных экспертов по применению ИИ в разработке, дал интервью по итогам года…__ https://habr.com/ru/companies/lanit/articles/985162/ Понимание кода на уровне целого репозитория требует понимания межфайловых зависимостей, взаимодействия модулей, отношений импорта, соглашений. LLM с такими сложными связями сегодня работают плохо. Как только генерация кода произойдет с учётом некого локального файла, появляется проблема: начинается итеративный процесс тестирования и генерации, захватываются другие фрагменты, ошибка может начать распространяться вместо того, чтобы итеративно сойтись к нулю. RepoUnderstander: How to Understand Whole Software Repository? https://arxiv.org/html/2406.01422v1 DependEval: Benchmarking LLMs for Repository Dependency Understanding https://arxiv.org/abs/2503.06689v1 Сегодня стратегия снижения рисков обычно такая: нужно хранить не только полный репозиторий, но и его сжатый вариант LongCodeZip: Compress Long Context for Code Language Models https://www.arxiv.org/pdf/2510.00446 Retrieval-Augmented Code Generation: A Survey with Focus on Repository-Level Approaches https://arxiv.org/html/2510.04905v1 Также рекомендуется специальным образом фрагментировать проект на составляющие и работать с законченными конструкциями, объединение которых даст лучший результат, чем работа с полной кодовой базой. И здесь мы переходим к архитектуре решений, которые создаются с помощью LLM - все выше описанные ограничения, научно обоснованные, никуда не денутся и с хорошей модульностью, но хорошая модульность с управляемой сложностью серьезно снизит их негативное влияние.