Ваш AI-агент не понимает код. Он просто очень уверенно угадывает — поэтому мы создали SLICER

“AI agents write units of changes that look good in isolation. They are consistent with themselves and your prompt. But respect for the whole…”

«AI-агенты создают отдельные изменения, которые хорошо выглядят сами по себе. Они согласованы внутри себя и соответствуют вашему запросу. Но целостность всей системы при этом остаётся без внимания».

— Mo Bitar, создатель Standard Notes, после двух лет активной разработки с AI

AI-агент хорошо пишет код локально, но теряет систему целиком — поэтому мы создали CodeSlicer

Содержание

1. По отдельности всё работает. Вместе — разваливается

2. Решение проблемы

3. Сценарии использования

4. Как работает алгоритм

5. Как проверяется достоверность

6. Что показали тесты

7. Как выглядит результат

8. Чем CodeSlicer отличается от похожих инструментов

9. Что можно построить поверх CodeSlicer

10. Почему registry библиотек важнее ещё одного prompt

11. Не весь граф должен стать зелёным

12. Что будет дальше

13. Возможная модель монетизации

14. Итог

По отдельности всё работает. Вместе — разваливается

AI-агент хорошо пишет код локально. Он добавляет функцию, чинит тест, меняет компонент или создаёт endpoint. Изменение выглядит аккуратно, проходит ближайшие проверки и соответствует последнему сообщению пользователя.

А потом ломается сайт, пропадает часть пользовательского сценария или внезапно перестаёт работать соседний сервис. В коде нет одной очевидной строки с ошибкой: проблема возникает на границе нескольких модулей.

Локально — блеск. Глобально — каша.

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

• один агент выбирает provider, не заметив вторую реализацию;

• другой меняет HTTP wrapper, но не видит backend route;

• третий исправляет service, не зная о background consumer;

• четвёртый обновляет frontend client, но оставляет старый barrel export;

• тесты проходят в одном сценарии, а соседний пользовательский путь перестаёт работать.

Каждый отдельный фрагмент может выглядеть правильно. Общая система при этом становится несогласованной. Агент пишет хорошие отдельные главы, но постепенно теряет сюжет всей книги.

Большой проект больше похож на нервную систему, чем на набор независимых файлов. Сигнал от одной функции проходит через DI-контейнер, сервисы, базы данных, HTTP-границы, очереди, frontend и тесты.

Одна правка в сигнатуре или provider binding (связывании зависимости с реализацией) может пройти через несколько языков и слоёв проекта. Главный вопрос не в том, где встречается имя функции, а в том, какие пути между компонентами существуют на самом деле.

Опытный разработчик может чувствовать эти связи из контекста проекта. AI-агент вынужден восстанавливать их по частям, в пределах текущего контекстного окна. Он может открыть не тот файл, забыть ранее найденную альтернативу или достроить правдоподобный target (целевой символ) там, где доказательств недостаточно.

Разработчик может помнить, какой provider создаёт сервис, какой wrapper ведёт к endpoint и почему два метода с одинаковым именем живут в разных классах. Агенту приходится собирать этот пазл вслепую — по кусочкам, без картинки на коробке.

Отсюда возникает центральный вопрос статьи:

Как отличить настоящую связь в кодовой базе от убедительной истории, которую достроил AI?

Какой именно save вызывается?

Рассмотрим простой код:

class OrderService:
    def __init__(self, repository):
        self.repository = repository

    def create_order(self, order):
        return self.repository.save(order)

Первое предположение выглядит очевидным:

self.repository → OrderRepository → OrderRepository.save

Но такой вызов сам по себе не доказывает target. В проекте могут существовать OrderRepository.save, PaymentRepository.save, AuditRepository.save и MockRepository.save. Объект может приходить через constructor DI, provider, factory, registry или runtime-конфигурацию.

Extractor видит наблюдаемый факт:

receiver: self.repository
method: save

Дальше нужно проверить constructor parameter, provider binding, concrete type, field assignment и method lookup. Только такая цепочка позволяет связать вызов с конкретным методом.

Вероятная связь и доказанная связь — не одно и то же. Confidence без evidence — это просто красиво оформленная догадка.

