Смена подхода к интеллектуальным задачам

Традиционный подход: контроль через компетенцию

Раньше возможности ограничены навыками. Развитие идёт медленно — как дерево наращивает годовые кольца, слой за слоем.

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

Современный подход: скорость через делегирование

Появление LLM-агентов изменило ситуацию. Специальные навыки больше не обязательны — задачи можно делегировать модели. Прогресс ускоряется в разы, открывая возможности, которые раньше были недоступны большинству пользователей.

Однако за скорость приходится платить предсказуемостью. Продумывание деталей реализации переходит от человека к модели, и направление развития решения может значительно отклониться от задуманного. Результат зависит от качества постановки задачи для AI — навыка, который нужно приобретать.

Почему ожидания расходятся с реальностью

Информационный шум и завышенные ожидания

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

Социальные сети усугубляют проблему. Они переполнены успешными кейсами: “я за час написал приложение с помощью Claude!” Создаётся искажённая выборка, где видны только победы — реальные или показательные псевдопобеды. Невидимы часы отладки, десятки неудачных попыток, тщательная подготовка промптов экспертами. Пользователь сравнивает свой реальный опыт с этими отретушированными примерами и делает вывод, что проблема в нём, а не в завышенных ожиданиях.

Когнитивная перегрузка

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

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

Маркетинг обещает мгновенную продуктивность. Реальность требует 2-3 месяцев последовательной практики для освоения базовых навыков работы с LLM [6]. Этот разрыв между обещанием и реальностью создаёт фрустрацию, которая накладывается на технические сложности самой технологии.

Технические причины сложности

Проблема “очевидного”

Главная сложность работы с LLM — асимметрия контекста. Пользователь держит в голове множество деталей своей задачи, включая те, которые кажутся настолько очевидными, что он не озвучивает их.

Для LLM никакого “очевидного” не существует. Модель работает исключительно с явно предоставленной информацией. То, что человек воспринимает как само собой разумеющееся, для модели остается белым пятном, которое она заполняет собственными предположениями.

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

Масштаб проблемы подтверждён эмпирически: анализ 433 диалогов разработчиков с ChatGPT показал, что отсутствие контекста — причина провала в 42% неэффективных промптов. Общий разрыв в знаниях встречается в 54.7% неудачных случаев против только 13.2% успешных [1].

Парадокс полной спецификации

В делегировании задач LLM есть противоречие:

Традиционная работа: начинаешь с неполного понимания → выполняешь → узнаёшь детали → корректируешь подход → продолжаешь. Неполное знание в начале — это норма.

Работа с LLM: должен предоставить полную спецификацию в начале → но критичные детали узнаёшь только в процессе работы → которую ты делегировал и не выполняешь сам → поэтому не узнаёшь этих деталей.

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

Конкретный пример: создавая UI компонент вручную, разработчик обнаруживает необходимость обработки edge cases только при интеграции с реальными данными — пустые списки, длинные заголовки, отсутствующие изображения. Эти требования проявляются в процессе, их невозможно сформулировать заранее. При делегировании LLM этот процесс открытия не происходит, и компонент создаётся без учёта случаев, о которых пользователь просто не подумал.

Это объясняет, почему эксперты предметной области получают лучшие результаты от LLM — не потому что они лучше “знают, как разговаривать с AI”, а потому что у них уже есть детальное понимание задачи, накопленное за годы ручной работы.

Потеря обратной связи и инкрементального обучения

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

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

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

Следствие: пользователь не получает обучающей обратной связи. Он не развивает интуицию о том, как правильно формулировать задачи, потому что не понимает механизма, который превратил его инструкцию в конкретный результат. В традиционной работе каждая ошибка объясняет себя сама — код не компилируется, тест падает, UI выглядит не так. С LLM результат просто “не тот”, но почему именно — остаётся неясным.

Дополнительный риск: петли обратной связи человек-AI усиливают предвзятости в 3 раза сильнее, чем человек-человек. Исследование показало, что начальная предвзятость в 53% превращается в 65% в выводах AI, затем ещё больше увеличивается, когда люди учатся на этих выводах — и часто не осознают этого влияния [2].

Психологические барьеры

Парадокс скорости

LLM может выполнить за минуты то, на что у человека ушли бы дни. Казалось бы, это делает итерацию тривиальной: получил неудовлетворительный результат — уточни задачу и запусти заново.

На практике возникает психологический барьер. Когда результат приходит быстро, но оказывается неправильным, это вызывает фрустрацию, блокирующую желание итерировать. Пользователь думает: “Раз это так быстро, почему не получилось с первого раза?”

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

Проблема калибровки ожиданий

В традиционной работе человек заранее знает, что задача займёт, например, неделю. Он морально готов к этому временному горизонту. С LLM задача “должна” решиться быстро, и каждая дополнительная итерация воспринимается как провал, хотя даже несколько итераций (каждая от минут до часов в зависимости от объёма и сложности) — это всё равно гораздо быстрее недели.

Отсутствует калибровка: сколько итераций “нормально” для задачи определённой сложности? Простая задача (форматирование кода) — 1-2 итерации. Средняя задача (новый компонент с чёткими требованиями) — 3-5 итераций. Сложная задача (рефакторинг архитектуры) — 7-15 итераций. Этот опыт ещё не накоплен интуитивно ни индивидуально, ни коллективно, поэтому любая итерация вызывает вопрос “а должно ли так быть?”

Исследование на 560 участниках выявило контринтуитивный метод ускорения калибровки: демонстрация границ ошибок AI (где и почему модель проваливается) улучшает решения о делегировании эффективнее, чем показ только успешных результатов [3]. Это сокращает время калибровки с недель до дней. Парадоксально, но знание ограничений инструмента оказывается важнее знания его возможностей.

