Зачем учиться, когда есть ИИ: разбор без утешений

Вопрос звучит примерно так: «Модель пишет код быстрее меня и знает больше меня. Зачем я потрачу двести часов на изучение того, что она выдаёт за секунды?»

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

Утешение первое: «ИИ — это просто инструмент, всё как раньше». Неправда. Кое-что действительно изменилось, и делать вид, что нет, — значит терять время на вещи, которые больше не окупаются.

Утешение второе: «Учиться теперь не нужно, нужно уметь промптить». Тоже неправда, и это дороже первой ошибки, потому что расплата приходит позже — в момент, когда сломанную систему надо чинить, а знания, которое для этого нужно, ни у кого в комнате нет.

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

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

Часть 1. Что известно измеримо

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

Эксперименты, показавшие ускорение

Peng, Kalliamvakou, Cihon, Demirer (2023), The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. Рандомизированный эксперимент, 95 разработчиков, задача — написать HTTP-сервер на JavaScript. Группа с Copilot справилась на 55,8 % быстрее. Цифра честная, но границы у неё жёсткие: изолированная задача с нуля, стандартный шаблон, отсутствие существующей кодовой базы, отсутствие требований к сопровождению. Исследование выполнено сотрудниками GitHub — это не делает его неверным, но означает, что задача выбрана в зоне, где инструмент силён.

Cui, Demirer, Jaffe, Musolff, Peng, Salz (2024), «The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers». Три полевых эксперимента, суммарно тысячи разработчиков в Microsoft, Accenture и одной анонимной компании. Основной результат — рост числа завершённых задач порядка 26 % у групп с доступом к Copilot, с большим эффектом у менее опытных участников. Работа опубликована как препринт на SSRN; искать по названию и фамилиям авторов. Ограничение принципиальное: измерялось количество завершённых единиц работы, а не их качество и не стоимость последующего сопровождения.

Эксперимент, показавший замедление

METR (2025), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Рандомизированный эксперимент на 246 реальных задачах в зрелых open-source репозиториях; участники — 16 опытных контрибьюторов, работавших со своим кодом в среднем несколько лет. Результат: с ИИ-инструментами задачи выполнялись на 19 % дольше.

Самое интересное — не знак эффекта, а то, что участники его не заметили.

До эксперимента разработчики прогнозировали ускорение на 24 %. После эксперимента — уже зная свои результаты, но не зная агрегированных данных — они считали, что ускорились примерно на 20 %. Фактически они замедлились на 19 %. Разрыв между ощущением и измерением — около 39 процентных пунктов.

Выборка мала, задачи специфичны (крупные знакомые репозитории с высокими требованиями к качеству), инструменты — начала 2025 года. Это не общий закон. Но конкретно расхождение субъективной оценки с измерением — тот самый феномен, вокруг которого построен весь этот трек, и мы вернёмся к нему в главе про иллюзию понимания.

Наблюдательные данные

DORA, Accelerate State of DevOps Report 2024. Опрос, а не эксперимент. Прирост внедрения ИИ на 25 % ассоциирован со снижением пропускной способности доставки примерно на 1,5 % и стабильности доставки примерно на 7,2 %. Это корреляция на самоотчётах: организации, активно внедряющие ИИ, могут отличаться от остальных десятком других способов. Разбор того, почему такие данные нельзя читать как причинность, — в главе про причинные и статистические ошибки.

Perry, Srivastava, Kumar, Boneh (2023), «Do Users Write More Insecure Code with AI Assistants?» (конференция ACM CCS, препринт arXiv:2211.03622). Участники с доступом к ИИ-ассистенту писали менее безопасный код — и при этом чаще были уверены, что написали безопасный. Тот же разрыв между ощущением и фактом, но уже по качеству, а не по скорости.

Vaithilingam, Zhang, Glassman (2022), «Expectation vs. Experience» (CHI Extended Abstracts). Пользователи Copilot не завершали задачи значимо быстрее, но предпочитали работать с ним — потому что он избавлял от поиска и написания рутины. Предпочтение реально; ускорение — не обязательно.

Что из этого следует

Не «ИИ ускоряет» и не «ИИ замедляет». Следует более скучное и более полезное:

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

Часть 2. Почему «модель знает — мне не надо» ломается механически

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

Он ломается в четырёх местах, и все четыре — не про мораль, а про механику.

2.1. Проверка требует того же знания, что и производство

Вы не можете принять решение, которое не умеете оценить. Приняв его без оценки, вы приняли не решение, а ставку.

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

