Automatyczne sprawdzanie zadań programistycznych: sześć dekad badań

Andrei Niasiuk · 11 sierpnia 2026 · Fakty sprawdzone: 12 sierpnia 2026

Ten przegląd obejmuje około sześćdziesięciu badań z pięciu stref językowych i prowadzi do jednego wniosku: automatyczne sprawdzanie zadań programistycznych już dawno stało się szybkim i niezawodnym sposobem kontroli kodu, ale po ponad sześciu dekadach żadne z omawianych tu badań nie wykazało, że uczy ono programować lepiej. To samo pytanie stawia się w tej dziedzinie od 1960 roku, gdy Communications of the ACM opublikował dwustronicową notatkę J. Hollingswortha o systemie oceniającym zbudowanym dla kursu programowania w Rensselaer Polytechnic Institute, działającym na maszynie IBM 650: kompilował rozwiązania studentów, uruchamiał je i zwracał wynik. Był to pierwszy udokumentowany automatyczny system oceniania zadań programistycznych. Ponad sześć dekad później automatyczne ocenianie działa na uczelniach na pięciu kontynentach, a literatura badawcza na ten temat rozeszła się na co najmniej pięć stref językowych. Właśnie o te mniej więcej sześćdziesiąt prac tu chodzi; źródła podane są w dalszej części tekstu przy pierwszym przywołaniu, a wszystkie one wracają do tego samego pytania.

Hollingsworth zadał to pytanie już w artykule, od którego zaczęła się cała dziedzina. Opisując pierwsze piętnaście miesięcy pracy swojego systemu w porównaniu z metodą grup laboratoryjnych, którą ten zastąpił, napisał:

“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)

„Po piętnastu miesiącach nasze doświadczenie skłania nas do przekonania, że studenci uczą się programowania nie tylko tak samo dobrze, ale prawdopodobnie nawet lepiej niż przy metodzie, którą stosowaliśmy wcześniej: w grupach laboratoryjnych liczących cztery lub pięć osób”.

Cytat pochodzi z metadanych CrossRef; oryginalne strony z 1960 roku są za paywallem ACM i nie zostały porównane ze skanem druku.

To stwierdzenie dotyczy nauki, a nie oszczędności czasu, i stoi na samym początku tej literatury: nie wymyślił go żaden późniejszy dział marketingu. Wszystko, co przyszło potem, wraca do niego i sprawy nie rozstrzyga.

Dlaczego popyt nigdy nie zniknął

Systemy tego typu polski czytelnik może znać z własnego podwórka: BaCa i Satori, napisane odpowiednio na Uniwersytecie Jagiellońskim i Politechnice Wrocławskiej, działają od lat. Mimo to nie ma o nich ani jednej publikacji naukowej, podczas gdy niemieckie, fińskie i belgijskie systemy automatycznego oceniania, o których dalej w tym tekście, do literatury trafiły. Polskie doświadczenie działa, ale dla światowej nauki pozostaje niewidoczne.

Odpowiedź ma niewiele wspólnego z pedagogiką, a wiele z arytmetyką.

Gdzie załamują się proporcje kadry do studentów

Badanie z 2025 roku dotyczące wprowadzającego kursu programowania w Indian Institute of Technology Patna podaje, że kursem “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” („kierowało trzech wykładowców, co dało stosunek liczby wykładowców do studentów 1:172, przy dodatkowym wsparciu asystentów w stosunku około 1:20”) (Nareti i in., 2025). Żadna indywidualna determinacja nie wyrówna ręcznie takiej proporcji.

Infrastruktura dorównująca skali

