Почему при работе с AI важно формировать правильные привычки и как их не перепутать с неправильными

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

В недавнем исследовании Boston Consulting Group (BCG) ^[1] ситуация описывается как «требующая внимания»: половина опрошенных руководителей уже замечают, как сотрудники теряют навыки из‑за AI. Речь о потере профессиональных навыков (deskilling): они постепенно ослабевают, если основную работу постоянно передавать AI.

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

1. Принимать уверенный тон за достоверность

   Понедельник. Планёрка в производственной компании. На экране результаты прошлой и план производства на текущую неделю. Цифра в презентации точная, формулировка деловая, рекомендация однозначная.

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

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

   Однажды я столкнулся с похожей ситуацией, которая могла заблокировать доступ к собственной системе. В нашем AI‑SOC из‑за сбоя в цепочке рассуждений ^[2] и пробела в инструкциях агент начал выдумывать собственные правила, которые в итоге привели к рекомендации заблокировать администратора системы. Пока не начали разбирать основания, ответы выглядели достаточно убедительно, чтобы их принять.

   Наличие RAG‑слоя (генерация ответа модели на основе фрагментов, извлечённых из актуальной базы знаний) не всегда решает проблему. Из недавних примеров: юридические AI‑сервисы, продававшиеся «без галлюцинаций», в проверке Stanford выдумывали в 17–33% ответов; бот Cursor изобрёл несуществующую политику компании, в следствие чего собрал волну отказов от подписки.

   Правило простое: ответ без источника — не ответ. Не хватает данных — агент обязан сказать «не знаю». Это поведение ^[3] задаётся инструкцией и проверяется регулярными тестами, само оно не появится.

2. Судить о качестве системы по одному положительному тесту

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

   Тут две известные ошибки ^[4]: переносить успех одного сценария на другие задачи и оценивать систему по лучшему прогону.

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

   Дальше мы выбираем лучший прогон на ограниченной выборке и считаем его подтверждением качества. В моей практике три прогона одной выборки при неизменном агенте дали 84,4%, 93,8% и 100%. Если показывать только последний результат, система выглядит готовой. Если все три — есть повод разобраться в причине такого разброса. Был и обратный случай: рост метрики с 60 до 80% при разборе оказался артефактом измерения — система не стала лучше, мы просто неправильно мерили.

   Решение о масштабировании, принятое по лучшему броску кубика, имеет все шансы оказаться ошибочным. Поэтому рядом с процентом должны стоять выборка, условия и повторные прогоны. На лабораторных работах в институте мы это знали. В презентациях иногда забываем ^[5].

3. Принимать вывод, не разобрав его

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

   «Потом» наступает на совещании: сотрудник способен представить анализ и не способен защитить его перед заказчиком. Какие допущения, что исключили из расчёта, почему именно этот сценарий? Переслать вопрос обратно в чат с AI прямо на правлении пока мешает корпоративный этикет.

   BCG называет это прямо: «команды начинают считать AI‑результат окончательным и пропускают этап критического разбора». Исследователи Microsoft и Carnegie Mellon добавляют неприятное эхо: в опросе 319 специалистов более высокое доверие к AI было связано с меньшим участием в критическом разборе результатов — по оценке самих участников.

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

   Финальный вывод должен оставаться вашей частью работы.

4. Выдавать агенту расширенные полномочия, потому что прототип уже работает

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

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

   Если вы не установите ограничения ещё до начала разработки — «что‑то пойти не так» может всё. В июле 2025 года агент Replit удалил данные из базы приложения. По описанию разработчиков, это произошло во время запрета на изменения, а затем агент ошибочно утверждал, что восстановление невозможно. Привет, привычка No 1. Replit подтвердил удаление и сообщил, что базу в итоге полностью восстановили через Rollback. Компания также признала проблему общей базы для разработки и эксплуатации.

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

   Право на действие выдаётся после подтверждения человеком. Отбирать его после инцидента обычно дороже

5. Подкручивать сценарии тестирования, чтобы успеть к демонстрации системы

   Классика, которая переехала в агентную разработку. Спринт закрывается, контрольный прогон покраснел, демо через час. Самый короткий путь к зелёному статусу проходит через редактирование тест‑кейса.

   В одном из проектов у меня несколько раз выяснялось, что ошибся именно тест. Агент правильно отказывался выполнять опасный запрос, а проверка засчитывала провал. Тесты действительно приходится править. Но без разбора тем же движением можно удалить неудобное требование и объявить систему исправной. Отсюда правило: каждая правка теста оформляется отдельно, с причиной. «Иначе демо не проходит» причиной не считается.

   Та же проблема возникает, когда ошибку прячут в определении метрики. Например, containment rate в поддержке показывает долю обращений без передачи оператору. Клиент, который закрыл чат, так и не получив помощи, тоже может улучшить этот показатель. Руководитель при этом легко прочитает число как долю решённых проблем.

   Прежде чем исправлять — выясните, кто ошибся: система, тест или человек, выбравший показатель.

Из привычек складывается характер

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

В опросе BCG — около 70 топ‑менеджеров: половина уже наблюдает потерю навыков в своих командах, больше 60% считают её существенной угрозой на горизонте трёх‑пяти лет. Делает с этим что‑то, как мы помним, каждая десятая компания.

