Code intelligence stack 2026: как собирать карту кода, а не коллекцию AI-игрушек

Эта заметка выросла из работы над собственной системой автономной мультиагентной разработки, которой я занимаюсь параллельно с основными проектами. Шесть evidence-слоёв и rollout-план — не абстрактная модель, а контракт, проверенный её реальными сценариями: polyglot code search для агентов, разграничение evidence и actor в памяти, retention в telemetry для длинных сессий, и обязательная трассировка каждого agent-driven изменения до коммита.

Code intelligence stack 2026: как собирать карту кода, а не коллекцию AI-игрушек

В большой кодовой базе вопрос «где находится эта функция?» быстро превращается в расследование. Нужно найти все реализации и вызовы, понять зависимости, проверить статические нарушения, сопоставить код с реальным поведением в продакшене, а затем убедиться, что изменение не сломало соседний сервис. В монорепозитории или полиглотной системе это уже не задача для обычного grep и не задача, которую безопасно делегировать одному чат-боту.

Под code intelligence я буду понимать не конкретный AI-продукт, а замкнутый контур из шести типов фактов:

Текстовые и символьные факты — поиск по файлам, веткам, коммитам и определениям.

Статические факты — AST, типы, data-flow, зависимости и нарушения правил.

Динамические факты — трассировки, профили, latency, ошибки и поведение под нагрузкой.

Операционные факты — логи, метрики, корреляция релиза с инцидентом и срок хранения данных.

Реляционные / knowledge-graph факты — code-as-data запросы, типизированные recipes, символьные связи между репозиториями и multi-hop вопросы.

Генеративная интерпретация — LLM, которая отвечает на вопросы только поверх перечисленных источников и показывает, откуда взялся вывод.

Первые пять — это evidence-слои вокруг единой CODEBASE; LLM — это actor, который их интерпретирует, а не шестой источник evidence. Иллюстрация ниже визуализирует этот контракт.

Я сравнил инструменты по шести осям: code search, static analysis, runtime tracing, log aggregation, LLM-assisted investigation и knowledge-graph code models. Дата проверки первоисточников — 20 июля 2026 года. Там, где данные быстро меняются, это отмечено отдельно.

Иллюстрация · шесть слоёв code intelligence

Code intelligence — это система evidence-слоёв вокруг единой CODEBASE, а не отдельный AI-продукт. Пять слоёв — это источники фактов; LLM — это actor, который их интерпретирует.

SEARCH · textual & symbolic · Zoekt · livegrep

STATIC · rules, types, data-flow · Semgrep · Ruff

RUNTIME · traces & profiles · perf · bpftrace

TELEMETRY · logs, metrics, retention · OTel · Loki

GRAPH · relational, multi-hop queries · CodeQL · OpenRewrite

LLM · actor, not evidence · Aider · Cody

inner link — evidence acquisition

outer link — cross-layer correlation

Суть

Если нужен не маркетинговый список, а практичный стартовый набор, я бы начал так:

Быстро найти символ в чужом коде — Sourcegraph или Zoekt.

Ловить уязвимости до продакшена — связка Semgrep и CodeQL в CI, SAST плюс SCA как два слоя (расшифровка в §2).

Объяснить «почему тормозит» в Linux-сервисе — perf/bpftrace плюс Pyroscope или Parca для continuous profiling.

Заменить «один AI-чат-бот за всё» — собрать стек из пяти evidence-слоёв (поиск, статика, runtime, telemetry, реляционный граф) и поставить LLM-actor последним звеном.

Этот список не означает «установите всё». Сначала определите, какой вопрос вы хотите сделать дешёвым: найти символ, поймать уязвимость, объяснить latency, удалить данные по запросу пользователя или проверить изменение через LLM.

Как выбирать: зрелость важнее количества stars

Для каждого инструмента я использовал четыре фильтра:

есть ли понятный primary source и живая документация;

насколько инструмент подходит для production-сценария, а не только для demo;

где проходит граница OSS, коммерческих функций и vendor lock-in (зависимость от конкретного вендора);

что происходит с кодом, логами и персональными данными при self-hosted (своя инфраструктура) и SaaS-развёртывании.

