Парадокс. Мы измеряем железо лучше, чем себя самих.
Некоторое время назад я поймал себя на мысли о том, что у нас уже есть всевозможные инструменты для анализа загрузки процессора, памяти, температуры видеокарты, сетевого трафика и даже скорости вращения кулеров, но в конце восьмичасового рабочего дня за компьютером часто бывает сложно ответить самому себе на простой: что я делал весь день?
Не сколько часов я “работал”, не сколько часов и какие приложения были открыты на экране, а именно что происходило? какова была моя продуктивность? где я был в фокусе, куда направлял внимание? какую долю дня занимали реальные полезные действия а какую прокрастинация и смены контекста? Делал ли я регулярные перерывы для сохранения здоровья?
С появлением 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 нет вообще. Вся классификация, аналитика и инсайты работают на правилах и эвристиках, и работают офлайн. Агент здесь обозначен постольку, поскольку софт проактивен и не ждёт, пока вы заполните таблички, а сам собирает сигналы, классифицирует, замечает аномалии и уточняет, только когда есть реальный повод.
Агент действует иначе, он учится и запоминает паттерны поведения пользователя при работе, он сам собирает сигналы, сам классифицирует проекты, сам замечает аномалии, сам запрашивает уточнения когда не уверен, сам строит рабочую картину дня, сам готовит черновики отчётов и саммари дня, сам замечает признаки усталости и переутомления, сам предлагает перерывы, сам подсвечивает инсайты и рекомендации.
Агентность не означает, что приложение должно командовать человеком. Наоборот. Правильный агент достаточно умён, чтобы работать автономно, не тревожить лишний раз и обращаться к пользователю только когда есть реальный повод.
Объяснимость. Почему единая магическая оценка это плохо.
Плохо, когда: 5 часов за ПК. Продуктивность 61%. Усталость 58%. Делайте выводы сами.
Хорошо, если: Из 5 часов за ПК эффективное время было 3.5 часа. Продуктивность просела после 16:00. До этого были две хорошие фокус-сессии по 25 минут. Потом выросло число переключений между IDE, браузером и мессенджером. Перерыв был пропущен три раза. Осанка начала «сыпаться» примерно через 40 минут после последнего отдыха.
Если агент не может объяснить, почему он сделал вывод — это не агент, а генератор красивых цифр. Нужен гибкий функционал объяснимости: каждый инсайт ссылается на понятные интерпретируемые сигналы, каждый сегмент имеет уверенность, спорные моменты попадают в ревью, пользователь может переопределить правила и классификации, ручные исправления влияют на обучаемость системы.
Обзор дня как раз позволяет увидеть сгруппированные рабочие сегменты дня, и может автоматически применить распознанные правила а может переопределить.
Зачем тут нужна камера.
Камера в приложении для оценки продуктивности может звучать подозрительно. Это не стандартный функционал. Я долго думал как можно наилучшим образом определять признаки усталости, расфокусировки, переутомления. В итоге без камеры эффективно сделать это невозможно.
Если мы говорим не только про время, а про рабочее состояние, контекст дня — тело нельзя игнорировать. Усталость часто появляется раньше, чем мы её осознаем. Сначала меняется поза, появляется сутулость. Потом пользователь может чаще наклоняться к экрану, подкладывать руку под голову. Начинает реже моргать. Пропускает предложенный перерыв. Потом падает фокус. А потом пользователь ощущает «что-то день выдался тяжёлый», хотя тяжёлым день стал ещё два часа назад после нескольких пропущенных перерывов.
Я тут ничего не придумываю. NIOSH пишет, что периодические перерывы и смена позы полезны, а добавление коротких 5-минутных перерывов снижает дискомфорт и зрительное напряжение. CDC/DHA также рекомендуют 20-20-20 для глаз, а OSHA отдельно указывает на связь бликов, положения монитора, зрительного напряжения и неудобных поз.
И проактивность здесь не абстракция. Когда совокупность сигналов пересекает порог, агент не молчит и не ждёт, пока вы сами заметите признаки. Он коротко вмешивается контекстной подсказкой и тут же уходит. Не модальное окно на весь экран, а карточка, которая всплывает и закрывается через пару секунд.
Вот несколько реальных триггеров.
Это не просто помодоро по расписанию, подсказкb появля.тся тогда, когда сигналы говорят, что она нужна, а не каждые 25 минут вслепую. Помодоро доступно как один из режимов, но по-умолчанию подсказки контекстные и триггерятся по сигналам, а не по таймеру. К тому же пороги можно гибко настроить вручную.
Мы не пытаемся ставить диагноз. LogAgent не врач. Он смотрит на рабочие микро-сигналы: позу, расстояние до экрана, моргание, освещение, длительность сессии, пропущенные перерывы, рост переключений и другие. Если несколько сигналов одновременно ухудшаются, агент может мягко вмешаться.
Хотя камера и закрывает большой пласт получения сигналов, которые участвуют в общей логике аналитики усталости, эту функцию можно выключить.
Приватность. Я являюсь сторонником подхода Privacy-first.
Ядро трекинга и локальной аналитики работает офлайн. Сбор + локальная аналитика сигналов = офлайн всегда. Сеть агенту не нужна вообще. Даже для аналитики видео потока с камеры. Вся логика аналитики позы, морганий и т.д. работает алгоритмичски через локальную модели MediaPipe Face Mesh. Обработка фреймов производится покадрово в памяти в режиме реального времени без сохранения кадров и видео вообще. В историю попадают только числовые признаки и события для анализа.
Это не только этическое решение, а ещё и инженерное. Локальная обработка дешевле на масштабе, быстрее по отклику и проще для доверия. В текущей версии агент не использует LLM вообще. Генерация саммари и инсайтов — это система правил и алгоритмы.
Сам же агент в текущей версии работает без LLM. Вся классификация на правилах и эвристиках, локально. И именно поэтому privacy-обещание держится: некуда утекать. Локальную LLM в ядре я не исключаю в будущем, но именно локальную, чтобы это правило не нарушалось.
AI-native работа.
Это новая проблема, которую обычные трекеры плохо видят.
В 2026 разработчик всё чаще работает не только в классической IDE. В дело вступают Cursor, Claude Code, Codex, OpenCode, Grok + терминал, браузер, документация, issue tracker и git. Внешне это может выглядеть как «сидел в браузере и VS Code». На деле это может быть полноценная комбинированная AI-assisted сессия разработки.
Это важные сигналы, которые невозможно переоценить при анализе рабочего дня пользователя. Сессии, токеномика, промпты, изменения в коде. Они позволяют видеть в масштабе сколько времени ушло на работу и с какими AI-агентами, какие задачи решались через AI, где AI ускорил, где зациклил, где было много токенов и мало результата, какой код потом попал в коммит, сколько времени ушло на ревью и исправление результата.
Уточню, чтобы снять вопрос: AI в названии раздела AI + Git это не про то, что внутри крутится нейросеть. Это про то, что агент анализирует вашу работу с AI-инструментами (Claude Code, Cursor, Codex, консольными агентами): сессии, токены, что ушло в коммит, сколько времени съело ревью, пуши в гит.
Например WakaTime хорошо показывает «разработческую» активность по IDE, проектам, веткам, коммитам и языкам. Но следующий слой аналитики будет не только про «где писали код», а про «как пользователь работал вместе с ИИ». LogAgent можно позиционировать как слой поверх новой AI-native работы и раннего обнаружения признаков ментального перегруза.
Биллинг и отчёты: деньги должны вытекать из реального дня.
Если вы фрилансер или консультант, проблема может быть не в том, что вы мало работаете. Часто проблема в том, что вы плохо фиксируете помните и отмечаете мелкие сегменты работы. 18 минут на правку. 12 минут на проверку деплоя. 34 минуты на ресерч. 26 минут на переписку. По отдельности мелочь. За месяц это деньги.
LogAgent автоматически группирует рабочие сегменты, связывает их с проектами, клиентами, показывает уверенность по каждому. Опциональное подтверждение спорных, готовит отчёт/инвойс, оставляет пометки «почему это время попало в биллинг». Важно не просто «засечь работу в приложениях», а собрать объяснимое основание для отчёта.
Вот сегодняшний день: почти 10 часов за компьютером, 60% продуктивного времени, ведущая категория Продуктивность, 1286 переключений контекста, средняя усталость 58%. Каждую из этих цифр можно развернуть до сигналов, на которых она построена.
История.
История очень важна. По одному дню сложно построить достоверный анализ. Неделя стабильных сигналов уже ценнее. После месяца истории стабильных сигналов агент замечает закономерности, паттерны, корреляции, аномалии в поведении. Спустя 3 месяца уже есть надёжная база сигналов, из которых выстраиваются паттерны поведения, выпады, аномалии, и можно строить реалистичную картину дня.
Почему именно такая комбинация функций.
Может возникнуть вопрос зачем в одном приложении тайм-трекинг, осанка, перерывы, git, биллинг и AI-инсайты? Почему не сделать пять отдельных инструментов?
Потому что проблема находится между этими инструментами:
Усталость влияет на фокус -> фокус влияет на качество работы; Переключения влияют на длительность задач -> длительность задач влияет на биллинг и продуктивность; AI Native анализ видит работу с ИИ агентами -> Git и IDE помогают понять проект; Камера и оценка усталости помогают понять состояние -> перерывы помогают «перезагружаться» и предотвращать переутомления; Авто анализ и автоучет работы в приложениях делает черновик дня -> ручное подтверждение улучшает классификацию; Всё вместе даёт объяснимый день.
Один сигнал может врать. Несколько сигналов могут быть спорными. Серия сигналов даёт более честную картину дня.
LogAgent это первый практический компонент более крупной истории под названием DuoHuman AI — персональной экосистемы самооцифровки и personal life OS. Но это тема для отдельной статьи и здесь не буду растекаться.
Пускай это будет вводная статья из серии статей об агенте. В следующих статьях, если вам будет интересно, я раскрою технические детали, расскажу о функциях и их взаимосвязи подробнее, покажу что и как устроено. Поверьте, опыта получено колоссальное количество и рассказать есть о чём.
А пока можем подискутировать в комментах.
Доверили бы вы приложению камеру, если можно проверить, что кадры не пишутся и не уходят в сеть?
Хотели бы вы такой агент у себя на машине, если он работает локально и не отправляет данные в облако?
Нужна ли разработчику аналитика по усталости, фокусу и AI-сессиям, или это уже перебор?
ссылка на оригинал статьи https://habr.com/ru/articles/1044414/