Opracowanie z 2014 roku, przygotowane przez badaczy z Uniwersytetu Tsinghua, Uniwersytetu Pekińskiego i University of Illinois at Urbana-Champaign, rekonstruuje historię chińskich systemów automatycznej oceny programów (tzw. online judge); to historia infrastruktury budowanej pod samą skalę zjawiska: ZOJ Uniwersytetu Zhejiang uruchomiono w 2003 roku; POJ Uniwersytetu Pekińskiego, uruchomiony w 2004 roku, “long led the country” („przez długi czas był krajowym liderem”) pod względem liczby zgłoszonych programów, a do 2014 roku zgłoszono “more than 8 million programs” („ponad 8 milionów programów”); HDOJ Politechniki Elektronicznej w Hangzhou “first broke through the 10 million mark” („jako pierwszy przekroczył próg 10 milionów”) zgłoszeń, już w styczniu 2014 roku (Liu, Wang & Xie, 2014; oryginał w języku chińskim: “北京大学的POJ…于2004年建立，程序提交量长期在国内领先，迄今已经提交了800多万个程序，…另外，杭州电子科技大学的HDOJ…程序提交数目于2014年1月率先冲破1000万大关”).

Tam, gdzie brakuje komputerów

AutoGrad, stworzony dla kursu programowania SuaCode, poszedł tam, gdzie zabrakło nawet komputerów: na telefony. Jego autorzy opisują go jako “the first system built and tested in an African context across over thirty-five countries across the continent” („pierwszy system zbudowany i przetestowany w kontekście afrykańskim, obejmującym ponad trzydzieści pięć krajów kontynentu”), wdrożony do oceniania prac “1000+ students across Africa… with over 3,000 code files graded” („ponad 1000 studentów w całej Afryce… z oceną ponad 3000 plików z kodem”) (Annor i in., 2021). Powód, jak zauważa ten sam artykuł, jest prozaiczny: komputery “tend to be in schools and not in homes” („z reguły stoją w szkołach, a nie w domach”) na większości kontynentu, podczas gdy odsetek posiadaczy smartfonów wciąż rośnie.

Przypadek mierzalny: Japonia

Na Uniwersytecie Nihon liczba studentów na kursie przekroczyła w pewnym momencie setkę, a jeden prowadzący przestał być w stanie sprawiedliwie ocenić prace w ramach godzin zajęć. Skala mniejsza niż w Chinach czy Indiach, ale efekt widać tu najostrzej. Po wdrożeniu systemu wspomagającego automatyczne ocenianie sprawozdań dla kursu programowania w C, wynik okazał się wyrazisty: “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” („ten system wymaga tylko jednego prowadzącego, a czas potrzebny na ocenianie skrócił się do 1/4 czasu sprzed jego wdrożenia… wcześniej codzienne raporty przesyłane mailem wymagały jednego prowadzącego i trzech asystentów, a przy tym systemie wystarcza jeden prowadzący… ocenianie ręczne pozwalało sprawdzić 0,5 raportu na minutę, przy tym systemie 2 raporty na minutę”) (Watanabe, 2009; oryginał w języku japońskim, pierwsza część ze wstępu artykułu, druga z jego wniosków: “本システムによって教員１名ですみ，評価に要する時間が従来の1/4にすることができた…手作業による採点では0.5通/分に対して，本システムでは２通/分であり”).

Żaden z tych faktów nie jest w przebadanej tu literaturze kwestionowany: automatyczne ocenianie niezawodnie zamienia niewykonalną proporcję prowadzący-studenci w wykonalną, i to jest jego najlepiej udokumentowana zaleta.

Co automatyzacja naprawdę daje i czym za to się płaci

Mechanika sprawdzania programu to rozwiązany problem inżynierski, a granice tego rozwiązania opisano jawnie.

Granica teoretyczna

INGInious, platforma do oceniania stworzona na UCLouvain na potrzeby kursu MOOC o paradygmatach programowania, sama nazywa granicę, na którą trafia: teoretyczną. We własnym raporcie z doświadczeń formułuje to wprost: “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]).” („Informatycy wiedzą, że automatyczna korekta nie jest zadaniem łatwym ze względu na ograniczenia teoretyczne: w rzeczywistości nie da się sprawdzić, czy kod studenta robi to samo co kod poprawny (to konsekwencja twierdzenia Rice’a [Beckman, 1980])”) (Derval, Gego, Reinbold, Frantzen & Van Roy, 2015). Automatyczne ocenianie zastępuje wyczerpującą poprawność wykonalnym przybliżeniem, zwykle baterią testów, a to przybliżenie jest, jak można dowieść, niepełne.

