Вайб-кодинг как инструмент создания профессиональных мини-приложений на занятиях информатики

Автор: Апушкин Виктор Михайлович

Организация: Сестрорецкий технологический колледж им. С.И. Мосина

Населенный пункт: Санкт-Петербург г. Сестрорецк

С чего началась работа

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

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

В названии статьи использован термин «вайб-кодинг». В этой работе под ним понимается создание прототипа через запросы к генеративной нейросети на обычном языке. У термина есть более узкое толкование, связанное с минимальным вниманием к самому коду; его отличие от других форм программирования с помощью ИИ обсуждает С. Уиллисон [1]. Для занятия я считал обязательным другое условие: студент должен понимать назначение приложения и уметь проверить его ответ, даже если код получен с помощью нейросети.

От одной порции к банкетному меню

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

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

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

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

Как автомобильный калькулятор стал сметой

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

Содержание разделов должно уточняться под конкретный сервис. Например, для замены масла имеет значение агрегат, в котором выполняется работа. Для шиномонтажа — размер колёс, число колёс и состав операций, включая балансировку. Эти уточнения нужны не для усложнения экрана: от них зависит содержание заказа и его стоимость. В студенческих вариантах удалось реализовать разделы услуг и итоговый расчёт. Печатная форма позволяет представить результат как документ для дальнейшего согласования и оплаты.

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

Три урока и работа между занятиями

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

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

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

Третий урок был посвящён показу и обсуждению. Каждый представлял приложение и объяснял его работу. Мы вместе разбирали, что получилось, какие возможности стоит добавить, а какие — упростить. Не каждое предложение обязательно превращалось в доработку: группа обсуждала, нужна ли она пользователю вообще. За выполненную работу выставлялись оценки; учитывались демонстрация результата и объяснение его работы.

Как проверяли расчёты

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

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

Что я считаю главным результатом

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

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

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

Список источников

1. Willison S. Not all AI-assisted programming is vibe coding (but vibe coding rocks). 19.03.2025. URL: https://simonwillison.net/2025/Mar/19/vibe-coding/ (дата обращения: 30.10.2026).

Полный текст статьи см. в приложении.