ИИ-инструменты для кода мешают начинающим разработчикам стать опытными

Эссе «AI Coding will Prevent Expertise» на блоге larsfaye.com разбирает, почему постоянная опора на ИИ-ассистенты для кода мешает разработчикам, и в первую очередь начинающим, сформировать настоящую экспертизу. В доступном тексте автор эссе не подписан. Он отталкивается от собственной предыдущей статьи «Agentic Coding is a Trap» и введённого там понятия «парадокса опытного оркестратора»: навыки, нужные для эффективного управления ИИ-агентами при написании кода, это ровно те же навыки, что угасают от постоянного использования этих агентов. Опытные разработчики, по его наблюдению, страдают от этого меньше: их знания успели затвердеть за годы практики. У тех, кто пришёл в профессию уже во времена больших языковых моделей, такого запаса опыта нет, хотя от них при этом ждут (иногда прямо требуют) ускоряться с помощью тех же ИИ-ассистентов, которыми эффективно и ответственно способен пользоваться только тот, у кого уже есть многолетний опыт. Эссе открывается словами Сэма Альтмана из OpenAI: «Мы видим будущее, где интеллект, коммунальная услуга вроде электричества или воды, и люди покупают его у нас по счётчику и используют так, как им вздумается».

Дальше вводится понятие «эксперта-новичка» (Expert Novice). Индустрия, по описанию автора, шлёт начинающим разработчикам противоречивые сигналы. С одной стороны: тезис «ИИ вас не заменит, вас заменит тот, кто использует ИИ», который в ходу с 2023 года, и посыл, что без ИИ вы отстанете от коллег. С другой: тут же говорится, что лучший результат от этих моделей получают только те, кто применяет мышление более высокого порядка, не «вайб-кодит», а пишет продуманные спецификации, проектирует по хорошим паттернам и тщательно проверяет вывод модели, прежде чем что-либо отправлять в продакшен. Но именно такие навыки, продукт того самого трения и сложностей, через которые годами проходит человек, чтобы выработать профессиональное чутьё, «хороший вкус». Получается порочный круг: если инструменты требуют экспертизы, но сами при этом убирают трение, которое эту экспертизу формирует, откуда новичку взять экспертизу, чтобы начать эффективно этими инструментами пользоваться?

Одна из надежд в том, что модели сами ускорят обучение, пока используются для генерации кода: джуниоры смогут работать с той же уверенностью, что и ветераны, при «личном ИИ-репетиторе», а знание синтаксиса и мелкие пробелы в понимании будет закрывать сам инструмент. Но компания JetBrains, крупный игрок на рынке инструментов для разработчиков, недавно сослалась на исследование «The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers» («Расширяющийся разрыв: польза и вред генеративного ИИ для начинающих программистов»; его авторы и институция в тексте эссе не названы). Оно детально разобрало живые сессии кодинга новичков с разной степенью ИИ-помощи и пришло к парадоксальному на первый взгляд выводу: «Участники думали, что это как личный репетитор. Судя по данным нашего исследования... мы увидели, что на деле они не использовали инструменты генеративного ИИ как репетитора. На деле было ровно наоборот».

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

Из-за самонаправленной природы LLM получается «перевёрнутое обучение»: чем больше опыта у человека, тем больше пользы приносит модель, потому что он способен точно её направлять, проверять и перепроверять результат; чем меньше опыта, тем сильнее модель способна ввести в заблуждение. В незнакомой области человек не знает, чего именно не знает, а гибкий и покладистый характер LLM создаёт ощущение, что знаешь больше, чем на самом деле; сложно даже сформулировать правильные вопросы, которые направили бы модель к качественному ответу. Автор сравнивает это с компасом, который всегда указывает на север, в какую бы сторону вы сами ни решили, что находится север. В том же исследовании даже один из наиболее подготовленных участников, с изначально хорошими навыками планирования, на середине задачи вдруг «пропустил важные этапы планирования, сразу перейдя к написанию кода», не устояв перед Copilot, который быстро подталкивал к готовому результату, и в итоге был вынужден просить ту же модель исправить ошибку, которую она сама и внесла.

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

В крупном исследовании Пенсильванского университета (UPenn) 2025 года «Generative AI without guardrails can harm learning» («Генеративный ИИ без ограничителей может вредить обучению») отслеживали 1000 студентов, изучавших математику с помощью LLM. Группа, использовавшая ИИ как «костыль», в итоге показала результат на 17% хуже, чем группа, занимавшаяся только по учебнику. Как и в исследовании про новичков-программистов, участники этой группы при этом были уверены, что справляются отлично.

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

К похожему выводу приходит и исследование Anthropic 2026 года «How AI assistance impacts the formation of coding skills» («Как помощь ИИ влияет на формирование навыков кодинга»), которое автор эссе цитирует напрямую: «Для начинающих сотрудников в разработке ПО или любой другой отрасли наше исследование можно рассматривать как ещё одно небольшое свидетельство в пользу осознанного развития навыков при использовании ИИ-инструментов. Когнитивное усилие, и даже болезненное ощущение "застревания", судя по всему, важно для формирования мастерства».

