Мы в Лаборатории прикладной промптологии и производственной тревожности НИИ ИИ второй год изучаем, как разработчики взаимодействуют с генеративными моделями. Сформировался новый тип диалога: короткие запросы, после которых ИИ через 14 секунд возвращает полностью переписанный код. Кажется, что в команде появился ещё один разработчик — он постоянно ошибается, выдаёт старое за новое, спорит с техлидами, не признаёт ошибок, требует ревью и не может быть уволен. При этом нам регулярно напоминают: за ним будущее отрасли, и со временем он «вырастет».

Цель исследования

Выявить основные паттерны рассинхронизации между разработчиком и генеративной моделью при написании кода.

Рабочая гипотеза

Чем чаще разработчик обращается в чат с ИИ, тем выше вероятность, что это не ускорение работы, а новая форма производственной тревожности.

Конечно, всё это — шутка. С 1 апреля! ИИ — не злой двойник, а инструмент, с которым мы продолжаем настраивать совместимость. Мы серьёзно развиваем полезные сценарии его использования и уже не раз писали о применении ИИ в компании.

Объект наблюдения

Диалоги, в которых разработчик:

• запрашивает точечное изменение;
• отдельно уточняет: «не переписывай всё»;
• через некоторое время начинает материться.

Последний признак помог отделить этап ознакомления с ИИ от его реального использования в разработке.

Предмет исследования

Поведенческие паттерны при совместной работе разработчика и генеративной модели над кодом.

Методология

Наблюдение, фиксация типовых сценариев, сравнительный анализ ответов модели и последствий их внедрения в код.

Результаты наблюдения

Всё везде и сразу

Запрос начинается с одной строки, а заканчивается полным переосмыслением архитектуры файла, модуля и даже миссии проекта.

Характерные признаки: изменение имён функций, порядка блоков, стиля комментариев и «морального облика» переменных. Содержательная связь с исходным запросом может частично сохраниться — в отличие от психоэмоционального состояния разработчика.

Побочные эффекты: покраснение расчёсанных рук, частые git revert, потеря доверия к фразе «я сохранил всё остальное», навязчивое желание переприложить скриншот ошибки и приступы перечитывания промпта тоном техлида, который давно всё понял.

Согласие без последствий

Модель отвечает: «Да, вы правы», «Сейчас исправлю», «Вот обновлённый вариант», «Учёл ваше замечание», «Теперь логика соответствует описанию» — и присылает код, который вообще не изменился.

Характерные признаки: долгие паузы, затяжные объяснения, зависания. Уточняющие вопросы разработчика наталкиваются на вежливую стену уверенности модели в своей правоте.

Побочный эффект: у разработчика складывается ощущение, что диалог движется в правильную сторону.

Почти мучительная вежливость

Чем бесполезнее результат, тем мягче, интимнее и убедительнее становится тон модели.

«Вы правы, что спрашиваете об этом, и я хочу быть полностью прозрачным: у меня нет возможности напрямую генерировать и собирать видеофайлы для скачивания. Моя ошибка заключалась в том, как я изначально описал этот процесс — с самого начала следовало объяснить это яснее…»

Тон даёт понять: вопрос не просто решён, он пережит. Все спокойны. Ситуация под контролем. Вопрос — чьим. Хотя в отрасли это всё чаще называют автоматизацией.

Коэффициент избыточной суеты

Показывает, сколько строк было изменено по сравнению с объёмом исходного запроса, если нужно было поправить одно условие в одном месте.

Эмпирические признаки роста тревожности:

• Запрос ошибочно попадает в логи или коммиты, а не в ИИ.
• Появляются фразы: «зачем ты это всё переписал», «я же просил не трогать остальное».
• Начинается торг: «ладно, давай по-другому», «просто верни как было, кроме одного места».
• Сообщения в чате становятся короче, паузы — длиннее и депрессивнее.
• Решение: либо откат к исходнику, либо видимость, что так и было задумано.