Jak duża jest ta luka w praktyce

GATE, system zbudowany na Uniwersytecie Technicznym w Clausthal i Uniwersytecie Humboldtów w Berlinie, sprawdzono na realnym wprowadzającym kursie programowania z 2009 roku; tam widać, w liczbach, jak duża potrafi być ta luka. Jego autorzy podali: “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)” („Z 1031 rozwiązań testy funkcjonalne sklasyfikowały 759 rozwiązań (73,6%) jako niepoprawne, ale prowadzący ćwiczenia mimo to ocenili 201 z nich (26,5%) jako poprawne, ponieważ występowały w nich tylko drobne błędy, np. literówki czy źle ustawiony pakiet”) (Müller & Strickroth, 2013; oryginał w języku niemieckim: “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 (z.B. Tippfehler, Package falsch gesetzt).”). Ponad jedna czwarta rozwiązań odrzuconych przez testy automatyczne była, w ocenie żywego prowadzącego, w rzeczywistości poprawna. Ta liczba pochodzi od samych twórców systemu i została opublikowana obok jego prawdziwych, statystycznie istotnych korzyści na tym samym kursie: wzrostu o 25 punktów procentowych udziału zgłoszeń poprawnych składniowo wśród studentów korzystających z automatycznej kontroli składni. Niezależny niemiecki system JACK podaje porównywalną liczbę we własnym raporcie z 2008 roku: “Up to 28% of the results needed manual correction by the teacher, in most cases because of false negatives.” („Do 28% wyników wymagało ręcznej korekty przez prowadzącego, najczęściej z powodu fałszywych odrzuceń”) (Goedicke, Striewe & Balz, 2008).

Kiedy studenci zaczynają grać pod kryterium

Rozprawa doktorska Petriego Ihantoli z 2011 roku na Uniwersytecie Aalto dokumentuje, jak łatwo studenci uczą się obchodzić kryterium, gdy tylko rozpoznają, za co dokładnie ono nagradza: “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.” („Przeanalizowaliśmy, jak zachowują się studenci, gdy są nagradzani za strukturalne pokrycie testami (np. pokrycie linii kodu), i stwierdziliśmy, że może to prowadzić do pisania testów o dobrym pokryciu, ale słabej zdolności wykrywania błędnych programów”) (Ihantola, 2011). Optymalizacja metryki i rozwijanie samej umiejętności okazały się, w świetle tych danych, dwiema różnymi czynnościami.

Te liczby dziedzina publikuje o sobie sama: odsetek fałszywych odrzuceń wobec własnego systemu podali sami autorzy GATE, twórcy INGInious z góry zastrzegli granicę teoretyczną w swoim raporcie, a rozprawa Ihantoli wprost dokumentuje, jak studenci obchodzą kryterium pokrycia. Żadna z tych prac nie twierdzi jednak, że niedoskonałe przybliżenie, wdrożone na dużą skalę, uczy programowania lepiej, niż uczyłby człowiek sprawdzający prace. To twierdzenie należy do osobnego, znacznie cieńszego zbioru dowodów.

Co o nauce mówią przeglądy systematyczne

Właśnie tego osobnego twierdzenia nie potwierdza własna literatura przeglądowa tej dziedziny.

Przegląd systematyczny Keuninga, Jeuringa i Heerena z 2018 roku, jeden z najczęściej cytowanych w tej dziedzinie, sklasyfikował 101 narzędzi według rodzaju generowanej przez nie informacji zwrotnej. Jego główny wniosek dotyczy funkcjonalności narzędzi, nie ich skutków: “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.” („Stwierdziliśmy, że informacja zwrotna koncentruje się głównie na wskazywaniu błędów, a w mniejszym stopniu na ich naprawianiu i podpowiadaniu kolejnego kroku. Ponadto nauczyciele nie mogą łatwo dostosować narzędzi do własnych potrzeb”) (Keuning, Jeuring & Heeren, 2018). Innymi słowy: przegląd obejmujący 101 narzędzi ma zaskakująco mało do powiedzenia o tym, czy którekolwiek z nich mierzalnie poprawiło to, czego nauczyli się studenci, bo takich dowodów w większości po prostu nie ma, żeby je zebrać.

