Can LLMs generate Enterprise Quality Code? Или почему pass rate уже мало (Рубрика #AI4SDLC)
LLM может пройти тесты и все равно написать код, который enterprise-команда потом будет долго разгребать. Именно об этом доклад Prasenjit Sarkar из Sonar: "Can LLMs generate Enterprise Quality Code?". Главная мысль простая, но неприятная: pass rate больше не достаточен. HumanEval, MBPP и SWE-bench хорошо отвечают на вопрос “работает ли решение в тесте?”, но гораздо хуже отвечают на вопрос “можно ли это безопасно втащить в большую кодовую базу?”.
В enterprise важно не просто реализовать функциональные требования и выдать рабочий код - важны вопросы безопасности, надежности, maintainability, когнитивной сложности, архитектурной связности, объема технического долга и кучи других нефункциональных требований. Но обычно мы смотрим в бенчах на то, как модель может сгенерировать корректный код, но не смотрим а не добавит ли она уязвимость, раздует метод, ухудшит читаемость или сломает принятые в репозитории правила. Поэтому Sonar продвигает идею Agent-Centric Development Cycle (AC/DC): Guide -> Generate -> Verify -> Solve. То есть AI-агента сначала нужно направить контекстом и стандартами проекта, потом дать ему сгенерировать код, затем независимо проверить результат и только после этого исправлять найденные проблемы.
Важная деталь: Generate делает coding agent, а ценность Sonar здесь в независимом слое Guide, Verify и Solve. Это не про “заменить разработчика”, а про то, чтобы встроить AI-код в управляемый инженерный контур. Интересная часть - их `LLM Leaderboard for Code Quality & Security. Это не просто таблица “какая модель решила больше задач”. Pipeline такой: модель генерирует код, код компилируется и гоняется на тестах, потом SonarQube анализирует bugs, vulnerabilities, code smells и complexity. Для Java сейчас указано примерно ~3,900` задач ComplexCodeEval, ~400 MBPP и ~160 HumanEval. При этом correctness через pass@1 считается только для HumanEval и MBPP, а остальные benchmark-и участвуют в метриках качества: complexity, security, reliability и maintainability.
Вот это, кажется, правильная рамка для engineering leaders: AI-код надо принимать через verification loop. Чем быстрее агенты пишут код, тем строже должна быть система, которая проверяет не только “прошли ли тесты”, но и “не и не наработали ли мы себе на будущий инцидент”.
#AI #AI4SDLC #Engineering #Architecture #DevSecOps #Software #Agents
LLM может пройти тесты и все равно написать код, который enterprise-команда потом будет долго разгребать. Именно об этом доклад Prasenjit Sarkar из Sonar: "Can LLMs generate Enterprise Quality Code?". Главная мысль простая, но неприятная: pass rate больше не достаточен. HumanEval, MBPP и SWE-bench хорошо отвечают на вопрос “работает ли решение в тесте?”, но гораздо хуже отвечают на вопрос “можно ли это безопасно втащить в большую кодовую базу?”.
В enterprise важно не просто реализовать функциональные требования и выдать рабочий код - важны вопросы безопасности, надежности, maintainability, когнитивной сложности, архитектурной связности, объема технического долга и кучи других нефункциональных требований. Но обычно мы смотрим в бенчах на то, как модель может сгенерировать корректный код, но не смотрим а не добавит ли она уязвимость, раздует метод, ухудшит читаемость или сломает принятые в репозитории правила. Поэтому Sonar продвигает идею Agent-Centric Development Cycle (AC/DC): Guide -> Generate -> Verify -> Solve. То есть AI-агента сначала нужно направить контекстом и стандартами проекта, потом дать ему сгенерировать код, затем независимо проверить результат и только после этого исправлять найденные проблемы.
Важная деталь: Generate делает coding agent, а ценность Sonar здесь в независимом слое Guide, Verify и Solve. Это не про “заменить разработчика”, а про то, чтобы встроить AI-код в управляемый инженерный контур. Интересная часть - их `LLM Leaderboard for Code Quality & Security. Это не просто таблица “какая модель решила больше задач”. Pipeline такой: модель генерирует код, код компилируется и гоняется на тестах, потом SonarQube анализирует bugs, vulnerabilities, code smells и complexity. Для Java сейчас указано примерно ~3,900` задач ComplexCodeEval, ~400 MBPP и ~160 HumanEval. При этом correctness через pass@1 считается только для HumanEval и MBPP, а остальные benchmark-и участвуют в метриках качества: complexity, security, reliability и maintainability.
Вот это, кажется, правильная рамка для engineering leaders: AI-код надо принимать через verification loop. Чем быстрее агенты пишут код, тем строже должна быть система, которая проверяет не только “прошли ли тесты”, но и “не и не наработали ли мы себе на будущий инцидент”.
#AI #AI4SDLC #Engineering #Architecture #DevSecOps #Software #Agents