Jak przygotować przyszłych developerów do pracy z AI? Perspektywa HBO-ICT
Na uczelniach zawodowych wykładowcy HBO-ICT przygotowują przyszłych developerów do pracy, w której AI może wygenerować działający kod, zanim student zrozumie problem. Co powinna chronić edukacja?
TraceYield — wiedza
11 min czytania · Zaktualizowano 19 września 2026
TraceYield
Dowody pracy wspomaganej przez AI
Jak przygotować przyszłych developerów do pracy z AI? Perspektywa HBO-ICT
Przyszli developerzy trafiają do zespołów już za chwilę
Tworzymy oprogramowanie i sami korzystamy z AI. Widzimy też, jak szybko zmienia się punkt wyjścia: student może dziś dostać wiarygodnie wyglądający, działający kod, zanim naprawdę zrozumie problem, architekturę czy kompromisy stojące za rozwiązaniem.
Dla wykładowców HBO-ICT i osób uczących programowania to duża odpowiedzialność. Przygotowują przyszłych developerów do pracy w zespołach, gdzie AI będzie czymś zwyczajnym, a jednocześnie muszą chronić umiejętność brania odpowiedzialności za kod.
Rozmowa, która została z nami na długo
Niedawno rozmawialiśmy z osobą, która właśnie kończyła HBO-ICT. Gdy padło pytanie o frontend, odpowiedź brzmiała w zasadzie: „Claude”. To nie było przyznanie się do winy ani argument przeciwko AI. Był to po prostu uczciwy obraz tego, jak łatwo narzędzie może przejąć środek ciężkości pracy.
Problem nie polega na tym, że student używa Claude, Codexu, Cursora czy innego agenta. My też używamy tych narzędzi. Trudność zaczyna się wtedy, gdy można przyjąć przekonujący wynik bez umiejętności wyjaśnienia problemu, założeń i ryzyka, które ten wynik ze sobą niesie.
Pytanie edukacyjne wygląda dziś inaczej
Repozytorium nadal może pokazać dobrą pracę: czytelny kod, przechodzące testy i działający interfejs. Ale końcowy efekt mówi mniej niż kiedyś o tym, jak student sformułował zadanie, rozważył alternatywy, zareagował na błąd albo zdecydował, że rozwiązanie jest gotowe do oddania.
Dlatego Npuls i badania nad ocenianiem odpornym na wpływ AI koncentrują się na projektowaniu oceny, efektach uczenia się i dowodach — a nie tylko na wykryciu narzędzia w końcowym artefakcie. Wizja Npuls dotycząca oceniania, egzaminowania i AI to dobry punkt wyjścia do tej rozmowy.
Dwa dopracowane projekty mogą oznaczać zupełnie inne uczenie się
Wyobraźmy sobie dwóch studentów oddających podobną aplikację. Pierwszy prosi agenta o strukturę, przyjmuje pierwszą sensowną implementację i nie umie wyjaśnić ważnych wyborów. Drugi korzysta z AI przez cały projekt, ale sprawdza sugestie, odrzuca niepasujące rozwiązanie, po nowych danych inaczej formułuje zadanie i potrafi obronić końcowy kompromis.
Repozytoria mogą wyglądać równie dobrze. Z punktu widzenia nauki nie są to jednak takie same osiągnięcia. Pierwszy student oddał artefakt. Drugi ćwiczył pracę developera: definiowanie problemu, ocenę rozwiązań, debugging, testowanie i odpowiedzialność.
Dlaczego dowód z procesu jest potrzebny
Nie musi to być pełny log promptów ani zapis każdego kliknięcia. Krótkie wyjaśnienie zmienionego podejścia, wybrany moment debugowania, test podważający założenie albo krótki walkthrough kodu daje prowadzącemu więcej niż wynik detektora AI.
Zarówno raport ACM Task Force o ocenianiu programowania, jak i badania nad ocenianiem odpornym na wpływ AI wskazują, że jeden końcowy artefakt nie wystarcza. Dowody powinny być proporcjonalne do efektu uczenia się i możliwe do wykorzystania przez studenta oraz prowadzącego.
To nie jest argument za nadzorem
TraceYield nie jest detektorem AI, wskaźnikiem samodzielności ani automatycznym systemem oceniania. Historia użycia narzędzia nie dowodzi sama w sobie zrozumienia, a prowadzący nie potrzebuje trwałego zapisu każdej prywatnej interakcji.
Chodzi o niewielki, możliwy do omówienia obraz ważnych momentów: co student sprawdził, co zmienił, co zweryfikował i co umie wyjaśnić. Dowód z procesu ma prowadzić do lepszej rozmowy akademickiej, nie do dodatkowego obciążenia kontrolą.
Gdzie w tym miejscu jest TraceYield
Właśnie wokół tego problemu zaczęliśmy budować TraceYield. Na poziomie sesji można zrozumieć jeden epizod pracy z AI. Na poziomie projektu połączyć powiązane momenty. Na poziomie profilu studenta zauważyć wzorce w kolejnych zadaniach — zawsze po to, by prowadzący mógł je zinterpretować.
Produkt pokazuje dowody i kontekst; ocena edukacyjna pozostaje po stronie wykładowcy. Jak działa TraceYield oraz przebieg pracy programistycznej wyjaśniają ten model szerzej.
Co powinna chronić edukacja
Nie trzeba chronić każdej ręcznie wykonanej czynności. Trzeba chronić umiejętności potrzebne wtedy, gdy AI się myli, nie jest dostępna, nie rozumie kontekstu albo podaje przekonującą, lecz błędną odpowiedź: formułowanie problemu, czytanie kodu, testowanie zachowania, myślenie o architekturze, dostrzeganie ryzyka i uzasadnianie decyzji.
AI może pomagać w uczeniu tych umiejętności: może wygenerować wadliwy patch do review, wiarygodne wyjaśnienie do podważenia albo kilka podejść do porównania. Ważne, aby szybka odpowiedź nigdy nie zastąpiła zrozumienia po stronie studenta.
Zakończenie pracy przez agenta nie zawsze oznacza zakończenie pracy inżynierskiej.
Referencje
Program pilotażowy
Zrozum, dlaczego Twój zespół korzysta z AI właśnie w taki sposób.
TraceYield analizuje dowody przebiegu pracy, zamiast kończyć na kosztach i liczbie tokenów. Dołącz do prywatnego pilotażu, aby ocenić użycie AI z kontekstem pracy technicznej, kontrolami bezpieczeństwa i zaufaniem developerów.
Dołącz do pilotażu TraceYield