Siedem lat później badanie obserwacyjne z 2025 roku, obejmujące pięć college’ów typu community college, zaczyna się od wskazania dokładnie tej samej, wciąż nierozwiązanej luki: “However, empirical assessments of auto-grader feedback’s impact on learning outcomes, such as grades and pass rates, remain insufficient (Keuning et al., 2018).” („Empiryczne oceny wpływu informacji zwrotnej z systemów automatycznego oceniania na wyniki nauczania, takie jak oceny i wskaźniki zaliczeń, pozostają jednak niewystarczające (Keuning i in., 2018)”) (Zhang, Burte, Savelka, Bogart & Sakr, 2025). Badanie z 2025 roku wprost cytuje przegląd Keuninga jako powód swojego istnienia: jedna skarga, od siedmiu lat otwarta, bo nie nadeszło nic, co mogłoby ją zamknąć.

Najmocniejszy argument na tak, sprawdzony

Praca Stephena Edwardsa z początku lat 2000. o ocenianiu opartym na TDD za pomocą Web-CAT na Virginia Tech podaje konkretną liczbę, i to ona podchodzi najbliżej pozytywnego dowodu w tej literaturze: studenci oceniani metodą TDD i Web-CAT “submitted programs containing approximately 45% fewer defects per 1000 lines of code” („oddawali programy zawierające około 45% mniej defektów na 1000 linii kodu”) niż kohorta oceniana starą metodą (Edwards, 2004). Streszczenie wersji czasopisma JERIC tego samego badania podaje inną liczbę: “a 28% reduction in defects per thousand lines of code” („28-procentowe zmniejszenie liczby defektów na tysiąc linii kodu”) (Edwards, 2003). Rozbieżność między tymi liczbami pozostaje nierozstrzygnięta w sprawdzonych tu źródłach.

Za obiema liczbami stoi quasi-eksperyment, a nie badanie randomizowane: kohorta z wiosny 2001 roku oceniana starą metodą w porównaniu z kohortą z wiosny 2003 roku ocenianą metodą TDD i Web-CAT, po 59 studentów w każdej, jeden semestr, z ręczną oceną defektów na sprawdzonej ręcznie próbie 18 programów ekstrapolowaną na resztę. W źródłach tu przeglądanych niezależna replikacja tego wyniku się nie znalazła; przeglądy systematyczne tej dziedziny (Keuning i in., 2018; Messer i in., 2024) cytują późniejsze prace narzędziowe Edwardsa, ale nie potwierdzają pierwotnego twierdzenia. Jedynym zewnętrznym punktem danych o Web-CAT poza Virginia Tech jest wdrożenie w Arabii Saudyjskiej, gdzie 50,6% studentów zgłosiło niezadowolenie z informacji zwrotnej systemu (Aldriye, Alkhalaf & Alkhalaf, 2019). Satysfakcja nie jest wynikiem nauczania, ale to jedyny niezależny dowód, jaki udało się znaleźć. Rzetelne, złożone w dobrej wierze twierdzenie sprzed dwudziestu kilku lat, nigdy niezależnie niezreplikowane, samo w sobie nie wystarcza, by zamknąć tę sprawę.

Najnowsza wersja obietnicy w bezpośrednim teście

Zanim przejdziemy do obu badań, jedno trzeba powiedzieć wprost: żadne z nich nie testuje klasycznego autogradera opartego na testach. Badań kontrolowanych tego rodzaju nie ma w tym korpusie wcale; właśnie tę lukę Keuning i Zhang wciąż nazywają po imieniu. Rok 2025 przyniósł za to dwa randomizowane badania najnowszych nośników tej samej obietnicy: informacji zwrotnej opartej na AI, nałożonej na ten sam zautomatyzowany potok sprawdzania. Testują one dzisiejszą wersję twierdzenia Hollingswortha, nie jego narzędzie, i oba wypadły dla niej niepochlebnie.

Badanie randomizowane: przyrost wiedzy