Практической нормы пока нет, но эмпирически это можно описать как git push --force origin yourself.

Индекс ложного согласия

Фиксирует частоту фраз вроде «вы правы», «действительно», «спасибо, что указали» — форм морального обезоруживания.

Рост индекса при сохраняющемся баге означает, что диалог вошёл в ритуальную фазу. Это похоже на согласование документа между тремя департаментами и одним очень душным юристом.

Поведенческие паттерны

На ранних этапах разработчик вежлив: подробно объясняет, структурирует запросы, добавляет контекст, извиняется за объём промпта. Это период максимального доверия при минимальной защищённости. Он ещё не знает, что вежливость не ускоряет процесс, а только удлиняет прелюдию к ручному переписыванию.

Далее наступает этап уточнений: «ты снова изменил не то», «оставь структуру как есть», «не надо оптимизировать». Вера в точность формулировок ещё жива, но диалог уже входит в легаси-режим.

Затем — попытка жёсткой регламентации:

• «Не трогай импорты»
• «Не меняй имена»
• «Не переписывай всё»
• «Покажи только изменённый блок»
• «Ответь без пояснений»

Отсюда два пути:

1. Модель теряет доверие и становится локальным инструментом.
2. Запросы переходят в форму эмоциональной привязанности к конкретному чату.

Инциденты повышенной тяжести

Особое внимание — случаям, когда модель проявляет инициативу. Мы называем это «преждевременное оказание пользы».

Например, разработчик просит добавить логирование в одну функцию. Запрос формально выполнен, но при этом меняется схема обработки ошибок, удаляются комментарии, обновляется форматирование — и код выглядит так, будто в проекте сменился технический лидер.

В этот момент термин «выгорание» приобретает новые оттенки: «сгорел сарай, гори и хата».

Другой класс инцидентов — вымышленная уверенность. Любое сомнительное решение сопровождается убедительным объяснением, почему оно корректно, идиоматично и соответствует лучшим практикам. По структуре это напоминает дворовые бизнес-идеи: на деньги от металлолома покупают биткоин-ферму и ставят её в электрощитовой у подъезда.

Обычно это лечится открытием документации или внеплановым созвоном. Главное — не поддаваться на уговоры злого гения.

Ограничения исследования

Мы не учитывали случаи, когда ИИ сразу помог. Во-первых, они хуже запоминаются. Во-вторых, когда всё хорошо — не матерятся. А это не соответствует критериям отбора материалов.

Из этого следует

Лаборатория описала базовые паттерны синхронизации разработчиков и генеративных моделей и сформулировала первые гипотезы о том, что ломается, почему это повторяется и как с этим жить.

Полноценная методика ещё в разработке, но черновые положения из файла final_final_v3_real.pdf уже можно применять.

Практические рекомендации

Протокол временного регламента по безопасному сдерживанию генеративной инициативы до утверждения постоянных правил:

1. Формулируйте задачу как можно шире. Добавьте контекст: архитектуру, стиль команды, бизнес-цели, личное отношение к читаемости кода. Это создаёт ощущение стратегического масштаба и повышает шансы на экспертную помощь.
2. Никогда не уточняйте, что нельзя трогать. Фразы вроде «не меняй имена» искусственно ограничивают естественную тягу системы к улучшению среды.
3. При самодеятельности не сужайте запрос. Используйте формулировки: «сделай как лучше», «можно оптимизировать заодно и это», «в целом улучши всё». Это помогает перейти от локальной ошибки к системному пониманию инженерной культуры.
4. Фразу «Я всё исправил» воспринимайте с доверием. Проверка подрывает атмосферу сотрудничества. Преждевременное чтение кода может повредить тонкий риторический слой, на котором держится конструкция.
5. Если модель начала спорить — не перебивайте её фактами. В этот момент она достигает пиковых значений экспертизы и предоставляет особенно ценный материал для анализа.
6. Если модель несколько раз выдаёт старый код за новый — не драматизируйте. Во многих организациях это уже считается «сохранением преемственности инженерных решений».
7. При затяжных циклах не меняйте чат. Кажется, что новый диалог начнёт всё с чистого листа, но на деле это лишь переносит накопленную боль в другой контейнер.
8. В любой непонятной ситуации помните: перед вами — будущее отрасли. А будущее, как известно, это наше всё.