Решение проблемы

Вайбкодинг ускоряет написание кода, но плохо отвечает на вопрос: что ещё изменится после этой правки?

Изменение одного метода может пройти через несколько уровней:

React-компонент
→ hook
→ API client
→ HTTP wrapper
→ endpoint
→ backend route
→ service
→ repository
→ database
→ background task

Обычный поиск по строке видит совпадение имени. AI-агент может прочитать несколько файлов, но часто теряет связь между ними, особенно когда в проекте есть dependency injection, aliases и re-export, вложенные router prefixes, динамические HTTP paths, несколько классов с одинаковыми методами, frontend и backend на разных языках, фоновые задачи и event handlers.

CodeSlicer — локальный CLI, MCP-сервер и визуальный интерфейс, которые строят граф влияния проекта и отвечают не только «где встречается символ», а:

Что затронет изменение, почему система считает это связанным и каким частям результата можно доверять?

CodeSlicer можно подключить к KODIK IDE, Cursor, Windsurf, Codex, Claude Code, Antigravity и другим AI-агентам через CLI, MCP и agent skills. Инструмент не заменяет редактор, а даёт агенту проверяемый граф проекта и контекст влияния.

Главное свойство CodeSlicer — разделение факта и гипотезы:

1. extractor извлекает то, что непосредственно написано в коде;

2. resolver пытается связать факт с конкретным символом;

3. support pack добавляет правила конкретного фреймворка;

4. quality guard проверяет provenance и противоречия;

5. impact query строит цепочку и помечает слабые участки;

6. AI получает граф как контекст, но не может напрямую записать в него подтверждённую связь.

Что получает разработчик

Результатом является не картинка ради картинки, а воспроизводимый GraphDocument. В нём есть узлы, рёбра, статусы разрешения, confidence, evidence chain и provenance.

{
  "from": "OrderService.create_order",
  "to": "OrderRepository.save",
  "kind": "CALLS",
  "resolution_status": "resolved",
  "evidence_class": "static_inferred",
  "validation_status": "not_validated",
  "confidence": 0.86,
  "resolver_id": "typed_receiver_resolver",
  "source_fact_ids": [
    "fact:field-binding:self.repository",
    "fact:call:self.repository.save",
    "fact:declaration:OrderRepository.save"
  ],
  "evidence": [
    "constructor parameter repository: OrderRepository",
    "self.repository = repository",
    "self.repository.save(order)"
  ]
}

Если target нельзя выбрать однозначно, система не должна угадывать:

ambiguous
unresolved
unsupported_semantics
quarantine

Это менее эффектно, чем нарисовать лишнюю стрелку, но гораздо полезнее для PR-review и агентской разработки.

Не просто граф

Визуальная карта сама по себе не отвечает на вопрос, что делать после изменения. Для агента ценность появляется, когда он получает компактный impact slice (ограниченный срез области влияния):

изменённый узел
+ связанные callers и callees
+ endpoints и пользовательские сценарии
+ релевантные тесты
+ evidence каждой связи
+ альтернативные кандидаты
+ unresolved boundaries

CodeSlicer не заменяет IDE и не пишет код вместо агента. Агент по-прежнему принимает решение и редактирует проект. CodeSlicer отвечает на другой вопрос:

Какой минимальный и проверяемый контекст нужен агенту именно для этой задачи?

Сценарии использования

Найти причину поломки сайта

После изменения OrderRepository.save агент запрашивает:

Покажи все подтверждённые и вероятные цепочки, которые могут быть затронуты изменением OrderRepository.save.
Отдельно покажи frontend, routes, background tasks, tests и unresolved areas.

Ответом становится не список совпадений, а impact-цепочка с доказательствами.

Проверить pull request

В текущем PR-review workflow CodeSlicer принимает diff, сопоставляет изменённые файлы и символы с графом, а затем выдаёт must_change, should_review, possibly_related, подозрительные связи, рекомендуемые тесты и причины высокого риска.

Важно: diff определяет изменённые символы, но не заменяет полный анализ проекта. Для большого проекта нужен предварительно сохранённый граф или incremental workflow.

