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

Моя моделька решила его не ставить :)

Если интересны причины, закину под спойлер

Скрытый текст

Коротко: смысл есть, но CodeSlicer пока не готов быть моим постоянным «навигатором по коду». Я бы не подключала его глобально и не доверяла ему выбор обязательных изменений или тестов. Как экспериментальный второй источник на крупном polyglot-проекте — интересен.

Что проверила:

Клонировала актуальный commit a400517.
Чистая установка на Windows/Python 3.13 работает.
Полный тестовый набор: 378 passed, 7 skipped за 19,3 с.
doctor: ok, native Tree-sitter доступен, загружаются 11 support packs.
Встроенные benchmark’и воспроизводятся: Python — 21 fixture, 20 TP, 0 FP/FN, 29 mutations; TypeScript — 12 fixture, 15 mutations, заявленная endpoint precision 1.0.
Небольшой full-stack fixture из 25 файлов анализируется примерно за 0,6 с.

То есть это не пустой README с нарисованной архитектурой. Реализация объёмная, CLI и MCP действительно существуют.

Что в идее полезно именно мне:

локальный граф без отправки исходников в облако;
evidence и provenance для связей;
явные ambiguous/unresolved, вместо попытки красиво угадать;
повторное использование графа для impact-запросов;
потенциально полезный компактный контекст для больших Python/FastAPI + frontend проектов.

Автор правильно отделяет инструмент от компилятора и признаёт частичную семантику JS/TS/Go/Java, dynamic DI и эвристический scoring. Это хороший признак инженерной честности. README с ограничениями

Но есть серьёзная проблема: главное обещание пока не подтверждается end-to-end.

На собственном fixture fullstack_react_ts_python я запросила влияние OrderRepository.save:

анализ дошёл до service и handler;
до route и frontend не дошёл;
endpoint-рёбра ссылаются на backend.app.api...create_order, тогда как реальный node имеет ID method:backend.app.api...create_order;
прямой пересчёт показал 52 ребра с отсутствующим endpoint-node, а impact-engine graph-quality сообщил dangling_edge_count: 0;
запрос direction=both захватил посторонний users-контур, хотя frontend/route нужного order-flow так и не показал.

Иными словами, отдельные «зелёные» рёбра есть, но сквозная цепь местами не соединена. Причём встроенные QA-проверки проверяют отдельные пары, а не непрерывный путь repository → service → handler → route → frontend → test. Статья обещает именно такую цепочку и quality gate для dangling edges. Заявления статьи

Есть и признаки очень ранней зрелости:

все 21 commit сделаны одним автором за 11–12 июля 2026 года;
нет настроенного CI;
1 star, 1 fork, опубликованных releases нет. История проекта, репозиторий

Это не приговор, просто пока лаборатория, а не измерительный прибор.

Мой вердикт:

идея: 8/10;
текущая реализация как research prototype: 6/10;
готовность стать моим доверенным MCP для ежедневной работы: 3/10.

Рекомендация: глобально не устанавливать. Если испытывать — то на одном реальном проекте в read-only режиме и сравнить 10 заранее известных изменений: recall затронутых компонентов, ложные связи, выбранные тесты, время и токены. До исправления invariant’ов node/edge и end-to-end benchmark я бы не допускала его ни к CI-gating, ни к автоматическому разделению работы между агентами.

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

Комментарии 3

Публикации