Практика проверки чужого и сгенерированного кода разобрана в главах ревью кода, написанного ИИ и верификация результата.

2.2. Постановка задачи требует модели предметной области

Чтобы получить полезный ответ, нужно задать вопрос в терминах, которых вы можете не знать. Не зная слова «идемпотентность», вы не спросите про идемпотентность — вы спросите «почему деньги списались дважды» и получите правдоподобный разбор сетевых ретраев без упоминания ключа идемпотентности.

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

2.3. Модель уверенно ошибается, и уверенность не коррелирует с правотой

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

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

2.4. Иронии автоматизации: это уже проходили

Всё описанное выше — не новость про ИИ. Это известный класс эффектов из инженерной психологии, задолго до языковых моделей.

Lisanne Bainbridge (1983), Ironies of Automation (Automatica, 19(6)). Центральный парадокс: автоматизация забирает у оператора рутинные действия, но оставляет ему аварийные — то есть именно те, для которых нужен навык, поддерживаемый рутинной практикой. Оператор теряет квалификацию ровно там, где его вмешательство критично.

Endsley & Kiris (1995) описали out-of-the-loop performance problem: человек, наблюдающий за автоматикой вместо того, чтобы действовать, хуже понимает текущее состояние системы и медленнее вмешивается при отказе.

Parasuraman & Riley (1997), «Humans and Automation: Use, Misuse, Disuse, Abuse» (Human Factors, 39(2)) и обзор Parasuraman & Manzey (2010) — про automation bias и complacency: люди систематически принимают подсказку автоматики без проверки, и тем охотнее, чем чаще она была права раньше.

Перенос на разработку прямой и печальный: чем надёжнее модель в 95 % случаев, тем меньше шансов, что вы заметите оставшиеся 5 %. Это цена, а не мнение, и она платится не в момент использования, а позже.

Смотреть на эту картинку стоит так: генерация кода сжимает фазу «написать» — реальную и часто большую. Она не сжимает «понять, что нужно» и «внедрить, а потом отвечать за это». А фаза «проверить» может вырасти, потому что читать чужой правдоподобный код дороже, чем свой, и требует знания, которого вы не приобрели, пока его писала модель.

Часть 3. Что действительно перестало окупаться

Это самая полезная часть главы, потому что она про экономию времени, а не про долг.

Подешевело, и это правда:

• Заучивание сигнатур и деталей API. Помнить порядок аргументов в strftime или точное имя флага в ffmpeg — навык, стоимость которого упала практически до нуля. Она падала и раньше — сначала из-за документации по F1, потом из-за поиска и Stack Overflow. Модель просто продолжила тренд.
• Одноразовый шаблонный код. Конфиг CI, разовый скрипт миграции, регулярное выражение под конкретный лог, парсер CSV с кривой кодировкой. Если код выполняется один раз и его результат проверяется глазами, учиться писать его самому незачем.
• Первый черновик в незнакомой области. Раньше вход в тему стоил вечера гуглинга, чтобы понять хотя бы словарь. Теперь — двадцати минут диалога. Это реальное и большое ускорение старта.
• Механический перевод между формами. JSON в структуру, SQL в ORM, один язык в другой на уровне синтаксиса.

Подорожало — и вот это важно:

• Умение отличить правдоподобное от правильного. Раньше неправильный ответ обычно выглядел неправильно: обрывочный кусок с форума, устаревший ответ с минусами, страница на непонятном языке. Теперь неверный ответ выглядит как верный. Стоимость навыка оценки выросла напрямую.
• Знание собственной системы. Ваш репозиторий, ваши обходные решения, ваши договорённости с соседней командой, причина, по которой в проекте до сих пор живёт странный воркараунд, — этого нет ни в одной обучающей выборке. Это буквально то, за что вам платят.
• Модель предметной области. Чтобы спросить, надо знать имя (см. 2.2). Словарь области — теперь не удобство, а условие доступа.
• Знание, работающее в условиях отсутствия ИИ: ночной инцидент, отсутствующий интернет, закрытый контур, ситуация, где цена ошибки такова, что «модель сказала» не является объяснением ни для кого.

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

Часть 4. Историческая аналогия и почему она ничего не доказывает

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

Оба — не аргументы, а выбор аналогии. Полезнее посмотреть, что на самом деле происходило.

Что здесь видно и что не видно.

Видно: каждый раз дешевело исполнение, а дорожала оценка. Ассемблерное кодирование ушло из массовой практики — понимание того, что делает процессор, осталось нужным там, где важна производительность. Заучивание API ушло — умение выбрать между двумя ответами осталось.