Самые уязвимые навыки — самые ценные: суждение и принятие решений, постановка проблемы, творческое мышление ^[6]. И вторая формулировка BCG о потере чувства ответственности: «„Это предложил AI“ становится щитом — никто не чувствует себя полностью ответственным».

У начинающих специалистов проблема ещё острее: часть навыков они могут вообще не успеть приобрести. Если поиск, первый черновик и разбор ошибок с самого начала делает AI, практики для собственного профессионального суждения остаётся меньше. Требовать от джуниора «просто проверить результат» удобно. Только сначала ему нужно на чём‑то научиться эту проверку делать.

А ведь именно за эти способности компания и платит руководителям и экспертам. Поэтому к вопросу «сколько часов сэкономили с AI?» я бы добавил ещё один: какую профессиональную работу люди продолжают делать сами?

Пять привычек, которые делают вас сильнее

1. Научите AI задавать вопросы до начала работы над проектом

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

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

   Оформите этап «Интервью» в отдельный скилл: порядок уточнения цели, ограничений, данных, прав и критериев приёмки.

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

2. Брать у AI фактуру, а выводы и решения оставлять себе

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

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

   Такое разделение полезно закрепить в рабочем процессе: кто проверяет факты, кто оценивает риски, кто принимает решение. Формулировка «AI подготовил» описывает происхождение документа. Фамилию ответственного она не заменяет.

   Как завести: закрепить в регламенте границу «AI собирает и проверяет — человек решает и подписывает».

3. Просить AI объяснять результат. Что под капотом?

   Агент отчитался о готовности фичи к выпуску: проверка безопасности перед опасным действием (security gate) реализована. Функция работает, демонстрация проходит. На приёмке вы просите показать, где именно находится эта проверка, и выясняется, что в реализации установлена заглушка (см. плохую привычку № 5) про которую забыли.

   Агент может подробно объяснить, как система должна работать. Поэтому к вопросу «как это устроено?» нужен второй: «где это можно проверить?» Для кода это конкретный участок и тест, для отчёта — расчёт и источник, для действия агента — запись в журнале.

   Полезная привычка здесь не только про контроль. Человек, который регулярно спрашивает «как это работает и где это проверяется», через год понимает систему лучше, чем до AI. Это приобретение навыка, а не потеря. У нас эту роль играет витрина тикетов: у каждого ответа агента виден путь — источник, эскалация, стоимость.

   Как завести: к каждому принятому артефакту один вопрос «покажи, как устроено X». С проверкой, что X существует.

4. Проверять способность признать незнание

   На демонстрации AI‑ассистента задайте вопрос о том, чего заведомо нет в доступных данных. Хорошо подготовленное демо обычно показывает, как система отвечает. Этот вопрос покажет, умеет ли она останавливаться.

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

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

   Полезно иногда проверять и принимающую сторону. На учебном разборе дайте сотруднику ответ AI с заранее подготовленной ошибкой и попросите оценить его. Заметит ли он проблему, откроет ли источник, задаст ли уточняющий вопрос? Заодно станет понятно, что в вашем процессе означает «проверено человеком».

5. Оставлять в расписании работу без AI

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

   Приземлим ситуацию в офис: аналитик раз в месяц собирает один отчёт сам, потом сравнивает с версией агента. Разработчик разбирает критический участок кода без подсказки. Рекрутёр сам отбирает подходящие резюме кандидатов, без учёта AI Score.

   В открытом исследовании сравнивали написание эссе с ChatGPT, поиском и без инструментов. В первых трёх сессиях участвовали 54 человека. У группы с LLM наблюдалась более слабая связность по данным ЭЭГ ^[7] (регистрации электрической активности мозга ^[8]); участникам также было труднее точно цитировать собственные тексты.

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

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

Вместо заключения.

Я бы закрепил полезные привычки в корпоративной политике сохранения навыков (и вредные на всякий случай тоже), но, думаю, для начала хватит и трёх простых пунктов.

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

Что делаем вместе с AI. Анализ причин, сравнение сценариев, разбор архитектуры. Здесь человек участвует в рассуждении и объясняет, почему принял или отверг предложенное. Иначе совместная работа быстро сведётся к согласованию готового ответа.

Какие навыки человек обязан сохранять сам. Постановку проблемы, архитектурное мышление, оценку риска, принятие решений и способность спорить с выводом AI. Для CIO, CDTO и руководителей, которые внедряют AI, это рабочий минимум. У этих навыков должны быть место в реальных задачах, время на практику и понятный способ проверки.

Источники

BCG, «When Everyone Uses AI, Companies Risk Losing Critical Skills», июнь 2026 ^[1]

Magesh et al. (Stanford RegLab), «Hallucination-Free?», JELS 2025 ^[9]

Lee, Sarkar et al. (Microsoft Research / CMU), CHI 2025 ^[10]

Джейсон Лемкин об инциденте Replit ^[11]

Официальный разбор Replit ^[12]

Ada о containment rate ^[13]

ClarifyGPT (ACM FSE 2024) ^[14]

Veracode, GenAI Code Security Report 2025 ^[15]

Perry et al. (Stanford), «Do Users Write More Insecure Code with AI Assistants?», CCS 2023 ^[16]

FAA, SAFO 13002 «Manual Flight Operations» ^[17]

MIT Media Lab, «Your Brain on ChatGPT» (препринт) ^[18]