Граф кода одной командой: ставим graphlens-mcp в проект и перестаём жечь токены на grep
Третья часть серии. В первой я разбирал сам движок graphlens — что он делает и как устроен внутри. Во второй гонял бенчмарк на 936 прогонов и смотрел, где граф реально окупается, а где проще остаться с grep. Здесь — про то, что осталось за кадром в обеих частях: движок это ещё не инструмент, и чтобы подключить его к агенту, поверх нужно дописать прилично кода. Вот этот код я и собрал в отдельный продукт. graphlens-mcp ставится одной командой, дальше работает сам. Он в alpha, бесплатный (MIT), и прогнать его на своём проекте можно минут за пять.
Сколько стоит контекст для кодового агента: grep vs граф vs LSP на большом проекте (936 прогонов)
Продолжение статьи про graphlens. Там я описал, что инструмент делает и как устроен, и по дороге уверенно заявил, что «агент жжёт токены, бегая grep'ом по репозиторию». Заявил — но ни одной цифры не привёл. Эта статья закрывает дыру: вот замеры, вот данные, вот воспроизводимый стенд. Спойлер: вывод оказался не таким, каким я его себе рисовал, и это самое интересное.КороткоЯ взял одного и того же агента (Claude Code), менял у него ровно одну вещь — какой MCP-сервер отдаёт контекст по коду, — и гонял по 26 задачам на apache/superset. Четыре «руки»: filesystem
graphlens: превращаем репозиторий в типизированный граф — Python, TypeScript, Go и Rust в одной модели
Любой инструмент для «понимания кода», которым я пользовался, рано или поздно упирался в одну из двух стен.Первая — цикл «grep → открыть → прочитать → перейти по импорту → снова grep». Работает, но медленно, и у него нет ни малейшего представления о том, что process_order, найденный в services.py — это тот самый process_order, который вызывается из api.py, а не однофамилец из tests/. Когда этим занимается LLM-агент, он ещё и сжигает на этом тонну токенов.Вторая стена — моноязычность
Команда PVS-Studio просит присылать примеры ошибок, связанные с использованием вайб-кодинга
PVS-Studio, Вайб-кодингЕсть две школы мысли.
Синдром тревожного анализатора и разработчика-заложника
Мы просто смотрим на экран. Один варнинг. Один, но он красный. Он "орёт". Не получается сразу понять, в чём дело. Условный рефлекс срабатывает, и уже открывается Git. Сейчас пофиксим, а потом подумаем. Даже если предупреждение касается чего-то безобидного, один красный прямоугольник на фоне зелёных строчек может парализовать внимание.
Необходимость статического анализа для РБПО на примере 190 багов в TDengine
Одна из важнейших составляющих безопасной разработки программного обеспечения — это статический анализ кода. Он позволяет выявить ошибки и потенциальные уязвимости на ранних этапах разработки ПО, что сокращает стоимость их исправления. Но что ещё важнее, он позволяет выявить те проблемы и дефекты безопасности, о которых разработчики даже не подозревают.
