TL;DR
Когда два человека работают над одной задачей в разных чатах с AI — их результаты расходятся даже при одинаковых стартовых данных. Модель в каждом чате накапливает свой контекст, и через несколько запросов два пользователя получают два несовместимых решения. Исследователи назвали это context drift — контекстный дрейф.
Главная находка: AI не знает, что существует второй пользователь и второй чат. Каждая модель генерирует текст исходя только из своего диалога — и два человека с одинаковым заданием, но разными историями разговора, приходят к разным архитектурам, разным терминам, разным решениям. Особенно болезненно это проявляется, когда части одного проекта потом нужно соединить.
Второй эффект — ранний якорь: если пара запрашивала ответ у AI в самом начале работы, до собственного обсуждения, их дальнейшие решения крутились вокруг первого варианта. Думали меньше, исследовали меньше. Те, кто сначала обсуждал задачу между собой — получали более разнообразный и проработанный результат.
Схема находок
ПАТТЕРН 1: Один общий чат (shared instance)
→ Один человек вводит промпт, второй видит экран
→ Общий контекст → общее понимание → согласованный результат
ПАТТЕРН 2: Два отдельных чата (separate instances)
→ Каждый вводит промпты в свой чат
→ Контекст расходится → context drift → разные решения
РЕЖИМ ИСПОЛЬЗОВАНИЯ LLM (выбирайте осознанно):
IS (информатор) → задаёте вопросы, ответы вплетаете в своё решение
GE (генератор) → просите стартовый черновик, сами дорабатываете
PD (продюсер) → AI генерирует весь документ, вы направляете
ЛОВУШКА: Ранний якорь
→ Спросили AI ДО обсуждения между собой
→ Первый ответ стал рамкой
→ Остальные идеи отбрасывались как "не то"
Пример применения
Задача: Вы с партнёром по бизнесу готовите питч-дек для стартапа. Разделились: вы делаете слайды про продукт, он — про рынок. Каждый спрашивает Claude в своём чате.
Что пойдёт не так:
Вы описали аудиторию как "малый бизнес до 50 человек", ваш партнёр — как "предприниматели и фрилансеры". В финале слайды конфликтуют: объём рынка посчитан по-другому, ценностное предложение не бьётся с целевой аудиторией, тон разный.
Промпт — правильный старт:
Мы с партнёром делаем питч-дек для [название стартапа].
Контекст, который знают оба:
— Продукт: [что делает]
— Аудитория: [кто конкретно]
— Ключевое ценностное предложение: [одна фраза]
— Что уже решили: [список договорённостей]
Я отвечаю за раздел: [что именно]
Партнёр отвечает за: [что именно]
Правила единообразия:
— Называем аудиторию всегда: [как именно]
— Объём рынка считаем по: [какой методологии]
— Тон: [деловой / дружелюбный / etc]
Помоги мне с [конкретная задача] в рамках этих договорённостей.
Результат:
Модель будет работать в рамках зафиксированного контекста. Когда партнёр скопирует тот же "якорный блок" в свой чат — оба получат согласованную терминологию, единый образ аудитории и совместимые части.
Почему это работает
Слабость LLM: модель не помнит другие чаты и не знает, что существует второй пользователь. Каждый диалог — изолированный пузырь. Когда два человека идут разными путями, модель честно помогает каждому — и уводит их в разные стороны.
Сильная сторона LLM: модель отлично следует явно зафиксированным договорённостям. Если записать общий контекст в промпт — она держится его дисциплинированно. Единый "якорный блок" с ключевыми определениями и решениями выравнивает оба чата.
Про ранний якорь: LLM генерирует убедительные ответы с первого запроса — даже если задача не продумана. Мозг воспринимает конкретный текст как "уже решённое" и перестаёт искать альтернативы. Простое правило: сначала 10-15 минут обсудите задачу между собой — без AI. Потом идите к модели с вопросом.
Рычаги управления: - Якорный блок в начале промпта → синхронизирует два отдельных чата - Режим использования (IS / GE / PD) → выбирайте осознанно до начала работы, а не "по ходу" - Порядок работы: сначала люди, потом AI → снижает эффект раннего якоря
Шаблон промпта
Якорный блок для совместной работы
=== ОБЩИЙ КОНТЕКСТ ПРОЕКТА (не менять) ===
Проект: {название}
Цель: {одна фраза}
Аудитория: {конкретное описание — кто именно}
Ключевые договорённости:
— {договорённость 1}
— {договорённость 2}
— {договорённость 3}
Термины (использовать единообразно):
— {термин 1}: {как мы его понимаем}
— {термин 2}: {как мы его понимаем}
Моя зона ответственности: {что именно}
=== КОНЕЦ ОБЩЕГО КОНТЕКСТА ===
Режим работы: {информатор / генератор / продюсер}
Задача: {конкретный запрос}
Что подставлять:
- {название} — название проекта, документа или задачи
- {договорённости} — то, что вы с коллегой уже обсудили устно
- {термины} — слова, которые каждый может понять по-разному (аудитория, рынок, пользователь)
- {режим} — информатор (просто отвечает на вопросы), генератор (даёт черновик), продюсер (пишет весь документ)
🚀 Быстрый старт — вставь в чат:
Вот шаблон якорного блока для совместной работы с AI.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про состав команды, ключевые договорённости и как вы делите зоны ответственности — потому что без этого якорный блок не защитит от дрейфа. Она возьмёт паттерн и адаптирует под вашу задачу.
Ограничения
⚠️ Исследование, не техника: Это наблюдательное исследование — оно описывает что происходит, но не тестирует конкретные промпты. Практические рекомендации — интерпретация, не проверенные инструкции.
⚠️ Контекст — командная работа: Находки про дрейф и якорь исследовались в парах. Для соло-работы эффекты могут быть слабее — хотя дрейф между разными чатами одного человека тоже реален.
⚠️ Профессиональный контекст: Участники — опытные разработчики. Насколько находки переносятся на другие профессии и задачи — открытый вопрос.
⚠️ Маленькая выборка: 18 пар — достаточно для качественных наблюдений, но не для статистических законов.
Как исследовали
Команда собрала 18 пар опытных разработчиков и дала им 90 минут: спроектировать мобильное приложение для парковки велосипедов на кампусе университета. Задача намеренно выбрана нейтральной — не требует узкоспециальных знаний. У каждой пары был доступ к кастомному чату на базе ChatGPT 3.5, который логировал все промпты и ответы. Формат, инструменты и решение — использовать ли AI вообще — оставили на усмотрение участников.
Интересно: двое из 18 пар вообще не использовали AI — один выбрал Stack Overflow, другой решил что объяснять задачу модели займёт больше времени, чем просто подумать самим. Это само по себе инсайт: высококвалифицированные специалисты часто видят в AI больший накладной расход, чем ценность.
После сессии — интервью с каждой парой. Исследователи смотрели записи экранов, читали транскрипты разговоров, анализировали логи промптов. Они не знали заранее про "дрейф" или "якорь" — паттерны проявились при анализе. Именно поэтому им можно доверять: это наблюдение, а не подтверждение гипотезы.
Неожиданный вывод: опыт работы с AI не влиял на то, насколько команда полагалась на него. Новички и ветераны делали примерно одинаковые ставки на AI — просто по-разному с ним взаимодействовали.
Адаптации и экстраполяции
1. Борьба с якорем через "запрет на первый ответ"
🔧 Техника: задержать AI до первой версии своего решения
Перед тем как открыть чат — напишите свой ответ на задачу в 3-5 предложениях. Только потом идите к AI. Вы уже не чистый лист — у вас есть своя рамка, и первый ответ модели не станет якорем.
Вот моя первоначальная идея: {ваши 3-5 предложений}
Что в ней не так? Какие альтернативы я, возможно, не рассмотрел?
Не улучшай мою идею — найди её слабые места и предложи противоположные подходы.
2. Явный выбор режима в начале сессии
🔧 Техника: объявить режим работы до первого запроса
Три режима из исследования — информатор, генератор, продюсер — дают разный результат. Объявите режим явно:
Сегодня ты — информатор. Отвечай на конкретные вопросы.
Не предлагай структуру, не генерируй документы,
не давай рекомендаций если я не прошу.
Первый вопрос: {вопрос}
Это особенно полезно если вы склонны "соглашаться с AI" — режим информатора держит вас в позиции автора решения, а не его одобрителя.
Ресурсы
Статья: "The Role of LLMs in Collaborative Software Design" (2026) Конференция: 34th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (FSE Companion '26), Montreal Авторы: Victoria Jackson (University of Southampton), Yoonha Cha (UC Irvine), Rafael Prikladnicki (Pontifícia Universidade do Rio Grande do Sul), André van der Hoek (UC Irvine) DOI: https://doi.org/10.1145/3803437.3806702