🚀 Как Google научился смотреть в мозг разработчика без внедрения ему чипов

Окей, друзья, вот это прям кайф.
Google сделал систему InSession, которая соединяет логи из десятков инструментов разработчиков (IDE, код-ревью, Jira, Calendar, всё подряд) и пытается понять - что на самом деле делают инженеры весь день.

То есть не “кажется, что Вася сегодня был продуктивен”, а буквально: сколько времени Вася писал код, сколько читал доки, сколько ревьюил чужой код и сколько залипал в Gmail.

⸻

🧠 Зачем вообще это всё

Потому что в Google 30 000+ инженеров, и если даже немного увеличить продуктивность каждого - эффект колоссальный.
А сделать это можно только если ты понимаешь, куда реально уходит время.

Но тут же куча проблем:
• нельзя следить за людьми напрямую (этика, приватность, HR-кошмары),
• разные инструменты логируют по-разному,
• и вообще, как понять — Вася просто задумался или реально работает?

⸻

⚙️ Что такое InSession

Это такая огромная труба, куда сыпятся логи со всех инструментов.
Система превращает их в события (events), потом в сессии (sessions) — куски времени, когда разработчик работал над конкретной задачей.
Дальше уже можно считать метрики:
• coding time 🧑🏻‍💻 - сколько реально писали код,
• reviewing time 👀 - ревью чужого кода,
• shepherding time 🧹 - правки по ревью,
• investigation time 🔍 - чтение доков,
• meeting time 🗓️, email time 📧, и т.д.

Короче, цифровая тень рабочего дня разработчика.

⸻

🧩 Но без паранойи!

Google сразу зашил 7 принципов приватности:
• никаких данных вне рабочих инструментов,
• никакого контента из писем и чатов,
• всё шифруется, логируется и хранится 3 года,
• никаких персональных отчётов - только агрегаты.

То есть HR не может прийти и сказать: “Ага, Иванов кодил всего 2 часа!”
Именно поэтому разработчики вообще согласились на участие.

⸻

📊 Что удалось выяснить

Один пример — проверили эффект программы Readability Certification (внутренний экзамен на знание стандартов кода).

Результат:
• после сертификации ревью шли быстрее на 4,5% (C++),
• исправления по ревью - на 10% быстрее,
• инженеры сами говорят: “Да, это реально помогает”.

То есть не просто бюрократическая галочка - метрики подтверждают эффект.

⸻

🧪 Проверка реальности

Чтобы убедиться, что логи не врут, исследователи сравнили данные InSession с “дневниками” 25 инженеров.
Оказалось, совпадение почти идеальное по email и встречам (0.8+ по коэффициенту согласия), и довольно хорошее по коду и ревью (~0.7).
Разночтения были из-за:
• отсутствующих логов (часть инструментов не трекается),
• мультизадачности,
• человеческой памяти (“забыл записать”).

⸻

🧭 Что из этого вынесли
1. Не всё надо логировать - только ключевые источники.
2. Обогащайте данные. Даже добавление “gain focus” в логах IDE дало +2 часа видимой активности в неделю на инженера.
3. Верифицируйте метрики. Без человеческой проверки легко наловить абсурда.

⸻

💡 Главный инсайт

InSession - это не “big brother”, а инструмент для улучшения DevEx на уровне всей компании.
Он помогает понять закономерности поведения инженеров, проверить эффективность процессов и (в идеале) сделать работу чуть-чуть человечнее и эффективнее.



🔥 - “Я за! Метрики рулят”
❤️ - “Главное — не превратить всё в KPI-ад”
🦄 - “Хочу такую систему, но open source!”

Написал обзор гайда

Главная мысль. Агент - это не чатик, а система принятия решений с инструментами, памятью и ограниченной «властью». Работает в вероятностном мире, значит, всё вокруг него должно быть измеряемо, наблюдаемо и ограничено по полномочиям.

Мне особенно нравится мысль про вероятностный мир

Почему это не “ещё один сервис”:

От детерминизма к вероятностям: одинаковый ввод → разные исходы. Нужны другие тесты и выпуск.

Code-first уходит, приходит evaluation-first: шипим только с доказательствами (качество, латентность, безопасность, стоимость).

Агент = инструменты + политика полномочий + трассы рассуждений (observable traces).

ADLC вместо SDLC (DevSecOps для агентов): Plan → Code/Build → Test/Optimize/Release → Deploy → Monitor (runtime loop) → Operate. Две «внутренние петли»: эксперименты на сборке и оптимизация в рантайме.

Безопасность по-взрослому:

Песочницы (Firecracker/gVisor/политики контейнеров) + kill-switch + least-privilege.

Агентские угрозы: memory poisoning, tool misuse, goal hijack - нужны отдельные контроли, не только классический AppSec.

Наблюдаемость и метрики:

Не «жив ли сервис?», а «прав ли агент?». Логи/трейсы рассуждений, groundedness, hallucination rate, cost per outcome, champion-challenger.

Говернанс:

Каталог сертифицированных агентов/инструментов/промптов, версии, риск-профиль, артефакты оценок и редтиминга - прежде чем выпускать.

Интеграции = MCP-серверы:

Инструменты выводим через Model Context Protocol, поверх - MCP-Gateway (политики, мTLS, квоты, аудит, многоарендность). Это «входные ворота» ко всем бэкендам.

Когда вообще строить агента? Если есть многошаговая логика/суждение и измеримые бизнес-метрики; не стесняйтесь выбирать простые решения вместо «агентов ради агентов».

Что делать завтра:

1) Завести ADLC как стандарт (шаблоны метрик/гейтов).
2) Включить агентские evals в CI/CD.
3) Поставить MCP-gateway и каталог.
4) Обязать песочницы и авторизацию «минимум прав».
5) Сделать общую панель «качество-стоимость-риски»

Мне отдельно нравится про Evals

Evals - это «медосмотр» агента.
Проверки, которые показывают: «агент делает правильно, безопасно и за разумные деньги». Они нужны потому, что агент отвечает по-разному на один и тот же запрос - важно мерить «прав ли он», а не только «живет ли сервис».
Как их делают (3 вида):
• Offline - в сборке/CI: гоняем набор задач и ловим регрессии до релиза.
• Online - в проде: постоянно мерим качество/безопасность/бизнес-эффект.
• In-the-loop - прямо во время работы: микропроверка, которая подсказывает агенту что делать дальше (например, релевантен ли контекст).
Что мерим (примеры метрик):
• успех задачи, groundedness, успех вызовов инструментов.
• частота джейлбрейков, утечки данных, нарушения политик.
• стоимость/токены на задачу, классы ошибок.
• CSAT/оценки, cost per outcome (сколько стоит результат).
Как раскатывать версии:
• Champion–Challenger: новую версию сравниваем с текущей на реальном трафике/данных; победителя - в промо. Это весомее офлайна.