Версия Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# ИИ пишет код. Кто научится его исправлять?

> Задача по программированию может быть выполнена ещё до того, как её автор разберётся в системе. Два эксперимента подводят команды к практическому вопросу: как младшие разработчики будут учиться объяснять, диагностировать и адаптировать работу с помощью ИИ?

By BIG CHANGE Editorial

Published: 2026-09-22T16:40:55.934Z
Updated: 2026-09-22T16:40:55.934Z
Canonical: https://bigchange.ai/blog/ai-coding-skills-learning-apprenticeship

![An automated arm assembles abstract interlocking modules while a junior developer studies orange pathways inside an opened module.](https://bigchange.ai/api/media/file/ai-coding-learning-apprenticeship-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. Automation can deliver a finished implementation before a newcomer has traced how it works. This conceptual scene represents the need to build understanding alongside AI-assisted output; it is not a product interface, study result or forecast of inevitable deskilling.

Младший разработчик может попросить ИИ-ассистента поработать с незнакомой библиотекой, получить работающий код и двигаться дальше. Функция может быть готова раньше, чем разработчик поймёт, почему она работает. Это важно, когда код в следующий раз даст сбой, требования изменятся или кому-то придётся решить, безопасно ли исправление ассистента.

Инженер-программист Александру Неделку поднял эту проблему в эссе от [22 сентября](https://alexn.org/blog/2026/09/22/ai-has-no-wisdom-and-neither-will-you). Он утверждает, что разработчики формируют инженерное суждение, читая код, принимая решения и сталкиваясь с последствиями ошибок. Его прогноз о том, что некоторые компании будут рекламировать политику отказа от ИИ, — мнение, а не наблюдаемый сдвиг в отрасли. Отдельный эксперимент, опубликованный в январе, позволяет поставить вопрос об обучении уже и проверить его: что программисты поняли сразу после выполнения задачи с помощью ИИ? [исследовании Anthropic](https://www.anthropic.com/research/AI-assistance-coding-skills)

## Главное изменение

- **Что изменилось:** ИИ упрощает сдачу готового программного обеспечения без самостоятельной проработки его логики. Он может предложить реализацию до того, как новичок потренируется принимать решения, необходимые для объяснения или исправления кода.
- **Почему это важно:** Сегодня руководители могут получить больший объём результата, но ослабить путь, по которому младшие сотрудники становятся специалистами, способными диагностировать завтрашние сбои. Риск особенно велик при работе с незнакомыми понятиями; помощь в знакомой работе всё ещё может быть полезной.
- **За чем следить:** Команды могут начать считать обучение частью поставки, выделяя время на объяснение, диагностику и адаптацию работы с ИИ. Тогда при найме и разработке инструментов для программирования могут наряду со скоростью оценивать продемонстрированное понимание.

## Выполненная задача и освоенный навык — разные результаты

В [рандомизированном исследовании с участием 52 программистов](https://arxiv.org/abs/2601.20245) участники использовали незнакомую библиотеку Python Trio для выполнения двух задач по программированию. Половина работала с ИИ-ассистентом, доступным прямо в среде разработки, половина — без него. Участники знали, что после этого пройдут тест. Вскоре после работы проверка оценивала понимание концепций, чтение кода и отладку.

Средний результат группы с ИИ составил 50% против 67% у группы без ИИ: разница в 17 процентных пунктов, а не относительное снижение на 17%. Наибольший разрыв был в вопросах по отладке. В среднем группа с ИИ закончила примерно на две минуты быстрее, но эта разница во времени не была статистически значимой. Это результаты короткого знакомства с одной библиотекой и немедленной проверки, а не оценка карьеры разработчиков или качества производственной системы. [Результаты и ограничения исследования](https://www.anthropic.com/research/AI-assistance-coding-skills)

Исследователи также наблюдали за тем, как участники пользовались ассистентом. Одни в основном делегировали написание и отладку кода; другие просили объяснений или самостоятельно разбирались в концепциях. Более вовлечённые модели взаимодействия, как правило, сопровождались лучшими результатами, однако эти небольшие группы выделили уже после эксперимента. Участников случайным образом распределяли по группам с доступом к ИИ и без него, но не по способу общения с ассистентом. Просьба объяснить решение может помочь обучающемуся, но это исследование не доказывает, что какой-либо запрос или процесс устраняет разрыв в обучении. [Анализ взаимодействия в статье](https://arxiv.org/html/2601.20245v2)

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

## Скорость тоже важна, а ответ зависит от задачи

В других условиях ИИ также ускорял программирование. В [контролируемом эксперименте с GitHub Copilot](https://arxiv.org/abs/2302.06590) 95 профессиональным фрилансерам поручили создать HTTP-сервер на JavaScript. Среди завершивших задачу участники с Copilot справились в среднем примерно за 71 минуту против 161 минуты в контрольной группе — время выполнения сократилось на 55,8%. Исследователи не проверяли, чему программисты научились после этого. Это была ограниченная задача по реализации, а не знакомство с незнакомой библиотекой с последующим тестом на понимание.

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

Эссе Неделку идёт дальше эксперимента. Он утверждает, что поддерживаемость становится заметна через месяцы или годы, а опыт растёт благодаря ответственности за ошибки. Исследование не измеряет долгосрочную поддерживаемость и не показывает, что пользователи ИИ вообще перестают учиться. Его полезный вызов адресован организациям: если команда всё чаще делегирует практическую работу, где будущие специалисты по устранению неполадок получат такую практику? [эссе Неделку](https://alexn.org/blog/2026/09/22/ai-has-no-wisdom-and-neither-will-you)

## Попросите обучающегося доказать понимание после запуска кода

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

1. **Объяснить:** Не обращаясь к ассистенту, описать, почему незнакомая часть кода работает, какие предположения она делает и что может привести к сбою. Старший инженер может задать уточняющий вопрос по конкретному изменению.
2. **Диагностировать:** Создать небольшую реалистичную неисправность в безопасной тестовой ветке. Попросить обучающегося найти причину и объяснить, какое наблюдение позволило отвергнуть заманчивый, но неверный вариант исправления. Важны рассуждения, а не запоминание команды.
3. **Адаптировать:** Изменить требование, а затем попросить обучающегося доработать реализацию и тесты. Пользоваться ИИ можно, но нужно уметь обосновать новое поведение и назвать то, что ещё следует проверить.

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

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

## Вопрос об ученичестве касается найма и проектирования продуктов

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

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

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

## Sources

- [Александру Неделку: «У ИИ нет мудрости, и у вас её тоже не будет»](https://alexn.org/blog/2026/09/22/ai-has-no-wisdom-and-neither-will-you) — В эссе Неделку утверждает, что инженерное суждение развивается через чтение, принятие решений и ответственность за ошибки. Его тезисы о поддерживаемости и прогноз о политике отказа от ИИ — мнение, а не измеренные результаты.
- [Anthropic: как помощь ИИ влияет на формирование навыков программирования](https://www.anthropic.com/research/AI-assistance-coding-skills) — Авторы описывают рандомизированный эксперимент Trio с 52 участниками: 50% против 67% в немедленном тесте, разница в 17 процентных пунктов; небольшая разница во времени выполнения не была статистически значимой. Наблюдения о стилях взаимодействия не являются экспериментальным выводом, а исследование не измеряет долгосрочное развитие карьеры.
- [Шэнь и Тэмкин: как ИИ влияет на формирование навыков](https://arxiv.org/abs/2601.20245) — В статье подробно описаны задача, участники, рандомизация и оценивание. В февральской версии исправлены опечатки в таблице. Мы опираемся на неё, ограничивая причинный вывод доступом к ИИ и немедленным пониманием, а не выдавая определённый способ формулировать запрос за доказанную методику.
- [Пэн и соавторы: влияние ИИ на продуктивность разработчиков](https://arxiv.org/abs/2302.06590) — В отдельном контролируемом исследовании Copilot профессиональные фрилансеры, создававшие сервер на JavaScript, выполнили задачу быстрее с помощью ИИ; сокращение времени на 55,8% рассчитано среди завершивших работу. Это исследование не проверяло обучение, а задача отличалась от упражнения с незнакомой библиотекой Trio.