Тайм-трекеры отвечают не на тот вопрос. Нужен локальный агент рабочего состояния.
Парадокс. Мы измеряем железо лучше, чем себя самих.
Некоторое время назад я поймал себя на мысли, что у нас есть всевозможные утилиты для анализа загрузки процессора, памяти, температуры видеокарты, сетевого трафика и даже скорости вращения кулеров, но в конце восьмичасового рабочего дня за компьютером часто бывает сложно ответить самому себе на простой: что я делал весь день?
Не сколько часов я "работал", не сколько часов приложения были открыты на экране, а именно что происходило? какова была моя продуктивность? где я был в фокусе, куда направлял внимание? какую долю в дне занимали реальные полезные действия а какую прокрастинация и смены контекста? Делал ли я регулярные перерывы для сохранения здоровья?
С появлением Cursor, Claude Code, Codex и других AI-агентов рабочий день стал ещё более рваным и еще более нагруженным. Появление мультиагентных инструментов разработки только усилило проблему - частые смены фокуса, высокая когнитивная нагрузка, переключения контекста - я понял, что нужно что-то с этим делать.
С этого началась идея создания LogAgent. Сначала казалось, что делаю умный тайм-трекер + экспортируемая стата дня. Потом стало понятно - само время использования приложений само по себе почти ничего не объясняет.
Почему бы мне просто не взять готовый инструмент?
Я начал рассуждать логически: существующие тайм-трекеры знают "сколько", но не знают "в каком состоянии"; таск-менеджеры знают "что запланировано" но не знают что "реально произошло"; помодоро-подобные решения используют одинаковый ритм разным задачам, но не всё так однозначно; health-приложния измеряют сон, шаги, пульс, но они ничего не знают про "5 часов в IDE", "3 часа ресерча документации", "час поиска неявной ошибки"; IDE-метрики и плагины видят код, количество строк и функций, редакций, но ничего не знают о моей усталости, сделанных перерывах, переключениях, общем контексте работы;
Я посмотрел многие решения из соседних категорий.
Рынок не пустой, наоборот, вокруг много хорошего. ActivityWatch отличный локальный автотрекер приложений и сайтов, и в отличие от многих хранит данные на устройстве.
WakaTime закрывает developer-метрики: проекты, файлы, ветки, коммиты, IDE, языки. RescueTime и подобные помогают с фокусом и продуктивностью.
Есть приложения для анализа осанки, Pomodoro, биллинг-утилиты, есть Rize с частичным ИИ, но целиком облачный. Каждый отвечает на свой вопрос.
Но это разные части одной реальности под названием «рабочий день», а не единая модель состояния. Я не нашёл инструмента, который собирает воедино время, проекты, фокус, перерывы, усталость, осанку, git/IDE и биллинг в одну объяснимую картину.
LogAgent отвечает на другой вопрос: «что происходило с моим рабочим состоянием за компьютером — и что из этого следует?»
Возьмем новую единицу анализа: не час, а рабочее состояние
Один час работы может быть чем угодно. Час работы в потоке с глубоким фокусом. Час прокрастинации, замаскированной под ресерч. Час тупого зависания не понимая как подступиться к задаче. Час созвона. Час ресерча. Час работы с ИИ агентом, где половина времени ушла на промпты, а половина на ревью результата.
Поэтому я научил LogAgent анализировать не время, а состояние рабочего процесса в течение дня.
Эволюционно и поэтапно в процессе разработки я пришел к следующим компонентам: активные приложение, домены и сайты, рабочие директории проектов, git-контекст, IDE/терминал, AFK, длительность фокус-сессий, переключения контекста, перерывы, сигналы усталости, пользовательские подтверждения, правила классификации, задачи/клиенты/биллинг.
По-отдельности каждый сигнал слабый. Активное окно говорит лишь о том, что оно было в фокусе в конкретный момент времени. Git говорит, что были изменения в проекте. AFK говорит, что человек отошёл. Частые переключения с учетом контекста могут свидетельствовать о начале прокрастинации. Сигналы с камеры говорят, что пользователь начинает сутулиться и реже моргает.
Но вместе эти сигналы начинают складываться в полноценную картину: вот здесь была работа над проектом, а здесь частые переключения, здесь восстановление фокуса, здесь спорный сегмент, который лучше подтвердить вручную.
Для чего нужна агентность.
Агент. Первая мысль - опять прилепили это модное слово :) Но тут речь немного о другой стороне агентности. Я вкладываю в него не "обёртку над LLM". Для меня агентность, это про проактивность и автономность, а не про то, есть внутри нейросеть или нет.
В текущей версии LLM нет вообще. Вся классификация и инсайты работают на правилах и эвристиках, и работают офлайн. Агент здесь обозначен, потому что софт не ждёт, пока вы заполните таблички, а сам собирает сигналы, классифицирует, замечает аномалии и спрашивает, только когда есть реальный повод.
Мы привыкли, что софт работает пассивно: заполнил таблички, нажал кнопку, получил результат. А что, если мы введем проактивность?
Агент действует иначе, он учится и запоминает паттерны поведения пользователя при работе, он сам собирает сигналы, сам классифицирует проекты, сам замечает аномалии, сам запрашивает уточнения когда не уверен, сам строит рабочую картину дня, сам готовит черновики отчетов и саммари дня, сам замечает признаки усталости и переутомления, сам предлагает перерывы, сам подсвечивает инсайты и рекомендации.
Агентность не означает, что приложение должно командовать человеком. Наоборот. Правильный агент достаточно умён, чтобы работать автономно, не тревожить лишний раз и обращаться к пользователю только когда есть реальный повод.
Объяснимость. Почему единая магическая оценка это плохо.
Плохо, когда: Продуктивность 61%. Усталость 58%. Делайте выводы.
Хорошо, если: Продуктивность просела после 16:00. До этого были две хорошие фокус-сессии по 25 минут. Потом выросло число переключений между IDE, браузером и мессенджером. Перерыв был пропущен три раза. Осанка начала "сыпаться" примерно через 40 минут после последнего отдыха.
Если агент не может объяснить, почему он сделал вывод, это не агент, а генератор красивых цифр. Нужен гибкий функционал объяснимости: каждый инсайт ссылается на понятные интерпретируемые сигналы, каждый сегмент имеет уверенность, спорные моменты попадают в ревью, пользователь может переопределить правила и классификации, ручные исправления влияют на обучаемость системы.
Обзор дня как раз позволяет увидеть сгруппированные рабочие сегменты дня, и может автоматически применить распознанные правила а может переопределить.
Зачем тут нужна камера.
Камера в приложении для оценки продуктивности может звучать подозрительно. Это не стандартный функционал. Я долго думал как можно наилучшим образом определять признаки усталости, расфокусировки, переутомления. В итоге без камеры эффективно сделать это невозможно.
Если мы говорим не только про время, а про рабочее состояние, контекст дня - тело нельзя игнорировать. Усталость часто появляется раньше, чем мы её осознаем. Сначала меняется поза, сутулость. Потом пользователь может чаще ближе наклоняться к экрану. Начинает реже моргать. Пропускает предложенный перерыв. Потом падает фокус. А потом пользователь скажет "что-то день выдался тяжелый", хотя тяжелым день стал еще два часа назад после нескольких пропущенных перерывов.
Я тут ничего не придумываю. NIOSH пишет, что периодические перерывы и смена позы полезны, а добавление коротких 5-минутных перерывов снижает дискомфорт и зрительное напряжение. CDC/DHA также рекомендуют 20-20-20 для глаз, а OSHA отдельно указывает на связь бликов, положения монитора, зрительного напряжения и неудобных поз.
И проактивность здесь не абстракция. Когда совокупность сигналов пересекает порог, агент не молчит и не ждёт, пока вы сами заметите признаки. Он коротко вмешивается контекстной подсказкой и тут же уходит. Не модальное окно на весь экран, а карточка, которая всплывает и закрывается через пару секунд.
Вот несколько реальных триггеров.
Это не помодоро по расписанию, подсказка появляется тогда, когда сигналы говорят, что она нужна, а не каждые 25 минут вслепую. Помодоро доступно как один из режимов, но по умолчанию подсказки контекстные по сигналам, а не по таймеру. К тому же пороги можно гибко настроить вручную.
Мы не пытаемся ставить диагноз. LogAgent не врач. Он смотрит на рабочие микро-сигналы: позу, расстояние до экрана, моргание, освещение, длительность сессии, пропущенные перерывы, рост переключений и другие. Если несколько сигналов одновременно ухудшаются, агент может мягко вмешаться.
Хотя камера и закрывает большой пласт получения сигналов, которые участвуют в общей логике аналитики усталости, эту функцию можно выключить.
Приватность. Я являюсь сторонником подхода Privacy-first.
Ядро трекинга и локальной аналитики работает офлайн. Сбор + локальная аналитика сигналов = офлайн всегда. Сеть не нужна вообще. Даже для аналитики с камеры. Вся логика аналитики позы, морганий и т.д. работает на алгоритмах и локальной модели MediaPipe Face Mesh - обработка производится покадрово в памяти в режиме реального времени без сохранения кадров и видео вообще. В историю попадают только числовые признаки и события для анализа.
Face Landmarker умеет определять landmarks и выражения на изображениях и видеопотоке, а Face Mesh оценивает 468 3D landmarks в реальном времени даже на мобильных устройствах.
Это не только этическое решение, а ещё и инженерное. Локальная обработка дешевле на масштабе, быстрее по отклику и проще для доверия.
В текущей версии агент не использует LLM вообще. Генерация саммари и инсайтов — это система правил и алгоритмы.
Уточню, чтобы снять вопрос: AI в названии раздела это не про то, что внутри крутится нейросеть. Это про то, что агент анализирует вашу работу с AI-инструментами (Claude Code, Cursor, Codex, консольными агентами): сессии, токены, что ушло в коммит, сколько времени съело ревью, пуши в гит.
Сам же агент в текущей версии работает без LLM. Вся классификация на правилах и эвристиках, локально. И именно поэтому privacy-обещание держится: некуда утекать.
Локальную LLM в ядре я не исключаю в будущем, но именно локальную, чтобы это правило не нарушалось.
AI-native работа.
Это новая проблема, которую обычные трекеры плохо видят.
В 2026 разработчик всё чаще работает не только с IDE. В дело вступают Cursor, Claude Code, Codex, OpenCode, Grok + терминал, браузер, документация, issue tracker и git. Внешне это может выглядеть как "сидел в браузере и VS Code". На деле это может быть полноценная комбинированная AI-assisted сессия разработки.
Это важные сигналы, которые невозможно переоценить при анализе рабочего дня пользователя. Сессии, токеномика, промпты, изменения в коде. Позволяет видеть в масштабе сколько времени ушло на работу и с какими AI-агентами, какие задачи решались через AI, где AI ускорил, где зациклил, где было много токенов и мало результата, какой код потом попал в коммит, сколько времени ушло на ревью и исправление результата.
Например WakaTime хорошо показывает разработческую активность по IDE, проектам, веткам, коммитам и языкам. Но следующий слой аналитики будет не только про "где писали код", а про "как пользователь работал вместе с ИИ". LogAgent можно позиционировать как слой поверх новой AI-native работы и раннего обнаружения признаков перегруза.
Биллинг и отчёты: деньги должны вытекать из реального дня.
Если вы фрилансер или консультант, проблема не в том, что вы мало работаете. Часто проблема в том, что вы плохо помните и отмечаете мелкие сегменты работы. 18 минут на правку. 12 минут на проверку деплоя. 34 минуты на ресерч. 26 минут на переписку. По отдельности мелочь. За месяц это деньги.
LogAgent автоматически группирует рабочие сегменты, связывает их с проектами, показывает уверенность по каждому. Опциональное подтверждение спорных, готовит отчёт/инвойс, оставляет след "почему это время попало в биллинг". Важно не просто "засечь работу в приложениях", а собрать объяснимое основание для отчёта.
Вот сегодняшний день: 4ч 25м за компьютером, 73% продуктивного времени, ведущая категория Development, 229 переключений контекста, усталость 33%. Каждую из этих цифр можно развернуть до сигналов, на которых она построена
История.
История очень важна. По одному дню сложно построить достоверный анализ. Неделя стабильных сигналов уже ценнее. После месяца истории стабильных сигнал агент замечает паттерны, корреляции, аномалии в поведении. Спустя 3 месяца уже есть надежная база сигналов, из которых выстраиваются паттерны поведения, выпады, аномалии, и можно строить реалистичную картину дня.
Почему именно такая комбинация функций.
Может возникнуть вопрос зачем в одном приложении тайм-трекинг, осанка, перерывы, git, биллинг и AI-инсайты? Почему не сделать пять отдельных инструментов?
Потому что проблема находится между этими инструментами:
Усталость влияет на фокус -> Фокус влияет на качество работы; Переключения влияют на длительность задач -> Длительность задач влияет на биллинг и продуктивность; AI Native анализ видит работу с ИИ агентами -> Git и IDE помогают понять проект; Камера и перерывы помогают понять состояние -> Перерывы помогают "перезагружаться" и предотвращать переутомления; Авто анализ и автоучет работы в приложениях делает черновик дня -> Ручное подтверждение улучшает классификацию; Всё вместе даёт объяснимый день.
Один сигнал врёт. Несколько сигналов спорят. Серия сигналов даёт более честную картину дня.
LogAgent это первый практический компонент более крупной истории под названием DuoHuman - персональной экосистемы самооцифровки. Но это тема для отдельной статьи и здесь не буду растекаться.
Пускай это будет вводная статья для серии статей об агенте. В следующих статьях я раскрою технические детали, расскажу о функциях и их взаимосвязи подробнее, покажу что и как устроено. Поверьте, опыта получено колоссальное количество и рассказать есть что.
А пока можем подискутировать в комментах.
Доверили бы вы приложению камеру, если можно проверить, что кадры не пишутся и не уходят в сеть?
Хотели бы вы такой агент у себя на машине, если он работает локально и не отправляет данные в облако?
Нужна ли разработчику аналитика по усталости, фокусу и AI-сессиям, или это уже перебор?