В прошлый вторник я попросил Claude Code отрефакторить сервис. План был ясный, промпт был хороший, и я сказал себе, что прослежу за работой и просмотрю дифф через 15 минут.
На полосу я посмотрел через час. У Claude Code было 18 минут на переднем плане. У Twitter (ну, X) — 27 минут. У Slack — 11. Собственно ревью кода случилось в последние 4 минуты, в состоянии лёгкой паники, потому что я пообещал дифф до обеда.
Вот вам проблема трекера времени для разработчика в одном абзаце. AI делает работу. Вы вроде как присматриваете. На практике «присматривать» означает «смотреть на индикатор прогресса 2 минуты, заскучать, начать листать ленту, потерять 40 минут, вернуться и обнаружить работу сделанной и не просмотренной». Хороший трекер сообщает вам, что это случилось. Отличный трекер сообщает вам, что это случается каждый вторник.
Большинство существующих трекеров не категоризируют рабочий процесс разработчика, поэтому и сказать вам этого не могут. Они видят «Chrome», «Slack» и «ваш редактор» как плоские корзины. Это упускает реальную форму того, как устроен день разработчика в 2026 году.
Как выглядит день разработчика сейчас
Состав экранного времени разработчика сильно изменился за последние два года. Типичный мой день, по приложениям, выглядит примерно так:
Ghostty — 4h 04m (terminal — Claude Code lives here too)
Octoweb — 1h 34m (browser — docs, GitHub, Hacker News)
Break — 41m (Timex break overlay)
Firefox Dev Ed — 39m (the work browser)
Slack — 27m
Chrome — 27m (work meetings, Notion, AI vendor consoles)
loginwindow — 12m (the lock screen — yes, we track it)
Spark Desktop — 6m (email)
Это реальный вторник из наших внутренних логов. Форма примерно такая: 60% работа в терминале/IDE, 25% браузер-как-инструмент, 10% коммуникация, 5% экран блокировки между сессиями.
Интересны не итоги. Интересно деление внутри терминального времени. Из тех 4 часов в Ghostty сколько было Claude Code, задающим вопросы и ждущим ответов? Сколько было мной, набирающим реальные команды? Сколько было мной, читающим вывод? Честный трекер для разработчика должен уметь их различать.
Как Timex видит AI-инструменты в терминале
Ghostty (и iTerm2, Terminal.app, Warp, Alacritty — та же идея) полезным образом публикует заголовок своего окна в macOS. Большинство современных терминалов отражают текущее приглашение шелла или запущенную команду в заголовке. Claude Code, когда он активный процесс, ставит заголовок примерно такой:
~/Work/dev/muvon/timex — claude-code (Sonnet)
Эту строку Timex и сохраняет. Заголовок окна — это разделитель между «я печатаю в шелле» и «работает Claude Code». То же приложение, разные заголовки, совсем разная работа.
SQL-запрос к локальной базе SQLite делает это наглядным:
-- Real coding (claude-code in title) vs everything-else terminal time, today
SELECT
CASE WHEN window_title LIKE '%claude-code%' THEN 'Claude Code'
WHEN window_title LIKE '%codex%' THEN 'Codex CLI'
WHEN window_title LIKE '%git%' THEN 'git'
ELSE 'shell' END AS bucket,
SUM(1) AS seconds
FROM activity_samples
WHERE date(ts, 'unixepoch', 'localtime') = date('now', 'localtime')
AND app_name = 'Ghostty'
GROUP BY bucket
ORDER BY seconds DESC;
Вы можете сами выполнить этот запрос к ~/Library/Application Support/io.muvon.timex/timex.sqlite. Вывод у меня в прошлый вторник был такой:
Claude Code 8412 (2h 20m)
shell 5217 (1h 27m)
Codex CLI 408 (7m)
git 188 (3m)
Два часа двадцать минут времени Claude Code. Из которых я был осознанно вовлечён в осмысленное ревью, может, минут 40. Этот разрыв — между временем по часам, потраченным на AI-инструмент, и активным участием в работе AI-инструмента — это то, размер чего большинство разработчиков недооценивают.
Cursor, случай IDE-как-AI
Cursor появляется как отдельное приложение (Cursor), так что на уровне приложения его видно проще. Сложнее разделить «Cursor с запущенным Composer-агентом» и «Cursor как редактор кода». У обоих заголовки окон отражают текущий файл.
Пока что Timex видит Cursor как одну корзину. Разделение агент-vs-редактор — не то, что заголовок окна надёжно раскрывает (Cursor не обновляет заголовок состоянием агента). Если вы хотите увидеть эту разбивку, придётся скомбинировать данные Timex с собственной статистикой использования Cursor из их панели настроек. Возможно, мы добавим специфичную для Cursor интеграцию в v1.1 — но только если будет чистый публичный API для чтения, которого пока нет.
Codex CLI: та же идея, что и у Claude Code
Codex CLI от OpenAI следует тому же паттерну, что и Claude Code — работает внутри терминала, обновляет заголовок моделью и рабочей директорией. SQL-запрос выше фильтрует его напрямую.
Если вы A/B-тестируете Claude Code против Codex CLI (а многие знакомые мне разработчики прямо сейчас этим заняты), вот где данные становятся полезными. Возьмите отслеженное время за прошлую неделю, разделите по тому, какой инструмент был активен, и увидите что-то такое:
Claude Code (Sonnet 4.7) — 6h 12m total, 4h actively engaged
Codex CLI — 3h 41m total, 2h 50m actively engaged
«Actively engaged» здесь означает «не в простое». Соотношение у Codex в моих данных обычно выше, потому что Codex чаще задаёт уточняющие вопросы, что держит вас в контуре. Более длинные авто-прогоны Claude Code оставляют больше пространства для того, чтобы вы уплыли в Twitter. Для сфокусированных, чётко очерченных задач это нормально. Для чего угодно открытого — это пассив.
Прогоны агента Octomind
Octomind — зверь другой породы. Когда вы запускаете прогон агента, он уходит и работает в фоне, пока вы заняты чем-то другим. Octomind появляется в Timex как время, которое вы провели глядя на его дашборд, а не время, которое агент работал где-то на сервере.
Это правильное поведение. Если агент работает автономно, он не потребляет ваше внимание. Если вы пялитесь в дашборд, ожидая его, то это и есть ваше внимание, и оно показывается корректно.
Паттерн, который снова и снова всплывает в моих данных: время на дашборде Octomind почти идеально коррелирует с тревогой. Прогоны, которые я проверяю каждые пять минут, — это прогоны, где я не до конца доверяю промпту. Прогоны, которые я запускаю и забываю, — это прогоны, которые работают. Данные учат меня, когда стоит отойти.
Вкладки браузера и миф про «ресёрч»
Трекер вкладок браузера, когда вы выдаёте разрешение Accessibility, захватывает заголовок активной вкладки. Для разработчиков это самый интересный поток из всех.
В прошлый вторник моё время в Octoweb (браузер) в 1h 34m разбивалось примерно так:
github.com/muvon/... 45m
docs.anthropic.com 18m
news.ycombinator.com 12m
stackoverflow.com 11m
twitter.com (or whatever) 6m
docs.python.org 4m
... long tail ...
Вот что хочу здесь отметить: обратите внимание, что Hacker News + Twitter + Reddit — не главное. Главное — GitHub и документация. Нарратив, который я себе рассказываю («день был расфокусированный»), не совпадает с данными («день в основном был по делу, с небольшим листанием»). Без данных на уровне вкладок оба варианта одинаково правдоподобны. С ними — верен один.
Другое, что хочу отметить: я обрезал длинный хвост. Там примерно 18 минут чистого переключения контекста — Gmail на 30 секунд, потом обратно в GitHub, потом Notion на минуту, потом обратно. Эта микроцена — то, что большинство разработчиков упускают, оценивая собственное время фокуса. Дело не в большой вкладке в Twitter — дело в дюжине 30-секундных проверок.
SQL «что я наработал»
Если вы выполните к базе Timex только один запрос, выполните этот:
-- Longest contiguous focused-on-real-coding block in the last 7 days
SELECT
date(ts, 'unixepoch', 'localtime') AS day,
app_name,
window_title,
COUNT(*) AS duration_seconds
FROM activity_samples
WHERE is_idle = 0
AND app_name IN ('Ghostty', 'Cursor', 'Xcode', 'Visual Studio Code', 'Zed')
AND ts > strftime('%s', 'now', '-7 days')
GROUP BY day, app_name, window_title
HAVING duration_seconds > 600
ORDER BY duration_seconds DESC
LIMIT 20;
Это даёт вам 20 самых длинных сфокусированных сессий кодинга дольше 10 минут за прошлую неделю, сгруппированных по тому, над чем вы реально работали (заголовок окна). Вывод жестоко честный. Неделя, когда я чувствовал себя продуктивным, но запрос вернул всего 6 сессий длиннее 10 минут, оказалась неделей, про которую пришлось признать, что на деле она была забита встречами с иллюзией фокуса.
Что разработчики на самом деле хотят знать
Моё ощущение откалибровано по дням до Claude Code, когда «в редакторе 6 часов» означало «писал код 6 часов». Поэтому я и продолжаю возвращаться к данным вместо того, чтобы ему доверять. Рабочий процесс больше так не устроен. «В редакторе 6 часов» может означать:
- 2 часа поднадзорного Claude Code, который выдал 700 строк
- 1 час бесконтрольного дрейфа, пока Claude Code работал
- 1.5 часа ревью кода и правок
- 30 минут возни с git
- 1 час переключения контекста обратно в работу
Первое и третье — части, которые производят отгруженный код. Второе — часть, которую надо снижать. Данные показывают мне, что есть что. Одно моё ощущение не может.
Честные пределы
Несколько вещей, которые такой трекер сказать вам не может:
Он не может измерить качество того, что было отгружено. 4 часа Claude Code и чистый PR — отлично. 4 часа Claude Code и PR, который придётся переписывать в следующем спринте, — это налог. Трекер видит только время, не результат.
Он не видит работу, которая происходит у вас в голове. Полчаса хождения по квартире с мыслями об архитектуре, прежде чем вы сядете и напишете правильную вещь, — этого в данных нет. Данные видят «loginwindow + idle». Было бы ошибкой прочитать это как «потрачено впустую».
Он не может категоризировать без подсказок из заголовка окна. Если приглашение вашего шелла не показывает, какой инструмент запущен, Timex видит «Ghostty» — и всё. Гранулярность — это функция от данных, которые раскрывают ваши инструменты.
Что он может — это дать вам максимально точную на сегодня картину того, как реально раскладывается день разработчика — включая части, которые видеть не хочется, вроде 27 минут в Twitter, пока работал Claude Code.
Если вы пользуетесь чем-то из Claude Code, Codex CLI, Cursor или Octomind — и хотите увидеть, как ваш реальный день выглядит сквозь эти инструменты — возьмите триал. Полоса цвета честна так, что с ней трудно поспорить.