Автоматическая проверка заданий по программированию: шесть десятилетий исследований

Андрей Несюк · 11 августа 2026 г. · Факты проверены: 12 августа 2026 г.

Этот обзор охватывает около шестидесяти исследований в пяти языковых зонах и приходит к выводу: автоматическая проверка лабораторных работ по программированию давно стала быстрым и надёжным способом проверить код, но за шесть с лишним десятилетий ни одно из рассмотренных здесь исследований не показало, что она учит программировать лучше. Этот вопрос в отрасли задают с 1960 года, когда Communications of the ACM опубликовал двухстраничную заметку Дж. Холлингсуорта (J. Hollingsworth) о проверяющей программе для курса программирования в Политехническом институте Ренсселера, работавшей на машине IBM 650: она компилировала решения студентов, запускала их и выдавала результат. Это первый документированный автоматический проверщик заданий по программированию. Сегодня автопроверка работает в аудиториях на пяти континентах, а исследовательская литература о ней разошлась минимум на пять языковых зон: те самые примерно шестьдесят работ, на которые дальше по тексту даны ссылки. Все они тянут за собой один и тот же вопрос.

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

“After fifteen months, our experience leads us to believe that students learn programming not only as well but probably better than they did under the method we did use—laboratory groups of four or five students.” (Hollingsworth, 1960)

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

Цитата взята из метаданных CrossRef: страницы 1960 года у ACM платные, и со сканом печатного оригинала её не сверяли.

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

Почему спрос никуда не делся

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

Где не выдерживает нагрузка на преподавателя

Обзор 2025 года вводного курса программирования в Индийском технологическом институте Патны сообщает, что курс «coordinated by three faculty members, resulting in a faculty-to-student ratio of 1:172, with additional support from TAs at a ratio of about 1:20» («координировали три преподавателя, из-за чего соотношение преподаватель-студент составило 1:172, с дополнительной поддержкой ассистентов в соотношении около 1:20») (Nareti et al., 2025). Никакая личная самоотверженность вручную такое соотношение не выправит.

Инфраструктура под стать масштабу

Отчёт 2014 года, составленный исследователями из Университета Цинхуа, Пекинского университета и Иллинойсского университета в Урбане-Шампейн, прослеживает историю китайских систем автоматической проверки программ (online judge), и по нему видно, что Китай отстроил под эту задачу инфраструктуру промышленного масштаба: ZOJ Чжэцзянского университета запущена в 2003 году; POJ Пекинского университета, запущенная в 2004-м, «долгое время лидировала в стране» по числу отправленных решений: «более 8 миллионов программ» к 2014 году; HDOJ Ханчжоуского электротехнического университета «первой преодолела отметку в 10 миллионов» отправленных программ в январе 2014 года (Liu, Wang & Xie, 2014; оригинал на китайском: «北京大学的POJ…于2004年建立，程序提交量长期在国内领先，迄今已经提交了800多万个程序，…另外，杭州电子科技大学的HDOJ…程序提交数目于2014年1月率先冲破1000万大关», перевод: «POJ Пекинского университета… основана в 2004 году, по числу отправленных программ долгое время лидировала в стране, на сегодня отправлено более 8 миллионов программ… кроме того, HDOJ Ханчжоуского электротехнического университета… число отправленных программ в январе 2014 года первым преодолело отметку в 10 миллионов»).

Там, где не хватает компьютеров

AutoGrad, созданный для курса программирования SuaCode, его авторы описывают как «the first system built and tested in an African context across over thirty-five countries across the continent» («первую систему, построенную и испытанную в африканском контексте более чем в тридцати пяти странах континента»), развёрнутую для проверки «1000+ students across Africa… with over 3,000 code files graded» («более 1000 студентов по всей Африке… с проверкой более 3000 файлов кода») (Annor et al., 2021). Там, где не хватает даже компьютеров, эта система переехала на телефоны, потому что, как отмечает та же статья, компьютеры «tend to be in schools and not in homes» («как правило, стоят в школах, а не дома») на большей части континента, тогда как владение смартфонами продолжает расти.

Измеримый случай: Япония

