Edukacja i ocena deweloperów w erze agentów

Edukacja i ocena deweloperów w erze agentów

Niniejsza analiza odzwierciedla krajobraz edukacyjny i certyfikacyjny na dzień 26 lipca 2026 r.

Wstęp

Autonomiczne agenty kodujące zmieniają rozwój oprogramowania z zadania skoncentrowanego na pisaniu kodu w zadanie skoncentrowane na specyfikowaniu pracy, delegowaniu zadań, nadzorowaniu wykonania i przeglądaniu wyników.

Nowoczesne agenty kodujące mogą przeglądać repozytorium, opracowywać plan implementacji, modyfikować wiele plików, uruchamiać testy, reagować na błędy i otwierać pull request do przeglądu przez człowieka. Obecna dokumentacja GitHub opisuje przepływy pracy, w których deweloperzy przypisują problemy agentom, monitorują ich pracę, proszą o przegląd kodu, dostarczają informacje zwrotne oraz zatwierdzają lub odrzucają wynik. (docs.github.com)

To stwarza trudne pytanie dla edukacji:

Jeśli student może poprosić agenta o stworzenie działającego programu, co powinien być zobowiązany zrozumieć?

Odpowiedzią nie jest porzucenie podstaw programowania. Jest nią zmiana zastosowania tych podstaw.

Studenci nadal muszą rozumieć struktury danych, algorytmy, języki programowania, projektowanie systemów, bezpieczeństwo, testowanie i debugowanie. Jednakże, coraz częściej muszą stosować tę wiedzę do:

• Rozkładania niejednoznacznych problemów na możliwe do zarządzania zadania
• Tworzenia precyzyjnych specyfikacji i kryteriów akceptacji
• Dostarczania użytecznego kontekstu agentom kodującym
• Oceniania, czy wygenerowany kod jest poprawny i łatwy w utrzymaniu
• Projektowania testów, które ujawniają ukryte błędy
• Przeglądania ryzyka związanego z bezpieczeństwem, prywatnością, wydajnością i architekturą
• Koordynowania kilku agentów lub narzędzi bez utraty kontroli
• Wyjaśniania i obrony decyzji technicznych

Następne pokolenie edukacji deweloperów będzie zatem oceniać w mniejszym stopniu zdolność studenta do tworzenia dużych ilości kodu, a w większym stopniu jego zdolność do rozumienia, kierowania, weryfikowania i ulepszania systemów oprogramowania.

Centralna zmiana: Od produkcji kodu do oceny inżynierskiej

Agenty kodujące to nie tylko szybsze autouzupełnianie

Tradycyjne asystenty kodowania sugerują linię, funkcję lub mały blok kodu. Autonomiczne agenty kodujące działają na większą skalę. Mogą pracować na wielu plikach, wywoływać narzędzia programistyczne, wykonywać testy, sprawdzać dokumentację i kontynuować pracę przez wiele etapów.

To zmienia jednostkę pracy. Przepływ pracy dewelopera coraz częściej wygląda następująco:

1. Zrozumienie problemu użytkownika lub biznesowego.
2. Zdefiniowanie pożądanego zachowania.
3. Podział pracy na mniejsze zadania.
4. Przypisanie odpowiedniego zadania agentowi.
5. Sprawdzenie planu agenta.
6. Pozwolenie agentowi na implementację w kontrolowanym środowisku.
7. Uruchomienie testów i kontroli bezpieczeństwa.
8. Przeglądanie wyniku.
9. Żądanie zmian lub rewizja projektu.
10. Zatwierdzenie, połączenie i monitorowanie oprogramowania.

Osoba, która pomija etapy planowania i przeglądu, może nadal produkować kod, ale nie może wiarygodnie stworzyć godnego zaufania produktu.

Ograniczenia surowej produkcji kodu

Surowa produkcja kodu staje się słabszą miarą umiejętności, ponieważ agent może szybko wygenerować dużą ilość prawdopodobnego kodu. Jednocześnie agenci nadal mają trudności z długoterminową ewolucją oprogramowania, zmianami obejmującymi wiele plików, niejasnymi wymaganiami i utrzymywaniem zachowania po wielokrotnych modyfikacjach. Badanie porównawcze z 2025 roku wykazało znaczną lukę między wydajnością agentów w izolowanym rozwiązywaniu problemów a bardziej złożonymi, długoterminowymi zadaniami ewolucji oprogramowania. (arxiv.org)

To tworzy ważne rozróżnienie edukacyjne:

• Student, który potrafi wygenerować kod, może go nie rozumieć.
• Student, który potrafi wyjaśnić, przetestować, zakwestionować i naprawić kod, wykazuje głębsze kompetencje.

Celem edukacyjnym powinno zatem stać się zweryfikowane osądzanie oprogramowania, a nie tylko udane generowanie kodu.

Jak adaptują się programy nauczania

Programy nauczania uniwersyteckiego zmierzają w stronę zrozumienia i weryfikacji

Raport "Computer Science Curricula 2023" przygotowany przez ACM, Institute of Electrical and Electronics Engineers Computer Society oraz Association for the Advancement of Artificial Intelligence przewidywał, że generatywna sztuczna inteligencja zmieni edukację programistyczną. Jego wytyczne sugerują, że studenci będą potrzebować większego nacisku na czytanie, rozumienie, weryfikowanie, edytowanie, modyfikowanie, adaptowanie i testowanie kodu. Identyfikuje również dekompozycję problemów jako obszar, który prawdopodobnie stanie się ważniejszy. (csed.acm.org)

