Шесть слоёв evidence, четыре стадии evidence loop, три профиля внедрения и четырёхнедельный rollout — практический code intelligence stack для больших полиглотных кодовых баз.
В большой кодовой базе вопрос «где находится эта функция?» быстро превращается в расследование. Нужно найти все реализации и вызовы, понять зависимости, проверить статические нарушения, сопоставить код с реальным поведением в продакшене, а затем убедиться, что изменение не сломало соседний сервис. В монорепозитории или полиглотной системе это уже не задача для обычного grep и не задача, которую безопасно делегировать одному чат-боту.
Под code intelligence я буду понимать не конкретный AI-продукт, а замкнутый контур из шести типов фактов:
Первые пять — это evidence-слои вокруг единой CODEBASE; LLM — это actor, который их интерпретирует, а не шестой источник evidence. Иллюстрация в начале раздела визуализирует этот контракт.
Я сравнил инструменты по шести осям: code search, static analysis, runtime tracing, log aggregation, LLM-assisted investigation и knowledge-graph code models. Дата проверки первоисточников — 20 июля 2026 года. Там, где данные быстро меняются, это отмечено отдельно.
Если нужен не маркетинговый список, а практичный стартовый набор, я бы начал так:
Этот список не означает «установите всё». Сначала определите, какой вопрос вы хотите сделать дешёвым: найти символ, поймать уязвимость, объяснить latency, удалить данные по запросу пользователя или проверить изменение через LLM.
Для каждого инструмента я использовал четыре фильтра:
Термин «mature» здесь означает, что инструмент имеет устойчивый production-сценарий и не находится в beta или maintenance mode (режим заморозки). Это не обещание отсутствия багов. И наоборот: beta-инструмент может быть очень быстрым и удобным, но его нельзя бездумно ставить в blocking gate (блокирующая проверка CI).
Поиск по коду — самый недооценённый слой. Прежде чем строить граф и подключать LLM, вы должны уметь быстро ответить на вопросы «где объявлено», «кто вызывает», «в какой ветке это изменилось» и «есть ли такая же проблема в соседних репозиториях».
Sourcegraph Code Search — практичный выбор для enterprise-контура, если важны несколько хостингов, ветки и коммиты, symbol search, batch changes и слой Cody поверх индекса. Его сильная сторона — не просто поиск строки, а единый интерфейс для cross-repo расследований. Цена этой глубины — коммерческая модель, непрозрачный pricing и необходимость отдельного privacy review для SaaS или AI-функций.
Zoekt — Apache-2.0 и хорошая база для OSS-only сценария. Это trigram-based движок, который лежит под Sourcegraph Code Search. Он умеет быстро искать по большим объёмам кода, поддерживает regexp, boolean-запросы и symbol ranking. Но Zoekt сам по себе не является готовой заменой всей Sourcegraph-платформе: UI, синхронизация репозиториев, права доступа и эксплуатационные процессы придётся собрать самостоятельно.
Выбор простой: если вам нужен законченный enterprise-продукт и устраивает лицензия — Sourcegraph; если важен контроль над данными и есть команда на сборку платформы — Zoekt.
OpenGrok остаётся разумным вариантом для Java-heavy и legacy-окружений. Он давно умеет cross-reference, поддерживает много языков и предоставляет web UI и API. Обратная сторона — JVM-стек, стоимость полного reindex и необходимость настройки при очень больших репозиториях. Также нужно проверять конкретную комбинацию лицензий: у проекта CDDL-1.0 и смешанные компоненты.
livegrep — более узкий, но удобный single-tenant сценарий. Это быстрый regex-поиск по гигабайтам исходников с re2 и mmap-индексами. Он хорошо подходит для внутреннего «Google Code Search», когда не нужны сложный permission model и многорепозиторная семантика.
Hound можно рассматривать только если нужен очень маленький deployment footprint и допустим maintenance mode. Для нового стратегического слоя я бы не делал его базовым выбором.
Не начинайте с semantic search, если у вас нет точного текстового и символьного поиска. В противном случае LLM будет красиво пересказывать неполный индекс, а команда не сможет проверить ответ простым повторным запросом.
Вместо одного «магического» анализатора полезно разделить работу по стоимости.
Практичная схема выглядит так: Ruff и локальные Semgrep-правила дают быстрый feedback; CodeQL и глубокий taint-анализ (отслеживание непроверенных данных) запускаются в CI; SonarQube собирает межрепозиторную картину качества. При этом один и тот же finding должен иметь owner, severity, suppression reason и срок пересмотра. Иначе инструмент просто производит backlog.
Статический анализ не показывает, какая ветка реально выполняется и где тратится время. Для Linux-native систем базой остаются perf (подсистема профилирования Linux) events, perf, ftrace и инструменты Brendan Gregg. Они дают аппаратные counters, kernel tracepoints, kprobes, uprobes и USDT с небольшими накладными расходами.
bpftrace (диагностический one-liner) удобен, когда нужно быстро написать диагностический запрос без отдельной C-программы: посмотреть системные вызовы, latency блокировок, сетевые события или поведение процесса. Это зрелый инструмент, но он требует Linux с поддержкой BPF и не заменяет полноценную систему непрерывного профилирования.
Для JVM нужен async-profiler (sampling-профилировщик JVM). Он снимает CPU и heap profiles, работает с native frames, JIT и GC-потоками и умеет отдавать результат в JFR (Java Flight Recorder — встроенный в JDK профилировщик/трейсер с низкими накладными расходами.) (Java Flight Recorder) и flame graph (визуализация стека вызовов). В Java-сервисе это обычно более полезный старт, чем попытка применять универсальный агент ко всем языкам.
Для continuous profiling можно выбрать Pyroscope (backend continuous profiling) или Parca (eBPF profiling с pprof):
go tool pprof и большинством flame-graph утилит.) (формат профилей Google)-формат, поэтому особенно интересен для Go, Rust, C/C++ и Kubernetes без добавления SDK в приложение.Профиль без контекста бесполезен. Каждое измерение должно быть связано с версией сборки, сервисом, окружением и временным окном. Иначе flame graph превращается в картинку без причинности.
Главное решение в observability — не «Loki или Elastic», а то, сохраните ли вы возможность заменить backend без переписывания instrumentation.
OpenTelemetry (Открытый стандарт данных телеметрии (traces, metrics, logs) с vendor-neutral SDK и Collector; задаёт формат, но не хранит данные.) (стандарт телеметрии) стоит ставить в этот слой первым. Это vendor-neutral модель данных, SDK и Collector для traces, metrics и logs. OTel (Открытый стандарт данных телеметрии (traces, metrics, logs) с vendor-neutral SDK и Collector; задаёт формат, но не хранит данные.) не хранит данные и не является системой поиска, но задаёт общие semantic conventions, маршрутизацию и границу между приложением и backend.
Дальше выбор зависит от формы запросов:
Для self-hosted SaaS AGPL (Свободная лицензия с copyleft-оговоркой для сетевого использования: если вы запускаете AGPL-сервис для пользователей, вы должны открыть исходники. Для embedded в закрытый коммерческий продукт — обычно legal blocker.) может быть приемлема, но для встраивания компонента в закрытый коммерческий продукт юридическая оценка обязательна. Также заранее определите retention (срок хранения данных), data residency, erase workflow и доступ к логам. Нельзя обещать пользователю удаление данных, если выбранный storage не умеет надёжно найти и удалить все копии.
LLM полезна, когда она сокращает путь от вопроса к проверяемым фактам. Она опасна, когда выдаёт уверенное объяснение поверх неполного индекса.
Aider — сильный OSS-вариант для terminal-based работы. Он умеет строить карту репозитория, работать с разными моделями, автоматически запускать lint и tests и фиксировать изменения в git. Его естественная роль — управляемый CLI-помощник, а не автономный production-deployer.
Cursor удобен как enterprise IDE, а Sourcegraph Cody логичен для команды, которая уже использует Sourcegraph и хочет подавать модели его code graph. У обоих вариантов есть цена: коммерческая зависимость, vendor-specific indexing и необходимость проверить, куда отправляются исходники, prompts, snippets и результаты поиска.
Continue.dev больше нельзя рекомендовать как базу для новых установок: согласно официальной документации, репозиторий больше не поддерживается и оставлен read-only после финального релиза 2.0. Его можно изучать как исторический reference для prompt patterns, но это не текущий deployment target.
Минимальный guardrail для любого LLM-инструмента:
Если модель не может показать evidence, это гипотеза, а не finding.
Термин «knowledge graph (реляционная модель кода) кода» часто используют для трёх разных вещей.
OpenRewrite строит Lossless Semantic Tree и применяет type-aware recipes. Это сильный выбор для массовых refactoring и framework migrations: вместо regex-замены инструмент понимает структуру программы и может повторно применить рецепт к нескольким репозиториям. Но зрелость парсеров различается по языкам: Java обычно покрыт лучше, чем более новые направления.
CodeQL хранит код в реляционной модели, которую на практике можно использовать как knowledge model: запросы выражают связи между источниками данных, вызовами, типами и sink-ами. Это особенно полезно для security и cross-repo поиска уязвимых паттернов.
SCIP (Индексный формат Sourcegraph для symbols и связей между ними; позволяет разным language indexers отдавать данные в общий формат.) (индексный формат Sourcegraph) — индексный формат Sourcegraph Code Intelligence Protocol. Он полезен как interoperability layer: отдельные language indexers могут отдавать символы и связи в общий формат. Однако экосистема SCIP всё ещё сильнее всего связана с Sourcegraph.
Sourcegraph Code Graph — коммерческий production-grade граф для cross-repo symbol navigation и AI-grounded Q&A. Он даёт максимальную ценность, когда уже есть Sourcegraph-scale code search. Но для маленького репозитория отдельный граф почти всегда избыточен.
Практическое правило: граф нужен для отношений и multi-hop вопросов — «какие сервисы зависят от этого типа?» или «какие вызовы ведут к этому sink?» — а не для любого поиска строки. Для local fact lookup обычный индекс быстрее, дешевле и проще проверить.
Минимальная production-схема может выглядеть так:
Git repositories
-> Zoekt or Sourcegraph index
-> SCIP and symbol metadata
-> Semgrep, CodeQL, SonarQube, Ruff
-> OpenTelemetry Collector
-> logs, traces, profiles
-> Loki, Quickwit, OpenObserve, or Elastic
-> Aider, Cody, or another guarded LLM interface
-> diff, tests, SAST, reviewer
Здесь важна последовательность. LLM не должна быть первым звеном. Сначала строятся индексы и telemetry contracts, затем добавляется модель, которая умеет переходить от вопроса к evidence. Если поменять порядок, вы получите дорогой чат с устаревшим контекстом, а не code intelligence.
На диаграмме выше compliance-sensitive concerns показаны как горизонтальный overlay, пересекающий оба основных профиля, а не как третий равноправный столбец. Compliance ортогонален выбору инструментов: можно запускать OSS или GitHub-centric, и в обоих случаях можно включать compliance-sensitive режим. Два вопроса — какой vendor mix? и какой compliance posture? — независимы.
Zoekt, Semgrep OSS, CodeQL CLI, Ruff, perf/bpftrace, OpenTelemetry (Открытый стандарт данных телеметрии (traces, metrics, logs) с vendor-neutral SDK и Collector; задаёт формат, но не хранит данные.), Loki или Quickwit, Aider и OpenRewrite. Этот вариант даёт контроль над кодом и данными, но требует собственной работы над auth, indexing, UI, retention и upgrades.
Sourcegraph или GitHub-native search, CodeQL (Движок GitHub для анализа кода как данных: код преобразуется в реляционную модель, запросы пишутся на QL для поиска уязвимостей и паттернов.), Semgrep, SonarQube, OpenTelemetry, выбранный observability backend, Cody или Cursor. Это быстрее запускается, но нужно заранее зафиксировать границы SaaS, стоимость индексации и exit plan (план миграции с вендора).
Начните не с LLM, а с data map: какие репозитории, логи и профили содержат персональные данные, где они хранятся, кто имеет доступ и как выполняется deletion request (запрос на удаление данных). После этого выбирайте self-hosted indexing, OTel (Открытый стандарт данных телеметрии (traces, metrics, logs) с vendor-neutral SDK и Collector; задаёт формат, но не хранит данные.) Collector с фильтрацией, backend с понятным retention и только затем AI-инструмент с проверенной политикой обработки данных.
152-ФЗ (закон о персональных данных) и GDPR нельзя свести к одной галочке в продукте. Delete API в Quickwit или заявленный GDPR-ready статус OpenObserve — полезные технические элементы, но compliance определяется всей системой: collection, access, storage, backups, deletion, residency и организационные процессы.
После пилота измеряйте не количество инструментов и не token spend, а time-to-find, time-to-explain, долю findings с reproducible evidence, false-positive rate и время от runtime-сигнала до исправления.
Каждая неделя на диаграмме заканчивается явным exit gate. Следующая неделя начинается только когда gate удовлетворён — это правило последовательности, а не календарное правило. Gate — это однострочный проверяемый критерий, а не цель:
Если gate не выполнен — сначала чините разрыв, потом продолжаете. Pilot repository и gates — единственные durable артефакты, которые переживают rollout; всё остальное можно заменить.
Code intelligence быстро меняется, поэтому эту статью нельзя считать вечным каталогом:
Для такой области разумен re-fetch каждые шесть месяцев, а для commercial AI tooling и compliance-sensitive deployments — перед каждым существенным изменением.