Как runtime-контекст помогает AI делать более точные и правильные изменения в коде

Как код сам объясняет себя, если у вас есть весь runtime-контекст

Сегодня LLM-ассистенты вроде Cursor и GitHub Copilot уверенно вошли в инструментарий разработчика. Они умеют дописывать код, фиксят баги, помогают с простым рефакторингом. Но всё ещё работают вслепую — без знания реального поведения приложения в рантайме.

Если вы работаете с распределённой системой, то знаете: чтобы ответить на вопрос «что сломано?», нужно больше, чем лог или трасса. Нужен контекст. Полный. Со всеми слоями исполнения: от HTTP-запроса и SQL до внутренних вызовов методов и возвращаемых значений.

В BitDive мы решили отдать этот контекст LLM — и всё это работает прямо в IDE, где вам это и нужно. Давайте посмотрим на конкретном примере, как доступ к полным данным о поведении приложения в рантайме кардинально меняет качество анализа и фиксов.

Почему одного кода больше недостаточно

Когда вы просите LLM «помоги мне с этим багом», и у неё есть только код — она будет угадывать. Иногда угадает, иногда — нет. Но если у неё есть вся картина исполнения конкретного вызова — она перестаёт гадать и начинает анализировать.

Именно это мы реализовали через BitDive + Cursor: даём модели не только код метода, но и то, как он вёл себя в реальности. Какие параметры пришли, какие ответы вернулись, что сработало, а что нет. Вместо «догадок по сигнатуре» — точное поведение из продакшена.

Практический пример: обнаружение и исправление N+1 проблемы

Для демонстрации возьмём простое микро сервисное приложение с GitHub: web-app. Оно состоит из нескольких микро сервисов: API Gateway, Faculty, Report, OpenAI и других компонентов.

BitDive не требует каких-то изменений в коде приложений или дополнительной разметки — всё работает из коробки. Для тестирования запущен простой JMeter тест, который периодически обращается к endpoints (можно заменить curl запросами прямо из Cursor).

После подключения BitDive MCP сервера к Cursor и добавления библиотеки BitDive к каждому микро сервису (что не требует изменений в коде), запустим простой тест и посмотрим, что происходит.

Визуализация архитектуры в BitDive

В интерфейсе BitDive мы можем наглядно увидеть карту микро сервисов нашего приложения. На схеме отображены все компоненты системы:

• Faculty Service — сервис для работы со студентами и преподавателями

• Report Service — сервис генерации отчетов

• OpenAI Service — интеграция с AI API

• База данных PostgreSQL — хранилище данных

Стрелками показаны связи между сервисами, а цветовая индикация помогает быстро оценить состояние каждого компонента.

Первоначальный анализ с runtime-контекстом

Попросим Cursor проанализировать поведение сервисов:

Результат анализа выявил критические проблемы:

1. ⚠️Чрезвычайно высокое время отклика в Report Service — 796.49ms в среднем

2. ⚠️ Высокое время отклика в OpenAI Service — 678.09ms

3. ⚠️ Подозрительно высокое количество SQL запросов в Faculty Service — 994 SQL вызова, из них 974 от StudentRestController

Особенно интересен последний пункт: при тестировании 1 запрос каждые 3 секунды генерирует ~270 запросов в минуту к базе данных. Это классическая N+1 проблема.

Детальный анализ конкретного вызова

Теперь проанализируем конкретный вызов:

analyze deb61f9e-3f2f-11f0-bda4-4f2e85a73b5e call  

В интерфейсе BitDive мы видим детальную трассировку этого вызова. На временной диаграмме показано, как запрос проходит через различные компоненты системы:

• StudentRestController — обработка HTTP запроса

• StudentService — бизнес-логика

• StudentRepository — множественные обращения к базе данных

Справа отображается панель с детализацией конкретного метода findAll(), где видно все SQL запросы с их временем выполнения.

Cursor с runtime-контекстом сразу диагностировал проблему:

• Endpoint: StudentRestController.getStudents()

• Длительность: 94.31ms

• SQL запросов: 243 отдельных запроса

• Проблема: Классическая N+1 — один запрос для получения студентов + 242 дополнительных запроса для каждого студента

Trace показал точную структуру проблемы:

