Кризис vibe coding: почему выпускники CS больше не умеют программировать без ИИ

В марте 2026 года в треде Reddit, быстро собравшем 8 000 апвоутов, старший инженер стартапа серии B опубликовал скриншоты домашнего собеседования, которое он только что отклонил. Кандидат — недавний выпускник CS с GPA 3.9 из уважаемой программы — сдал код, который идеально работал на счастливом пути и безмолвно портил данные в каждом граничном случае. Когда его попросили пройти по логике на последующем звонке, кандидат не смог объяснить, почему одна из его собственных функций использовала рекурсию. Строкой, взорвавшей тред, был его честный ответ: «Я просто сказал Claude, что нам нужно, и он написал это. Обычно я читаю код, только если он не работает».

Это кризис vibe coding, и к 2026 году он перешёл из Twitter разработчиков в HR-конвейеры, дебрифы по найму и всё чаще в кабинеты заведующих кафедрами CS, пытающихся понять, что только что произошло с их выпускниками. Термин был введён Андреем Карпатым в феврале 2025 года для описания нового позитивного способа работы: опиши намерение, прими то, что произвела модель, отправь. В течение года та же фраза стала отраслевой сокращением для поколения программистов, которые могут бегло писать промпты, но не могут рассуждать о том, что их код на самом деле делает.

Для преподавателей программирования это не гипотетическая проблема о будущем работы. Это сегодняшняя педагогическая чрезвычайная ситуация о студентах, которых вы выпускаете прямо сейчас. Эта статья смотрит на то, что исследования и полевые отчёты реально показывают об индуцированной ИИ атрофии навыков, почему CS1 — выпускной проект уникально уязвим, и как небольшая, но растущая группа преподавателей перестраивает курсы, чтобы выпускники могли программировать — а не только давать промпты.

Что такое vibe coding на самом деле (и почему Карпатый сказал, что это должно быть весело)

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

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

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

Педагогическая проблема — вторая группа, и они составляют большинство студентов, поступающих в программы CS в 2026 году. Сам Карпатый отступил от своей рамки позже в 2025 году, отметив, что vibe coding имеет смысл для экспертов на личных проектах и разрушителен для всех остальных.

Паттерн атрофии навыков в реальных числах

Доказательная база теперь существенна, и она указывает в одном направлении. Анализ CodeRabbit в декабре 2025 года, рассматривавший pull request'ы по сотням open-source репозиториев, обнаружил, что код, написанный совместно с генеративным ИИ, содержал примерно в 1,7 раза больше «серьёзных» проблем, чем код, написанный людьми. Логические ошибки (некорректные зависимости, ошибочный поток управления) и уязвимости безопасности были оба значительно повышены, а дефекты безопасности появлялись с частотой в 2,74 раза выше, чем в чисто человеческом коде.

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

Самая ясная иллюстрация пришла от разработчика, проведшего 30-дневный эксперимент в начале 2026 года: никакой ИИ-помощи в течение месяца, затем рефлексия о разнице. Эссе на dev.to «I Coded Without AI for 30 Days: The Results Were Embarrassing» стало одним из самых обсуждаемых эссе разработчиков в году. Основной вывод: работающий старший инженер с восьмью годами опыта больше не мог написать простой обход двоичного дерева по памяти. Навык был аутсорсен и затем тихо разрушен.

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

Почему программное образование уникально уязвимо

Другие области справляются с ИИ в образовании несовершенно, но у большинства всё ещё есть нетронутые рамки оценивания. Студента литературы по-прежнему можно попросить обсудить отрывок на семинаре. Студента химии — выполнить лабораторную процедуру. Студента математики — вывести доказательство у доски. У программного образования нет ни одного из этих нетронутых режимов оценивания. Почти каждое задание по программированию — домашнее, оцениваемое тем, проходит ли код тесты — а ИИ 2026 года тривиально проходит эти тесты.

Это создаёт три уязвимости, специфичные для программирования:

