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

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

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

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

Важно сразу отделить два разных вопроса, которые постоянно смешивают:

1. Помогает ли модель сделать работу? Часто да, иногда нет — см. измерения в главе 01.
2. Помогает ли модель научиться? Это отдельный вопрос с отдельным ответом, и связи между ними нет. Результат сегодня и способность повторить результат через месяц без инструмента — два разных измерения, и они умеют расходиться в разные стороны.

Всё, что будет ниже, крутится вокруг второго вопроса. Про то, как устроены сами модели, — трек ai-basics; про инженерную сторону работы с ними — трек ai-agents. Здесь — только про то, что происходит с вашей головой.

Один инструмент, два несовместимых режима

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

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

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

Почему режим по умолчанию не обучающий

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

Первое: попытка извлечения. Память укрепляется, когда её пытаются достать, а не когда в неё кладут — Roediger & Karpicke (2006), обзор Dunlosky и соавторы (2013). Ответ, полученный за две секунды, устраняет попытку. Подробно — извлечение из памяти.

Второе: порождение. Самостоятельно сформулированный ответ удерживается лучше прочитанного — эффект генерации, Slamecka & Graf (1978); и даже неудачная попытка перед объяснением улучшает последующее усвоение — Kornell, Hays & Bjork (2009). Модель порождает за вас.

Третье: желательная трудность. Условия, замедляющие освоение, улучшают удержание и перенос — Bjork & Bjork (2011). Инструмент, оптимизированный на устранение трудностей, не различает полезные и бесполезные: он устраняет все. Подробно — желательные трудности.

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

Разница между сценариями — примерно девяносто секунд вашего времени. Разница в исходе — та, ради которой написан весь трек.

Что известно из исследований

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

Прямые эксперименты: результаты противоположны

Bastani, Bastani, Sungu, Ge, Kabakcı, Mariman (2024), «Generative AI Can Harm Learning» (препринт SSRN). Полевой эксперимент в турецкой школе, около тысячи старшеклассников, математика. Три группы: контроль, обычный чат, чат с ограничениями (подсказки вместо готовых решений, спроектированные учителями). Во время практики обе группы с доступом решали заметно лучше контроля — порядка +48 % у обычного чата и +127 % у ограниченной версии. На последующей контрольной без доступа к инструменту группа обычного чата показала результат примерно на 17 % хуже контроля, а ограниченная версия — на уровне контроля.

Из этой картинки надо вынести три вещи, и все три неприятные.

1. Левая панель ничего не говорит о правой. Рост результата в присутствии инструмента — не индикатор обучения, а индикатор наличия инструмента.
2. Ограничения на подсказку сняли вред, но прироста по сравнению с контролем не дали. То есть «правильно настроенный ИИ-тьютор» в этом эксперименте оказался не лучше обычной практики, а просто не хуже.
3. Границы: школьники, математика, короткий горизонт, конкретная реализация. Переносить это на инженера, разбирающегося с транзакционной семантикой брокера, напрямую нельзя.

Kazemitabaar и соавторы (2023), «Studying the Effect of AI Code Generators on Supporting Novice Learners in Introductory Programming» (CHI 2023). Контролируемый эксперимент, около семи десятков новичков школьного возраста, вводное программирование, доступ к генератору кода на этапе обучения. Результат противоположный по знаку тревоге: на отложенной проверке без инструмента группа с генератором не показала ухудшения, а по части измерений оказалась лучше. Цифры и детали дизайна стоит смотреть в самой статье — здесь важен факт наличия результата с другим знаком.

Prather и соавторы (2024), «The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers» (ICER 2024). Наблюдательное исследование с протоколом «думай вслух»: за новичками смотрели, пока они решают задачи с ассистентом. Описаны характерные режимы залипания — принятие предложенного кода без понимания, дрейф от собственного плана к тому, что предложил инструмент, и рост уверенности, не подкреплённый результатом. Общий вывод авторов: разрыв между сильными и слабыми студентами расширяется. Дизайн наблюдательный и выборка небольшая — это описание феноменов, а не измерение эффекта.