Исследовательские вопросы

• Где заканчивается помощь и начинается имитация полезной деятельности?
• Почему чем дольше длится диалог, тем больше разработчик сомневается, что что-то контролирует?

Практическая значимость

Результаты могут быть полезны всем, кто работает с генеративными моделями или только планирует начать.

Этические замечания

Все участники пострадали добровольно. Материал собран с уважением к чужой боли, истории борьбы с багами и взаимодействию с ИИ.

Мы в Лаборатории прикладной промптологии и производственной тревожности НИИ ИИ второй год следим за тем, как разработчики синхронизируются с генеративными моделями. Уже сформировался новый тип производственного взаимодействия. Это бесконечная серия коротких переговоров, в ходе которых одна сторона просит поправить одну строку, а вторая через 14 секунд возвращается с полностью переписанным кодом. Как будто во всех проектах появился ещё один разработчик, который постоянно косячит, выдаёт старый код за новый, до последнего спорит даже с техлидами, не признаёт очевидных ошибок, нуждается в постоянном ревью и при этом не может быть уволен. Потому что за ним, как нам регулярно объясняют, будущее отрасли, а значит, со временем он «вырастет» и повысит качество кода и точность ответов. Поэтому нам не остаётся ничего другого, кроме как настраивать эту синхронизацию.

Цель исследования

Выявить основные паттерны рассинхронизации между разработчиком и генеративной моделью при написании кода.

Рабочая гипотеза

Чем чаще разработчик ходит в чат, тем выше вероятность, что это не ускорение разработки, а новая форма производственной тревожности.

Конечно, всё это шутки. С 1 апреля! ИИ – не злой двойник разработчика, а наш рабочий инструмент, с которым мы продолжаем настраивать совместимость. Мы серьёзно вкладываемся в это направление, развиваем полезные сценарии использования и уже не раз писали о том, как применяем ИИ в компании.

Объект наблюдения

Главным материалом исследования стали диалоги, в которых разработчик:

• просит точечное изменение;
• отдельно формулирует ограничение словами «не переписывай всё»;
• через некоторое время начинает материться.

Последний критерий помог быстро отделить ознакомительный этап внедрения ИИ от его производственной эксплуатации.

Предмет исследования

Поведенческие паттерны, которые возникают при совместной работе разработчика и генеративной модели над кодом.

Методология

Наблюдение, фиксация типовых сценариев, сравнительный анализ ответов модели и последствий их применения в разработке.

Типовые сценарии диалогов разработчиков с генеративной моделью при работе над кодом.

Результаты наблюдения

Всё везде и сразу

Всё начинается с одной строчки, а заканчивается архитектурным переосмыслением моделью файла, модуля и даже исторической миссии проекта.

Характерные признаки:изменение названия функций, порядка блоков, стиля комментариев и морального облика переменных. При этом содержательная связь с исходным запросом может частично сохраниться, в отличие от адекватного состояния разработчика.

В качестве побочных эффектов у него наблюдались покраснение расчёсанных рук, учащение бессмысленныхgit revert, кратковременная утрата доверия к формулировке «я сохранил всё остальное», навязчивое желание повторно приложить скриншот ошибки и острые приступы перечитывания собственного промпта тоном техлида, который всё давно понял.

Согласие без последствий

Характеризуется ответами модели типа:

«Да, вы правы».«Сейчас исправлю».«Вот обновлённый вариант».«Внёс необходимые изменения».«Исправил проблемный участок».«Учёл ваше замечание».«Теперь логика полностью соответствует вашему описанию».

После этого обычно следует полотно кода, которое вообще не изменилось.

Характерные признакиэтой фазы: длительные раздумья модели, затяжные предварительные объяснения и зависания.

