Необходимость постоянного трения для формирования долгосрочных навыков.
"Мы видим будущее, в котором интеллект станет такой же коммунальной услугой, как электричество или вода, и люди будут покупать его у нас по счётчику и использовать для чего угодно" — Сэм Альтман, OpenAI
В предыдущей статье, Agentic Coding is a Trap, разбирался "парадокс опытного оркестратора": навыки, необходимые для управления ИИ-агентами при программировании, — это те же самые навыки, которые могут атрофироваться из-за постоянного использования этих агентов. Экспертиза во многом была тем самым отличающим фактором: чем опытнее разработчик, тем менее вероятно, что он столкнётся с деградацией навыков, поскольку знания успели закостенеть за годы практики.
Если оглядеться вокруг прямо сейчас, окажется, что подавляющее большинство тех, кто получает максимальную пользу от этих моделей, — это люди с годами, если не десятилетиями опыта в отрасли (естественно, накопленного ещё до появления ИИ-инструментов). И любой ветеран отрасли скажет то же самое: фундамент этих знаний закладывается непосредственно практикой.
Разработчики, пришедшие в профессию примерно во времена LLM, оказываются в положении, когда у них нет преимущества многолетнего стажа, но при этом их подталкивают (а иногда и обязывают) ускорять работу с помощью ИИ-ассистентов, для эффективного и ответственного использования которых как раз и требуется многолетний опыт.
Это неудобное положение для данной группы: возникает ситуация, когда новичку нужны навыки уровня эксперта, чтобы задействовать инструменты и не отставать от отрасли.
"Эксперт-новичок"
Отрасль сейчас посылает очень противоречивые сигналы. С одной стороны, всем внушают: если не использовать ИИ-инструменты, коллеги, которые их используют, "оставят вас позади". Фраза "ИИ не заменит вас, вас заменит тот, кто использует ИИ" повторяется по кругу с 2023 года.
С другой стороны, тут же говорят, что для получения наилучших результатов от этих моделей нужно подключать мышление более высокого порядка: "вайб-кодинг" — тупиковый путь, нужно "подниматься выше по стеку", создавать надёжные спецификации, проектировать архитектуру с хорошими паттернами и всегда тщательно проверять результат, чтобы никогда не отправлять в продакшн то, чего не понимаешь.
Но навыки для этого — функция человека, который годами испытывал трудности и трения, в итоге сформировавшие "хороший вкус".
Отсюда возникает ещё один парадокс ситуации: если эти инструменты требуют экспертизы, но при этом сами инструменты способны активно устранять то самое трение, которое формирует экспертизу, то каким путём человеку вообще стать экспертом, чтобы эффективно ими пользоваться?
Уверенность без понимания
Есть надежда, что эти модели в итоге ускорят обучение, поскольку используются для генерации кода. Джуниоры смогут работать с той же уверенностью и весомостью, что и ветераны отрасли, имея своего "личного ИИ-наставника". Знание синтаксиса становится всё менее важным, а любые пробелы в знаниях или неопределённость закрывает ИИ-инструмент. Более глубокая механика кода остаётся абстрагированной, поскольку разработчик находится выше в стеке.
JetBrains, крупный игрок на рынке инструментов разработки, недавно завершила исследование начинающих и junior-разработчиков, скрупулёзно анализируя их поведение в живых сессиях программирования и проверяя способность обучаться кодингу с ИИ-инструментами при разной степени вовлечённости последних. Главный вывод получился неожиданным и противоречащим интуиции:
"Участники думали, что это как персональный наставник. Но данные исследования... показали, что на самом деле они не использовали GenAI-инструменты как персонального наставника. На деле всё было с точностью до наоборот."
Участники, сильнее полагавшиеся на помощь ИИ:
- "Часто пропускали критически важные этапы планирования, поскольку сами не рассуждали над решением — за них это делал Copilot."
- "Заканчивали работу с 'иллюзией компетентности', а не с реальным пониманием."
В противовес им, участники, ограничивавшие использование ИИ:
- "Добивались успеха благодаря выработанной 'отрицательной экспертизе' — то есть 'способности игнорировать неверные или бесполезные подсказки GenAI' — что позволяло сосредоточиться на написании собственных решений, не сбиваясь с пути."
- "Могли использовать GenAI для ускорения, создавая код, который и так собирались написать."
Начинающие разработчики, наиболее неограниченно и уверенно использовавшие ИИ, "пропускали критически важные шаги в процессе решения задачи и в итоге оказывались потерянными."
Возможно, неудивительно, но лучше всех показали себя те новички, кто значительно ограничивал или полностью игнорировал помощь ИИ при написании кода.
Перевёрнутое обучение
Из-за самонаправленной природы LLM чем больше у человека опыта, тем больше пользы приносят такие модели, поскольку он может точно направлять, проверять и верифицировать результат. Чем меньше знаний, тем сильнее модель может ввести в заблуждение. Взаимодействие с LLM ради освоения новых навыков принимает форму "перевёрнутого обучения" — смены ролей, при которой ученик изначально направляет наставника, наставник отвечает, а затем ученик снова корректирует наставника.
Этот процесс шаткий: LLM крайне чувствительны к формулировке запроса. Осваивая новую область, человек не знает, чего он не знает, а гибкий и услужливый дизайн LLM может создать впечатление, будто знаний у вас больше, чем на самом деле.
Если территория хотя бы отчасти незнакома, часто даже не знаешь, какие вопросы нужно задать, чтобы направить модель к наилучшим ответам. Это начинает напоминать компас, который всегда указывает на север — туда, куда вы сами предположили, что север может находиться.
Из того же исследования JetBrains: даже наиболее подготовленных студентов сбивала с толку помощь ИИ именно из-за такой модели обучения. Один из участников продемонстрировал хорошее базовое планирование и привычки, но внезапно "пропустил критически важные этапы планирования решения задачи, сразу перейдя к написанию кода, соблазнившись быстрой генерацией кода от Copilot", и в итоге был вынужден полагаться на ту же LLM, чтобы исправить ошибку, которую она сама и внесла.
ИИ-моделям недостаёт рассудительности, эмпатии и педагогического намерения, а предлагаемые решения опираются не на опыт, а на паттерны в обучающих данных (по своей сути LLM — это невероятно сложные интерполяторы паттернов).
Машина бесконечных ответов соблазнительна и, как известно, способна вызывать зависимость. Ситуация может довольно быстро выйти из-под контроля, особенно у неопытных разработчиков. Стоит глубоко погрузиться в сгенерированное решение, и человек часто оказывается вынужден полагаться на ИИ-инструмент и в его завершении, минуя то самое трение при решении задачи, которое необходимо для формирования ментальной модели (справедливости ради, этому явлению подвержены и опытные разработчики).
Трение — это функция, а не баг
Экспертиза и мастерство не формируются исключительно через наблюдение и диалог — они возникают через опыт, повторение и метод проб и ошибок; нужно потерпеть неудачу, чтобы добиться успеха. Если бы кто-то захотел научиться готовить, он мог бы наблюдать за работой шеф-повара и бесконечно расспрашивать его. Через месяц он смог бы в деталях описать идеально прожаренный medium-rare стейк рибай, но так и не узнал бы, каково это — приготовить его самому, и почти наверняка пережарил бы его при первой же попытке.
В программировании бесконечно много моментов, когда приходится отслеживать труднообъяснимые ошибки без единого лога, замечать тонкую разницу в производительности между разными методами или переписывать подход, когда становится очевидно, что он не масштабируется.
Именно это прикладное трение формирует "интуицию разработчика" (или "вкус"). У немцев есть отличное слово для этого: Fingerspitzengefühl (чувство кончиков пальцев). Это мышечная память, которая срабатывает, когда разработчик смотрит на что-то и думает: "да... это, скорее всего, приведёт к проблемам." Избегая механики борьбы, эту интуицию просто невозможно сформировать.
В масштабном исследовании Пенсильванского университета 2025 года Generative AI without guardrails can harm learning проследили за 1000 студентами, изучавшими математику с помощью LLM, и обнаружили, что студенты использовали ИИ как костыль и в итоге показали результат на 17% хуже, чем студенты, работавшие просто с учебником (и точно так же, как в исследовании JetBrains, студенты, использовавшие ИИ, считали, что преуспевают).
Впрочем, LLM необязательно должны только генерировать код.
Если использовать их как сократических партнёров по спаррингу, а не как генераторы ответов, исследования показывают, что "диалоговые ИИ-системы способны существенно стимулировать рефлексивное, критическое и самостоятельное мышление".
В том же исследовании Пенсильванского университета тестировали версию "Наставник": студенты просили помощь, а затем самостоятельно решали задачу. Группа с GPT-наставником показала поразительный результат — на 127% лучше в тренировочной сессии с ИИ (хотя, что интересно, на самом тесте набрала примерно столько же баллов, сколько и группа с учебником).
Это работает потому, что модель больше не используется как средство производства, и когнитивная работа снова ложится на самого человека. Именно когда трение сохраняется, оно оставляет устойчивый отпечаток, ведущий к экспертизе.
Исследование Anthropic 2026 года "How AI assistance impacts the formation of coding skills" пришло к схожим выводам:
Для начинающих специалистов в разработке ПО или любой другой отрасли наше исследование можно рассматривать как небольшое доказательство ценности осознанного развития навыков с ИИ-инструментами. Когнитивные усилия — и даже болезненное застревание на проблеме — вероятно, важны для формирования мастерства.
В этом есть определённая ирония: самое продуктивное обучение с помощью ИИ-инструмента для программирования происходит тогда, когда он вообще почти не используется для генерации кода.
Коллапс кадрового резерва
Если LLM способны писать код и отлаживать его, а агентные workflow могут выполнять проектирование систем на основе обилия паттернов в обучающих данных, то в чём тогда смысл этих знаний вообще? Программирование будет вестись целиком на естественном языке, и можно будет отказаться от необходимости работать непосредственно с кодом, поскольку модели продолжают совершенствоваться и закрывают любые пробелы в знаниях или неоднозначности. Они будут отлаживать любые возникающие проблемы и справляться с любой сложностью, которую сами же вносят.
Ставка на триллион долларов делается на то, что эти знания перестанут иметь значение, потому что LLM возьмут всю нагрузку на себя и по сути станут новым поколением "разработчиков". От этого веет тем же высокомерием, что двигало прежними no-code-движениями и лихорадочными фантазиями CEO, а не реальным положением дел на местах.
Программирование/разработка ПО — уникальное пересечение логики, математики, решения задач, критического мышления, планирования, коммуникации и творчества. LLM способны обнаруживать паттерны в масштабе, недоступном ни одному человеку, но паттерны дают ограниченный эффект.
Дэвид Крамер, сооснователь Sentry (платформы для отслеживания производительности и ошибок), сформулировал это лаконично в недавнем интервью:
Мне кажется, есть тип людей... которые искренне верят, что LLM станут достаточно хороши, чтобы потом вернуться и всё это исправить, привести в порядок весь хлам, накопившийся по пути. Я не думаю, что это так. По-моему, это научный эксперимент.
Хочешь похвастаться, что можешь сгенерировать весь свой код и запустить сотни процессов параллельно, — я в ответ покажу тебе, насколько сломан этот код в ста процентах случаев.
Кадровый резерв рухнет — или просто изменится?
Это действительно зависит от того, произойдёт ли необходимый сдвиг к более педагогическому использованию этих систем.
Продолжая фокусироваться на ИИ-подходах к программированию, которые ставят генерацию кода выше глубокого понимания, отрасль не взращивает следующее поколение экспертов, которым предстоит унаследовать код, создаваемый сегодня.
Подход: трение прежде всего
Джоэл Спольски прозорливо писал (причём ещё в 2002 году) в своём "Законе дырявых абстракций":
Инструменты генерации кода, притворяющиеся, что абстрагируют что-либо, как и все абстракции, протекают. И единственный способ грамотно справляться с этими протечками — изучить, как работают сами абстракции... абстракции экономят время работы, но не экономят время обучения.
Если разработчик хочет выучить Java, ему, вероятно, не стоит начинать со Spring Boot. Если хочет освоить основы JavaScript — не стоит начинать с React. Если хочет по-настоящему хорошо разбираться в CSS — не стоит начинать с Tailwind. LLM вполне можно считать предельной дырявой абстракцией.
Совет здесь очень похож на тот, что был дан ранее.
Если разработчик хочет стать экспертом в программировании, ему стоит по большей части игнорировать возможности этих моделей по чистой генерации кода и вместо этого использовать их для интерактивной документации, динамических генераторов туториалов и сократических упражнений.
Разумеется, это не панацея: использование ИИ-инструмента в роли наставника несёт собственные риски, поскольку он подвержен тем же галлюцинациям, что и в любом другом взаимодействии, и на него нельзя полагаться исключительно как на источник знаний. Если невозможно должным образом проверить точность сгенерированного кода, то невозможно проверить и точность сгенерированной концепции. Используя ИИ как наставника, обязательно нужно сверять его выводы с официальной документацией, коллегами-людьми и реальной практикой методом проб и ошибок.
"Программирование на самом деле отличный способ закрепить понимание. Чем больше пишешь код, тем лучше понимаешь предметную область, в которой работаешь."
— Кент Бек, создатель разработки через тестирование (TDD)
Выбор этого более медленного и осознанного пути — лучший способ нарастить экспертизу, но нельзя не признать, насколько это тяжело, когда вся окружающая экосистема активно этому противодействует. ИИ (зачастую бездумно) насаждается в компаниях повсеместно и встраивается в большинство инструментов и IDE для разработки, которые в основном ориентируются на senior-инженеров (некоторые инструменты, например Cursor, вообще прячут просмотр кода, если пользователь сам его специально не запросит). Некоторые компании даже принуждают разработчиков использовать ИИ исключительно для всех задач по написанию кода, независимо от уровня опыта, — и таким компаниям ещё предстоит извлечь собственные уроки на своём опыте.
Однако для всех остальных, кто стремится найти баланс между глубоким обучением и продуктивностью, есть набор проверочных вопросов, которые помогут убедиться, что использование этих инструментов принесёт долгосрочную пользу.
Чек-лист по использованию ИИ-помощи:
- Смог бы я выполнить эту задачу, не имея доступа к ИИ-инструменту?
- Использую ли я модель, чтобы углубить понимание, или чтобы быстрее получить ответ?
- Если бы мне пришлось проверить и верифицировать сгенерированный результат, смог бы я адекватно объяснить, что там происходит?
- Если я изучаю новую концепцию, провёл ли я достаточное исследование, чтобы знать, какие вопросы правильно задавать?
- Сверил ли я и проверил ли подход другими способами (чтение документации, обычный поиск, StackOverflow, Reddit)?
- Это по-настоящему рутинная задача, которая уже решалась сотни раз, или где-то в процессе требуется принятие управленческого решения?
Даже разработчик с десятилетиями опыта за плечами постоянно обращается к таким вопросам в повседневной работе, особенно при попытке освоить что-то новое (а в этой отрасли это происходит бесконечно).
Ключевое — распознавать разницу между когнитивным долгом и когнитивной разгрузкой: когнитивный долг — это отказ от собственных суждений и решений, тогда как когнитивная разгрузка — это делегирование механической или рутинной работы.
Как упоминалось в исследовании Anthropic, "болезненное застревание" на проблеме — это хорошо. Требуются дисциплина и усилия, чтобы не скатиться обратно к простому получению готовых ответов, которые к тому же могут оказаться неточными изначально. LLM не переписали внезапно фундаментальные принципы того, как люди учатся, но дали новый способ это делать.
Интеллект — не биржевой товар
Хочется надеяться, что со временем произойдёт переосмысление: понимание того, что навыки не развиваются без активного участия. Нужно вовлекаться напрямую и непрерывно, чтобы испытать то необходимое трение, которое в итоге приводит к экспертизе (даже если это означает двигаться медленнее).
Если внимание так и останется приковано к количеству строк кода и сожжённых токенов, пока кадровый резерв экспертизы годами будет иссякать, видение Сэма Альтмана о продаже интеллекта по счётчику вполне может стать реальностью. Знание предметной области может стать большим дефицитом, и, садясь за любую задачу по разработке, человек будет испытывать приступ паралича, если рядом не окажется активной подписки на ИИ-инструмент.
LLM — это статическая база данных навыков. Это интерполяционные движки. Разработка ПО же — это упражнение в адаптации и решении новых, нестандартных задач. Невозможно проинтерполировать себе путь через совершенно уникальный сбой системы.
— Франсуа Шолле, создатель бенчмарка ARC-AGI