Что из этого следует. Знак эффекта зависит от двух вещей: как устроен доступ (готовое решение против подсказки) и что именно измеряют (результат с инструментом или без него). Любое утверждение вида «исследования показали, что ИИ помогает/вредит обучению» без указания этих двух параметров — не результат, а лозунг.

Что даёт литература об обучающих системах

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

Bloom (1984), «The 2 Sigma Problem» (Educational Researcher, 13(6)) — источник знаменитого тезиса, что индивидуальное репетиторство даёт улучшение на два стандартных отклонения. Отсюда растёт вся риторика «ИИ даст каждому персонального репетитора и мы получим две сигмы».

VanLehn (2011), «The Relative Effectiveness of Human Tutoring, Intelligent Tutoring Systems, and Other Tutoring Systems» (Educational Psychologist, 46(4)) — систематический разбор, который эту картину переворачивает. Величины эффекта оказались порядка 0,79 для живого репетитора и порядка 0,76 для интеллектуальных обучающих систем относительно обучения без репетитора. Это заметно и полезно, но это не две сигмы, и разрыв между живым человеком и системой в этих данных мал. И дальше — уточнение, которое почти никогда не делают: интеллектуальные обучающие системы содержат модель ученика: отслеживают освоенные навыки, подбирают следующую задачу, дозируют подсказку. У чата такой модели нет вообще, поэтому переносить на него даже 0,76 нет оснований — это другой класс системы. Всё, что делает чат, — отвечает на то, что вы спросили, ровно настолько, насколько вы спросили.

Aleven, Stahl, Schworm, Fischer & Wallace (2003), «Help Seeking and Help Design in Interactive Learning Environments» (Review of Educational Research, 73(3)) и Baker, Corbett, Koedinger & Wagner (2004) про «gaming the system» — два десятилетия наблюдений за тем, как учащиеся обращаются с подсказками в таких системах. Устойчивый результат: значительная доля пользователей кликает по подсказкам до последней, самой конкретной, и решает задачу подсказкой, а не головой; и эта стратегия связана с худшими итоговыми результатами. Ещё раз: это описано за двадцать лет до языковых моделей, на системах, которые специально пытались подсказку дозировать. Чат подсказку не дозирует вообще.

Kalyuga, Ayres, Chandler & Sweller (2003) — эффект инверсии компетентности: подробное руководство помогает новичку и мешает эксперту. В нашем контексте это означает, что оптимальный режим работы с моделью у джуна и у сеньора — разный, и об этом отдельный раздел ниже.

Механизмы, у которых база есть вне темы ИИ

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

Беглость чужого объяснения принимается за собственное понимание. Deslauriers, McCarty, Miller, Callaghan & Kestin (2019) (PNAS, 116(39)): студенты на занятиях с активным вовлечением учились измеримо лучше, а чувствовали, что научились хуже, чем на гладкой лекции. Гладкость подачи повышает оценку своего понимания и не повышает понимание. Модель производит максимально гладкие объяснения — это её сильная сторона и одновременно главный источник систематической ошибки в самооценке. Смежные работы разобраны в главе про иллюзию понимания.

Доступ к знанию путается с обладанием знанием. Fisher, Goddu & Keil (2015) (JEP: General): возможность поискать в интернете завышает оценку собственного внутреннего знания, в том числе по темам, которые не искали. Ward (2021) (PNAS) уточнил эффект. Sparrow, Liu & Wegner (2011) (Science) описали смежное явление: когда информация доступна, лучше запоминается, где её взять, а не она сама. Здесь нужна честность: это работы про поисковые системы, а не про диалоговые модели; кроме того, статус репликаций части этих результатов стоит проверить самостоятельно, прежде чем на них опираться. Механизм — смешение внутреннего и внешнего источника — от природы источника не зависит, но это рассуждение, а не измерение.

