TGTGInsightаналитика telegramLIVE / telegram public index
← AI-Driven Development. Родион Мостовой
AI-Driven Development. Родион Мостовой avatar

TGINSIGHT POST

Post #128

@ai_driven

AI-Driven Development. Родион Мостовой

Просмотры1,760Количество просмотров
Опубликован29 июн.29.06.2025, 09:00
Содержимое поста

Содержимое

Может ли AI находить сложные ошибки в коде целых проектов? У меня в канале много дотнетчиков (спасибо Жене @epeshkblog, Саше @dotnetmore, Кириллу @csharp_gepard и Леше @itbeard) и многие из вас наверняка помнят популярный вопрос с собеседований про GetHashCode) Следующий кейс как об этом. Есть расхожее заблуждение о том, что LLM все еще слишком глупы для того, чтобы находить ошибки в коде проектов. Особенно когда речь идет о больших и сложных кодовых базах. В действительности же нейросети развиваются каждый день, и чтобы GenAI тулинг смог находить даже сложные ошибки в коде, в сущности, необходимы всего 2 составляющие: 1. Мощная LLM с возможностью размышлений (reasoning, thinking). Например, наши внутренние бенчмарки показывают, что самыми внимательными к багам являются модели Gemini 2.5 Pro и OpenAI o3. 2. Релевантный контекст. Важно находить золотую середину между избыточным контекстом и недостаточным контекстом. В случае если в LLM поступает лишний контекст, она просто с большей вероятностью в нем запутается и качество ревью упадет драматически. С другой стороны, если контекста недостаточно, то нейросеть просто не сможет "понять" как то или иное изменение кода повлияет на проект в целом, упустив таким образом важные потенциальные проблемы. Простой пример - код, предназначенный для однопоточного выполнения, в многопоточной среде, как правило, будет выполняться с ошибками. Например, мы CodeAlive предварительно индексируем кодовую базу, выстраивая граф вызовов, иерархию типов и другие связи - именно этот шаг помогает максимально эффективно работать с контекстом нашему AI Code Review. Поделюсь таким кейсом: Недавно мы заметили баг, из-за которого в системе дублировались артефакты Identifier артефакта - это композиция из fileName, className, funcName). Но самое интересное то, что в коде мы уже обрабатывали дубликаты через HashSet и этой ошибки не должно было быть вовсе: HashSet<ArtifactAggregate> artifactsToSave = new(); void TryAddArtifact(ArtifactAggregate artifact) { if (artifactsToSave.Add(artifact) == false) { // log error } } При этом, GetHashCode, на первый взгляд даже корректный, уже был реализован ранее (но я честно о нем даже и не вспомнил тогда). И тут и возникла та самая ситуация, когда даже разработчику непонятно, в чем дело (ведь мы же уже защитились!). Почесав репу, я подумал, почему бы не попросить CodeAlive поискать корень проблемы: почему у нас дублируются Identifier артефактов в базе? мы же вроде защищены от этого в TryAddArtifact Ответ прилагаю на скрине. Но он мне настолько понравился, что я продублировал его в текст. Здесь важно отменить, что весь контекст AI-агент собрал сам - все, что я дал ему на входе это вопрос выше. Проблема действительно оказалась именно в некорректных св-вах в Equals и GetHashCode. Кстати, многие хотят попробовать CodeAlive сразу на больших проектах, без регистрации и смс, теперь это стало возможным. Мы проиндексировали опенсорс проекты (ASP.NET Core, Java Spring, laravel, GORM, VSCode, etc.) и теперь каждый может задать по ним свои вопросы: https://www.codealive.ai/#public-chats У меня есть еще отдельный флоу для решения сложных coding проблем через LLM, если такое интересно, то ваши реакции - лучшая мотивация для нового поста) И поделитесь своими кейсами и флоу, в которых LLM-ки применяются на гране своих возможностей, мы можем собрать потом все в один пост.