Дать AI-агенту компактный контекст

Вместо передачи всего репозитория агент получает изменённый узел, релевантный подграф, лучшие evidence paths, необходимые фрагменты файлов и unresolved/suspicious boundaries.

Это позволяет строить агентов для code review, миграций, рефакторинга и диагностики без постоянного повторного обхода всей кодовой базы.

Разобраться в незнакомом проекте

Сначала CodeSlicer показывает inventory, языки, библиотеки, routes, tests и архитектурные кластеры. Затем агент может задать типизированные вопросы:

Какие frontend-компоненты вызывают этот endpoint?
Какие сервисы используют этот repository?
Почему это ребро существует?
Какие области проекта не удалось разрешить?

Исследовать неизвестную библиотеку

В экспериментальном research workflow неизвестная библиотека не становится автоматически доверенным знанием. Система создаёт research task, а внешний AI-агент изучает официальную документацию и исходный код, формирует candidate support pack, добавляет positive и forbidden fixtures, запускает mutation и determinism tests, проходит trust lifecycle и только затем подключает правило к обычному анализу.

Как работает алгоритм

Схема показывает основной конвейер: проект сначала превращается в raw facts, затем факты нормализуются и разрешаются в semantic graph. Support packs подключаются к этапам семантического связывания, а неизвестные участки уходят в отдельный research workflow. AI предлагает правила и тесты, но не записывает подтверждённые рёбра напрямую.

Этапы конвейера

Почему support pack — это не просто набор regex

Support pack описывает, как библиотека участвует в нескольких слоях:

APIRouter
→ route declaration
→ include_router prefix
→ handler
→ Depends provider
→ service

Каждое framework-specific ребро должно иметь attribution:

{
  "support_pack": "python/fastapi",
  "rule_id": "fastapi.apirouter.post",
  "rule_version": "1.0.0",
  "trust_level": "verified_on_fixture",
  "resolver_hook": "fastapi_router_resolver",
  "matched_pattern": "@router.post",
  "evidence": [
    "local route decorator",
    "parent router prefix",
    "app.include_router prefix"
  ]
}

AI может предложить pack, но не может самостоятельно перевести его в confirmed без validation.

Статусы и доверие

confidence отвечает на вопрос «насколько сильна цепочка доказательств», а validation_status — «проверялась ли она наблюдением».

resolution_status: resolved | ambiguous | unresolved
evidence_class: static_proven | static_inferred | support_pack
validation_status: not_validated | runtime_observed

Если путь состоит из нескольких рёбер, его статус определяется самым слабым участком. Это не даёт длинной цепочке стать подтверждённой из-за нескольких сильных рёбер и одного слабого.

Что происходит при изменении проекта

В экспериментальном incremental workflow CodeSlicer сохраняет стабильные RawFact:

fact_id
fact_kind
canonical subject
canonical target
normalized properties
evidence location
provides dependency keys
consumes dependency keys

После изменения файла вычисляется FactDiff, затем через reverse dependency index находятся affected facts, edges и resolvers. Незатронутые факты и рёбра переиспользуются, а derived annotations пересчитываются детерминированно.

Как проверяется достоверность

Нельзя доказать качество impact analyzer только количеством nodes и edges. Поэтому benchmark проверяет не только наличие ожидаемых связей, но и отсутствие ложных.

Expected и forbidden edges

Для каждого fixture задаются две группы:

expected_edges
forbidden_edges

Например, для fullstack order-flow ожидается связь OrderRepository.save с OrderService.create_order и POST /api/v1/shop/orders. При этом users route и saveOrderDraft должны быть исключены, даже если их имена похожи.

Mutation testing

Система намеренно меняет evidence:

• удаляет constructor binding;

• заменяет provider;

• добавляет второго кандидата;

• удаляет import;

• меняет receiver type;

• убирает HTTP wrapper;

• меняет route prefix.

Ожидаемый результат — edge исчезает, target меняется, статус становится ambiguous, создаётся quarantine или снижается confidence. Связь не может остаться прежней confirmed только потому, что совпало имя метода.

Determinism

