Откриване на програмни грешки чрез изкуствен интелект: Опитът на Materialize

Публикувано от Svetni.me Editorial на 24 май 2026 г.

Инженерите от платформата за бази данни в реално време Materialize споделиха детайли за успешната интеграция на автономни агенти за откриване на дефекти в своя софтуер [1]. Процесът стартира през февруари 2026 г., съвпадайки с пазарния дебют на модела Claude Opus 4.6 на Anthropic, като в момента системата се поддържа основно от версията Claude Opus 4.7 и алтернативно от модела GPT 5.5 на OpenAI.

Процес на ИИ сканиране и верификация в Materialize
Изображение: Svetni.me / Авторско изображение

Инфраструктура и управление на сесиите

Процесът по сканиране се управлява чрез базов команден скрипт, който дефинира обектите за анализ и ги предава към кодиращия агент [1]. За да се осигури напълно автоматизирано изпълнение без човешка намеса, агентите се стартират в изолирани виртуални машини в специален режим на пропускане на проверките за права (--dangerously-skip-permissions) [1]. Анализират се четири основни направления:

  1. Всички отворени заявки за сливане (pull requests) в GitHub, които са готови за преглед.
  2. Всеки отделен комит, влят в основния клон (main), с цел анализ на пълния контекст от промени.
  3. Всеки индивидуален файл с изходен код на продуктовата част.
  4. Повторен анализ на файловете с инструкции да се игнорират вече известните бъгове, което пести токени и насочва вниманието на модела към по-сложни проблеми.

Инструменти и прецизност

За преодоляване на ограниченията на линейния преглед на кодови бази, разработчиците разчитат на интеграцията на езикови протоколи (LSP) и библиотеката с отворен код Trailmark на Trail of Bits [1, 2]. Тя трансформира програмния код в интерактивен граф на повикванията и позволява на агента да изчислява обсега на влияние (blast radius) на потенциалните уязвимости и да проследява потоците от данни.

Въпреки високата ефективност на Opus 4.7 при изследването на контекста за предотвратяване на фалшиви сигнали, всяка открита аномалия се филтрира по ниво на критичност (средно и високо) и се съпоставя с отворените задачи в GitHub и Linear [1].

Методът „Stay Honest“ за верификация

Практиката на екипа показва, че пълната автоматизация при докладването на бъгове крие рискове от фалшиво-позитивни резултати. Поради това инженерът по тестването Денис Фелсинг въвежда тристепенен ръчен филтър:

  • Лесни за потвърждение: Директно изпълнение на SQL заявка за провокиране на неправилно поведение или срив.
  • Трудни за потвърждение: Разработчикът указва на езиковия модел да разшири съществуващата тестова рамка за създаване на сигурен възпроизводител.
  • Бързи корекции: Когато поправката е от един ред, директно се отваря Pull Request заедно с тестов случай.

Благодарение на тази рамка екипът е открил стотици уязвимости, които са убягвали от съществуващите тестови комплекти.

Източници:

[1]: Finding Bugs using LLMs - Materialize
[2]: Trailmark turns code into graphs - The Trail of Bits Blog