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