Когнитивная разгрузка. Risko & Gilbert (2016), «Cognitive Offloading» (Trends in Cognitive Sciences, 20(9)) — обзор того, как люди систематически переносят когнитивную работу вовне. Ключевой вывод обзора трезвый: разгрузка рациональна и полезна, вопрос всегда в том, что именно разгружается. Разгрузить перебор синтаксиса — выигрыш. Разгрузить построение модели предметной области — потеря, отложенная во времени.

Модель соглашается с вами. Sharma и соавторы (2023), «Towards Understanding Sycophancy in Language Models» (препринт arXiv; искать по названию) документируют устойчивую склонность моделей подстраиваться под мнение собеседника, в том числе менять правильный ответ на неправильный после возражения пользователя. Для обучения это критично: источник обратной связи, который соглашается, обратной связью не является. Подробнее о том, почему испорченная обратная связь хуже её отсутствия, — обратная связь.

Чего нет

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

Правило порядка: попытка раньше ответа

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

Ваша попытка должна предшествовать ответу модели. Не «вместо», а «раньше». Порядок операций важнее их состава.

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

Смежная доказательная база: Kapur (2008), «Productive Failure» (Cognition and Instruction, 26(3)) — учащиеся, которые сначала безуспешно бились над задачей и только потом получали объяснение, показывали лучший перенос, чем те, кому объяснили сразу. Оговорка обязательна: результаты по продуктивной неудаче воспроизводятся не всегда и зависят от граничных условий — есть работы, уточняющие, когда именно «сначала попытка, потом объяснение» выигрывает у обратного порядка (см. обзорные работы Sinha и Kapur). Направление эффекта устойчиво, величина и границы — предмет спора.

Таймбокс. «Сначала попытка» не означает «мучиться час». Разумная договорённость с собой: 10–15 минут на самостоятельную попытку в незнакомой теме, которая останется в работе; ноль минут, если тема разовая. Верхняя граница нужна, потому что упорство ради упорства — не желательная трудность, а потеря времени; критерий полезности трудности разобран в главе 06. Практическая сторона удержания таких интервалов — фокус и помодоро.

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

Лестница подсказки

Между «спросил» и «не спросил» лежит шкала, и запрос можно осознанно поставить на нужную ступень.

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

1. Только термин. «Как называется ситуация, когда два запроса читают одно значение и оба пишут?» — вы получаете имя и дальше ищете сами. Имя — это ключ доступа: не зная слова, вы не сформулируете запрос ни в поиске, ни в модели.
2. Направление. «В каком разделе спецификации PostgreSQL это описано?», «В каком файле этого репозитория это скорее всего лежит?» Навигация сохраняется, содержание вы добываете сами.
3. Наводящий вопрос. Явно попросить не давать ответ: «Не отвечай. Задай мне три вопроса, которые помогут найти ошибку в моём рассуждении». Работает нестабильно — модель склонна сорваться в ответ, — но при явной инструкции чаще срабатывает.
4. Принцип без вашего кода. Объяснение механизма на нейтральном примере, дальше вы сами применяете к своей ситуации. Перенос остаётся вашей работой, а перенос — самое дорогое; см. перенос знания.
5. Пример на соседней задаче. Проработанный пример, но не вашей задачи. Для новичка это может быть лучшим вариантом: разбор проработанных примеров новичкам помогает (Sweller & Cooper, 1985), а самостоятельные блуждания без опоры — нет (Kirschner, Sweller & Clark, 2006).
6. Готовое решение. Быстро, законно, если тема не ваша. Обучающего события нет.

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

[Ступень 3 — не давать ответ]
Не давай решение и не пиши код, я разбираюсь сам. Моя гипотеза: <...>.
Задай 2–3 вопроса, проверяющих её, и скажи, какое наблюдение её
опровергнет. Если у меня неверное допущение — назови допущение, не вывод.

[Ступень 4 — принцип без моей задачи]
Объясни механизм <тема> на нейтральном примере, не связанном с моим кодом.
Мне нужна модель, а не патч. В конце — три условия, при которых он ломается.