Термин «mature» здесь означает, что инструмент имеет устойчивый production-сценарий и не находится в beta или maintenance mode (режим заморозки). Это не обещание отсутствия багов. И наоборот: beta-инструмент может быть очень быстрым и удобным, но его нельзя бездумно ставить в blocking gate (блокирующая проверка CI). Но вы это и сами знаете.

1. Поиск по коду: сначала найдите факты

Поиск по коду — самый недооценённый слой. Прежде чем строить граф и подключать LLM, вы должны уметь быстро ответить на вопросы «где объявлено», «кто вызывает», «в какой ветке это изменилось» и «есть ли такая же проблема в соседних репозиториях».

Sourcegraph и Zoekt

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 и livegrep

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 будет красиво пересказывать неполный индекс, а команда не сможет проверить ответ простым повторным запросом.

2. Статический анализ: разделяйте быстрый feedback и глубокое расследование

Вместо одного «магического» анализатора полезно разделить работу по стоимости.

Ruff — быстрый Python-linter и formatter. Он заменяет несколько привычных инструментов и хорошо подходит для каждого локального запуска и каждого pull request.

Semgrep — pattern-based SAST, SCA и secrets scanning. YAML-правила легко писать и ревьюить. Это хороший слой для кастомных правил команды и быстрого поиска опасных паттернов.

CodeQL — GitHub code-as-data движок. Запросы работают по реляционной модели разобранного кода и особенно полезны для vulnerability hunting, data-flow и повторного запуска одного правила на множестве репозиториев. CodeQL живёт на границе STATIC и GRAPH: со стороны static он работает как глубокий анализатор, со стороны graph — как реляционный query engine (см. диаграмму шести слоёв выше).

SonarQube Community Build — широкий quality-gate слой с большим покрытием языков и правил. Его удобно использовать для портфельного отчёта и единых gate-правил, но глубина функций зависит от редакции.

ty — быстрый Python type checker из экосистемы Astral. На 2026-07-23 это всё ещё 0.0.x (последний релиз 0.0.63), несмотря на зрелость LSP, поддержку Pydantic и регулярные релизы. Подходит для экспериментов и неблокирующего feedback, но в production gate без отдельного тестового окна не ставить.

Практичная схема выглядит так: Ruff и локальные Semgrep-правила дают быстрый feedback; CodeQL и глубокий taint-анализ запускаются в CI; SonarQube собирает межрепозиторную картину качества. При этом один и тот же finding должен иметь owner, severity, suppression reason и срок пересмотра. Иначе инструмент просто производит backlog.

3. Runtime tracing и profiling: код объясняет намерение, продакшен — факт

Статический анализ не показывает, какая ветка реально выполняется и где тратится время. Для Linux-native систем базой остаются perf (подсистема профилирования Linux) events, perf, ftrace и инструменты Brendan Gregg. Они дают аппаратные counters, kernel tracepoints, kprobes, uprobes и USDT с небольшими накладными расходами.

bpftrace удобен, когда нужно быстро написать диагностический запрос без отдельной C-программы: посмотреть системные вызовы, latency блокировок, сетевые события или поведение процесса. Это зрелый инструмент, но он требует Linux с поддержкой BPF и не заменяет полноценную систему непрерывного профилирования.

Для JVM нужен async-profiler. Он снимает CPU и heap profiles, работает с native frames, JIT и GC-потоками и умеет отдавать результат в JFR и flame graph. В Java-сервисе это обычно более полезный старт, чем попытка применять универсальный агент ко всем языкам.

Для continuous profiling можно выбрать Pyroscope или Parca:

Pyroscope хорошо вписывается в Grafana ecosystem и удобен, если рядом уже есть Loki, Tempo и Mimir.

Parca использует eBPF agent и pprof-формат, поэтому особенно интересен для Go, Rust, C/C++ и Kubernetes без добавления SDK в приложение.

Профиль без контекста бесполезен. Каждое измерение должно быть связано с версией сборки, сервисом, окружением и временным окном. Иначе flame graph превращается в картинку без причинности.

4. Logs и observability: сначала стандарт данных, потом backend

Главное решение в observability — не «Loki или Elastic», а то, сохраните ли вы возможность заменить backend без переписывания instrumentation.

OpenTelemetry стоит ставить в этот слой первым. Это vendor-neutral модель данных, SDK и Collector для traces, metrics и logs. OTel не хранит данные и не является системой поиска, но задаёт общие semantic conventions, маршрутизацию и границу между приложением и backend.