Te same wytyczne zwracają uwagę na kluczową kwestię: nawet jeśli agent pisze program, człowiek pozostaje odpowiedzialny za ustalenie, czy program jest poprawny. Oznacza to, że edukacji programistycznej nie można sprowadzić do pisania promptów. Studenci potrzebują wystarczającej wiedzy technicznej, aby ocenić wynik.

Raport przewiduje również zmiany w edukacji inżynierii oprogramowania, w tym większe wykorzystanie sztucznej inteligencji do generowania kodu, debugowania, analizy statycznej i przeglądu kodu. Skuteczne wykorzystanie tych narzędzi wymaga silniejszych umiejętności projektowania i rozumienia kodu, a nie słabszych. (csed.acm.org)

Akredytacja zaczyna nagradzać szersze wyniki inżynierskie

Obecne kryteria akredytacji informatyki przez Accreditation Board for Engineering and Technology już kładą nacisk na:

• Analizę złożonych problemów informatycznych
• Projektowanie i ocenę rozwiązań informatycznych
• Profesjonalną komunikację
• Odpowiedzialność prawną i etyczną
• Bezpieczeństwo i prywatność
• Społeczne wpływy informatyki
• Kompleksowy projekt lub komponent doświadczalny (abet.org)

Te wyniki dobrze pasują do środowiska deweloperskiego opartego na agentach, ponieważ mierzą one osąd i odpowiedzialność, a nie liczbę naciśnięć klawiszy.

Na dzień 26 lipca 2026 r. proponowane zmiany w kryteriach akredytacji Accreditation Board for Engineering and Technology na cykl 2026–2027 obejmują dodatkowe kryteria programów sztucznej inteligencji oraz wymóg, aby absolwenci byli w stanie stosować teorie, modele i techniki sztucznej inteligencji do złożonych problemów. Proponowane zmiany wciąż oczekiwały na ostateczne przyjęcie i oczekiwano, że wejdą w życie po spotkaniu jesienią 2026 r., z pierwszym zastosowaniem podczas cyklu oceny 2027–2028. (abet.org)

Prawdopodobny kierunek jest jasny: programy będą musiały wykazać, że studenci potrafią budować i oceniać systemy, a nie tylko wykonywać izolowane ćwiczenia programistyczne.

Nowe kursy uczą wykorzystania agentów jako dyscypliny inżynierskiej

Kilka ostatnich kursów uniwersyteckich ilustruje powstający wzorzec.

Kurs Uniwersytetu Maryland z 2025 roku dotyczący efektywnego wykorzystania asystentów kodowania i agentów sztucznej inteligencji obejmował narzędzia, które potrafią wywoływać systemy kompilacji, uruchamiać testy i naprawiać błędy. Omówiono w nim również łatwość utrzymania, architekturę, projektowanie interfejsów programowania aplikacji, wydajność, skalowalność, bezpieczeństwo, ciągłą integrację, przegląd kodu, asynchroniczne agenty i automatyczny przegląd kodu. (cs.umd.edu)

Uniwersytet Pensylwanii zaproponował kurs informatyki na drugim roku studiów, skupiający się na tworzeniu oprogramowania opartym na sztucznej inteligencji. Proponowane tematy obejmują delegowanie zadań kodowania, modułowe projektowanie, skalowalne testowanie, zarządzanie ryzykiem, odtwarzalność, współpracę i etykę. (seas.upenn.edu)

Kurs Uniwersytetu Michigan z jesieni 2026 roku, „Applied Agentic Software Engineering”, jest jeszcze bardziej precyzyjny. Jest zorganizowany w trzech fazach:

1. Efektywne wykorzystywanie agentów kodujących
2. Budowanie agenta przy użyciu interfejsu programowania aplikacji dużego modelu językowego
3. Projektowanie, ocenianie i wdrażanie orkiestratora agentów

Kurs wykorzystuje projekty, laboratoria, demonstracje i zaliczenia zamiast tradycyjnych egzaminów. Stwierdza, że ocenianie będzie nagradzać zrozumienie bardziej niż wynik końcowy i prosi studentów o wyjaśnienie, dlaczego agent zawiódł i jak naprawić otaczający system. (eecs498-aase.github.io)

To znacząca zmiana w projekcie. Kurs nie uczy studentów szybszego tworzenia kodu. Uczy ich, jak stać się technicznymi nadzorcami systemów, które produkują kod.

Jak zmieniają się bootcampy

Bootcampy adaptują się szybciej niż wiele tradycyjnych programów, ponieważ ich programy nauczania są ściśle związane z wymaganiami rynku pracy. Jednak jakość adaptacji jest zróżnicowana.

Model bootcampu dedykowanego sztucznej inteligencji

Obecny bootcamp Le Wagon „Artificial Intelligence Software Development” łączy rozwój full-stack z integracją sztucznej inteligencji. Jego opublikowany program nauczania obejmuje kodowanie wspomagane sztuczną inteligencją, integrację dużych modeli językowych, wdrożenia produkcyjne, generowanie wspomagane wyszukiwaniem oraz autonomiczne agenty sztucznej inteligencji. (lewagon.com)