В университете Нихон, как только число студентов на курсе перевалило за сотню, один преподаватель уже не успевал проверять работы честно в отведённые аудиторные часы. Масштаб здесь меньше индийского или китайского, но эффект от внедрения виден резче. После внедрения системы автоматической поддержки проверки отчётов для курса программирования на языке Си результат оказался разительным: «this system needs only one instructor, and the time required for grading was reduced to 1/4 of what it was before… previously, one instructor and three teaching assistants were needed for daily emailed reports, but with this system one instructor suffices… manual grading achieved 0.5 reports per minute; with this system, 2 reports per minute» («для этой системы достаточно одного преподавателя, а время на проверку сократилось до 1/4 от прежнего… раньше на ежедневные отчёты по почте требовался один преподаватель и три ассистента, а с этой системой хватает одного преподавателя… при ручной проверке выходило 0,5 отчёта в минуту, с этой системой 2 отчёта в минуту») (Watanabe, 2009; оригинал на японском, первая часть взята из введения статьи, вторая из заключения: «本システムによって教員１名ですみ，評価に要する時間が従来の1/4にすることができた…手作業による採点では0.5通/分に対して，本システムでは２通/分であり»).

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

Что автоматизация надёжно даёт и чем за это платят

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

Теоретический предел

INGInious, платформа автопроверки, созданная в Лувенском католическом университете (UCLouvain) для MOOC по парадигмам программирования, сама формулирует предел, дальше которого автоматика в принципе не шагнёт, в собственном отчёте об опыте использования: «Computer scientists know that automatic correction is not an easy task, because of theoretical limits: it is actually impossible to check whether the student’s code does the same as a correct one (consequence of Rice’s Theorem, see [Beckman, 1980])» («Специалисты по информатике знают, что автоматическая проверка непростая задача: из-за теоретических ограничений фактически невозможно проверить, делает ли код студента то же самое, что и правильное решение (следствие теоремы Райса [Beckman, 1980])») (Derval, Gego, Reinbold, Frantzen & Van Roy, 2015). Автопроверка подменяет исчерпывающую корректность посильным приближением, обычно набором тестов, и это приближение доказуемо неполно.

Насколько велик разрыв на практике

GATE, система, созданная в Техническом университете Клаусталя и Берлинском университете имени Гумбольдта, прошла проверку на реальном вводном курсе программирования 2009 года, и результат показывает, насколько велик на практике разрыв между приближением и истиной. Авторы сообщили: «Of 1031 solutions, functional tests classified 759 solutions (73.6%) as incorrect, but tutors nevertheless rated 201 of these (26.5%) as correct, since only minor errors were present (e.g. typos, incorrectly set package)» («Из 1031 решения функциональные тесты классифицировали 759 решений (73,6%) как некорректные, но преподаватели-тьюторы всё равно оценили 201 из них (26,5%) как правильные, поскольку в них были лишь мелкие ошибки (например, опечатки или неверно указанный пакет)») (Müller & Strickroth, 2013; оригинал на немецком: «Von 1031 Lösungen wurden durch die Funktionstests 759 Lösungen (73,6%) als nicht korrekt klassifiziert aber 201 Lösungen (26,5%) hiervon von den Tutoren trotzdem als korrekt bewertet, da nur kleinere Fehler vorhanden waren»). Больше четверти решений, которые автоматические тесты отклонили, по суждению живого тьютора на деле были в порядке. Эту цифру дали сами разработчики системы, опубликовав её вместе с подлинными и статистически значимыми плюсами на том же курсе: доля синтаксически корректных сдач выросла на 25 процентных пунктов у студентов, пользовавшихся автоматической проверкой синтаксиса. Независимая немецкая система JACK называет сопоставимую цифру в собственном отчёте 2008 года: «Up to 28% of the results needed manual correction by the teacher, in most cases because of false negatives» («До 28% результатов требовали ручной корректировки преподавателем, в большинстве случаев из-за ложноотрицательных срабатываний») (Goedicke, Striewe & Balz, 2008).

Когда критерий начинают обыгрывать