Дальше выбор зависит от формы запросов:

Grafana Loki — label-based aggregation, дешёвое хранение и хорошая связка с Grafana. Не следует ожидать от него поведения полнотекстового Elasticsearch: body лога не индексируется так же глубоко, а high-cardinality labels (метки с огромным числом значений) могут ухудшить работу.

Quickwit — S3-native поисковый backend на Tantivy. Он интересен для больших объёмов логов и трасс с columnar storage. Наличие delete tasks помогает строить процессы удаления, но само по себе не делает deployment GDPR-compliant.

OpenObserve — single-binary observability backend на Rust с SQL и PromQL. Он удобен для небольшого self-hosted контура, но AGPL-3.0 (копилефт-лицензия) и более молодая экосистема требуют отдельного legal и operational review.

Elastic Stack — зрелый выбор, если нужен глубокий full-text search, богатая ingest-экосистема и SIEM-сценарии. Лицензирование и стоимость хранения нужно рассматривать отдельно от технических возможностей.

Для self-hosted SaaS AGPL может быть приемлема, но для встраивания компонента в закрытый коммерческий продукт юридическая оценка обязательна. Также заранее определите retention, data residency, erase workflow и доступ к логам. Нельзя обещать пользователю удаление данных, если выбранный storage не умеет надёжно найти и удалить все копии.

5. Расследование с помощью LLM: модель не источник истины

LLM полезна, когда она сокращает путь от вопроса к проверяемым фактам. Она опасна, когда выдаёт уверенное объяснение поверх неполного индекса.

Aider — сильный OSS-вариант для terminal-based работы. Он умеет строить карту репозитория, работать с разными моделями, автоматически запускать lint и tests и фиксировать изменения в git. Его естественная роль — управляемый CLI-помощник, а не автономный production-deployer.

Cursor удобен как enterprise IDE, а Sourcegraph Cody логичен для команды, которая уже использует Sourcegraph и хочет подавать модели его code graph. У обоих вариантов есть цена: коммерческая зависимость, vendor-specific indexing и необходимость проверить, куда отправляются исходники, prompts, snippets и результаты поиска.

Devin позиционируется как автономный coding agent для end-to-end задач (issue → patch → PR). На 2026-07 он остаётся коммерческим продуктом с закрытым runtime, и для code intelligence сценариев его стоит рассматривать только как black-box: ссылок на промежуточные evidence нет, воспроизводимый trace требует отдельной договорённости с вендором.

Continue.dev больше нельзя рекомендовать как базу для новых установок: согласно README репозитория continuedev/continue, он больше не поддерживается и оставлен read-only после финального релиза 2.0. Его можно изучать как исторический reference для prompt patterns, но это не текущий deployment target.

Минимальный guardrail для любого LLM-инструмента:

модель получает только разрешённые репозитории и ветки;

каждый ответ содержит ссылки на файлы, символы, коммиты или runtime traces;

изменения сначала попадают в diff, а не сразу в production;

lint, tests, SAST и секрет-сканирование запускаются после генерации;

доступ к чувствительному коду, логам и персональным данным проходит отдельный review.

Если модель не может показать evidence, это гипотеза, а не finding.

6. Граф знаний: разные графы отвечают на разные вопросы

Термин «knowledge graph (реляционная модель кода) кода» часто используют для трёх разных вещей.

OpenRewrite строит Lossless Semantic Tree и применяет type-aware recipes. Это сильный выбор для массовых refactoring и framework migrations: вместо regex-замены инструмент понимает структуру программы и может повторно применить рецепт к нескольким репозиториям. Но зрелость парсеров различается по языкам: Java обычно покрыт лучше, чем более новые направления.

CodeQL хранит код в реляционной модели, которую на практике можно использовать как knowledge model: запросы выражают связи между источниками данных, вызовами, типами и sink-ами. Это особенно полезно для security и cross-repo поиска уязвимых паттернов.

SCIP — индексный формат 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.

Иллюстрация · evidence loop (closed verification loop), четыре стадии

Каждое сгенерированное изменение должно пройти через цикл обратно через детерминированную верификацию и human review. Каждая метка под стадией несёт source-layer tag, совпадающий с диаграммой шести слоёв.

Find Explain Verify Change

Три практичных профиля внедрения

Иллюстрация · профили внедрения с общей governance baseline