Ten model traktuje sztuczną inteligencję jako wątek przewijający się przez cały program, a nie jako pojedynczą, opcjonalną lekcję. Od studentów oczekuje się, że nauczą się zarówno:

• Jak działają konwencjonalne systemy oprogramowania
• Jak używać narzędzi sztucznej inteligencji do budowania i obsługi tych systemów

Ta kombinacja jest ważna. Uczeń, który wie tylko, jak obsługiwać agenta, może nie być w stanie rozpoznać wadliwej architektury. Uczeń, który zna tylko konwencjonalne programowanie, może nie być przygotowany na nowoczesne przepływy pracy w rozwoju oprogramowania.

Model „dodania modułu sztucznej inteligencji”

Bootcamp inżynierii oprogramowania Springboard utrzymuje konwencjonalne podstawy w rozwoju stron internetowych, interfejsach programowania aplikacji, rozwoju front-end, rozwoju back-end i projektach full-stack, jednocześnie dodając moduł sztucznej inteligencji skupiony na inżynierii promptów i współpracy z narzędziami generatywnymi. (springboard.com)

Ten model jest przydatny dla uczniów, którzy najpierw potrzebują solidnych podstaw programistycznych. Odzwierciedla również praktyczną rzeczywistość: wielu studentów nie powinno zaczynać od budowania autonomicznych agentów. Najpierw powinni nauczyć się, jak działa oprogramowanie, jak używać kontroli wersji, jak czytać komunikaty o błędach i jak testować program.

Słabością jest to, że krótki moduł inżynierii promptów może stać się zbyt płytki. Poważny program nauczania ery agentów powinien uczyć czegoś więcej niż tylko tego, jak prosić o kod. Powinien uczyć:

• Jak stworzyć plik kontekstu repozytorium
• Jak napisać specyfikację techniczną
• Jak zdefiniować granice zadań
• Jak ograniczyć uprawnienia agenta
• Jak sprawdzać plany agenta
• Jak oceniać wygenerowane testy
• Jak wykrywać problemy z bezpieczeństwem
• Jak porównywać alternatywne projekty
• Jak dokumentować udział agenta

Na co powinni zwracać uwagę studenci bootcampów

Potencjalni studenci powinni zapytać, czy program ocenia następujące kwestie:

• Czy studenci potrafią wyjaśnić kod, którego sami nie napisali?
• Czy studenci przeglądają i naprawiają wadliwe wyniki agentów?
• Czy oceniane są testy, bezpieczeństwo i łatwość utrzymania?
• Czy jest demonstracja na żywo lub obrona techniczna?
• Czy studenci utrzymują historię projektu kontrolowaną wersjami?
• Czy studenci są uczeni, jak pracować bez agenta, gdy jest to konieczne?
• Czy program uczy odkrywania produktu i analizy wymagań?
• Czy umiejętności specyficzne dla narzędzi są zrównoważone z trwałymi zasadami inżynierskimi?

Program, który reklamuje „zbudowanie aplikacji w tydzień ze sztuczną inteligencją”, może być doskonały do szybkiego prototypowania, ale to nie to samo, co przygotowanie kogoś do profesjonalnej inżynierii oprogramowania.

Jak adaptują się certyfikacje

Dostawcy certyfikacji rozwijają trzy szerokie typy poświadczeń.

Certyfikaty wiedzy specyficzne dla narzędzi

Certyfikacja GitHub Copilot firmy Microsoft ocenia odpowiedzialne użytkowanie, funkcje Copilot, architekturę danych, tworzenie kontekstu i promptów, produktywność deweloperów, prywatność, wykluczenia treści i zabezpieczenia. Egzamin jest nadzorowany, trwa sto minut i może zawierać interaktywne komponenty. (learn.microsoft.com)

Ten certyfikat potwierdza użyteczną wiedzę zawodową. Może wykazać, że dana osoba rozumie, jak odpowiedzialnie używać określonej platformy programistycznej.

Jego ograniczeniem jest to, że jest silnie związany z jednym produktem. Profesjonalista, który wie, jak obsługiwać GitHub Copilot, może nadal nie mieć umiejętności rozłożenia złożonego wymagania produktu, zakwestionowania wyboru architektonicznego lub przeglądu zmiany wrażliwej na bezpieczeństwo.

Certyfikaty rozwoju sztucznej inteligencji oparte na platformach

Certyfikacja AWS Certified Generative AI Developer – Professional jest szersza. Jej przewodnik egzaminacyjny obejmuje integrację modeli podstawowych, zarządzanie danymi, zgodność, implementację, agentowe rozwiązania sztucznej inteligencji, bezpieczeństwo, ład korporacyjny, testowanie, rozwiązywanie problemów, monitorowanie i optymalizację. (docs.aws.amazon.com)

Jednak egzamin jest głównie wielokrotnego wyboru i wielokrotnej odpowiedzi. Jest to znaczny test wiedzy, ale nie w pełni demonstruje, czy kandydat potrafi zbudować, przeglądnąć lub obronić działający system. (aws.amazon.com)