Докторская диссертация Петри Ихантолы 2011 года в университете Аалто прямым экспериментом показала, что критерий проверки поддаётся эксплуатации, как только студенты понимают, за что он вознаграждает: «We have analyzed how students behave when they are rewarded for structural test coverage (e.g. line coverage) and found that this can lead students to write tests with good coverage but with poor ability to detect faulty programs» («Мы проанализировали, как ведут себя студенты, когда их вознаграждают за структурное покрытие тестами (например, построчное покрытие), и обнаружили, что это может приводить к написанию тестов с хорошим покрытием, но слабой способностью выявлять ошибочные программы») (Ihantola, 2011). Оптимизация метрики и рост самого навыка оказались, судя по этим данным, двумя разными занятиями.

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

Что систематические обзоры говорят об обучении

Именно этот отдельный вопрос собственная обзорная литература отрасли и признаёт неподкреплённым.

Систематический обзор Кёнинга, Йёринга и Хеерена 2018 года, один из самых цитируемых в отрасли, закодировал 101 инструмент по типу генерируемой ими обратной связи. Его центральный вывод касается функциональности инструментов, а не их эффекта: «We have found that feedback mostly focuses on identifying mistakes and less on fixing problems and taking a next step. Furthermore, teachers cannot easily adapt tools to their own needs» («Мы обнаружили, что обратная связь в основном сосредоточена на выявлении ошибок и в меньшей степени на их исправлении и следующем шаге. К тому же преподаватели не могут легко адаптировать инструменты под свои нужды») (Keuning, Jeuring & Heeren, 2018). Иначе говоря, обзор, охвативший 101 инструмент, на удивление мало говорит о том, улучшил ли хоть один из них измеримо то, чему студенты научились: этих доказательств по большей части просто не существует, чтобы их обозревать.

Семь лет спустя наблюдательное исследование 2025 года в пяти муниципальных колледжах открывается тем же самым, всё ещё не закрытым разрывом: «However, empirical assessments of auto-grader feedback’s impact on learning outcomes, such as grades and pass rates, remain insufficient (Keuning et al., 2018)» («Однако эмпирических оценок влияния обратной связи от автопроверки на результаты обучения, такие как оценки и доля успешной сдачи, по-прежнему недостаточно (Keuning et al., 2018)») (Zhang, Burte, Savelka, Bogart & Sakr, 2025). Работа 2025 года прямо называет обзор Кёнинга причиной своего существования: одна жалоба, семь лет остающаяся открытой, потому что закрыть её всё это время было нечем.

Самое сильное свидетельство «за» при ближайшем рассмотрении

Ближе всего к положительному доказательству в этой литературе подходит работа Стивена Эдвардса (Stephen Edwards) начала 2000-х о тест-ориентированном оценивании с Web-CAT в Политехническом институте Виргинии. Она называет конкретную цифру: студенты, которых оценивали через TDD и Web-CAT, «submitted programs containing approximately 45% fewer defects per 1000 lines of code» («сдавали программы, содержащие примерно на 45% меньше дефектов на 1000 строк кода»), чем когорта, которую оценивали по-старому (Edwards, 2004). Аннотация журнальной версии JERIC того же исследования называет другую цифру, «a 28% reduction in defects per thousand lines of code» («снижение дефектов на 28% на тысячу строк кода») (Edwards, 2003); расхождение между цифрами в проверенных здесь источниках не разрешено.

За любой из двух цифр стоит квази-эксперимент, а не рандомизированное испытание: когорта Spring 2001, которую оценивали по-старому, сравнивается с когортой Spring 2003, которую оценивали через TDD и Web-CAT, по 59 студентов в каждой, один семестр, с ручной оценкой дефектов на вручную проверенной выборке из 18 программ, экстраполированной на остальные. В рассмотренных здесь источниках независимой репликации результата не нашлось; систематические обзоры отрасли (Keuning et al., 2018; Messer et al., 2024) цитируют более поздние инструментальные статьи Эдвардса, но не подтверждают исходное утверждение. За пределами Политехнического института Виргинии о Web-CAT нашлось единственное свидетельство: саудовское развёртывание, где 50,6% студентов сообщили о недовольстве обратной связью системы (Aldriye, Alkhalaf & Alkhalaf, 2019); удовлетворённость не результат обучения, но другого независимого материала найти не удалось. Добросовестное утверждение двадцатилетней давности, ни разу не реплицированное независимо, само по себе недостаточно, чтобы закрыть вопрос.