Rozdźwięk między wynikiem a nauką widać najostrzej w badaniu Bassnera i zespołu z 2025 roku na politechnice w Monachium (Technical University of Munich), zatytułowanym bez ogródek “Less stress, better scores, same learning” („Mniej stresu, lepsze wyniki, ta sama nauka”). Badacze przeprowadzili 275 studentów wprowadzającego kursu informatyki przez 90-minutowe ćwiczenie z współbieżności w trzech wariantach (ograniczony ramami tutor AI, nieograniczony ChatGPT i grupa kontrolna bez AI), mierząc osobno wynik samego ćwiczenia i przyrost wiedzy przed/po. Oba warianty z AI dały wyższy wynik samego ćwiczenia. Żaden nie dał wyższego wyniku w pomiarze faktycznej nauki: “Despite these performance gains, neither AI condition produced greater pre-post knowledge gains or code-comprehension advantages… In this setting, generative AI acted primarily as a performance aid rather than a learning enhancer.” („Mimo tych wzrostów wyników, żaden z wariantów z AI nie dał większego przyrostu wiedzy między pomiarem początkowym a końcowym ani przewagi w rozumieniu kodu… W tym eksperymencie generatywna AI działała przede wszystkim jako wsparcie wykonania zadania, a nie jako wzmacniacz uczenia się”) (Bassner, Lenk-Ostendorf, Beinstingel, Wasner & Krusche, 2025). Tytuł nie jest przesadą: badanie pokazuje dokładnie ten mechanizm.

Badanie randomizowane: trwałość efektu

257 studentów wprowadzającego kursu programowania wzięło udział w osobnym badaniu z 2025 roku, które sprawdzało coś pokrewnego, ale innego: informację zwrotną generowaną przez LLM na temat błędów kompilacji, w porównaniu ze standardowymi komunikatami kompilatora. Dopóki interwencja działała, dawała realną, zmierzoną korzyść: mniej „kręcenia się w kółko” i większą wytrwałość przy trudnych zadaniach. Następnie badacze usunęli informację zwrotną i zmierzyli ponownie: “Notably, this positive impact was also observed in challenging tasks. However, its benefits did not sustain once the feedback was removed.” („Co ważne, ten pozytywny efekt był widoczny również w zadaniach trudnych. Jednak jego korzyści nie utrzymywały się po usunięciu informacji zwrotnej”) (Zhou, Pankiewicz, Paquette & Baker, 2025). Dopóki trwał, efekt był prawdziwy. Usunięcia interwencji już nie przetrwał. Ten wzorzec odczytujemy jako ślad protezy, nie nauczania, choć zbyt wcześnie zdjęte rusztowanie zostawiłoby ten sam ślad, a samo badanie między tymi odczytaniami nie rozstrzyga.

Oba badania znalazły to samo: informacja zwrotna wsparta przez AI zmienia to, co studenci produkują, dopóki jest obecna, a zmiany w tym, co im zostaje później, żadne nie znalazło. Obowiązuje tu ta sama miara rygoru, którą wyżej przyłożyliśmy do Edwardsa: każde z tych badań to jedna uczelnia i jedna krótka interwencja (90-minutowe ćwiczenie w Monachium, błędy kompilatora jednego kursu), publikacja z ostatniego roku, na razie bez replikacji. Wniosek pozostaje więc wąski: pierwsze bezpośrednie pomiary najnowszej formy obietnicy znalazły wydajność bez uczenia się. Klasyczny autograder wciąż czeka na własny test.

Pozycja, której nie ma

Jeden fragment dowodów w tym korpusie nie był chyba wcześniej publikowany po angielsku, a pochodzi z miejsca dość nieoczywistego: z regulaminów rozliczania obciążenia dydaktycznego na uczelniach.

Rosyjskie i białoruskie uczelnie ustalają formalne budżety czasu, w godzinach, ile płatnej pracy wykładowcy warta jest każda kategoria sprawdzania prac: liczby używane wyłącznie do wyliczenia pensum dydaktycznego, bez jakiejkolwiek ramy pedagogicznej.

Rosyjskie normy