To ilustruje szerszy problem: egzaminy wiedzy są łatwiejsze do skalowania niż egzaminy wydajności. Organizacje certyfikujące mogą efektywnie testować terminologię i zasady projektowania, ale praktyczne kompetencje wymagają środowiska, w którym kandydaci muszą podejmować decyzje i radzić sobie z niepowodzeniami.

Certyfikaty oparte na laboratoriach i projektach

Certyfikaty Microsoft Applied Skills oferują bardziej obiecujący model. Wymagają od uczniów wykonania interaktywnych zadań zgodnych z rzeczywistą pracą w ramach oceny laboratoryjnej. Microsoft pozycjonuje te certyfikaty jako dowód, że kandydat potrafi rozwiązywać rzeczywiste wyzwania związane z chmurą i sztuczną inteligencją, a nie tylko przypominać sobie informacje. (learn.microsoft.com)

Program „Agentic Artificial Intelligence Program” edukacji wykonawczej Carnegie Mellon University łączy nauczanie na żywo, kierowane laboratoria, zadania, przepływy pracy z wieloma agentami, ocenę, bariery ochronne, logowanie, obserwowalność i projekt końcowy. (execonline.cs.cmu.edu)

Programy te nie są identyczne z niezależną certyfikacją zawodową, ale wskazują kierunek, w jakim prawdopodobnie podążą certyfikaty:

• Krótsze oceny praktyczne
• Izolowane środowiska deweloperskie
• Realistyczne repozytoria
• Zadania oceny i obserwowalności
• Systemy końcowe
• Ustne lub nagrane wyjaśnienia techniczne
• Dowody odpowiedzialnego użycia narzędzi

Techniki oceny mierzące zrozumienie

Najlepsza strategia oceny nie zakazuje agentów przy każdym zadaniu. Wykorzystuje agentów tam, gdzie odzwierciedlają oni praktykę zawodową, a niektóre czynności rezerwuje do pomiaru niezależnego zrozumienia.

1. Dokumenty specyfikacji i dekompozycji

Przed napisaniem kodu, wymagaj od studentów przedstawienia:

• Problem użytkownika
• Wymagania funkcjonalne
• Wymagania niefunkcjonalne
• Założenia
• Ograniczenia
• Struktury danych
• Interfejsy
• Kryteria akceptacji
• Rozpisanie zadań
• Znane ryzyka

Dokument powinien wyjaśniać, dlaczego problem został podzielony na poszczególne zadania.

To mierzy, czy student rozumie problem, zanim poprosi agenta o jego implementację.

2. Punkty kontrolne planowania agenta

Wymagaj od studentów przedstawienia proponowanego planu agenta przed rozpoczęciem implementacji. Student musi zidentyfikować:

• Które części planu są akceptowalne
• Które części są niekompletne
• Które założenia są niebezpieczne
• Które zadania wymagają zatwierdzenia przez człowieka
• Które testy powinny zostać dodane

Ostateczna ocena powinna nagradzać jakość osądu studenta, a nie długość planu agenta.

3. Oceny przeglądu kodu

Przedstaw studentom repozytorium wygenerowane przez agenta, zawierające celowe defekty. Defekty mogą obejmować:

• Niepoprawną obsługę przypadków brzegowych
• Niebezpieczne uwierzytelnianie
• Słabą obsługę błędów
• Ukryte problemy z wydajnością
• Zduplikowaną logikę
• Niejasne interfejsy
• Niewystarczające testy
• Naruszenia prywatności
• Ryzyka związane z zależnościami

Poproś studentów o sporządzenie recenzji z poziomami ważności, dowodami, proponowanymi poprawkami i testami regresji.

To jest bliższe profesjonalnej pracy z oprogramowaniem niż proszenie studentów o stworzenie kolejnej małej aplikacji od podstaw.

4. Wyjaśnienie zwrotne i obrona ustna

Student powinien być w stanie wyjaśnić:

• Co robi system
• Dlaczego wybrano taką architekturę
• Które części zostały wygenerowane
• Jakie założenia przyjął agent
• Jak testy demonstrują poprawność
• Co nadal może zawieść
• Jakie kompromisy zostały zaakceptowane

Krótka obrona ustna może być prowadzona indywidualnie lub w małych grupach. Nie musi być zastraszająca. Pięć do dziesięciu ukierunkowanych pytań często wystarcza, aby ujawnić, czy student rozumie przedłożony materiał.

5. Zadania transferowe

Po ukończeniu przez studenta projektu wspomaganego przez agenta, przedstaw nowe wymaganie, którego nie da się rozwiązać poprzez proste powtórzenie oryginalnego promptu.

Na przykład:

• Dodanie nowego źródła danych
• Zmiana celu wydajności
• Obsługa nieoczekiwanego formatu wejściowego
• Usunięcie zależności
• Dodanie kontroli dostępu
• Wyjaśnienie nieudanego testu
• Refaktoryzacja modułu bez zmiany jego zachowania

Student może użyć agenta, ale musi wyjaśnić plan, zweryfikować zmiany i obronić wynik.

Zadania transferowe mierzą, czy student nauczył się ogólnej metody, a nie zapamiętał udanej interakcji.

6. Projektowanie testów i testowanie kontrowersyjne

Studenci powinni być oceniani na podstawie jakości swoich testów, a nie tylko tego, czy wygenerowany kod przechodzi dostarczone testy.

Użyteczne wymagania obejmują:

• Pisanie testów brzegowych
• Tworzenie testów negatywnych
• Testowanie nieprawidłowego wejścia
• Testowanie odzyskiwania po awarii
• Sprawdzanie założeń dotyczących wydajności
• Używanie testów opartych na właściwościach, gdzie to stosowne
• Testowanie zachowań wrażliwych na bezpieczeństwo
• Wyjaśnienie, co pozostaje nietestowane

Kluczowe pytanie nie brzmi: „Czy kod przeszedł testy?”, ale „Czy student wiedział, co należy przetestować?”

7. Historia wersji i portfolio procesowe

Portfolio projektu może zawierać:

• Specyfikacja początkowa
• Dekompozycja zadań
• Plany agenta
• Główne prompty lub instrukcje
• Commity
• Wyniki testów
• Komentarze z przeglądu
• Nieudane podejścia
• Zmiany w projekcie
• Końcowa refleksja

Portfolio procesowe nie powinno stać się wymogiem do przedstawiania każdej linii prywatnej rozmowy. Reprezentatywny zapis jest często bardziej użyteczny niż ogromny transkrypt.

Kurs programowania Uniwersytetu Princeton z 2025 roku, na przykład, zezwalał na narzędzia generatywnej sztucznej inteligencji, ale wymagał od studentów opisania ich użycia w pliku readme poprzez reprezentatywne podsumowanie, a nie wyczerpujący transkrypt. (cs.princeton.edu)

8. Ustrukturyzowana ocena wzajemna

Ocena wzajemna zmienia studentów z samych producentów kodu w krytyków kodu. Wczesne badania sugerują, że ocena wzajemna oparta na kryteriach może z umiarkowaną dokładnością przybliżać ocenę instruktora, jednocześnie rozwijając myślenie ewaluacyjne i zaangażowanie. (arxiv.org)

Od studentów powinno się wymagać uzasadniania swoich komentarzy dowodami. „Ten kod jest zły” to nie recenzja. „Ta funkcja wykonuje zapytanie do bazy danych w pętli, tworząc prawdopodobny problem z wydajnością, gdy kolekcja się rozrośnie” to recenzja.

9. Problemy z promptami i specyfikacją

Problemy z promptami to ćwiczenia programistyczne, w których studenci piszą instrukcje w języku naturalnym, które powodują, że system sztucznej inteligencji generuje kod spełniający specyfikację. Podejście to wyraźnie uczy studentów komunikowania wymagań obliczeniowych systemom generującym kod. (arxiv.org)

Może to być przydatne, ale nie powinno być jedyną metodą oceny. Badanie z 2026 roku, obejmujące ponad dziewięciuset studentów, wykazało, że częste błędy obejmowały pomijanie ważnych szczegółów w promptach. Gdy wygenerowany kod zawodził, studenci często skupiali się na wyjaśnianiu swoich intencji, zamiast śledzić kod lub analizować przypadki testowe. (arxiv.org)

Promptowanie może zatem ujawnić umiejętności dekompozycji i komunikacji, ale musi być połączone z czytaniem kodu, testowaniem, debugowaniem i przeglądem.

Przykładowa struktura oceny

Praktyczny projekt mógłby wykorzystywać następujące wagi:

Ta struktura nadal nagradza działający produkt, ale zapobiega uzyskaniu wysokiej oceny przez studenta tylko dlatego, że agent wygenerował dużą bazę kodu.

Rzetelność akademicka w zajęciach wspomaganych agentami

Całkowite zakazy i nieograniczone użycie są niewystarczające

Całkowity zakaz może być odpowiedni dla konkretnej oceny podstawowej, zwłaszcza gdy celem nauczania jest niezależna praktyka programistyczna. Jednak uniwersalny zakaz jest coraz trudniejszy do wyegzekwowania i może uniemożliwić studentom naukę narzędzi, z którymi spotkają się w pracy zawodowej.

Nieograniczone użycie jest również niewystarczające. Jeśli studenci mogą przesyłać prace stworzone przez agenta bez wyjaśnienia, ocena może mierzyć dostęp do narzędzia, a nie naukę.

Najsilniejszym podejściem jest wyraźna polityka na poziomie zadania.

Trzy użyteczne tryby polityki

Tryb pierwszy: Agent zabroniony

Użyj tego dla:

• Egzaminów
• Podstawowych ćwiczeń programistycznych
• Indywidualnych demonstracji debugowania
• Ćwiczeń z podstawowych algorytmów
• Ocen mających na celu mierzenie samodzielnego przypominania sobie lub implementacji

Kurs „Principles of Imperative Computation” Uniwersytetu Carnegie Mellon zabrania używania narzędzi sztucznej inteligencji do jakiejkolwiek części ocenianej pracy, w tym generowania rozwiązań, wyjaśniania rozwiązań, formatowania kodu i generowania przypadków testowych. (cs.cmu.edu)

Tryb drugi: Agent ograniczony

Użyj tego, gdy studenci mogą prosić o:

• Wyjaśnienia koncepcji
• Pomoc z dokumentacją
• Interpretację komunikatów o błędach
• Wyjaśnienie biblioteki lub interfejsu programowania aplikacji
• Burzę mózgów
• Krytykę projektu stworzonego przez studenta
• Drobny refaktoring