Новейшая версия обещания под прямой проверкой

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

Рандомизированное испытание: прирост знаний

Острее всего это видно на рандомизированном испытании 2025 года в Мюнхенском техническом университете, названном без обиняков «Less stress, better scores, same learning» («Меньше стресса, выше баллы, то же обучение»). Басснер с коллегами провели 275 студентов вводного курса CS через 90-минутное упражнение по конкурентности в трёх условиях (ИИ-репетитор со строгими рамками, свободный ChatGPT и контроль без ИИ) и отдельно измерили и результат самого упражнения, и прирост знаний до/после. Оба ИИ-условия дали более высокий результат упражнения. Ни одно не дало более высокого прироста знаний между замерами до и после и не улучшило понимание кода. Вывод авторы формулируют так: «In this setting, generative AI acted primarily as a performance aid rather than a learning enhancer» («В этих условиях генеративный ИИ выступил прежде всего как средство повышения результативности, а не как усилитель обучения») (Bassner, Lenk-Ostendorf, Beinstingel, Wasner & Krusche, 2025). Результативность и обучение расходятся ровно так, как сказано в заголовке, и испытание показывает этот механизм напрямую.

Рандомизированное испытание: устойчивость

Отдельное рандомизированное исследование 2025 года на 257 студентах вводного курса программирования проверяло смежный, но иной вопрос: обратную связь от LLM по ошибкам компиляции в сравнении со стандартными сообщениями компилятора. Пока вмешательство действовало, оно давало реальный, измеренный эффект: снижение бесплодного «прокручивания колёс» и рост устойчивости на трудных задачах. Затем исследователи убрали обратную связь и измерили снова: «Notably, this positive impact was also observed in challenging tasks. However, its benefits did not sustain once the feedback was removed» («Примечательно, что этот положительный эффект наблюдался и на трудных задачах. Однако его польза не сохранялась после того, как обратную связь убирали») (Zhou, Pankiewicz, Paquette & Baker, 2025). Пока эффект длился, он был настоящим. Отмены вмешательства он не пережил: картина, которую мы читаем как признак костыля, а не обучения, хотя слишком рано убранные «строительные леса» оставили бы тот же след, и сама работа между этими прочтениями не выбирает.

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

Строка, которой нет

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

Здесь самое время вернуться к тарификационному листу, о котором шла речь раньше. 0,3 часа на проверку задания для российского или белорусского преподавателя не диковина, а повседневность; в контексте всей этой литературы это ещё и данные, которые можно сопоставить с мировой картиной. Российские и белорусские вузы задают формальные бюджеты времени, в часах, на то, сколько оплаченного труда стоит каждая категория проверки, и цифры эти используются исключительно для расчёта учебной нагрузки, безо всякой педагогической рамки.

Российские нормативы

Два независимо принятых российских документа сходятся в одном порядке величин. Норматив НИУ ВШЭ, действующий с 2004 года, устанавливает для проверки «эссе, домашних заданий, контрольных работ, рефератов» ставку «0,3 часа на одно задание». Исключением идут сами рефераты: на них норматив отводит 0,75 часа по программам подготовки бакалавров и специалистов и 1 час по программам подготовки магистров и аспирантов (НИУ ВШЭ, 2004). Норматив СПбГУТ, обновлённый в 2017-2018 годах, задаёт ту же величину для категории «Проверка, консультация и прием контрольных, расчетных и расчетно-графических работ»: «0,3 часа на одно задание, но не более 1 часа на одного студента на дисциплину в семестр» (СПбГУТ, 2017-2018); в отличие от норматива ВШЭ, СПбГУТ выносит рефераты отдельной строкой, поэтому цифра не смешивается со второй ставкой.

Белорусские нормативы