[Проверка себя после разбора]
Моё объяснение своими словами: <текст>. Не хвали и не пересказывай.
Перечисли: что фактически неверно, что упущено, где я подменил термин.
Отдельно — какой вопрос покажет, что я на самом деле не понял.

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

Роли, в которых модель действительно помогает учиться

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

Переводчик уровня абстракции

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

Как выглядит. «Объясни MVCC так, как объяснил бы человеку, который знает, что такое транзакция и блокировка, но никогда не читал про снапшоты». Дальше — уточняющие вопросы там, где непонятно, без стеснения.

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

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

Генератор задач и вариаций

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

Как выглядит. «Дай десять фрагментов кода на Go, в пяти из которых есть гонка данных, в пяти нет; не говори, где именно; перемешай». Или: «сгенерируй пятнадцать ситуаций отказа в распределённой системе, где для трёх правильный ответ — ретрай, для трёх — идемпотентный ключ, для трёх — компенсирующая транзакция, остальные — что-то другое; порядок случайный».

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

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

Экзаменатор по вашему материалу

Что это. Скормить свои заметки, конспект, файл с архитектурным решением — и попросить задавать вопросы. Ценность в том, что вопросы задаются по вашему материалу, а не по абстрактной теме.

Как выглядит. «Вот мой конспект по консенсусу в Raft. Задавай по одному вопросу, жди ответа, не подсказывай. После моего ответа скажи только, сошлось или нет, и в чём разошлось. Начинай с самого важного».

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

Когда не окупается. Если вопросы получаются поверхностными (частый случай, когда исходный материал скудный) — вы тренируете узнавание терминов вместо механизмов. Признак: на все вопросы отвечаете сходу. Это не признак знания, это признак плохих вопросов.

Оппонент

Что это. Роль, в которой модель атакует ваше решение. Для инженера ближайший аналог — недоброжелательный ревьюер или архитектурный комитет.

Как выглядит. «Вот мой дизайн: <описание>. Ты — скептик, который считает, что он развалится под нагрузкой. Назови пять сценариев отказа, которые я не учёл, начиная с самого вероятного. Не предлагай решений».

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

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

Слушатель вашего объяснения

Что это. Вы объясняете — модель ищет пробелы. Это единственная роль, у которой доказательная база самого приёма особенно прилична: самообъяснение улучшает понимание и перенос (Chi, Bassok, Lewis, Reimann & Glaser, 1989; Chi, de Leeuw, Chiu & LaVancher, 1994). Причём эффект даёт само проговаривание, независимо от слушателя.

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

Чего требует и когда не окупается. Дисциплины писать до, а не после; и понимания, что «техника Фейнмана» — популярный бренд для того же самого: доказательная база есть у самообъяснения как приёма, а не у названия и не у ритуала с четырьмя шагами. Не окупается, если тема не будет применяться, — тогда это красивая трата вечера. Смежный эффект — «эффект протеже», когда человек учится лучше, готовясь учить кого-то (Chase, Chin, Oppezzo & Schwartz, 2009); проверялся на детях и программных агентах, перенос на взрослых инженеров не измерялся.

Навигатор по первоисточнику

Что это и как выглядит. Не заменитель чтения, а способ сократить время до нужной страницы: «где в спецификации HTTP описано поведение кэша при Vary?», «какой раздел исходников отвечает за планировщик?». Получаете адрес — идёте читать сами. Именно так сохраняется карта репозитория и документации, о которой говорилось выше.

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

Где модель отнимает обучение

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

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

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

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

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

Иллюзия покрытия. «Я прошёлся с моделью по всей теме» — за час можно получить обзор области, который ощущается как освоение области. Проверка ровно одна и она дешёвая: закройте чат и объясните тему письменно без подглядывания. Расхождение обычно шокирующее.

Антипаттерны, которые видно со стороны

