Comments 15
Моя моделька решила его не ставить :)
Если интересны причины, закину под спойлер
Скрытый текст
Коротко: смысл есть, но 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 имеет IDmethod: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, ни к автоматическому разделению работы между агентами.
Осталось сделать следующий шаг - предложить модельке, взять из проекта здравые идеи, если таковые в нем есть, и написать свой код, лишенный недостатков, обнаруженных в проекте. И результат выложить тут. Что бы другие читатели с твоим проектом сделали то же самое. :)
Или починить и сделать pr 💁♂️
Сейчас я не просто дорабатываю исходный проект, а фактически пересобираю продукт вокруг его сильных идей. CodeSlicer останется одним из ключевых источников impact-графа, но не единственным.
Цель — сделать local-first платформу: единый агрегатор, который сможет подключать Graphify, CodeGraph, SCIP/LSP, OpenAPI, OpenTelemetry, SARIF/SBOM, Joern и другие инструменты как опциональные источники доказательств. При этом их слабые и предположительные связи не будут автоматически влиять на итоговый риск или рекомендации.
Параллельно делаю новый localhost-интерфейс и затем расширение для VS Code.
Спасибо большое за подробный комментарий, сейчас активно улучшаем продукт, понимаем, что он пока на ранней стадии, через 3-4 дня можете снова протестировать, выйдет крупный апдейт с end to end сценариями)
Идея хорошая. Но проект ещё сыроват. Надеюсь, будет развиваться.
моя сказала раста нет, пока мимо
нафига вы lsp переизобретаете?
LSP не переизобретаем: используем готовые tsserver/Pyright/Roslyn как optional локальный semantic layer. А ещё CodeSlicer умеет работать с неизвестными библиотеками: не угадывает их семантику, а создаёт research workflow и отдельный versioned support pack с источниками, fixtures, confidence cap и проверкой. ИИ может предложить правило, но не может сам записать confirmed edge в граф.
https://www.agent-lsp.com/ или https://github.com/hewimetall/agent-lsp-real-inspect просто ?
крос, языковая lsp давно уже реализованно, к томуже например скаут по c c++ библиотекам или проектам, для полной поддержки нужно компилить проекты ( например я для скаутинга по cepth использую).
Кросс-языковой LSP мы и не считаем уникальной частью CodeSlicer — это optional semantic layer. Посмотрим Agent-LSP как готовый stateful backend с прогретым индексом. Основная ценность CodeSlicer остаётся в evidence-графе, сквозных связях, confidence, impact-анализе и подборе тестов.
Но согласен, по C/C++ замечание справедливое: одного подключения к clangd недостаточно, нужен build context — как минимум актуальный compile_commands.json, зависимости и иногда конфигурация или частичная сборка проекта. Сегодня буду исправлять и залью в гит изменения
Всё, из коробки уже это есть и упаковано в один go бинарь, как skill ( promt ) с lazy loaders :)
https://github.com/blackwell-systems/agent-lsp/blob/main/docs/index.md
включая eval через mypy
Понял, спасибо - посмотрел документацию поглубже.
Тогда нам нет смысла повторять этот слой. Логичнее подключить agent-lsp как готовый optional semantic backend, а в CodeSlicer оставить его часть: сопоставление с canonical evidence graph, сквозные frontend/backend и framework-связи, confidence, PR impact и подбор тестов. Отдельно проверим build context для clangd на реальных C/C++-проектах.
Есть ещё gortex — semantic graph + impact + MCP, 14 языков, cross-repo, 180+ tools.
Идея неплохая, но подача слишком самоуверенная. Будто достаточно построить граф зависимостей и хаос большого проекта испарится
Ваш AI-агент не понимает код. Он просто очень уверенно угадывает — поэтому мы создали SLICER