Запретить нельзя использовать: как обучать инженеров в эпоху нейросетей

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

• базовое понимание того, как работают LLM и где они ошибаются,
• навык формулировать четкие запросы,
• умение распознавать ошибки в коде и исправлять их,
• опыт, позволяющий отличать хорошее решение от плохого.

Эти навыки не возникают сами по себе — они формируются через опыт и практику.

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

Да, нейросеть всегда под рукой. Но она не знает контекста, не учитывает требования конкретного проекта, может предложить неэффективное или просто некорректное решение. Она не объяснит, почему код работает именно так, особенно если в нем есть ошибка. И если вы не понимаете, как устроено решение, то не сможете ни предложить улучшения, ни адаптировать его под задачу, ни поддерживать в будущем. Вы будете просто оператором нейросети, неспособным к реальной инженерной работе.

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

На одной из своих лекций по предмету «Наука о данных и аналитика больших объемов информации» я спросил у 30 магистрантов первого курса, используют ли они LLM-модели в учебе или работе. Руку поднял только один студент. Тогда я уточнил: «Не стесняйтесь, отвечайте честно. Кто действительно использует?» — и сам поднял руку. Вслед за мной руки подняли 29 человек из 30.

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

На младших курсах, где дается фундаментальное образование, стоит избегать использования LLM-моделей. Особенно при выполнении лабораторных работ по таким дисциплинам, как, например, «Алгоритмы и структуры данных», «Введение в язык программирования Go» или «Технологии промышленной разработки веб-приложений». Здесь студенты могут получить фундаментальные знания, прочувствовать всю сложность создания программ с нуля, набить руку.

Но реальность такова, что самостоятельно выполняют работы лишь единицы. Большинство студентов либо списывают готовые решения (в вузах часто существуют «серые» хранилища лабораторных работ, собранные за годы обучения предыдущими поколениями студентов и переходящие по наследству), либо используют LLM-модели для генерации кода. При этом, на мой взгляд, использование LLM-моделей для генерации кода предпочтительнее прямого списывания. Так студент хотя бы знакомится с новой технологией, а при списывании он не получает даже этого опыта. Но в случае с LLM студент хоть и приносит работающий код, но не может объяснить его работу.

Помимо подготовки лабораторных работ и сдачи экзаменов, студенты также используют LLM-модели при написании отчетов, научных статей, выпускных квалификационных работ. В целом, что тут плохого? LLM-модель выступает своего рода улучшенной версией поисковой системы или профессиональным редактором, который всегда под рукой. Все это в теории должно повысить качество итоговой работы.

Но на практике получается иначе:

• Студент не получает базовых навыков поиска информации по наукоемким базам данных, таким как, например, DBLP. А ведь поиск по разным источникам — ключевой навык любого инженера.
• Нередко, используя сгенерированный текст, студент вставляет его в отчет без изменений и добавления собственных аналитических рассуждений. В итоге мы получаем работу низкого качества.
• Иногда студенты полностью полагаться на LLM-модели в проверке орфографии и пунктуации, и это играет с ними злую шутку. Ни ChatGPT, ни DeepSeek не застрахованы от ошибок, поэтому за ними нужно обязательно перепроверять.

Сегодня существует множество инструментов, способных определить, был ли текст создан нейросетью — например, Scribbr, QuillBot, Grammarly. Однако все они работают только с обычным текстом, а не с программным кодом.

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

Чтобы повлиять на этот перекос, можно применить подход «горизонтального масштабирования».

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

Вместо концентрированной практики в одном семестре ее можно распределить на год: это даст возможность официально вовлечь студентов старших курсов в проверку и наставничество.

Такой подход мы уже применяем в Политехе — на курсах «Алгоритмы и структуры данных», «Технологии программирования», «Введение в Go» и скоро внедрим в «Технологиях промышленной веб-разработки».

Преимущества такого подхода:

• Преподаватель становится координатором, а не единственным проверяющим.
• Старшекурсники лучше усваивают материал, участвуя в обучении других, и растут.
• Младшие студенты получают больше знаний и навыков от студентов старших курсов, многие из которых уже работают в коммерческой разработке.
• Проверка становится строже: кто недавно сам «обманывал систему», отлично знает, где искать слабые места. Молодой преподаватель — самый строгий.
• А для кого-то из старших студентов это может стать шагом в академическом направлении: науке или преподавании.

Есть и ограничения:

• Такой подход не подходит для курсовых и ВКР — здесь нужен опытный преподаватель.
• Возможны конфликты интересов: если проверяющий и проверяемый дружат или живут рядом, это может повлиять на объективность. Решение — анонимная проверка.

Еще один вариант проверки заданий студентов состоит из четырех шагов:

1. Автоматическая проверка решения. Студент загружает работу в GitLab, где система автоматически проверяет соответствие техническим требованиям, запускает тесты и анализирует код. Если что-то не проходит — можно исправить и попробовать снова.
2. Код-ревью. После успешного тестирования преподаватель (или одногруппники, или старшекурсники) комментирует код — как при командной разработке. Работа считается принятой только после устранения всех замечаний.
3. Устная защита. Студент объясняет преподавателю свое решение и отвечает на теоретические вопросы.
4. В финале студент вносит небольшие изменения в код при преподавателе — по новому или измененному условию.

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

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

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

• На младших курсах основной акцент — на базовые знания и фундаментальные навыки.
• Пересмотреть учебные задачи так, чтобы их нельзя было решить «в лоб» с использованием LLM-моделей. Возможно, за счет повышения сложности заданий или их творческой постановки.
• Разрешить и поощрять использование LLM-моделей только на старших курсах, проводить анализ, осмысление результатов применения.

Современные инструменты позволяют выстроить новую, более прозрачную и эффективную систему проверки лабораторных и практических заданий. Я бы предложил следующий подход:

• Автоматическая проверка через GitLab и CI. Студент загружает работу в систему, запускаются автотесты и статический анализ. Только после прохождения всех проверок он допускается к следующему этапу.
  
• Устное собеседование. Важно убедиться, что студент понимает свой код. Для этого можно провести устное собеседование: как устроено решение, почему так, какие есть альтернативы.
  
• Лайвкодинг. Предложить студенту на месте написать кусочек кода, улучшив существующее решение.
  
• Можно записывать, как студент работает с кодом в редакторе — чтобы увидеть, писал ли он сам или просто вставлял готовые куски. Для этого подойдет специальное расширение. Такой плагин, кстати, сам по себе отличная тема для ВКР.

• При подготовке курсовых объясняем студенту, что LLM это полезный инструмент, который не заменяет самостоятельную работу. Студент должен уметь эффективно объединять различные маленькие кусочки когенерации в единое целое, отразить в работе свой опыт и знания.
• ВКР. Рекомендуем писать черновик текста вручную, а генерацию — использовать осознанно. Если студент применяет LLM-модель, стоит попросить его добавить раздел с описанием того, как он ее использовал: какие запросы задавал, какие ограничения заметил. Это позволяет сделать применение LLM осознанным, а преподавателю даст обратную связь о трудностях, ограничениях и тонкостях применения новых технологий.

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

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

В завершение признаюсь, что при написании этой статьи я использовал DeepSeek. Эта LLM помогла мне расширить изначальный черновик статьи, добавить туда необходимых теоретических деталей и логичные переходы. Безусловно, я не бездумно использовал результаты вывода моделей, а проводил их редактуру. Благодаря этому я сэкономил себе около 7 часов на подготовке этой статьи.

Я поделился этим, чтобы показать: вместо запретов важно научиться использовать возможности новых технологий осознанно. Так мы сможем сохранить качество подготовки и научить студентов работать с нейросетями вдумчиво и ответственно.

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