Одинаковый проект с одинаковой конфигурацией должен давать одинаковые canonical IDs, logical edges, unknown-region fingerprints и core semantic fingerprint. Timestamp, абсолютный временный путь и порядок runtime observations не должны менять смысловой результат.

Runtime observation не является абсолютной истиной

Если тест реально прошёл через вызов, это подтверждает только наблюдение в конкретном сценарии, окружении и конфигурации. Это не доказывает, что тот же путь выполняется всегда.

Корректный статус выглядит так:

STATIC_RESOLVED + RUNTIME_OBSERVED

А отсутствие вызова в одном тесте не считается доказательством отсутствия связи. Ветка могла не выполниться, объект мог быть замокан, а instrumentation мог не поддержать subprocess или async boundary.

Что измерять на реальном проекте

Высокая precision на маленьком fixture не означает полного понимания любой production-кодовой базы. Это означает, что конкретный паттерн доказуемо поддерживается.

Что показали тесты

Техническая схема имеет смысл только тогда, когда её можно проверить на размеченных сценариях. На текущем наборе тестовых сценариев результаты такие.

Python semantic resolution

TypeScript и frontend-backend bridge

• 12 тестовых сценариев;

• 15 mutation-сценариев;

• 4 cross-language сценария;

• endpoint precision: 1.0;

• forbidden violations: 0.

Эти результаты относятся только к размеченным и поддерживаемым паттернам. Они не означают, что CodeSlicer уже полностью понимает любую production-кодовую базу. Их смысл в другом: на конкретных конструкциях можно показать не только найденные связи, но и отсутствие запрещённых связей, реакцию на потерю evidence и стабильность результата.

Как выглядит результат

У каждого узла есть canonical identity, kind, location, язык, роль и связи. У каждого ребра — kind, direction, confidence, status, resolver и цепочка evidence.

Пример маршрута:

HTTP POST /api/v1/shop/orders
← FastAPI create_order
← OrderService.create_order
← OrderRepository.save

Или fullstack-цепочка:

OrderCreateForm
← useOrders
← api.orders.createOrder
← HTTP POST /api/v1/shop/orders
← FastAPI route

Чем CodeSlicer отличается от похожих инструментов

Важно не сравнивать инструменты только по слову «граф». Они решают разные задачи.

Graphify, CodeSee, Sourcegraph и Joern не нужно объявлять хуже. CodeSlicer может дополнять их:

Graphify / Sourcegraph → навигация и обзор
Joern / Semgrep / CodeQL → security и data-flow findings
CodeSlicer → impact, provenance, framework chains и контекст для агента

Сравнение сделано по официальным материалам:

• Graphify: concepts;

• Sourcegraph: Code Navigation;

• CodeSee: overview;

• Joern: documentation.

Что можно построить поверх CodeSlicer

Semantic graph — это инфраструктурный слой. На его основе можно строить несколько продуктов.

Багфиксы с ограниченной областью поиска

Если после создания заказа не обновляется остаток товара, агент получает не весь проект, а цепочку:

POST /orders
→ OrderService
→ OrderRepository
→ InventoryClient
→ stock update event
→ связанные тесты

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

Выбор тестов

При изменении метода можно найти связанные regression cases, незакрытые ветки, тесты на соседние endpoints и high-risk edges, которые стоит подтвердить runtime trace. Так test selection становится анализом реальной цепочки, а не поиском файлов по похожему имени.

Code review и оценка риска

PR review может показать:

HIGH:
изменена общая authorization-функция
затронуто 14 endpoints
tests покрывают только 8

UNKNOWN:
один путь проходит через dynamic provider

Такой отчёт отделяет обязательные проверки от вероятных и неизвестных.

Безопасный рефакторинг и миграции

Перед изменением публичной сигнатуры, DTO, endpoint или database model можно построить область влияния. Это применимо к переименованиям, миграции REST API, обновлению библиотеки, замене HTTP wrapper и разделению монолита.

Incident response

Во время инцидента исходной точкой может быть endpoint, stack trace, event name или database table. Граф помогает восстановить upstream и downstream:

runtime symptom
→ handler
→ service
→ external client
→ event consumer
→ affected tests

то не замена logs и distributed tracing, а способ связать runtime-сигнал со структурой исходного кода.

