TL;DR
Исследователи обнаружили, что можно предсказать примет ли разработчик подсказку от AI ещё ДО её генерации — только по поведению в редакторе кода. Модель смотрит на скорость печати, паузы, частоту undo, использование quick fix и другие действия в VS Code. Если паттерн говорит "сейчас не примет" — подсказку не показывают вообще. Это сократило вызовы LLM на 35% и подняло acceptance rate с 18.4% до 34.2% (+86%).
Главная находка: контекст готовности важнее качества подсказки. Большинство AI-ассистентов генерируют подсказки всегда, когда разработчик делает паузу. Но человек в разных режимах работы: иногда он в потоке и не хочет прерываний, иногда застрял и открыт к помощи, иногда активно дебажит и когнитивно перегружен. Принимать подсказку или нет определяется не только тем, насколько она точна, но и тем, в каком состоянии находится разработчик. Быстрая непрерывная печать, частое использование help-функций, серия отклонённых подсказок — всё это сигналы низкой receptiveness.
Механика: лёгкая ML-модель на поведенческих метриках работает как привратник. Когда разработчик делает паузу (триггер для автодополнения), система сначала смотрит на последние 60 секунд поведения: сколько символов напечатал, сколько пауз было, сколько раз нажал undo, менял ли файлы, какой acceptance ratio недавно, есть ли ошибки компиляции. Модель выдаёт вероятность принятия. Если ниже 0.1 — подсказку не генерируют. Если выше — вызывают LLM. Всё это работает без анализа кода или промптов — только поведенческие сигналы.
Ключевые поведенческие паттерны
Высокая receptiveness (примет подсказку):
- Медленная печать с паузами — думает, выбирает формулировку
- Недавно принял несколько подсказок — momentum эффект, открыт к помощи
- Низкая частота undo — уверенно двигается вперёд
- Мало обращений к help/quick fix — не перегружен проблемами
Низкая receptiveness (не примет):
- Быстрая непрерывная печать — в потоке, знает что делать
- Серия отклонённых подсказок — сейчас не то, что нужно
- Частые undo и quick fix — активно исправляет, когнитивная нагрузка
- Много ошибок компиляции — в режиме debugging, не до подсказок
Пример применения
Задача: Ты пишешь большую функцию для обработки данных пользователей. Сначала быстро набросал структуру (быстрая печать), потом застрял на логике фильтрации (пауза, медленная печать), потом активно дебажишь баги (много F5, console.log, undo).
Что делала бы система:
- Набросок структуры (быстрая печать без пауз) → подсказки НЕ показывать, ты в потоке
- Застрял на фильтрации (паузы, медленная печать) → подсказки показать, открыт к помощи
- Активный debugging (много console.log, F5, undo) → подсказки НЕ показывать, когнитивно перегружен
Результат исследования: Когда систему включили, из 2190 ситуаций она отфильтровала 768 (35%) как "сейчас не примет". Из оставшихся 1422 разработчики приняли 34.2% — против 18.4% когда показывали всё подряд.
Почему это работает
Слабость текущих AI-ассистентов: Они не чувствуют контекст готовности. Показывают подсказку каждый раз при паузе — независимо от того, думает ли человек, застрял, в потоке или дебажит. Результат: 80%+ подсказок игнорируются, создавая шум и нагружая GPU впустую.
Сильная сторона поведенческих сигналов: Они показывают когнитивное состояние разработчика прямо сейчас. Быстрая печать = уверенность, не нужна помощь. Паузы + медленная печать = размышление, открыт к идеям. Частые undo + обращения к help = перегрузка, не до новой информации. Серия принятых подсказок = momentum, продолжай помогать.
Как метод использует это: Модель обучена на 2318 реальных ситуациях: какие поведенческие паттерны привели к принятию подсказки, какие к отклонению. Она не пытается угадать ЧТО написать (это делает LLM), она угадывает ПРИМЕТ ли человек вообще что-то прямо сейчас. Порог настроен низко (0.1) — фильтруем только явно безнадёжные ситуации, где acceptance вероятность совсем низкая.
Побочный эффект: Меньше прерываний → выше концентрация → выше продуктивность. Меньше вызовов LLM → ниже latency и расходы на GPU.
Применимые принципы для работы в чате
Эта система работает в IDE автоматически, но принципы timing и receptiveness универсальны. Вот как их использовать в ChatGPT/Claude:
🎯 Принцип 1: Режимы работы
Разделяй работу на режимы и обращайся к AI по-разному:
Flow Mode (быстро пишешь, знаешь что делать): - НЕ прерывайся на AI — допиши то что в голове - Обращайся только если реально застрял
Exploration Mode (думаешь, выбираешь подход): - Самое время для AI — генерация идей, варианты решения - Проси несколько альтернатив, дискуссию
Debug Mode (исправляешь ошибки, высокая нагрузка): - НЕ проси генеративные подсказки — слишком много информации - Используй AI точечно: "что не так в этой строке?"
🎯 Принцип 2: Momentum Эффект
Если несколько запросов подряд дали полезный результат — продолжай в том же ключе. Если три запроса подряд не помогли — смени формулировку, роль или вообще сделай паузу. AI чувствителен к контексту диалога, streak неудач часто говорит о неудачном framing задачи.
🎯 Принцип 3: Структурируй сессии
Вместо одного длинного чата с постоянными прерываниями: - Отдельный чат для быстрого потока — ты пишешь код/текст, обращаешься только при блоке - Отдельный чат для исследования — генерация идей, обсуждение подходов - Отдельный чат для ревью — после того как написал, проверка и улучшение
Это аналог "не прерывать flow-state автоподсказками" из исследования.
🎯 Принцип 4: Осознанность паттернов
Замечай когда обращаешься к AI: - После пауз и медленного progress — хороший timing ✅ - Во время быстрого писания — плохой timing, потеряешь мысль ❌ - Когда уже перегружен информацией — плохой timing, не усвоишь ❌
Ограничения
⚠️ Применимость в чате: Система работает автоматически в IDE. В ChatGPT/Claude ты сам решаешь когда обращаться — принципы помогают делать это осознанно, но дисциплины требуют от тебя.
⚠️ Контекст разработки vs другие задачи: Исследование про код, но принципы timing работают шире. "Flow mode", "exploration mode", "debug mode" есть в любой интеллектуальной работе.
⚠️ Индивидуальность паттернов: Модель обучена на 9 разработчиках. Твои паттерны работы могут отличаться — принципы универсальны, но пороги чувствительности индивидуальны.
Как исследовали
Команда из ITMO University встроила ML-модель в production VS Code плагин и собирала данные 4 месяца. Плагин работал у 9 активных разработчиков (из 25 приглашённых), каждый использовал минимум 50 раз. Все с опытом 3+ года, большинство 5+ лет, кодят 4+ часа в день, в основном Python.
Собирали две категории данных: 1. Event-level: для каждой подсказки — длина промпта, длина completion, время до accept/reject, принял или нет 2. Behavioral stream: каждую минуту агрегировали метрики — скорость печати, паузы, навигация по файлам, undo/redo, использование quick fix, ошибки компиляции
Главная хитрость: Все метрики вычисляли ДО вызова LLM. Код и промпты не анализировали — только поведение в IDE. Privacy-preserving подход.
Обучение модели: 2318 событий подсказок, из них 426 приняли (18.4%), остальные отклонили или проигнорировали. Дисбаланс классов 1:4.4, поэтому использовали weighted loss. Обучили несколько моделей (XGBoost, LightGBM, CatBoost, Balanced Random Forest), выбрали CatBoost. Порог 0.1 — фильтруем только явно безнадёжные случаи, чтобы не задавить полезные подсказки.
Результаты удивили масштабом: Ожидали улучшение acceptance на 5-10%, получили +86%. При этом модель отфильтровала 35% запросов — существенная экономия GPU.
Почему сработало так сильно: SHAP-анализ показал, что recent acceptance ratio и typing rhythm — очень сильные предикторы. То есть ключ не в самой подсказке, а в том КАК человек работает последние 30-60 секунд. Это подтверждает гипотезу: контекст готовности важнее качества completion.
Неожиданная находка: Частое использование help-функций и quick fix коррелирует с низким acceptance. Интуитивно кажется наоборот — человек нуждается в помощи. Но на практике это сигнал cognitive overload: он уже перегружен проблемами, ещё одна подсказка только помешает.
Ресурсы
Pre-Filtering Code Suggestions using Developer Behavioral Telemetry to Optimize LLM-Assisted Programming — Mohammad Nour Al Awad, Sergey Ivanov, Olga Tikhonova (ITMO University, Saint Petersburg, Russia)
Релевантные отсылки из исследования: - Model Context Protocol (MCP) — фреймворк для embedding метрик и контекста в LLM-enhanced IDEs - RealHumanEval benchmark — измерение качества AI-ассистентов в реальных сценариях с участием людей - Tree-sitter — инструмент для парсинга кода и вычисления метрик сложности (cyclomatic complexity, Halstead effort, maintainability index)