Не видно: доказательства, что так будет и дальше. Индукция по четырём случаям — не закон. Возможно, оценка тоже подешевеет. Возможно, следующий скачок затронет именно её. У нас нет данных о будущем, и любой, кто говорит иначе, продаёт прогноз, а не знание. Разбор того, как отличать обоснованное утверждение от красиво оформленного, — в научном и инженерном рассуждении.

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

Популярное утверждение «период полураспада знаний инженера — пять лет» гуляет по конференциям без прослеживаемого источника. Направление верное, конкретная цифра — фольклор; не опирайтесь на неё в решениях.

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

Часть 5. Что происходит с обучением, когда рядом есть модель

Здесь механизм самый неприятный, потому что вред тихий.

5.1. Готовый ответ отменяет попытку извлечения

Обучение закрепляется не тогда, когда информация поступает в голову, а тогда, когда её оттуда достают. Это самый воспроизводимый результат в исследованиях обучения: Roediger & Karpicke (2006), «Test-Enhanced Learning» (Psychological Science, 17(3)) и обзор Dunlosky, Rawson, Marsh, Nathan & Willingham (2013) (Psychological Science in the Public Interest, 14(1)), где практика извлечения и распределённое повторение получили высшую оценку полезности, а перечитывание и подчёркивание — низшую.

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

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

5.2. Полезная трудность удаляется первой

Robert Bjork ввёл понятие desirable difficulties — трудностей, которые замедляют освоение и улучшают удержание и перенос (краткое изложение: Bjork & Bjork (2011), «Making Things Hard on Yourself, But in a Good Way»). Родственный эффект — эффект генерации: Slamecka & Graf (1978) показали, что самостоятельно порождённое слово запоминается лучше прочитанного. И Kornell, Hays & Bjork (2009) показали, что даже неуспешная попытка ответить до объяснения улучшает последующее усвоение.

Из этого следует неприятное: инструмент, оптимизированный на устранение трудностей, устраняет и полезные тоже — он не различает их. Ощущение лёгкости при этом растёт, а лёгкость субъективно воспринимается как признак понимания. Отсюда прямая дорога к иллюзии понимания; разбор самих трудностей — в главе желательные трудности.

5.3. Что показали эксперименты про ИИ и обучение

Bastani, Bastani, Sungu, Ge, Kabakcı, Mariman (2024), «Generative AI Can Harm Learning» — полевой эксперимент в турецкой школе, около тысячи старшеклассников, математика. Доступ к ИИ-репетитору заметно улучшал результат во время практики и ухудшал результат на последующей контрольной без доступа к инструменту. Версия с ограничениями (подсказки вместо готовых решений) вред снимала, но прироста итоговых баллов не давала. Работа доступна как препринт на SSRN; искать по названию.

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

Про исследование, которое цитируют неправильно. Работу Kosmyna и соавторов (MIT Media Lab, 2025) с ЭЭГ во время написания эссе с ChatGPT в прессе пересказали как «ИИ разрушает мозг». Это препринт, 54 участника, задача — школьное эссе, измерялись показатели связности ЭЭГ и способность процитировать собственный текст. Из такого дизайна нельзя получить вывод о когнитивной деградации. Если встретите заголовок про «атрофию мозга от ИИ» — это он, и его так читать нельзя.

Чего нет. Нет ни одного контролируемого исследования долгосрочного влияния ИИ-инструментов на профессиональное развитие инженеров. Все утверждения на эту тему — включая интуитивно убедительные — сейчас являются гипотезами. Отраслевой опыт (в том числе изложенный в этой главе) исследованием не является.

5.4. Инвертированный эффект руководства

Есть эффект, который делает картину сложнее и потому особенно важен: expertise reversal effect (Kalyuga, Ayres, Chandler, Sweller, 2003, Educational Psychologist, 38(1)). Подробное руководство помогает новичку и мешает эксперту: эксперту оно навязывает лишнюю обработку и мешает применять собственные схемы. Смежный тезис — Kirschner, Sweller & Clark (2006): обучение с минимальным руководством («просто разбирайся сам») для новичков работает хуже, чем прямое объяснение.

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

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

5.5. Уровни владения: где именно теряется переход

Полезно смотреть не на бинарное «знаю / не знаю», а на состояния и переходы между ними.

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

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

Часть 6. Мифы, которые попадутся по дороге

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

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

Часть 7. Ответ на вопрос главы

Собираем. Учиться нужно — но не по причинам, которые обычно называют.