• «Объясни и сразу напиши код». Две операции в одном запросе: объяснение вы прочитаете по диагонали, потому что код уже есть. Разделяйте.
• «Почему не работает?» с вставленным стектрейсом и без единой своей гипотезы. Дёшево, быстро, и через полгода вы не умеете читать стектрейсы.
• Итеративное «а теперь исправь» до зелёных тестов. Тесты позеленели, модель системы не построена ни у вас, ни у инструмента. Каталог того, как это ломается, — режимы отказа.
• Принятие кода, который вы не можете объяснить построчно, в области, за которую отвечаете. Это долг без тикета и без срока. Про то, как проверять такой код, — ревью кода от ИИ и верификация.
• Использование модели как единственного источника по спорному вопросу. У неё нет доступа к тому, что решили в вашей команде в прошлом квартале и почему.

Отдельно: новичок и модель

Здесь картина хуже всего, и об этом стоит сказать без смягчений. Из эффекта инверсии компетентности (Kalyuga и соавторы, 2003) и из наблюдений Prather и соавторов (2024) складывается неприятная асимметрия: новичок получает от модели наибольший прирост производительности и наибольший риск не построить схемы. Ему помогают сильнее, и он же теряет больше. Опытный инженер получает меньше ускорения, но у него есть чем проверять.

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

Как понять, учитесь ли вы

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

Отложенная проверка без инструмента. Единственный честный тест. Через несколько дней после разбора темы: закрыть всё, воспроизвести ключевое решение или объяснение письменно. Не «помню ли я, что читал», а «могу ли я это сделать». Как строить такие проверки — извлечение и интервальное повторение.

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

"""Журнал делегирования: что я отдал модели и мог ли сделать сам.

Это учёт, а не измерение: данные субъективные, контрольной группы нет.
Ценность — в том, что раз в месяц вы видите список тем, которые
делегируете целиком, и сверяете его со своей зоной ответственности.
"""

import json
from collections import Counter
from datetime import date
from pathlib import Path

LOG = Path.home() / ".delegation-log.jsonl"

# Поля записи: тема ("postgres/locks"), режим ("производство"/"обучение"),
# смог бы сам ("да"/"с трудом"/"нет"), моя ли это зона ответственности.


def log(topic: str, mode: str, could_alone: str, mine: bool) -> None:
    """Одна строка в конце сессии. Дольше десяти секунд — вести не будете."""
    entry = {"day": date.today().isoformat(), "topic": topic, "mode": mode,
             "could_alone": could_alone, "mine": mine}
    with LOG.open("a", encoding="utf-8") as f:
        f.write(json.dumps(entry, ensure_ascii=False) + "\n")


def gaps(min_events: int = 3) -> list[tuple[str, int]]:
    """Темы из моей зоны ответственности, где я ни разу не справился сам.

    O(n) по времени и O(k) по памяти: n — записей, k — различных тем.
    """
    total: Counter[str] = Counter()
    solo: Counter[str] = Counter()

    for line in LOG.read_text(encoding="utf-8").splitlines():
        e = json.loads(line)
        if not e["mine"]:
            continue          # чужие темы делегировать — нормально
        total[e["topic"]] += 1
        if e["could_alone"] == "да":
            solo[e["topic"]] += 1

    # Кандидаты в пробелы: тема встречается часто, самостоятельно — ни разу.
    return sorted(((t, n) for t, n in total.items()
                   if n >= min_events and solo[t] == 0), key=lambda p: -p[1])


if __name__ == "__main__":
    for topic, count in gaps():
        print(f"{topic}: {count} обращений, самостоятельно ни разу")

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

Самоэксперимент «день без модели». Раз в пару недель — рабочий день или хотя бы полдня без ассистента, на задачах из своей зоны; отключать лучше на уровне конфига редактора, а не силой воли. Результат дня — не сделанные задачи, а список затыков: где встали, что забыли, что казалось освоенным и не воспроизвелось. Затык в чужой теме — не проблема, затык в своей — предмет изучения. Честная оговорка: это n=1 без контроля и без слепоты, то есть не измерение, а способ обнаружить у себя разрыв, о котором вы иначе не узнаете. Как эксперимент он ничего не доказывает; как диагностика — работает.

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

