Как код сам объясняет себя, если у вас есть весь 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 проанализировать поведение сервисов:

telegram-cloud-photo-size-2-5325682773740090103-y.jpg

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

⚠️Чрезвычайно высокое время отклика в Report Service - 796.49ms в среднем
⚠️ Высокое время отклика в OpenAI Service - 678.09ms
⚠️ Подозрительно высокое количество 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-контекстом сразу диагностировал проблему:

telegram-cloud-photo-size-2-5325682773740090104-y.jpg

Endpoint: StudentRestController.getStudents()
Длительность: 94.31ms
SQL запросов: 243 отдельных запроса
Проблема: Классическая N+1 - один запрос для получения студентов + 242 дополнительных запроса для каждого студента

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

Начальный запрос: select s1_0.id,s1_0.description,s1_0.first_name...
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

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

telegram-cloud-photo-size-2-5325682773740090105-y.jpg

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

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

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

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

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

Количество компонентов в трассировке значительно сократилось
Время выполнения операций заметно уменьшилось
В панели справа теперь показывается единственный SQL запрос вместо сотен

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

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

telegram-cloud-photo-size-2-5325682773740090106-y.jpg

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

Метрика	До оптимизации	После оптимизации	Улучшение
Общее время	94.31ms	13.23ms	✅ 86% быстрее
SQL запросов	243 запроса	1 запрос	✅ 99.6% сокращение
Тип запроса	1 + 242 N+1	Один оптимизированный JOIN	✅ Устранена N+1

Новый единственный 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

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

telegram-cloud-photo-size-2-5325756707307122945-y.jpg

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

✅ 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/

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