Kursy systemowe Carnegie Mellon pozwalają na użycie narzędzi sztucznej inteligencji do zrozumienia interfejsów programowania aplikacji, bibliotek, frameworków, dostarczonego kodu i komunikatów o błędach, jednocześnie zabraniając prośby o częściowe lub pełne rozwiązania zadań. (cs.cmu.edu)

Tryb trzeci: Agent dozwolony z ujawnieniem

Użyj tego do realistycznych projektów inżynierii oprogramowania. Wymagaj od studentów ujawnienia:

• Jakie narzędzia zostały użyte
• Jakie zadania zostały delegowane
• Czy wygenerowany kod został skopiowany, zmodyfikowany lub przepisany
• Jak wynik został przetestowany
• Czego student się nauczył
• Które części projektu pozostają odpowiedzialnością studenta

Wytyczne dotyczące rzetelności naukowej Uniwersytetu Princeton stanowią, że dozwolone użycie sztucznej inteligencji musi być nadal ujawniane, a przedstawianie wygenerowanego wyniku jako własnego lub nieujawnienie jego użycia może stanowić naruszenie rzetelności. (scholarlyintegrity.princeton.edu)

Harvard Graduate School of Education podobnie zezwala na użycie narzędzi AI do celów takich jak wyjaśnianie, burza mózgów i eksploracja, jednocześnie zabraniając studentom przedstawiania pracy generowanej przez sztuczną inteligencję jako własnej. Wymaga również dokumentacji dozwolonego użycia i ostrzega, że studenci pozostają odpowiedzialni za dokładność, prywatność, prawa autorskie i stronniczość. (registrar.gse.harvard.edu)

Praktyczne oświadczenie o ujawnieniu

Kurs może udostępnić prosty szablon:

Użyłem [nazwa narzędzia] do [planowania, debugowania, generowania kodu, testowania, dokumentacji lub przeglądu]. Delegowałem [konkretne zadania]. Przejrzałem i zmodyfikowałem wynik, przetestowałem powstały system i pozostaję odpowiedzialny za dokładność, bezpieczeństwo i oryginalność zgłoszonej pracy.

Studenci nie powinni być zobowiązani do ujawniania zwykłej korekty pisowni w taki sam sposób, jak delegowanej implementacji. Polityka powinna rozróżniać między drobną pomocą a istotnym wkładem poznawczym lub technicznym.

Prywatność i równy dostęp

Instytucje powinny udostępniać zatwierdzone narzędzia lub alternatywy. Studenci nie powinni być zobowiązani do przesyłania poufnych prac, danych osobowych, niepublikowanych badań ani zastrzeżonego kodu do publicznych systemów.

Wytyczne UNESCO wzywają do podejścia skoncentrowanego na człowieku, które uwzględnia prywatność, bezpieczeństwo, równość, włączenie społeczne i gotowość instytucjonalną. (unesco.org)

Kursy powinny również brać pod uwagę studentów, którzy nie mogą sobie pozwolić na kilka płatnych narzędzi. Uczciwy kurs może:

• Dostarczyć wspólne narzędzie instytucjonalne
• Zaoferować lokalną lub open-source'ową alternatywę
• Projektować zadania, które nie zależą od jednego dostawcy
• Oceniać rozumowanie, a nie dostęp do najpotężniejszego modelu
• Umożliwić ścieżki bez agentów dla każdego kluczowego efektu uczenia się

Praktyczne metody produktywnego włączania agentów

Użyj kontrolowanego repozytorium

Daj studentom repozytorium zawierające:

• Przejrzysty plik readme
• Małą, ale realistyczną bazę kodu
• Zautomatyzowane testy
• Przepływ pracy ciągłej integracji
• Listę znanych problemów
• Przewodnik po stylu
• Listę kontrolną bezpieczeństwa
• Dziennik zmian

To sprawia, że użycie agenta jest obserwowalne i daje studentom coś bardziej realistycznego niż puste ćwiczenie z kodowania.

Wymagaj planu przed implementacją

Studenci nie powinni zaczynać od proszenia agenta o „zbudowanie całej aplikacji”. Wymagaj następującej sekwencji:

1. Poproś agenta o sprawdzenie repozytorium.
2. Poproś o podsumowanie architektury.
3. Poproś o ryzyka i brakujące informacje.
4. Napisz własny plan zadań studenta.
5. Zatwierdź jedno małe zadanie implementacyjne.
6. Przejrzyj wynikowe zmiany.
7. Uruchom testy przed kontynuowaniem.

To uczy kontrolowanego delegowania, a nie ślepego delegowania.

Użyj zespołu agentów z jasnymi rolami

Prosty wzorzec orkiestracji może obejmować:

• Planista: proponuje rozpisanie zadań
• Implementator: modyfikuje kod
• Tester: tworzy i uruchamia testy
• Recenzent: szuka defektów i ryzyk
• Ewaluator ludzki: zatwierdza lub odrzuca zmiany

Studenci powinni nauczyć się, że dodawanie kolejnych agentów nie poprawia automatycznie jakości. Więcej agentów może prowadzić do sprzecznych instrukcji, powielania wysiłków, zwiększonych kosztów i niejasnej odpowiedzialności.

