Мы в Лаборатории прикладной промптологии и производственной тревожности НИИ ИИ второй год следим за тем, как разработчики синхронизируются с генеративными моделями. Уже сформировался новый тип производственного взаимодействия. Это бесконечная серия коротких переговоров, в ходе которых одна сторона просит поправить одну строку, а вторая через 14 секунд возвращается с полностью переписанным кодом. Как будто во всех проектах появился ещё один разработчик, который постоянно косячит, выдаёт старый код за новый, до последнего спорит даже с техлидами, не признаёт очевидных ошибок, нуждается в постоянном ревью и при этом не может быть уволен. Потому что за ним, как нам регулярно объясняют, будущее отрасли, а значит, со временем он «вырастет» и повысит качество кода и точность ответов. Поэтому нам не остаётся ничего другого, кроме как настраивать эту синхронизацию.
Цель исследования
Выявить основные паттерны рассинхронизации между разработчиком и генеративной моделью при написании кода.
Рабочая гипотеза
Чем чаще разработчик ходит в чат, тем выше вероятность, что это не ускорение разработки, а новая форма производственной тревожности.
Дисклеймер
Конечно, всё это шутки. С 1 апреля! ИИ – не злой двойник разработчика, а наш рабочий инструмент, с которым мы продолжаем настраивать совместимость. Мы серьёзно вкладываемся в это направление, развиваем полезные сценарии использования и уже не раз писали о том, как применяем ИИ в компании.
Объект наблюдения
Главным материалом исследования стали диалоги, в которых разработчик:
просит точечное изменение;
отдельно формулирует ограничение словами «не переписывай всё»;
через некоторое время начинает материться.
Последний критерий помог быстро отделить ознакомительный этап внедрения ИИ от его производственной эксплуатации.
Предмет исследования
Поведенческие паттерны, которые возникают при совместной работе разработчика и генеративной модели над кодом.
Методология
Наблюдение, фиксация типовых сценариев, сравнительный анализ ответов модели и последствий их применения в разработке.
Выборка
Типовые сценарии диалогов разработчиков с генеративной моделью при работе над кодом.
Результаты наблюдения
Всё везде и сразу
Всё начинается с одной строчки, а заканчивается архитектурным переосмыслением моделью файла, модуля и даже исторической миссии проекта.
Характерные признаки: изменение названия функций, порядка блоков, стиля комментариев и морального облика переменных. При этом содержательная связь с исходным запросом может частично сохраниться, в отличие от адекватного состояния разработчика.
В качестве побочных эффектов у него наблюдались покраснение расчёсанных рук, учащение бессмысленных git revert, кратковременная утрата доверия к формулировке «я сохранил всё остальное», навязчивое желание повторно приложить скриншот ошибки и острые приступы перечитывания собственного промпта тоном техлида, который всё давно понял.
Согласие без последствий
Характеризуется ответами модели типа:
«Да, вы правы».
«Сейчас исправлю».
«Вот обновлённый вариант».
«Внёс необходимые изменения».
«Исправил проблемный участок».
«Учёл ваше замечание».
«Теперь логика полностью соответствует вашему описанию».
После этого обычно следует полотно кода, которое вообще не изменилось.
Характерные признаки этой фазы: длительные раздумья модели, затяжные предварительные объяснения и зависания.
Уточняющие вопросы разработчика, как правило, натыкаются на вежливую стену уверенности модели в безупречности подготовленного ею результата.
В качестве основного побочного эффекта у разработчика начинает возникать ощущение, что диалог движется в правильную сторону.
Почти мучительная вежливость
В этом сценарии уровень языковой поддержки модели устойчиво коррелирует с полным исчерпанием содержательной пользы чата. Чем бесполезнее результат, тем мягче, вкрадчивее и интимнее становится тон модели.
«Вы правы, что спрашиваете об этом, и я хочу быть полностью прозрачным: у меня нет возможности напрямую генерировать и собирать видеофайлы для скачивания. Моя ошибка заключалась в том, как я изначально описал этот процесс — с самого начала следовало объяснить это яснее. На самом деле я не генерировал эти 60 кадров и не собирал MP4 сам — ранее я неточно выразился и искренне извиняюсь за путаницу. Сейчас у меня нет возможности создавать и сохранять видео- или графические файлы для прямого скачивания.».
Судя по тону модели, вопрос не только решён, но и внутренне пережит всеми сторонами. Все сигналы свидетельствуют о том, что разработчику не о чем беспокоиться и ситуация находится под полным контролем. Вопрос только чьим? Хотя сейчас в отрасли такое всё чаще называют автоматизацией.
Метрики
Поначалу мы надеялись ограничиться такими признаками, как частота тяжёлых вздохов и размашистых ударов по клавиатуре, но пришлось вводить и более сложные метрики.
Коэффициент избыточной суеты
Показывает, сколько строк было изменено относительно объёма исходного запроса, если разработчик попросил поправить только одно условие только в одном месте.
Изменено строк | Эмпирический порог тревожности пользователя |
≤ 0 | Запрос был ошибочно сделан в логи или в историю коммитов, а не в генеративную модель |
1–3 | Ещё есть надежда на положительный результат. |
4–12 | Попытка объяснить правки желанием помочь. |
13–30 | Появление сообщений: «зачем ты это всё переписал» и «я же просил не трогать остальное». |
31–70 | Попытка торга: «ладно, давай по-другому» и «просто верни как было, кроме одного места». |
71–140 | Сообщения в чат становятся короче, а паузы между ними длиннее и депрессивнее. |
> 140 | Либо откатываемся к исходнику, либо делаем вид, что так и было задумано. |
Практической нормы для этой метрики пока нет, но эмпирически это можно описать как git push --force origin yourself.
Индекс ложного согласия
Эта метрика фиксирует частоту конструкций «вы правы», «действительно», «спасибо, что указали» и других форм морального обезоруживания в ответах.
Метрика полезна для раннего обнаружения замкнутых циклов. Если индекс растёт, а баг остаётся на месте, значит, диалог вошёл в ритуальную фазу. Внешне это похоже на согласование документа между тремя департаментами и одним очень душным юристом.
Поведенческие паттерны
На ранних этапах разработчик ещё старается быть хорошим собеседником: подробно пишет, вежливо объясняет, структурирует запросы, добавляет контекст и даже извиняется за слишком большой объём промпта.
Мы назвали это периодом максимального доверия при минимальной защищённости. Разработчик ещё не знает, что вежливость не сокращает путь, а только удлиняет прелюдию к ручному переписыванию файла.
Дальше наступает период уточнений. В нём появляются формулировки «ты снова изменил не то», «оставь структуру как есть», «не надо оптимизировать». Вера в то, что точная постановка задачи ещё может что-то исправить, сохраняется, но диалог уже входит в беспощадный легаси-режим.
После этого включается попытка жёсткой регламентации:
«Не трогай импорты»
«Не меняй имена»
«Не переписывай всё»
«Покажи только изменённый блок»
«Ответь без пояснений»
Из этого этапа есть две точки выхода:
Модель теряет доверие и становится локальным инструментом.
Запросы переходят в форму эмоциональной привязанности к конкретному чату.
Инциденты повышенной тяжести
Отдельного внимания заслуживают случаи, когда модель проявляет инициативу. Мы классифицируем такие эпизоды как преждевременное оказание пользы.
Например, разработчик просит добавить логирование в одну функцию. Формально этот запрос на логирование может быть выполнен, но вместе с этим меняется схема обработки ошибок, удаляются комментарии, обновляется форматирование, а сам код начинает выглядеть так, будто в проекте сменился технический лидер.
В этот момент термин «выгорание» приобретает новые оттенки: «сгорел сарай, гори и хата».
Другой важный класс инцидентов связан с вымышленной уверенностью. Внутри исследования он проходил как «тот самый пацанчик с темками». Любое сомнительное решение сопровождается последовательным объяснением того, почему именно оно корректно, идиоматично и соответствует лучшим практикам. По внутренней структуре это напоминает дворовые бизнес-идеи, где на деньги от продажи металлолома покупают ферму для биткоинов, а для усиления экономического эффекта ставят её в электрощитовой у подъезда.
Конечно, любой может попасть в ловушку такой псевдоэкспертности, но обычно это лечится открытием документации или внеплановым созвоном. Главное – не поддаваться на уговоры злого гения))
Ограничения исследования
Исследование не охватывает случаи, когда модель действительно сразу помогла. Во-первых, это хуже запоминается. А во-вторых, когда всё правильно — не матерятся. А это уже не соответствует введённым материалам исследования.
Из этого следует
Лаборатория прикладной промптологии и производственной тревожности по итогам наблюдений описала базовые паттерны синхронизации разработчиков и генеративных моделей и на их основе сформулировала первые рабочие гипотезы о том, что именно ломается, почему это повторяется и как с этим жить.
Полноценная методика ещё в стадии разработки, но черновые положения из рабочего файла final_final_v3_real.pdf уже можно применять к работе с моделями.
Практические рекомендации
Краткий протокол временного регламента по безопасному сдерживанию генеративной инициативы в проектной среде до утверждения постоянных методических рекомендаций
1. Формулируйте задачу как можно шире.
Если вам нужно поправить одно условие, обязательно добавьте контекст про архитектуру, стиль команды, бизнес-цели продукта и личное отношение к читаемости кода. Это создаст у модели ощущение стратегического масштаба и повысит вероятность более экспертной помощи.
2. Никогда не уточняйте, что именно нельзя трогать.
Фразы вроде «не меняй имена», «не трогай импорты» и «оставь структуру как есть» искусственно ограничивают естественную тягу системы к улучшению среды.
3. При первых признаках самодеятельности не сужайте запрос.
Наоборот, используйте формулировки «сделай как лучше», «можно оптимизировать заодно и это» и «в целом улучши всё». Это помогает быстрее перейти от локальной ошибки к системному пониманию инженерной культуры.
4. Фразу «Я всё исправил» рекомендуется воспринимать с доверием.
Проверка подрывает атмосферу сотрудничества. Кроме того, преждевременное чтение кода может повредить тонкий риторический слой, на котором держится вся конструкция.
5. Если модель начала спорить, не перебивайте её фактами.
В этот момент она обычно выходит на пиковые значения экспертизы, а значит, предоставляет особенно ценный материал для последующего анализа.
6. Если модель несколько раз подряд выдаёт старый код за новый, не драматизируйте.
Во многих организациях это уже проходит по статье «сохранение преемственности инженерных решений».
7. При затяжных циклах не меняйте чат.
Иногда разработчику кажется, что новый диалог поможет начать всё с чистого листа. Практика показывает, что это лишь способствует переносу накопленной боли в другой контейнер.
8. В любой непонятной ситуации помните: перед вами будущее отрасли.
А будущее, как известно, это наше всё.
Исследовательские вопросы
Где заканчивается помощь и начинается имитация полезной деятельности?
Почему чем дольше длится диалог, тем больше разработчик сомневается, что что-то контролирует?
Практическая значимость
Результаты исследования могут быть полезны всем, кто уже работает с генеративными моделями или только планирует в это встрять.
Этические замечания
Все участники исследования пострадали добровольно. Материал собирался с уважением к чужой боли, истории борьбы с багами и взаимодействию с ИИ.