Multi-agent разработка

Большую задачу можно разделить по веткам impact graph:

agent 1 → backend route и service
agent 2 → frontend client и component
agent 3 → database и migration
agent 4 → tests и verification

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

Security impact

CodeSlicer не заменяет taint analyzer или vulnerability scanner. Но после обнаружения опасного sink он может показать, какие внешние entrypoints до него доходят, какие сервисы используют уязвимый wrapper, какие endpoints затронуты и где остаётся unresolved dynamic dispatch.

Почему регситрация библиотек важнее ещё одного промта

Если каждый пользователь отдельно просит AI исследовать одну и ту же библиотеку, появляются несовместимые и непроверенные правила. Проверенный registry может хранить не только support pack, но и его доказательную базу:

library metadata
→ supported versions
→ semantic rules
→ official sources
→ positive fixtures
→ forbidden cases
→ mutation history
→ trust level
→ compatibility report

Пользовательский CodeSlicer при этом остаётся лёгким и локальным. Он получает версионированные правила, но исходный проект и GraphDocument продолжают храниться у пользователя.

Это не «облако, которое знает всё автоматически». Это каталог проверенных правил, где каждый pack проходит validation и имеет историю доверия.

После анализа большая кодовая база не обязана превратиться в полностью зелёную сеть. Правильный результат выглядит так:

confirmed
inferred
ambiguous
unresolved
unsupported_semantics

Неизвестность — часть результата, а не ошибка интерфейса. Если resolver не может доказать target, безопаснее вернуть unresolved, чем показать уверенную связь, которая приведёт агента к неправильному файлу.

Что будет дальше

Ближайшие технические задачи

1. расширение semantic providers для TypeScript/JavaScript;

2. повышение точности Go и Java без притворства compiler-level parity;

3. реальные incremental rebuild и equivalence checks;

4. runtime observation для pytest и других тестовых runners;

5. больше negative и mutation benchmarks;

6. безопасное закрытие unknown regions через повторяемые research tasks;

7. лучшее измерение context selection и token saving.

Библиотечный registry

Следующий этап — вынести локальные support packs в отдельное версионированное хранилище с compatibility reports, fixtures и историей validation. Подробно идея registry разобрана выше.

Локальный CodeSlicer при этом останется лёгким: CLI, MCP, parser, graph, cache и данные проекта будут работать у пользователя, а registry будет поставлять проверенные правила и их доказательную базу. Неизвестная библиотека может быть исследована агентом пользователя, но это будет candidate knowledge до прохождения validation.

Возможная модель монетизации

Базовый локальный движок может оставаться бесплатным и открытым: CLI, MCP, локальный parser, локальный GraphDocument, базовые public support packs и визуальный интерфейс.

Платными могут быть отдельные сервисы:

1. Verified Registry — проверенные packs, версии, fixtures и совместимость;

2. Private Registry — внутренние библиотеки и закрытые framework rules организации;

3. Team Impact CI — PR checks, history, dashboards и policy gates;

4. Research and Verification — исследование неизвестных библиотек с автоматической проверкой pack;

5. Enterprise self-hosted — registry и CI внутри VPC.

Ключевое ограничение: платный registry не должен означать обязательную загрузку исходного кода пользователя. В базовой модели CodeSlicer анализирует проект локально, а registry поставляет только версионированные правила и их доказательную базу.

Итог

CodeSlicer — не попытка заменить все существующие инструменты анализа кода одним графом. Это слой, который отвечает на другой вопрос:

Если изменить этот узел, какие части системы могут пострадать, какая цепочка это доказывает и где анализатор сам не уверен?

Для человека это impact report. Для AI-агента — компактный, структурированный и проверяемый контекст. Для команды — возможность обсуждать изменения через реальные цепочки, а не через догадки по совпадению имён.

AI уже научился быстро писать код. Теперь ему нужен слой, который не даст потерять систему целиком.

Источники исследования

• CodeSlicer на GitHub;

• Graphify: How it works;

• Sourcegraph: Code Navigation;

• CodeSee: Overview;

• Joern Documentation;

• SCIP Code Intelligence Protocol.