Normy Narodowego Uniwersytetu Badawczego Wyższa Szkoła Ekonomiczna (HSE), obowiązujące od 2004 roku, ustalają dla sprawdzania “эссе, домашних заданий, контрольных работ, рефератов” stawkę “0,3 часа на одно задание”; wyjątkiem są same referaty, dla których przewidziano osobną, wyższą stawkę: “0,75 часа на реферат по программам подготовки бакалавров и специалистов; 1 час на реферат по программам подготовки магистров и аспирантов” (HSE, 2004; tłum.: „Sprawdzanie esejów, prac domowych, prac kontrolnych, referatów: 0,3 godziny na jedno zadanie; 0,75 godziny na referat w programach studiów licencjackich/inżynierskich; 1 godzina na referat w programach magisterskich i doktoranckich”). Normy SPbSUT, zaktualizowane w latach 2017-2018, ustalają dla kategorii “Проверка, консультация и прием контрольных, расчетных и расчетно-графических работ” tę samą wartość: “0,3 часа на одно задание, но не более 1 часа на одного студента на дисциплину в семестр” (tłum. kategorii: „Sprawdzanie, konsultacja i odbiór prac kontrolnych, obliczeniowych i obliczeniowo-graficznych”; stawki: „0,3 godziny na jedno zadanie, ale nie więcej niż 1 godzina na studenta na przedmiot w semestrze”); w odróżnieniu od normy HSE, SPbSUT wyodrębnia referaty jako osobną pozycję, więc ta liczba nie miesza się z drugą stawką.

Białoruskie normy

Ogólnorepublikańska norma Ministerstwa Edukacji Białorusi ustala nie wartość punktową, lecz przedział, pierwszy z dwóch poziomów tego systemu. Sprawdzanie prac kontrolnych, w tym obliczeniowo-graficznych i obliczeniowych (obliczenia typowe), przewidzianych programem nauczania lub planem studiów, także w formie testu, kosztuje w niej od 0,35 do 0,5 godziny na 1 pracę, przy limicie 1 godziny na 1 studenta (kursanta, słuchacza) na przedmiot (moduł) w semestrze (Ministerstwo Edukacji Republiki Białorusi, wydanie 2018). Konkretna uczelnia ustala następnie własną wartość w ramach tego republikańskiego przedziału. Białoruska Państwowa Akademia Łączności zrobiła to w zarządzeniu wewnętrznym z 24 kwietnia 2025 roku, opartym wprost na uchwałach Ministerstwa z lat 2023-2024 (nr 310 z 26 września 2023 r. i nr 104 z 16 sierpnia 2024 r.), i poszła o krok dalej niż jakikolwiek rosyjski dokument znaleziony w tym przeglądzie: wymienia pracę laboratoryjną z nazwy. W jednej pozycji akademia zestawia prace kontrolne, obliczenia typowe, prace obliczeniowo-graficzne, referaty i sprawozdania z wykonania badań laboratoryjnych, wyceniając je na 0,4 godziny na 1 studenta oraz 0,25 godziny na jednego uczącego się na przedmiot lub moduł (BGAS, zarządzenie nr 126, 2025).

W czterech przeanalizowanych tu dokumentach (dwóch rosyjskich i dwóch białoruskich) nie ma osobnej pozycji dla sprawdzania kodu programu: nie pojawiają się w nich słowa “kod”, “program”, “kompilacja”, “debugowanie” ani żadne pokrewne. Sprawozdania z laboratoriów programistycznych ocenia się w tej samej ogólnej kategorii co eseje, obliczenia typowe i prace kontrolne w ogóle. Sprawdzanie cudzego programu i czytanie pisemnej pracy kontrolnej mieszczą się w jednej wspólnej kategorii, a nie w dwóch, choć nic tu nie mówi, czy autorzy w ogóle zastanawiali się nad tą różnicą. Dokumenty pokazują też księgowość taką, jaka jest: tam, gdzie automatyczne ocenianie zostało w tych instytucjach wdrożone, żyje ono w kategorii obciążeń starszej od niego samego, a żaden z czterech tekstów nie kreśli granicy między sprawdzaniem kodu a sprawdzaniem prozy.

