Trash News (private notes)

## Почему некоторым ИТ‑специалистам трудно работать с ИИ‑ассистентами

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

## Когнитивные и навыковые барьеры

### Отсутствие навыка декомпозиции

Эффективная работа с ИИ требует умения разбивать задачу на подзадачи и формулировать их так, чтобы они были понятны внешнему агенту.  
Типичные проявления:

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

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

### Слабая метаязыковая компетенция

Многие специалисты умеют писать код, но плохо описывают:

- контракты API;  
- сценарии использования;  
- бизнес‑контекст задачи;  
- ограничения среды и архитектуры.  

ИИ хорошо решает задачи, когда получает контекст: входные данные, примеры, формат результата, критерии корректности. Если этого нет, модель вынуждена «додумывать» детали, что рождает ошибки и усиливает недоверие к инструменту.

### Ожидание магии вместо диалога

Ещё одна распространённая проблема — ожидание одношагового чуда: «я напишу один запрос, и получу идеальное решение».  
Эффективная работа с ИИ больше похожа на парное программирование:

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

Те, кто не воспринимают это как диалог, быстро разочаровываются: первый ответ оказывается сырым, и инструмент объявляется «бесполезным».

## Психологические причины отказа от ИИ

### Угроза профессиональной идентичности

Для опытного специалиста ИИ может восприниматься как удар по самоощущению:

- «Если машина пишет код не хуже, то чем я вообще полезен?»  
- «Я десятилетиями копил опыт, а тут кто‑то нажимает кнопку и получает результат».  

Отсюда — подсознательное сопротивление: лучше объявить инструмент глупым и ненадёжным, чем признать, что часть привычного ручного труда теперь можно автоматизировать.

### Потребность в контроле

Некоторые специалисты болезненно относятся к любым «чёрным ящикам».  
ИИ:

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

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

### Страх потери уникальности

Часть профессионалов воспринимает свои знания как «личный капитал», который даёт им преимущество.  
Когда оказывается, что:

- шаблоны конфигураций;  
- типовые миграции;  
- распространённые паттерны архитектуры  

можно получить за секунды с помощью ИИ, возникает страх: «если это стало доступно всем, чем я отличаюсь от остальных?».

## Организационные и культурные факторы

### Недоверие к качеству и риски

Существует и рациональная сторона:

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

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

### Отсутствие нормальной онбординг‑культуры по ИИ

Во многих командах внедрение ИИ выглядит так: «вот вам доступ — дальше сами».  
Отсутствуют:

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

В итоге часть специалистов делает одну‑две неудачные попытки и закрепляет вывод: «это не работает».

## Как формировать культуру эффективной работы с ИИ

### Позиционировать ИИ как усилитель, а не замену

Важно явно проговаривать: ИИ — это:

- генератор черновиков и вариантов, а не финальный автор;  
- ускоритель рутины, а не замена архитектурного мышления;  
- инструмент для поиска решений, а не юридически ответственный субъект.  

Такое позиционирование снижает угрозу самооценке и помогает принять ИИ как часть рабочего стека.

### Учить декомпозиции и диалоговому стилю

Полезно развивать у специалистов два навыка:

- **Декомпозиция задач**: явный список шагов, подзадач и ограничений.  
- **Диалог с инструментом**: умение уточнять, проверять, критиковать и направлять модель.  

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

### Ограничивать ожидания и усиливать проверки

Чтобы уменьшить разочарование и реальные риски:

- сразу вводить правило: «любой код от ИИ проходит такой же ревью, как код человека»;  
- поощрять документирование: запросы, ответы и rationale решений;  
- использовать ИИ прежде всего там, где цена ошибки ниже (генерация тестов, документация, шаблоны).  

Так формируется практическое доверие к инструменту: он не идеален, но понятен и управляем.