Celem edukacyjnym nie jest zbudowanie największego systemu wieloagentowego. Jest nim wybór najprostszego przepływu pracy, który daje wiarygodne wyniki.

Wbuduj bramki zatwierdzania przez człowieka

Wymagaj wyraźnego zatwierdzenia, zanim agent będzie mógł:

• Zmieniać uwierzytelnianie
• Modyfikować schematy danych
• Dodawać zależności
• Uzyskiwać dostęp do systemów produkcyjnych
• Zmieniać konfigurację wdrożenia
• Usuwać pliki
• Łączyć pull request

To uczy studentów, że autonomia musi być ograniczona uprawnieniami i przeglądem.

Celowo oceniaj niepowodzenia

Agenty są najbardziej pouczające, gdy zawodzą w sposób informatywny. Instruktorzy powinni uwzględnić:

• Niejasne wymagania
• Sprzeczne ograniczenia
• Niekompletne testy
• Operacje wrażliwe na bezpieczeństwo
• Wprowadzającą w błąd dokumentację
• Niestabilne testy
• Ograniczenia wydajności
• Zmianę, która wydaje się poprawna, ale psuje inną funkcję

Zadaniem studenta jest zdiagnozowanie awarii i usprawnienie procesu.

Ramy kompetencji na lata 2026-2031

Poniższe ramy zostały zaprojektowane tak, aby pozostały użyteczne nawet w miarę zmian konkretnych narzędzi.

Domena pierwsza: Podstawy techniczne i umiejętność czytania kodu

Kompetentny deweloper potrafi:

• Czytać nieznany kod
• Wyjaśniać przepływ sterowania i przepływ danych
• Rozumieć interfejsy i zależności
• Analizować złożoność algorytmiczną
• Używać kontroli wersji
• Debugować bez całkowitego polegania na agencie

Dowody: wyjaśnienie kodu, zadanie debugowania ręcznego, krytyka projektu i indywidualne ćwiczenie transferowe.

Domena druga: Formułowanie problemu i dekompozycja

Kompetentny deweloper potrafi:

• Wyjaśniać cele użytkownika
• Identyfikować ograniczenia i założenia
• Oddzielać wymagania kluczowe od opcjonalnych
• Dzielić pracę na niezależnie testowalne zadania
• Definiować kryteria akceptacji
• Rozpoznawać, kiedy zadanie jest zbyt szerokie dla wiarygodnego delegowania

Dowody: specyfikacja, graf zadań, rejestr ryzyka i wyjaśnienie wyborów dekompozycji.

Domena trzecia: Kierowanie agentem i inżynieria kontekstu

Kompetentny deweloper potrafi:

• Dostarczać odpowiedni kontekst repozytorium
• Dawać precyzyjne instrukcje
• Definiować granice i uprawnienia
• Wybierać, kiedy używać agenta, a kiedy nie
• Porównywać alternatywne plany
• Odzyskiwać kontrolę, gdy agent postępuje zgodnie z błędną interpretacją

Dowody: punkty kontrolne planowania, reprezentatywne zapisy interakcji i zadanie rewizji na żywo.

Domena czwarta: Weryfikacja i przegląd

Kompetentny deweloper potrafi:

• Przeglądać wygenerowany kod
• Projektować sensowne testy
• Identyfikować ukryte założenia
• Przeglądać ryzyka bezpieczeństwa i prywatności
• Oceniać łatwość utrzymania
• Wyjaśniać, czego testy nie dowodzą

Dowody: przegląd kodu, testy kontrowersyjne, ćwiczenie znajdowania defektów i obrona ustna.

Domena piąta: Orkiestracja i operacje

Kompetentny deweloper potrafi:

• Koordynować narzędzia do planowania, implementacji, testowania i przeglądu
• Używać punktów kontrolnych i bramek zatwierdzania przez człowieka
• Śledzić koszty, czas i zachowanie narzędzi
• Utrzymywać powtarzalne przepływy pracy
• Obserwować awarie i ulepszać system
• Decydować, czy wielu agentów dodaje wartość

Dowody: działający przepływ pracy orkiestracji, logi, raport z oceny oraz analiza kosztów lub wydajności.

Domena szósta: Projektowanie produktu i systemów

Kompetentny deweloper potrafi:

• Wybrać odpowiedni poziom automatyzacji
• Projektować systemy modułowe
• Balansować prędkość, jakość, koszt i ryzyko
• Łączyć decyzje techniczne z wynikami dla użytkownika
• Rozpoznawać, kiedy proste rozwiązanie bez agenta jest lepsze

Dowody: brief produktu, zapis decyzji architektonicznej, prototyp i demonstracja skoncentrowana na użytkowniku.

Domena siódma: Odpowiedzialna praktyka zawodowa

Kompetentny deweloper potrafi:

• Ujawniać pomoc sztucznej inteligencji
• Chronić informacje prywatne i zastrzeżone
• Szanować prawa autorskie i obowiązki licencyjne
• Identyfikować ryzyka stronniczości i niezawodności
• Komunikować niepewność
• Akceptować odpowiedzialność za końcowy system

Dowody: oświadczenie o ujawnieniu, ocena ryzyka, przegląd prywatności i profesjonalna prezentacja.

Sugerowane poziomy biegłości

Do 2031 roku profesjonalny certyfikat powinien świadczyć o przejściu przez te poziomy, a nie tylko potwierdzać znajomość konkretnego narzędzia programistycznego.