Общереспубликанский норматив Министерства образования Беларуси задаёт не точечное значение, а диапазон: на проверку «контрольных работ, в том числе расчетно-графических и расчетных работ (типовые расчеты), предусмотренных учебной программой / учебным планом (в том числе в форме тестирования)» отводится от 0,35 до 0,5 часа на 1 работу, и «не более 1 часа на 1 студента (курсанта, слушателя) на учебную дисциплину (модуль) в семестр» (Министерство образования Республики Беларусь, редакция 2018 года). Конкретный вуз затем фиксирует собственную величину внутри этого республиканского диапазона; систему выстроили в две ступени. Белорусская государственная академия связи так и поступила приказом от 24 апреля 2025 года, прямо опирающимся на постановления Министерства 2023-2024 годов (№ 310 от 26 сентября 2023 г. и № 104 от 16 августа 2024 г.), и пошла на шаг дальше любого российского документа, найденного в этом обзоре: она называет лабораторную работу по имени. Приказ отводит на проверку контрольных работ, типовых расчётов, расчётно-графических работ, рефератов и отчётов о выполнении лабораторных исследований 0,4 часа на 1 студента / 0,25 часа на одного обучающегося на учебную дисциплину, модуль (БГАС, приказ № 126, 2025).

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

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

Шесть десятилетий спустя

То, что эта литература в целом подтверждает, сводится к короткому списку, а не к перечню отдельных случаев. Соотношение преподаватель-студент, которое вручную не вытянул бы никто (индийское 1:172 или китайские платформы на десятки миллионов отправленных решений), вытянуто, и этого не оспаривает ни один источник в обзоре, будь то Гана со ставкой на смартфоны или четырёхкратное ускорение в Японии. Дальше начинается плата. Гарантия корректности не сохраняется, её подменяет приближение: там, где кто-то потрудился измерить разрыв напрямую, у GATE он вышел к четверти отклонённых решений (26,5%). А критерий, как только становится тем, за что вознаграждают, начинают обыгрывать; это показало финское исследование покрытия тестами Ихантолы, а не абстрактное соображение.

Чего эта литература не подтверждает спустя шесть с лишним десятилетий после того, как Холлингсуорт впервые поднял этот вопрос, так это утверждения из его же статьи: что студенты, обучавшиеся с автоматическим проверщиком, учатся лучше. Собственная обзорная литература отрасли (систематический обзор 2018 года и цитирующее его наблюдательное исследование 2025-го) говорит, что доказательств по-прежнему недостаточно, почти одними и теми же словами, с разницей в семь лет (Keuning et al., 2018; Zhang et al., 2025). Оба рандомизированных испытания в этом корпусе, которые измеряли обучение напрямую (оба, заметим, испытания новейшей ИИ-обратной связи, а не классического автоматического проверщика), обнаружили разрыв между результативностью и обучением; одно из них названо настолько прямо, насколько вообще можно назвать: «меньше стресса, выше баллы, то же обучение» (Bassner et al., 2025). А единственный эффект, проявившийся как рост устойчивости на трудных задачах, переставал проявляться в тот самый момент, когда обратную связь отключали (Zhou et al., 2025).

Ничто из этого не делает автопроверку плохим инструментом для той задачи, которую она заведомо решает. Проблема пропускной способности, которую она снимает, реальна, и для ряда учреждений из этого обзора не решать её никогда не было реалистичным вариантом. Но и умереть обещанию об обучении никто не дал: Холлингсуорт сформулировал его в 1960-м; Эдвардс отправился искать под него цифры в 2003-м. Волну ИИ-инструментов 2025 года меряют им прямо сейчас. Чего не случилось ни в одной точке этой цепочки, так это подтверждения. Более честный итог, основанный на том, что реально показывают эти примерно шестьдесят исследований, у́же обещания: автопроверка измеримо ускоряет проверку программ. Учит ли она хоть кого-то писать их лучше, остаётся, выражаясь словами самой литературы, открытым вопросом.

Этот обзор опирается почти на шестьдесят исследований, собранных в пяти языковых зонах: англоязычной базовой литературе, другой европейской науке, российских и постсоветских источниках, белорусских источниках и более широком международном пласте, охватывающем Китай, Японию, Индию, Бразилию, Мексику и Африку. Его составил Андрей Несюк, разрабатывающий AutoLabSuite, платформу для проверки лабораторных работ по программированию в университетских курсах.