Общая governance baseline важнее конкретного vendor mix. Compliance-sensitive — это overlay, который пересекает оба основных профиля, а не третий стек инструментов.

OSS / self-hosted

GitHub-centric enterprise

compliance-sensitive overlay (applies on top)

На диаграмме выше compliance-sensitive concerns показаны как горизонтальный overlay, пересекающий оба основных профиля, а не как третий равноправный столбец. Compliance ортогонален выбору инструментов: можно запускать OSS или GitHub-centric, и в обоих случаях можно включать compliance-sensitive режим. Два вопроса — какой vendor mix? и какой compliance posture? — независимы.

OSS-only и self-hosted

Zoekt, Semgrep OSS, CodeQL CLI, Ruff, perf/bpftrace, OpenTelemetry, Loki или Quickwit, Aider и OpenRewrite. Этот вариант даёт контроль над кодом и данными, но требует собственной работы над auth, indexing, UI, retention и upgrades.

GitHub-centric enterprise

Sourcegraph или GitHub-native search, CodeQL, Semgrep, SonarQube, OpenTelemetry, выбранный observability backend, Cody или Cursor. Это быстрее запускается, но нужно заранее зафиксировать границы SaaS, стоимость индексации и exit plan.

Compliance-sensitive production

Начните не с LLM, а с data map: какие репозитории, логи и профили содержат персональные данные, где они хранятся, кто имеет доступ и как выполняется deletion request (запрос на удаление данных). После этого выбирайте self-hosted indexing, OTel (Открытый стандарт данных телеметрии (traces, metrics, logs) с vendor-neutral SDK и Collector; задаёт формат, но не хранит данные.) Collector с фильтрацией, backend с понятным retention и только затем AI-инструмент с проверенной политикой обработки данных.

План внедрения: четыре этапа

Иллюстрация · rollout из четырёх этапов с exit gates

AI — это последний добавленный слой, а не первая покупка. Каждый этап заканчивается явным exit gate; следующий этап начинается только после того, как gate удовлетворён.

Этап 1 — inventory

Этап 2 — static baseline

Этап 3 — runtime loop

Этап 4 — guarded AI

Этап 1 — inventory. Зафиксировать языки, репозитории, ветки, владельцев, вопросы расследований и data classification. Выбрать один pilot repository.

Этап 2 — static baseline. Подключить Ruff или language-native linter, Semgrep и один глубокий анализатор. Удалить шум, назначить owners и завести regression corpus.

Этап 3 — runtime loop. Включить OpenTelemetry, собрать минимальные traces и logs, добавить perf или async-profiler для одного критичного сервиса. Связать каждое событие с build revision.

Этап 4 — guarded AI. Подключить Aider, Cody или Cursor только к pilot scope. Требовать citations, diff, tests и security checks. Сравнить ответы модели с фиксированным набором расследований.

После пилота измеряйте не количество инструментов и не token spend, а time-to-find, time-to-explain, долю findings с reproducible evidence, false-positive rate и время от runtime-сигнала до исправления.

Контрольные точки перехода

Каждый этап на диаграмме заканчивается явным exit gate. Следующий этап начинается только когда gate удовлетворён — это правило последовательности, а не календарное правило. Gate — это однострочный проверяемый критерий, а не цель:

Gate 1 — pilot repository. Назначен owner, зафиксирован scope (какие репозитории, ветки, окружения), существует документ data classification. Без этого этап 2 будет оптимизировать шум, а не findings.

Gate 2 — owned findings. У каждого finding статического анализа есть owner, severity и либо путь исправления, либо явный suppression reason. Linter и Semgrep подключены; один глубокий анализатор (CodeQL или другой) выдаёт curated output.

Gate 3 — release-to-event link. Каждое событие телеметрии (trace, log line, profile sample) несёт build revision, service, environment и временное окно. Flame graph или log-запрос без этого контекста не отвечает на вопрос «это наше изменение?».

Gate 4 — cited & gated. Каждый ответ модели содержит ссылки на файлы, символы, queries или traces; каждый сгенерированный diff проходит tests, SAST и человеческое ревью; LLM подключён только к pilot scope. Без этого этап 4 производит чат, а не workflow.

Если gate не выполнен — сначала чините разрыв, потом продолжаете. Pilot repository и gates — единственные durable артефакты, которые переживают rollout; всё остальное можно заменить.