В разделе «Pipeline Collapse» («Коллапс кадрового конвейера») автор ставит вопрос ребром: если LLM способны писать и отлаживать код, а агентные рабочие процессы проектировать целые системы, опираясь на массив паттернов из обучающих данных, то зачем вообще нужна человеческая экспертиза в этой области? Ставка на триллионы долларов, по его формулировке, делается на то, что эти знания перестанут быть важны, потому что LLM возьмут на себя работу и фактически станут новым поколением «разработчиков». Автору в этом слышится тот же привкус самоуверенности, что двигал прежними движениями за отказ от кода (no-code) и амбициозными обещаниями руководителей компаний, оторванными от реальной практики. Кодинг, настаивает автор, уникальное пересечение логики, математики, решения проблем, критического мышления, планирования, коммуникации и творчества; LLM способны находить закономерности в масштабе, недоступном ни одному человеку, но одни закономерности решают не всё.

Сооснователь платформы мониторинга ошибок и производительности Sentry Дэвид Крамер в цитируемом эссе интервью говорит: «Мне кажется, есть тип людей, которые искренне верят, что LLM станет достаточно хорош, чтобы потом вернуться и всё это подчистить, разгрести весь мусор, который по пути накопился. Я в это не верю. По-моему, это научный эксперимент». В том же интервью он жёстко проводит грань: одни хотят похвастаться тем, что сумели сгенерировать весь код и запустить сотни процессов параллельно, а он готов в ответ показать, насколько такой код ломается, по его собственным словам, в ста процентах случаев. Автор завершает раздел вопросом без однозначного ответа: рухнет кадровый конвейер или просто изменится, зависит от того, получится ли сдвинуться к более педагогическому использованию этих систем. Пока индустрия продолжает продвигать ИИ-практики, где генерация кода стоит выше глубокого понимания, она, по его словам, не взращивает следующее поколение экспертов, которым предстоит унаследовать код, создаваемый сегодня.

В финале, в разделе «My Approach: Friction First» («Мой подход: сначала трение»), автор опирается на эссе Джоэла Спольски 2002 года «Закон дырявых абстракций» (The Law of Leaky Abstractions): «Инструменты генерации кода, которые претендуют на то, чтобы абстрагировать что-то, как и любые абстракции, протекают. И единственный способ грамотно справляться с этими протечками, разобраться, как эти абстракции устроены... абстракции экономят время на работе, но не экономят время на обучении». Практический вывод автора: если разработчик хочет выучить Java, ему, вероятно, не стоит начинать со Spring Boot. На рекомендации для тех, кто хочет освоить основы JavaScript, доступный текст эссе обрывается на полуслове: дальнейшая конкретная рекомендация автора в материале, по которому готовился этот пересказ, отсутствует.

Ключевые факты

• Тезис эссе: постоянное использование ИИ-ассистентов для кода мешает начинающим разработчикам сформировать реальную экспертизу, потому что убирает «трение», сложности и ошибки, через которые формируется профессиональное чутьё.
• Исследование, на которое сослалась JetBrains («The Widening Gap»): участники, активнее всего применявшие ИИ, пропускали этапы планирования и заканчивали работу с «иллюзией компетентности»; те, кто ограничивал использование ИИ, развили «негативную экспертизу», умение игнорировать неверные подсказки модели.
• Исследование Пенсильванского университета (2025, 1000 студентов изучали математику с LLM): группа, использовавшая ИИ как «костыль», показала результат на 17% хуже группы с одним учебником; группа с ИИ-репетитором показала на 127% лучший результат именно в тренировочной сессии, но на итоговом тесте набрала примерно столько же баллов, сколько группа с учебником.
• Исследование Anthropic (2026) о формировании навыков кодинга приходит к похожему выводу: когнитивное усилие и болезненное «застревание» на проблеме важны для формирования мастерства.
• Сооснователь Sentry Дэвид Крамер не верит, что LLM сами «подчистят» за разработчиками накопленный код; называет массовую генерацию кода «научным экспериментом» и говорит, что такой код ломается «в 100% случаев».

Почему это важно

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

Кому это важно

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

Как это применить

Собственный рецепт автора эссе, подход «Friction First» («сначала трение»): не начинать изучение языка или фреймворка со сложных абстракций (например, не браться за Java сразу со Spring Boot), а сперва разобраться, как всё устроено на нижнем уровне. Практически это означает: использовать ИИ-инструмент как «сократического собеседника», у которого сначала просишь объяснение и подсказку, а решение задачи потом пишешь сам, именно так была устроена «репетиторская» версия эксперимента UPenn, показавшая лучший результат в тренировочной сессии. Не пропускать этап планирования в угоду скорости, сознательно проверять и подвергать сомнению любой предложенный моделью код, а не принимать его как есть.

Можно ли доверять

Это авторское эссе-синтез, а не рецензируемая научная работа; сам автор в тексте не подписан, атрибутировать материал конкретному человеку по доступному тексту нельзя. Опирается эссе на три источника разного веса: подробно разобранное исследование новичков-программистов, на которое сослалась JetBrains (его авторы и институция в тексте эссе не названы); крупное исследование UPenn 2025 года, которое, впрочем, про обучение математике, а не коду, и используется как аналогия; и собственное исследование Anthropic 2026 года про формирование навыков именно в кодинге, вывод которого в первоисточнике сформулирован осторожно, «можно рассматривать как небольшое свидетельство». Реплика Дэвида Крамера про код, который ломается «в 100% случаев», это эмоциональное высказывание в интервью, а не измеренная статистика. Доступный текст эссе обрывается на середине последнего раздела, до итогового вывода.

Риски и подводные камни

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

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

— Дэвид Крамер, сооснователь Sentry