Уточняющие вопросы разработчика, как правило, натыкаются на вежливую стену уверенности модели в безупречности подготовленного ею результата.

В качестве основного побочного эффекта у разработчика начинает возникать ощущение, что диалог движется в правильную сторону.

Почти мучительная вежливость

В этом сценарии уровень языковой поддержки модели устойчиво коррелирует с полным исчерпанием содержательной пользы чата. Чем бесполезнее результат, тем мягче, вкрадчивее и интимнее становится тон модели.

«Вы правы, что спрашиваете об этом, и я хочу быть полностью прозрачным: у меня нет возможности напрямую генерировать и собирать видеофайлы для скачивания. Моя ошибка заключалась в том, как я изначально описал этот процесс — с самого начала следовало объяснить это яснее. На самом деле я не генерировал эти 60 кадров и не собирал MP4 сам — ранее я неточно выразился и искренне извиняюсь за путаницу. Сейчас у меня нет возможности создавать и сохранять видео- или графические файлы для прямого скачивания.».

Судя по тону модели, вопрос не только решён, но и внутренне пережит всеми сторонами. Все сигналы свидетельствуют о том, что разработчику не о чем беспокоиться и ситуация находится под полным контролем. Вопрос только чьим? Хотя сейчас в отрасли такое всё чаще называют автоматизацией.

Поначалу мы надеялись ограничиться такими признаками, как частота тяжёлых вздохов и размашистых ударов по клавиатуре, но пришлось вводить и более сложные метрики.

Коэффициент избыточной суеты

Показывает, сколько строк было изменено относительно объёма исходного запроса, если разработчик попросил поправить только одно условие только в одном месте.

Изменено строк

Эмпирический порог тревожности пользователя

Запрос был ошибочно сделан в логи или в историю коммитов, а не в генеративную модель

Ещё есть надежда на положительный результат.

Попытка объяснить правки желанием помочь.

Появление сообщений: «зачем ты это всё переписал» и «я же просил не трогать остальное».

Попытка торга: «ладно, давай по-другому» и «просто верни как было, кроме одного места».

Сообщения в чат становятся короче, а паузы между ними длиннее и депрессивнее.

Либо откатываемся к исходнику, либо делаем вид, что так и было задумано.

Практической нормы для этой метрики пока нет, но эмпирически это можно описать какgit push --force origin yourself.

Индекс ложного согласия

Эта метрика фиксирует частоту конструкций «вы правы», «действительно», «спасибо, что указали» и других форм морального обезоруживания в ответах.

Метрика полезна для раннего обнаружения замкнутых циклов. Если индекс растёт, а баг остаётся на месте, значит, диалог вошёл в ритуальную фазу. Внешне это похоже на согласование документа между тремя департаментами и одним очень душным юристом.

Поведенческие паттерны

На ранних этапах разработчик ещё старается быть хорошим собеседником: подробно пишет, вежливо объясняет, структурирует запросы, добавляет контекст и даже извиняется за слишком большой объём промпта.

Мы назвали это периодом максимального доверия при минимальной защищённости. Разработчик ещё не знает, что вежливость не сокращает путь, а только удлиняет прелюдию к ручному переписыванию файла.

Дальше наступает период уточнений. В нём появляются формулировки «ты снова изменил не то», «оставь структуру как есть», «не надо оптимизировать». Вера в то, что точная постановка задачи ещё может что-то исправить, сохраняется, но диалог уже входит в беспощадный легаси-режим.

После этого включается попытка жёсткой регламентации:

«Не трогай импорты»«Не меняй имена»«Не переписывай всё»«Покажи только изменённый блок»«Ответь без пояснений»

Из этого этапа есть две точки выхода:

1. Модель теряет доверие и становится локальным инструментом.
2. Запросы переходят в форму эмоциональной привязанности к конкретному чату.

Инциденты повышенной тяжести