Антипаттерны

Выбирать по stars. Популярность не заменяет permission model, retention, reindex cost и ответственность за эксплуатацию.

Строить граф до базового поиска. Граф усложнит систему, но не исправит плохой индекс.

Использовать LLM-as-source-of-truth. Ответ модели без ссылок на код, query или trace — только гипотеза.

Подключать SaaS к чувствительному коду без review. Индексация и prompts могут содержать больше данных, чем кажется по интерфейсу.

Считать AGPL технической деталью. Для embedded closed-source сценария это отдельный legal decision.

Ставить beta-инструмент в blocking gate. Для ty нужен режим наблюдения и явная фиксация версии до выхода из 0.0.x.

Хранить логи без erase plan. Нельзя обещать privacy, если не описаны raw data, replicas, backups и срок удаления.

Запускать все анализаторы на каждый commit. Разделяйте быстрый feedback, PR checks и nightly/full scans.

Использовать maintenance-mode-проект для нового ядра. Hound и архивированный Continue могут быть полезны как reference, но не как стратегический foundation.

Что перепроверить перед публикацией

Code intelligence быстро меняется, поэтому эту статью нельзя считать вечным каталогом:

commercial pricing и roadmap Sourcegraph, Cursor, Cody и Devin нужно проверять перед каждым внешним обновлением;

Quickwit остаётся в 0.8.x (последний релиз v0.8.2 на 2026-07-23), поэтому breaking changes требуют pinning и тестового upgrade;

ty следует пересмотреть после релиза 1.0 или появления production benchmark против mypy и Pyright (на 2026-07-23 — всё ещё 0.0.63, несмотря на LSP и поддержку Pydantic);

Continue.dev остаётся archived reference: репозиторий continuedev/continue read-only после финального релиза 2.0, активной разработки нет;

лицензии и условия AI-indexing нужно проверять по актуальному тексту перед enterprise rollout;

regulatory claims нужно сверять с юридической командой, а не с описанием observability-продукта.

Для такой области разумен re-fetch каждые шесть месяцев, а для commercial AI tooling и compliance-sensitive deployments — перед каждым существенным изменением.

Источники

Поиск по коду

Sourcegraph Code Search: https://sourcegraph.com/docs/code-search

Zoekt: https://github.com/sourcegraph/zoekt

OpenGrok: https://github.com/oracle/opengrok

livegrep: https://github.com/livegrep/livegrep

Hound: https://github.com/hound-search/hound

Статический анализ

Semgrep: https://docs.semgrep.dev/

CodeQL: https://codeql.github.com/docs/

SonarQube: https://www.sonarsource.com/products/sonarqube/

Ruff: https://github.com/astral-sh/ruff

ty: https://github.com/astral-sh/ty

Трассировка и профилирование

Linux perf: https://www.brendangregg.com/perf.html

perf-tools: https://github.com/brendangregg/perf-tools

bpftrace: https://github.com/bpftrace/bpftrace

async-profiler: https://github.com/async-profiler/async-profiler

Pyroscope: https://pyroscope.io/docs/

Parca: https://github.com/parca-dev/parca

Логи и телеметрия

OpenTelemetry: https://opentelemetry.io/docs/

Grafana Loki: https://grafana.com/oss/loki/

Quickwit: https://github.com/quickwit-oss/quickwit

OpenObserve: https://github.com/openobserve/openobserve

Elastic Logstash: https://github.com/elastic/logstash

Исследование с LLM и модели кода

Aider: https://github.com/Aider-AI/aider

Cursor: https://www.cursor.com/

Sourcegraph Code Search and code-graph context: https://sourcegraph.com/docs/code-search

Continue.dev status (archived, read-only after final 2.0): https://github.com/continuedev/continue

Devin: https://www.cognition.ai/devin

OpenRewrite: https://github.com/openrewrite/rewrite

Compliance-ссылки

Federal Law N 152-FZ (закон о персональных данных), официальная публикация: http://pravo.gov.ru/proxy/ips/?docbody=&nd=102108261

Federal Law N 152-FZ, текст в правовой системе: https://www.consultant.ru/document/cons_doc_LAW_61801/

GDPR Article 17 (right to erasure): https://gdpr-info.eu/art-17-gdpr/

Quickwit delete-tasks feature: https://quickwit.io/docs/operating/storage/