Конструктивное vs деструктивное взаимодействие

Когнитивные процессы, которые мы тренировали десятилетиями, остаются невостребованными или используются неправильно. Исследования различают два типа взаимодействия с AI:

Конструктивное взаимодействие:

  • Задавать зондирующие вопросы к предложениям AI
  • Оспаривать предположения
  • Синтезировать вывод с независимыми знаниями
  • Использовать AI как партнёра по мышлению
  • Итерировать на несовершенных результатах

Деструктивное взаимодействие:

  • Пассивное потребление ответов
  • Принятие первого вывода без оценки
  • Аутсорсинг мышления вместо его усиления
  • Избегание итераций из-за воспринимаемого “провала”

Простое внедрение “челлендж-промптов” после ответов AI (“Какие предположения здесь могут быть неверны?”) снижает пассивное принятие на 40% [4].

Инверсия метрик и навыков

Невидимые vs видимые итерации

Правильный вопрос не “Почему LLM не сделал идеально с первого раза?”, а “Какое время до результата приемлемого качества?”

Традиционный подход:

  • Время до первого результата: дни/недели
  • Количество итераций: встроены в процесс (невидимы)
  • Качество: высокое (при наличии навыков)
  • Барьер входа: высокий (нужны навыки)

LLM-подход:

  • Время до первого результата: минуты
  • Количество итераций: 3-7 для средних задач (видимы и вызывают фрустрацию)
  • Качество: от базово работающего до высокого (зависит от постановки задачи)
  • Барьер входа: низкий (специальные навыки не обязательны)

Сдвиг от выполнения к формулированию

Возникает новая специализация: не “как сделать задачу”, а “как описать задачу так, чтобы LLM её сделал”. Это отдельный навык, требующий понимания:

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

Парадокс: теперь нужно учиться не столько делать, сколько объяснять. При этом качество результата по-прежнему зависит от глубины понимания предметной области — эксперты получают отличные результаты за 1-2 итерации, новички тратят 5-7 итераций на тот же результат. Это не проблема технологии, а естественное следствие того, что любой инструмент эффективнее в умелых руках.

Развитие этого навыка требует 2-3 месяца последовательного использования [6], а не интуитивного освоения, как обещает маркетинг. Это реальная кривая обучения, требующая целенаправленной практики.

Как адаптироваться

Переход от ручной работы к делегированию LLM — это обмен контроля на скорость. Мы получаем низкий барьер входа и многократное ускорение, но теряем непрерывную обратную связь и автоматическое обучение через практику.

Адаптация требует:

  1. Принять итеративность как норму: итерации могут занимать от минут до часов в зависимости от объёма и сложности, но это всё равно быстрее, чем делать руками

  2. Развивать навык вербализации контекста: явно указывать стиль кода, паттерны проектирования, требования к обработке ошибок

  3. Калибровать ожидания реалистично: сложные задачи требуют 7-15 итераций даже с LLM. Это нормально

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

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

  6. Разбивать задачи на наблюдаемые цепочки: вместо “проанализируй датасет и создай визуализацию” использовать пошаговый подход с видимыми промежуточными результатами. Исследования показывают, что 9 из 10 пользователей естественно принимают такой подход, и он сохраняет возможности обучения при использовании возможностей AI [5]

  7. Практиковать конструктивное взаимодействие: задавать вопросы к предложениям AI, оспаривать предположения, использовать модель как партнёра по мышлению, а не как оракула

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

Источники

[1] ArXiv (2025). Анализ диалогов разработчиков с ChatGPT на GitHub. Исследование выявило разрыв в знаниях как основную причину неэффективных промптов.

[2] Glickman, M., & Sharot, T. (2025). How human–AI feedback loops alter human perceptual, emotional and social judgements. Nature Human Behaviour, 9(2). https://www.nature.com/articles/s41562-024-02077-2

[3] Taudien, S., et al. (2022). Calibrating Users’ Mental Models for Delegation to AI. Proceedings of ICIS 2022. https://aisel.aisnet.org/icis2022/user_behaivor/user_behaivor/16/

[4] ArXiv (2025). From Consumption to Collaboration: Measuring Interaction Patterns to Augment Human Cognition in Open-Ended Tasks. https://arxiv.org/html/2504.02780

[5] Wu, T., et al. (2022). AI Chains: Transparent and Controllable Human-AI Interaction by Chaining Large Language Model Prompts. Proceedings of ACM CHI 2022. https://dl.acm.org/doi/fullHtml/10.1145/3491102.3517582

[6] Синтез исследований и практических наблюдений экспертов (Yan, E., Willison, S., et al.) о кривой обучения работе с LLM показывает необходимость 2-3 месяцев последовательной практики для достижения базовой компетентности в делегировании задач AI.

Дополнительная литература

  • De Freitas, J., et al. (2023). Psychological barriers to the adoption of AI. Nature Human Behaviour. https://www.hbs.edu/ris/Publication%20Files/DeFreitas%20-%20Nature%20Human%20Behavior%20-%20Psychological%20Barriers%20to%20AI_b802852e-5cfb-4dca-8e68-d45af0b7d818.pdf

  • Yan, E. (2023). Patterns for Building LLM-based Systems & Products. https://eugeneyan.com/writing/llm-patterns/

  • Weng, L. (2023). LLM Powered Autonomous Agents. https://lilianweng.github.io/posts/2023-06-23-agent/

  • Anthropic. (2025). Effective context engineering for AI agents. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

You May Also Enjoy