Dokładniejsze omówienie tych norm oraz tego, co naprawdę wiadomo o cenie tej pracy dla osoby, która ją wykonuje, znajduje się w osobnym tekście na tej stronie.

Sześć dekad później

Zestawmy to, co ta literatura jako całość faktycznie potwierdza. Jeden wątek nie budzi w niej żadnych wątpliwości: przepustowość. Proporcja, której ręcznie domknąć się nie dało, została domknięta, i nikt w przebadanym tu korpusie temu nie zaprzecza. Indyjskie 1:172 jest tego skrajną wersją; chińskie platformy liczą zgłoszenia w dziesiątkach milionów; w Ghanie wdrożenie poszło na smartfony, bo komputery stoją w szkołach, a nie w domach; w Japonii ocenianie przyspieszyło czterokrotnie. Cena za to też jest znana: twierdzenie Rice’a wyklucza teoretyczną gwarancję poprawności, więc w zamian dostajemy szybkie, ale niepełne przybliżenie; tam, gdzie ktoś zmierzył tę niepełność wprost, sięgała ona mniej więcej jednej czwartej wszystkich odrzuconych rozwiązań (26,5% w przypadku GATE). I studenci, będąc studentami, zaczynają optymalizować pod kryterium, gdy tylko ono staje się tym, za co się nagradza; pokazało to wprost fińskie badanie pokrycia testami.

Czego ta literatura nie potwierdza, ponad sześć dekad po tym, jak Hollingsworth pierwszy postawił tę możliwość, to twierdzenie z jego własnej pracy: że studenci uczeni z automatycznym systemem oceniania uczą się lepiej. Własna literatura przeglądowa tej dziedziny, czyli przegląd systematyczny z 2018 roku i cytujące go badanie obserwacyjne z 2025 roku, mówi niemal tymi samymi słowami, z siedmioletnim odstępem, że dowodów wciąż brakuje (Keuning i in., 2018; Zhang i in., 2025). Oba kontrolowane badania w tym korpusie, które mierzyły naukę bezpośrednio, a nie samą wydajność (przy czym oba, zauważmy, dotyczą najnowszej informacji zwrotnej AI, nie klasycznego autogradera), wykazały rozdźwięk między wydajnością a nauką, a jedno z nich nosi tytuł tak dosłowny, jak to tylko możliwe: “less stress, better scores, same learning” („mniej stresu, lepsze wyniki, ta sama nauka”) (Bassner i in., 2025). A jedyna korzyść, która ujawniła się jako większa wytrwałość przy trudnych zadaniach, przestawała być widoczna w chwili wyłączenia informacji zwrotnej (Zhou i in., 2025).

Nic z tego nie czyni automatycznego oceniania złym narzędziem do zadania, które ono realnie wykonuje. Problem przepustowości, który rozwiązuje, jest prawdziwy, a dla wielu z przebadanych tu instytucji nierozwiązanie go nigdy nie było realną opcją. Ale obietnicy o nauce nie pozwolono też umrzeć: Hollingsworth sformułował ją w 1960 roku; Edwards szukał dla niej liczb w roku 2003. Falę narzędzi AI z 2025 roku mierzy się nią właśnie teraz. Jednego w żadnym punkcie tego łańcucha nie było: potwierdzenia. Uczciwsze podsumowanie, oparte na tym, co te niespełna sześćdziesiąt badań faktycznie pokazuje, jest węższe niż ta obietnica: automatyczne ocenianie mierzalnie przyspiesza sprawdzanie programów. Czy uczy kogokolwiek pisać je lepiej, pozostaje, mówiąc słowami samej literatury, pytaniem otwartym.

Ten przegląd opiera się na blisko sześćdziesięciu badaniach zebranych z pięciu stref językowych: anglojęzycznej literaturze bazowej, innych opracowaniach europejskich, źródłach rosyjskich i postsowieckich, źródłach białoruskich oraz szerszym zbiorze międzynarodowym obejmującym Chiny, Japonię, Indie, Brazylię, Meksyk i Afrykę. Przygotował go Andrei Niasiuk, twórca AutoLabSuite, platformy do sprawdzania laboratoriów programistycznych na kursach uniwersyteckich.