Не потому, что «ИИ хуже человека». По многим задачам не хуже. Аргумент от гордости ничего не стоит.

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

А вот настоящие причины:

1. Ответственность не делегируется. Инцидент разбирают с вами, а не с моделью. Всё, что вы не можете объяснить, вы будете объяснять в постмортеме. Практика разбора — дежурства и инциденты.
2. Ваша ценность — в знании, которого нет в обучающей выборке. Устройство вашей системы, история решений, ограничения бизнеса, договорённости между командами. Чем больше типового кода пишет модель, тем большую долю вашей ценности составляет именно это.
3. Обучение снижает стоимость проверки. Это самый прямой экономический аргумент: знание окупается не тем, что вы быстрее пишете, а тем, что вы за минуту отличаете рабочее решение от правдоподобного. При выросшем потоке правдоподобных решений эта экономия только растёт.
4. Асимметрия ошибок. Ошибка «выучил лишнее» стоит потраченного времени. Ошибка «не выучил нужное» стоит инцидента, провала на собеседовании или потолка в карьере — и обнаруживается в момент, когда учиться уже поздно. При равной неопределённости выбирают сторону с дешёвой ошибкой.
5. Мы не знаем, что будет дальше. Это не повод учить всё подряд — это повод предпочитать знание, устойчивое к смене инструмента (см. таблицу слоёв в части 4).

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

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

Часть 8. Как это выглядит у инженера: три сценария и цена каждого

Абстракция бесполезна без конкретики. Три типичные ситуации, три разных ответа.

Сценарий 1. Разовый скрипт на незнакомом языке

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

Решение: делегировать целиком. Не учить синтаксис, не читать книгу, не «заодно разобраться». Проверка: сверить результат на подвыборке, которую посчитали вручную или другим способом. Цена: через полгода вы не сможете написать такой скрипт сами. И это нормально — вам и не нужно. Когда не работает: если выясняется, что скрипт стал частью еженедельного отчёта. Тогда вы уже в сценарии 2 и не заметили перехода. Признак перехода: вы запускаете это второй раз.

Сценарий 2. Новая библиотека, которая войдёт в систему надолго

Команда берёт незнакомый брокер сообщений. Он останется на годы.

Решение: смешанное. Модель — для карты области и словаря (быстрый вход, часть 3). Дальше — своими руками: поднять локально, сломать намеренно, посмотреть поведение при отказе, прочитать первоисточник — документацию и, если есть, дизайн-документ. Ключевой кусок интеграции написать самостоятельно, даже если модель напишет быстрее. Проверка: нарисовать по памяти, что происходит при потере соединения в момент подтверждения, и сверить с реальностью экспериментом. Цена: двадцать-тридцать часов, которые можно было сэкономить в моменте. Окупаются на первом же инциденте — но не гарантированно: если библиотеку через квартал выкинут, вложение сгорит. Это ставка, а не безрисковая инвестиция, и честно называть её ставкой. Как читать первоисточники эффективно — чтение технических текстов; как учиться на чужом коде — учиться на чужом коде.

Сценарий 3. Инцидент в вашей системе

Три часа ночи, деградация, у вас пятнадцать минут до эскалации.

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

Общий принцип поперёк всех трёх: делегируйте производство, не делегируйте понимание того, за что отвечаете.

Часть 9. Ошибки, которые делают именно инженеры

• Путать «сделал» с «умею». Задача закрыта — значит, разобрался. Нет: закрытая задача говорит о состоянии «могу с подсказкой» (см. 5.5). Единственная дешёвая проверка — попробовать воспроизвести ключевое решение через неделю без подсказок.
• Копить долги понимания в коде, прошедшем ревью. Ревью проверяет код, а не ваше понимание кода. Влитый PR, который вы не сможете объяснить, — это долг, у которого нет тикета и срока, и он предъявится в момент отказа.
• Учить то, что интересно, вместо того, что закрывает пробел. Приятнее читать про распределённые системы, чем разбираться, почему у вас в проекте не работает кэш. Инструмент против этого — карта пробелов: карта карьеры портала даёт готовый список того, что обычно требуется на конкретных ролях и грейдах; сопоставление с реальными требованиями — в главах про грейды и рост. Как из этого собрать план — план обучения.
• Читать вместо проверки. Чтение приятно, ощущается как работа и почти не даёт удержания. Об этом вся глава иллюзия понимания.
• Принимать объяснение модели за верифицированное знание. Объяснение, которое звучит связно, часто верно — но связность порождается механизмом, не связанным с истинностью. Перепроверяйте объяснения, на которых будете строить решения.
• Считать, что обучение — вопрос дисциплины. Это в первую очередь вопрос устройства процесса и наличия времени. Организационная часть — внимание и энергия, фокус, прокрастинация и выгорание. Здесь мы разбираем устройство самого обучения, а не расписание.
• Учиться без обратной связи. Практика без проверки закрепляет и ошибки тоже. Это отдельная большая тема — обратная связь.