• Цикл задание-тест полностью автоматизируем. Codex, Claude Code и Cursor читают задание, пишут код, прогоняют набор тестов, итерируют по падениям и сдают работающее решение. Полный цикл, который должен пройти студент — понять требования, спроектировать решение, реализовать, отладить — может быть выполнен ИИ быстрее, чем студент прочтёт спецификацию.
• Живое оценивание логистически дорого. Курс CS1 на 200 студентов не может реально провести пятиминутную устную защиту каждого задания, не сжигая двадцать часов работы ассистентов за каждый цикл. Экономическая модель больших курсов CS предполагает асинхронное оценивание домашних работ.
• Списывание невидимо для студента. Студент, копирующий эссе, знает, что он списал. Студент, генерирующий ИИ для решения задания, может не воспринимать это как списывание — социальная норма сдвинулась быстрее, чем политика, и акт ощущается неотличимым от поиска в интернете. К моменту выпускного года, когда им нужно думать самостоятельно, они потратили четыре года, не построив релевантного навыка.

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

Как выглядит «не учиться ничему» на консультациях CS

Если вы преподаёте программирование, вы, вероятно, видели этот паттерн, даже если ещё не дали ему имя. Мы собрали самые распространённые диагностические сигналы от преподавателей по CS1, структурам данных и выпускным проектам конца 2025 — начала 2026.

• Студент не может найти собственный баг. Сдача прошла идеально. Новый юнит-тест падает. Студент открывает файл, смотрит на код, как будто видит его впервые, прокручивает вверх и вниз без гипотезы, в итоге говорит: «Спрошу у Claude, что не так». Первая реакция на падающий тест — эскалация к ИИ, а не формирование гипотезы.
• Студент не может ответить «почему». На вопрос «почему ты использовал здесь хеш-таблицу вместо массива» ответ — «так предложил ИИ». Выбор был сделан; стоящее за ним рассуждение никогда не было усвоено. Под кодом нет когнитивной модели.
• Студент не может сделать небольшую вариацию. «Измени, чтобы обрабатывалось и отрицательное число» должно быть тридцатисекундной правкой. Для ИИ-зависимого студента это становится пятиминутной сессией промптинга, потому что им нужно скормить ограничение модели, а не думать, где в существующем коде должно произойти изменение.
• Студент бегл в инструментах, неграмотен в задачах. Они могут настроить Vercel, собрать компонент React, поднять базу Postgres, развернуть через Docker. Могут пользоваться всей современной инструментальной цепочкой. Попросите реализовать quicksort. Тишина.
• Раскрытие на капстоуне. Выпускной проект, момент, когда накопленный навык должен окупиться, всё чаще становится моментом, когда раскрывается накопленное отсутствие навыка. Команды, которые vibe-кодили с CS1 до третьего курса, приходят на капстоун, не способные спроектировать систему, разбить функциональность, обработать те части программирования, которые ИИ делает хуже всего.

Педагогическое решение: трактовать ИИ-беглость как настоящий навык (и сделать её заслуженной)

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

Специфические дизайн-паттерны, работающие в курсах программирования 2026 года:

• 1. Двухтрековое задание. Каждое задание имеет «соло»-часть (без ИИ, часто небольшой класс-компонент) и «инструментальную» часть (ИИ разрешён, но документирован). Соло-часть ловит то, что студент реально может. Инструментальная часть учит его большему.
• 2. ИИ-беглость как оцениваемая компетенция. Студенты сдают использованные ИИ-промпты, полученные ответы и анализ, где ИИ был неправ или неэффективен. Критическое чтение ИИ-вывода трактуется как цель курса, а не обход.
• 3. Оценивание только отладки. Студентам дают работающий ИИ-сгенерированный код с тонкими багами (off-by-one, неправильный базовый случай, отсутствующая null-проверка, уязвимость безопасности) и оценивают по способности найти и исправить. Это тренирует навык, который ИИ выполняет хуже всего и который работодатели больше всего ценят.
• 4. Оценивание с видимым процессом. Обязательная история коммитов, обязательные комментарии, документирующие проектные решения, записанные прохождения кода. Артефакт сам по себе больше не является всей оценкой.
• 5. Живые технические разговоры. Короткий, структурированный устный компонент на каждом значимом задании. Пять минут на студента, фокус на одном-двух диагностических вопросах. Трение реально; сигнал отличный.
• 6. Проверка подлинности на системном уровне. Инструменты вроде Plagly.ai сканируют работы на ИИ-генерационные паттерны, стилевое единообразие на уровне когорты и отсутствие итеративных следов авторства, обычно проявляющихся в реальной студенческой работе. Это не оценка; это флаг, выводящий на поверхность работы, заслуживающие разговора на консультации.

Слой инструментов, делающий это практичным

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

Как это выглядит на практике для секции CS1 на 200 студентов:

• Авто-сканирование работ: Каждый загруженный файл проходит через сканирование обнаружения ИИ, возвращающее оценку уверенности и флаги по блокам. Plagly.ai выполняет этот анализ с точностью 99% для GPT-5.5, Claude 4.6, Gemini 3.1 и других крупных моделей, включая конкретные варианты кода, предпочитаемые этими моделями.
• Когортный дашборд: Преподаватель видит кластеризацию стилевых паттернов по секции. Когда восемь работ разделяют идиоматическую формулировку, идентичную плотность комментариев и тот же защитно-крайний паттерн, кластер всплывает для проверки.
• Следы авторства: Agentic Council от Plagly.ai — семь экспертных моделей, анализирующих работу на качество письма, структуру, обнаружение ИИ, оригинальность и согласованность — выдаёт отчёт со ссылками. Отчёт не утверждает академическую нечестность; он документирует паттерны, которые преподаватель может исследовать.
• Целевые разговоры на консультации: Студенты, чьи работы всплыли, получают пятиминутную устную проверку. Большинство быстро очищаются; небольшое число — нет, и они становятся случаями, которые преподаватель обрабатывает вдумчиво и под протокол.

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

Прогноз для программного образования на 18 месяцев

Большинство работающих преподавателей программирования, с которыми мы говорим в 2026, разделяют ощущение, что текущая установка нестабильна. Домашнее задание, оцениваемое прохождением тестов, структурно несовместимо с существованием агентных инструментов кодирования. Что-то должно уступить. Три правдоподобных направления, примерно в возрастающем порядке вероятности:

• Полные запреты ИИ: Некоторые учреждения попробуют, и большинство потерпят неудачу. Запреты невыполнимы, политики становятся противоречивыми, и студенты, следующие правилам, выпускаются менее умелыми, чем студенты, не следующие. Это худший-из-двух-миров результат, который уже дискредитировал себя в нескольких университетах, пробовавших в 2023-2024.
• Сдвиг способностей вниз по программе: CS1 начинается позже, с большим акцентом на концептуальные основы. CS2 покрывает то, что покрывал CS1. Продвинутые курсы становятся более теоретическими, потому что реализационная часть больше не там, где происходит обучение. Это случается, медленно.
• Сдвиг оценивания к живой демонстрации: Домашние задания становятся формирующими. Итоговые оценки определяются живым кодированием под наблюдением, устными защитами и работой с видимым процессом. Это направление, куда уже движутся сильнейшие программы CS, и направление, куда, как мы полагаем, в итоге придёт большинство программ.

Ни один из этих исходов не решает вопрос, что делать в этом семестре со студентами, которые у вас есть. Для этого практический ход — гибрид: сохранить текущие задания, добавить слой проверки, ловящий худшие случаи, добавить один-два очных оценочных компонента на курс и начать более медленную работу по переделке программы под мир, где агентный ИИ — это базовая линия. Инструменты проверки покупают вам время для переделки программы, не теряя эту когорту в vibe coding между делом.

Часто задаваемые вопросы

Vibe coding всегда плох или иногда легитимен?

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

Могут ли студенты утверждать, что они сами написали обнаруженный как ИИ код?

Могут, и иногда они правы. Ложные срабатывания в детекции кода чаще всего встречаются, когда студенты пишут очень «учебниковым» стилем, который случайно совпадает с паттернами, обычно производимыми ИИ. Защитный рабочий процесс не трактует оценку обнаружения как приговор — он трактует её как повод для пятиминутного разговора. Студент, написавший свой код, может объяснить его, модифицировать на месте и проследить выполнение. Студент, который его сгенерировал, почти никогда не может. Разговор, а не оценка, разрешает вопрос. Отчёты Plagly.ai спроектированы для поддержки этого разговора, а не для его замены.

Чем детекция кода отличается от детекции прозы?

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

А как насчёт студентов, которые искренне используют ИИ как наставника, не копируя его вывод?

Детекция кода использует похожие статистические основания — перплексия, бёрстность, стилистические отпечатки — но применяет их к разным поверхностным признакам. В коде самые информативные сигналы скорее структурные, чем лексические: паттерны именования переменных, плотность и стиль комментариев, идиомы использования библиотек, шаблоны обработки ошибок и выбор идиоматических конструкций. Мульти-модельные ансамбли достигают 90-95% точности на отдельных сдачах кода в 2026, поднимаясь значительно выше 95%, когда анализ паттернов на уровне когорты совмещён со скорингом на уровне файлов.

Работает ли это для проектных курсов и капстоунов?

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