Rekomendacje dla różnych interesariuszy

Uniwersytety

• Dodawać moduły inżynierii oprogramowania uwzględniające agentów do istniejących kursów.
• Zachować podstawy programowania i algorytmiki.
• Zastąpić niektóre zadania generowania kodu zadaniami przeglądu i transferowymi.
• Wymagać od studentów wyjaśniania i obrony ważnych prac.
• Szkolić kadrę w zakresie narzędzi agentowych, projektowania oceny, prywatności i polityki rzetelności.
• Tworzyć współdzielone repozytoria i środowiska sandbox.

Bootcampy

• Uczyć konwencjonalnego rozwoju i rozwoju wspomaganego agentami razem.
• Uczynić testowanie, architekturę i bezpieczeństwo centralnymi elementami programu nauczania.
• Wymagać projektów portfolio z zapisami procesów.
• Dodać demonstracje techniczne na żywo.
• Uczyć odkrywania produktu i pisania wymagań.
• Unikać obiecywania, że samo promptowanie tworzy inżynierów gotowych do pracy.

Dostawcy certyfikacji

• Zwiększyć wykorzystanie ocen laboratoryjnych.
• Włączyć przegląd kodu, testowanie, debugowanie i analizę zagrożeń.
• Używać realistycznych repozytoriów zamiast izolowanych pytań wielokrotnego wyboru.
• Testować osąd niezależny od narzędzi.
• Dodać krótkie ustne wyjaśnienia lub nagrane demonstracje.
• Często odświeżać zawartość, nie uzależniając certyfikatu od interfejsu jednego dostawcy.

Instruktorzy

• Precyzyjnie określić, co jest dozwolone w każdej ocenie.
• Projektować zadania wokół zamierzonego efektu uczenia się.
• Dostarczać studentom zatwierdzone narzędzia lub równoważne alternatywy.
• Oceniać proces, rozumowanie i weryfikację.
• Używać logów jako dowodów, a nie jako jedynego potwierdzenia.
• Unikać polegania na oprogramowaniu do wykrywania sztucznej inteligencji jako głównym mechanizmie zapewnienia rzetelności.

Uczniowie i twórcy produktów

• Nauczyć się wystarczająco dużo konwencjonalnego programowania, aby czytać i kwestionować wygenerowany kod.
• Zacząć od małego produktu, zamiast od niejasnej, dużej aplikacji.
• Napisać specyfikację przed uruchomieniem agenta.
• Delegować jedno zagadnienie na raz.
• Przeglądać każdą zmianę i testować każde założenie.
• Prowadzić zapis ważnych decyzji.
• Traktować agenta jako szybkiego młodszego współpracownika, a nie niekwestionowanego eksperta.

Pierwszy kolejny krok

Dla kogoś, kto rozpoczyna podróż tworzenia produktu, najbardziej użytecznym pierwszym krokiem jest:

Wybierz jeden mały problem użytkownika i napisz jednostronicową specyfikację, zanim poprosisz agenta o napisanie kodu.

Uwzględnij:

• Kim jest użytkownik
• Jaki problem mają
• Co musi robić pierwsza wersja
• Czego nie może robić
• Trzy testy akceptacyjne
• Jedno ważne zagadnienie bezpieczeństwa lub prywatności
• Trzy małe zadania implementacyjne

Następnie poproś agenta o przejrzenie specyfikacji i zidentyfikowanie brakujących wymagań, a nie o zbudowanie całego produktu.

Po poprawieniu specyfikacji, deleguj tylko pierwsze zadanie. Przejrzyj proponowany plan, sprawdź zmiany, uruchom testy i zapisz, co agent zrobił źle.

To pojedyncze ćwiczenie uczy najważniejszej lekcji ery agentów: jakość wyniku zależy mniej od tego, ile kodu agent może wyprodukować, niż od tego, jak jasno człowiek definiuje, nadzoruje i ocenia pracę.

Podsumowanie

Edukacja deweloperów zmierza w kierunku nowej równowagi.

Studenci nadal będą musieli pisać kod, zwłaszcza podczas nauki podstawowych koncepcji. Ale profesjonalne kompetencje będą coraz częściej demonstrowane poprzez dekompozycję problemów, specyfikację, zrozumienie kodu, przegląd, testowanie, orkiestrację, osąd produktu i odpowiedzialne wykorzystanie autonomicznych systemów.

Najlepsze programy nauczania nie będą traktować agentów kodujących ani jako maszyn do oszukiwania, ani jako magicznych korepetytorów. Będą je traktować jako potężne, ale omylne narzędzia inżynierskie. Studenci nauczą się, kiedy ich używać, jak je ograniczać, jak oceniać ich wyniki i jak wziąć odpowiedzialność za końcowy system.

Najbardziej trwałym deweloperem w ciągu najbliższych pięciu lat nie będzie osoba, która potrafi ręcznie wyprodukować najwięcej kodu lub wygenerować najdłuższy prompt. Będzie to osoba, która potrafi przekształcić niejasny cel w niezawodny proces, pokierować kilkoma narzędziami w kierunku tego celu, wcześnie wykryć błąd i wyjaśnić, dlaczego powstałe oprogramowanie zasługuje na zaufanie.