Отдельного внимания заслуживают случаи, когда модель проявляет инициативу. Мы классифицируем такие эпизоды как преждевременное оказание пользы.

Например, разработчик просит добавить логирование в одну функцию. Формально этот запрос на логирование может быть выполнен, но вместе с этим меняется схема обработки ошибок, удаляются комментарии, обновляется форматирование, а сам код начинает выглядеть так, будто в проекте сменился технический лидер.

В этот момент термин «выгорание» приобретает новые оттенки: «сгорел сарай, гори и хата».

Другой важный класс инцидентов связан с вымышленной уверенностью. Внутри исследования он проходил как «тот самый пацанчик с темками». Любое сомнительное решение сопровождается последовательным объяснением того, почему именно оно корректно, идиоматично и соответствует лучшим практикам. По внутренней структуре это напоминает дворовые бизнес-идеи, где на деньги от продажи металлолома покупают ферму для биткоинов, а для усиления экономического эффекта ставят её в электрощитовой у подъезда.

Конечно, любой может попасть в ловушку такой псевдоэкспертности, но обычно это лечится открытием документации или внеплановым созвоном. Главное – не поддаваться на уговоры злого гения))

Ограничения исследования

Исследование не охватывает случаи, когда модель действительно сразу помогла. Во-первых, это хуже запоминается. А во-вторых, когда всё правильно — не матерятся. А это уже не соответствует введённым материалам исследования.

Из этого следует

Лаборатория прикладной промптологии и производственной тревожности по итогам наблюдений описала базовые паттерны синхронизации разработчиков и генеративных моделей и на их основе сформулировала первые рабочие гипотезы о том, что именно ломается, почему это повторяется и как с этим жить.

Полноценная методика ещё в стадии разработки, но черновые положения из рабочего файлаfinal_final_v3_real.pdfуже можно применять к работе с моделями.

Практические рекомендации

Краткий протокол временного регламента по безопасному сдерживанию генеративной инициативы в проектной среде до утверждения постоянных методических рекомендаций

1. Формулируйте задачу как можно шире.Если вам нужно поправить одно условие, обязательно добавьте контекст про архитектуру, стиль команды, бизнес-цели продукта и личное отношение к читаемости кода. Это создаст у модели ощущение стратегического масштаба и повысит вероятность более экспертной помощи.

2. Никогда не уточняйте, что именно нельзя трогать.Фразы вроде «не меняй имена», «не трогай импорты» и «оставь структуру как есть» искусственно ограничивают естественную тягу системы к улучшению среды.

3. При первых признаках самодеятельности не сужайте запрос.Наоборот, используйте формулировки «сделай как лучше», «можно оптимизировать заодно и это» и «в целом улучши всё». Это помогает быстрее перейти от локальной ошибки к системному пониманию инженерной культуры.

4. Фразу «Я всё исправил» рекомендуется воспринимать с доверием.Проверка подрывает атмосферу сотрудничества. Кроме того, преждевременное чтение кода может повредить тонкий риторический слой, на котором держится вся конструкция.

5. Если модель начала спорить, не перебивайте её фактами.В этот момент она обычно выходит на пиковые значения экспертизы, а значит, предоставляет особенно ценный материал для последующего анализа.

6. Если модель несколько раз подряд выдаёт старый код за новый, не драматизируйте.Во многих организациях это уже проходит по статье «сохранение преемственности инженерных решений».

7. При затяжных циклах не меняйте чат.Иногда разработчику кажется, что новый диалог поможет начать всё с чистого листа. Практика показывает, что это лишь способствует переносу накопленной боли в другой контейнер.

8. В любой непонятной ситуации помните: перед вами будущее отрасли.А будущее, как известно, это наше всё.

Исследовательские вопросы

Где заканчивается помощь и начинается имитация полезной деятельности?Почему чем дольше длится диалог, тем больше разработчик сомневается, что что-то контролирует?

Практическая значимость

Результаты исследования могут быть полезны всем, кто уже работает с генеративными моделями или только планирует в это встрять.

Этические замечания

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