Мини-итог

• Контролируемые данные о влиянии ИИ на продуктивность разработчика противоречивы и зависят от контекста: сильное ускорение на типовых задачах с нуля, нулевой или отрицательный эффект на зрелых знакомых кодовых базах.
• Устойчивый и воспроизводящийся результат — разрыв между ощущением ускорения и измеренным результатом. Ощущению доверять нельзя ни в работе, ни в обучении.
• Делегировать производство можно; делегировать проверку — нет, потому что проверка требует того же знания, что и производство.
• Подешевело: заучивание API, шаблонный код, вход в незнакомую тему. Подорожало: способность отличить правдоподобное от верного, знание собственной системы, словарь предметной области.
• Механика обучения не изменилась: работает извлечение из памяти, распределённая практика, желательные трудности. Инструмент, устраняющий трудности, устраняет и полезные — он их не различает.
• Про долгосрочное влияние ИИ на профессиональное развитие инженеров контролируемых данных нет. Всё остальное на эту тему, включая эту главу, — рассуждение, а не измерение.
• Практический критерий, куда вкладывать время: смогу ли я оценить чужое решение по этой теме? Если нет, а тема остаётся в работе — это ваш следующий предмет изучения.

Источники

Работы, на которые опирается глава. Ссылки на конкретные страницы даны там, где я уверен в адресе; в остальных случаях приведены авторы, год и название — их достаточно для поиска.

Измерения влияния ИИ на разработку:

• Peng, Kalliamvakou, Cihon, Demirer (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.
• METR (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.
• Cui, Demirer, Jaffe, Musolff, Peng, Salz (2024). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. Препринт SSRN.
• Perry, Srivastava, Kumar, Boneh (2023). Do Users Write More Insecure Code with AI Assistants?
• DORA (2024). Accelerate State of DevOps Report.

Автоматизация и человек:

• Bainbridge (1983). Ironies of Automation. Automatica, 19(6).
• Endsley & Kiris (1995). The Out-of-the-Loop Performance Problem and Level of Control in Automation. Human Factors, 37(2).
• Parasuraman & Riley (1997). Humans and Automation: Use, Misuse, Disuse, Abuse. Human Factors, 39(2).
• Parasuraman & Manzey (2010). Complacency and Bias in Human Use of Automation. Human Factors, 52(3).

Обучение:

• Roediger & Karpicke (2006). Test-Enhanced Learning. Psychological Science, 17(3).
• Dunlosky, Rawson, Marsh, Nathan & Willingham (2013). Improving Students’ Learning With Effective Learning Techniques. PSPI, 14(1).
• Slamecka & Graf (1978). The Generation Effect. JEP: Human Learning and Memory, 4(6).
• Kornell, Hays & Bjork (2009). Unsuccessful Retrieval Attempts Enhance Subsequent Learning. JEP: LMC, 35(4).
• Bjork & Bjork (2011). Making Things Hard on Yourself, But in a Good Way.
• Kalyuga, Ayres, Chandler & Sweller (2003). The Expertise Reversal Effect. Educational Psychologist, 38(1).
• Kirschner, Sweller & Clark (2006). Why Minimal Guidance During Instruction Does Not Work. Educational Psychologist, 41(2).
• Bastani и соавторы (2024). Generative AI Can Harm Learning. Препринт SSRN.

Разбор мифов:

• Pashler, McDaniel, Rohrer & Bjork (2008). Learning Styles: Concepts and Evidence. PSPI, 9(3).
• Ericsson, Krampe & Tesch-Römer (1993). The Role of Deliberate Practice in the Acquisition of Expert Performance. Psychological Review, 100(3).
• Macnamara, Hambrick & Oswald (2014). Deliberate Practice and Performance. Psychological Science, 25(8).
• Kruger & Dunning (1999). Unskilled and Unaware of It. JPSP, 77(6); критика — Krueger & Mueller (2002), JPSP; Nuhfer и соавторы (2016–2017), Numeracy.

Что дальше

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

Что значит понимать: узнавание, воспроизведение, перенос