Цена

Всё описанное стоит времени и комфорта, и это надо назвать прямо.

• Скорость сегодня падает. Попытка перед запросом, проверка объяснения, отложенное воспроизведение — это часы, которые не пошли в задачи. Если горит релиз, правильный ответ — режим производства и никакого обучения: обучение здесь инвестиция, а не гигиена.
• Ощущение хуже. Вы сознательно выбираете более медленный и менее приятный путь, а обратная связь о его пользе приходит через недели. Это ровно та конструкция, которую человек бросает; см. прокрастинацию и внимание и энергию.
• Требуется дисциплина в мелочах и отдельная работа по проверке. Написать гипотезу до запроса — операция на двадцать секунд, которая проваливается чаще всего именно потому, что ничего не стоит её пропустить. Сверить объяснение с документацией дольше, чем поверить; экономить на этом можно, но тогда модель предметной области строится на непроверенном фундаменте, и обнаружится это в самый неудобный момент.

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

Мифы этой темы

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

Мини-итог

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

Источники

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

ИИ и обучение:

• Bastani, Bastani, Sungu, Ge, Kabakcı, Mariman (2024). Generative AI Can Harm Learning. Препринт SSRN.
• Kazemitabaar и соавторы (2023). Studying the Effect of AI Code Generators on Supporting Novice Learners in Introductory Programming. CHI 2023.
• Prather и соавторы (2024). The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers. ICER 2024.
• Sharma и соавторы (2023). Towards Understanding Sycophancy in Language Models. Препринт arXiv.

Обучающие системы и репетиторство:

• Bloom (1984). The 2 Sigma Problem. Educational Researcher, 13(6).
• VanLehn (2011). The Relative Effectiveness of Human Tutoring, Intelligent Tutoring Systems, and Other Tutoring Systems. Educational Psychologist, 46(4).
• Aleven, Stahl, Schworm, Fischer & Wallace (2003). Help Seeking and Help Design in Interactive Learning Environments. Review of Educational Research, 73(3).
• Baker, Corbett, Koedinger & Wagner (2004). Off-Task Behavior in the Cognitive Tutor Classroom: When Students Game the System. CHI 2004.

Механизмы обучения:

• 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.
• Kapur (2008). Productive Failure. Cognition and Instruction, 26(3); см. также более поздние обзоры Sinha и Kapur о границах эффекта.
• Chi, Bassok, Lewis, Reimann & Glaser (1989). Self-Explanations. Cognitive Science, 13(2); Chi, de Leeuw, Chiu & LaVancher (1994). Eliciting Self-Explanations Improves Understanding. Cognitive Science, 18(3).
• Chase, Chin, Oppezzo & Schwartz (2009). Teachable Agents and the Protégé Effect. Journal of Science Education and Technology, 18(4).
• Sweller & Cooper (1985). The Use of Worked Examples as a Substitute for Problem Solving. Cognition and Instruction, 2(1).
• Kirschner, Sweller & Clark (2006). Why Minimal Guidance During Instruction Does Not Work. Educational Psychologist, 41(2).
• Kalyuga, Ayres, Chandler & Sweller (2003). The Expertise Reversal Effect. Educational Psychologist, 38(1).

Метапознание и разгрузка:

• Deslauriers, McCarty, Miller, Callaghan & Kestin (2019). Measuring Actual Learning Versus Feeling of Learning. PNAS, 116(39).
• Fisher, Goddu & Keil (2015). Searching for Explanations. JEP: General, 144(3); Ward (2021). People Mistake the Internet’s Knowledge for Their Own. PNAS, 118(43).
• Sparrow, Liu & Wegner (2011). Google Effects on Memory. Science, 333.
• Risko & Gilbert (2016). Cognitive Offloading. Trends in Cognitive Sciences, 20(9).
• Pashler, McDaniel, Rohrer & Bjork (2008). Learning Styles: Concepts and Evidence. PSPI, 9(3).

Что дальше

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

План обучения: как не утонуть и как заметить, что продвинулся