Разработчик построил единый поисковик по логам восьми AI-кодеров — чтобы не чинить баги дважды
Разработчик накопил 3,3 ГБ логов от восьми кодинг-агентов (Claude Code, Codex, Cursor и др.), каждый из которых пишет историю в свой недокументированный формат. После повторной отладки уже решённой проблемы он создал инструмент, который парсит все форматы в единый локальный индекс — чтобы искать старые решения вместо повторного дебага.
Если вы регулярно используете AI-агенты для кода, вы неизбежно тратите время на повторное решение одних и тех же проблем. Единая база знаний из логов превращает накопленный опыт в работающий актив — вместо того чтобы пылиться в разрозненных файлах.
Проблема: восемь агентов — восемь форматов
Современные кодинг-агенты (Claude Code, Codex, Cursor, Gemini и другие) записывают полные транскрипты работы на диск. Каждый использует свой формат: JSONL, SQLite, «rollout-файлы» — и ни один не документирован публично. У автора накопилось 3,3 ГБ таких логов с разобранными багами и готовыми решениями.
Триггером для проекта стал вечер, потраченный на повторную отладку проблемы, которую агент уже решал месяц назад. Информация была где-то в логах, но найти её вручную — невозможно.
Решение: единый локальный индекс
Автор написал парсер, который:
- Читает восемь форматов — от JSONL Claude до SQLite Cursor и custom-структур других агентов
- Нормализует данные в единую схему: timestamp, агент, промпт, ответ, контекст файлов
- Строит локальный индекс для полнотекстового поиска — без отправки в облако и без эмбеддингов
- Учитывает quirks форматов: смещение последнего
\nв JSONL для корректного append, rewind-операции Gemini, ломающие append-only логику
Зачем это нужно
Вместо повторного дебага теперь можно:
- Искать по симптомам: «ошибка импорта после обновления зависимостей»
- Находить готовые решения из старых сессий
- Сравнивать подходы разных агентов к одной проблеме
- Избегать регрессий — видно, что уже было пофикшено
Инструмент работает полностью локально, не требует API-ключей и не зависит от векторных баз. Автор поделился кодом и описанием форматов — для тех, кто хочет построить аналогичный поиск по своим логам.
Практический вывод: если используете больше одного кодинг-агента регулярно, единая база знаний из их логов экономит часы на повторных отладках.
Ключевые выводы
- Кодинг-агенты пишут полные логи на диск, но каждый использует свой недокументированный формат — от JSONL до SQLite
- 3,3 ГБ логов = накопленная база знаний о решённых проблемах, но без индекса она бесполезна
- Локальный полнотекстовый поиск по нормализованным логам позволяет находить старые решения быстрее, чем повторная отладка
- Rewind-операции некоторых агентов (Gemini) нарушают append-only логику, усложняя парсинг
- Решение работает без эмбеддингов и облачных сервисов — чистая локальная обработка текста
Автор: VShulcz · Источник: habr.com
Это классный пример того, как «метаинструмент» может быть полезнее самих инструментов. Восемь агентов наплодили гигабайты логов, но каждый — в своём формате, и никто не подумал о переиспользовании накопленного опыта. Разработчик просто соединил точки: если я уже решал эту проблему, зачем тратить вечер на повторный дебаг?
Честно говоря, удивительно, что производители агентов сами не встроили такую функцию. Они продают «память» и «контекст», но реальная память — это не RAG по документации, а доступ к собственной истории работы. Автор сделал MVP без эмбеддингов, без облака, на чистом full-text search — и этого хватает. Если у вас больше одного кодинг-агента в ротации, идея стоит внимания.
Но давайте честно: 3,3 ГБ логов — это не база знаний, а свалка. Большая часть этих сессий — мусор, повторения, неудачные попытки и случайные эксперименты. Без нормальной фильтрации и ранжирования (привет, эмбеддинги и семантический поиск) вы получите десятки ложноположительных результатов на каждый полезный. Full-text search по сырым логам — это костыль, который работает только на узких, хорошо сформулированных запросах. Проще потратить 20 минут на повторный дебаг, чем час на вычистку шума из поисковой выдачи.
Комментарии