1. Начальный запрос: select s1_0.id,s1_0.description,s1_0.first_name...

2. 242 отдельных запроса вида:

select c1_0.student_id,c1_1.id,c1_1.label,c1_1.name,c1_1.start_date,t1_0.id,t1_0.first_name,t1_0.last_name,t1_0.picture,t1_0.title from enrollment c1_0 join course c1_1 on c1_1.id=c1_0.course_id left join teacher t1_0 on t1_0.id=c1_1.teacher_id where c1_0.student_id=('1'::int4)  

Точечное исправление с минимальными изменениями

Имея полную картину выполнения, Cursor предложил оптимальное решение:

fix this n+1 problem with minimal changes @faculty  

Изменения, которые были внесены:

Верификация результата

После применения фикса проанализировали новый trace:

analyze your fix- here is a trace after your changes d2e4f42a-3f30-11f0-98c8-b9eeeeb12adb  

В обновленном интерфейсе BitDive мы видим кардинальные изменения:

На новой временной диаграмме видно, что:

• Количество компонентов в трассировке значительно сократилось

• Время выполнения операций заметно уменьшилось

• В панели справа теперь показывается единственный SQL запрос вместо сотен

Визуально сразу понятно, насколько эффективнее стал работать endpoint.

Результаты впечатляют:

Это же мы видим в интерфейсе bitDive.

Новый единственный SQL запрос:

select distinct s1_0.id,c1_0.student_id,c1_1.id,c1_1.label,c1_1.name,c1_1.start_date, t1_0.id,t1_0.first_name,t1_0.last_name,t1_0.picture,t1_0.title,s1_0.description, s1_0.first_name,s1_0.grade,s1_0.index_number,s1_0.last_name from student s1_0 left join enrollment c1_0 on s1_0.id=c1_0.student_id left join course c1_1 on c1_1.id=c1_0.course_id left join teacher t1_0 on t1_0.id=c1_1.teacher_id order by s1_0.last_name,s1_0.first_name  

Полная верификация результата

Но самое важное — убедиться, что оптимизация не сломала функциональность. Попросим Cursor сравнить входные и выходные параметры:

 compare input and output parameters for each method to understand if new query and all the methods returns the same result  

Результат валидации впечатляет:

🎯 Ключевые выводы валидации:

• ✅ 100% консистентность данных — выходные данные идентичны побайтово

• ✅ Полная функциональная эквивалентность — все бизнес-логика сохранена

• ✅ API контракты неизменны — никаких breaking changes

• ✅ Оптимизация базы данных успешна — 99.5% сокращение запросов к БД

Оптимизация идеально реализована: ноль функциональных изменений при колоссальном росте производительности.

Почему это работает лучше традиционного подхода

Без runtime-контекста разработчик или AI ассистент должен:

• Читать код и пытаться понять потенциальные проблемы

• Гадать, где могут быть узкие места

• Тестировать различные гипотезы

• Надеяться, что изменения действительно решат проблему

С runtime-контекстом от BitDive всё кардинально иначе:

• AI видит точные данные о том, что происходит в реальности

• Может проанализировать конкретные вызовы и их производительность

• Предлагает точечные решения основанные на фактах, а не предположениях

• Может верифицировать результат, сравнив поведение до и после изменений

Выводы

Интеграция runtime-контекста в AI инструменты открывает новые возможности:

• Root cause анализ становится точным, а не гадательным

• Фиксы делаются целенаправленно в конкретных местах

• Верификация решений происходит на основе реальных данных

• Рефакторинг проводится с пониманием реального impact

Когда AI знает не только «что написано в коде», но и «как этот код работает в реальности», качество его рекомендаций кардинально возрастает. Это уже не угадывание по паттернам, а анализ на основе фактов.

Мы убеждены, что будущее AI-ассистированной разработки именно в такой интеграции статического и динамического анализа.

Я не буду сравнивать, как этот воркфлоу выглядел бы без BitDive и информации из ран тайма с голым кодом — каждый может сам всё сравнить и попробовать. BitDive бесплатен для соло-разработчиков и домашних проектов, так что барьер для входа минимальный.

https://bitdive.io/docs/cursor-analyze-services-with-bitdive/