Jak połączyć sztuczną inteligencję z metodą projektu na lekcjach informatyki

Realna sytuacja na lekcji informatyki wygląda często tak: część uczniów już używa narzędzi AI do pisania kodu, streszczeń i opisów, część ma ograniczony dostęp (brak konta, blokady, słabszy sprzęt), a nauczyciel musi jednocześnie utrzymać sensowny poziom nauki, uczciwość oceniania i bezpieczeństwo danych. Metoda projektu (PBL) świetnie do tego pasuje, ale tylko wtedy, gdy projekt ma barierki: jasne etapy, obowiązkowe artefakty, kontrolę procesu i standard weryfikacji odpowiedzi AI.

Najczęstsze „wykolejenia” w projektach z AI są przewidywalne: uczniowie oddają ładnie brzmiący opis bez działającego rozwiązania, jedna osoba „obsługuje AI” za całą grupę, powstaje kod, którego nikt nie rozumie, a halucynacje modelu wchodzą do pracy jako fakty. Da się temu zapobiec, jeśli AI potraktujesz jako narzędzie wspierające proces (analiza → decyzje → implementacja → testy → refleksja), a nie jako wykonawcę produktu.

Poniżej jest zestaw praktycznych wskazówek, które da się wdrożyć w typowych warunkach szkolnych (również w wariancie „minimum”: jedno konto nauczyciela, rotacyjny dostęp, a nawet praca częściowo offline). Każda wskazówka ma: cel, przykład i scenariusz „co może pójść nie tak” wraz z zabezpieczeniem.

AI w edukacji informatycznej, metoda projektu informatyka, ocenianie projektów z AI, kontrakt na użycie AI, weryfikacja odpowiedzi AI, promptbook ucznia, artefakty projektu szkolnego, praca w grupie a AI, halucynacje modeli językowych, prywatność danych uczniów, rubryka oceniania PBL, projekty programistyczne z AI

Sytuacja startowa: AI już jest w klasie, więc projekt musi mieć „barierki”

Trzy typowe scenariusze, które psują projekt

Scenariusz 1: „Tekst zamiast rozwiązania”. Uczniowie oddają obszerny opis (często wygenerowany), ale brakuje uruchamialnego kodu, danych testowych, zrzutów działania czy repozytorium. W informatyce to szczególnie groźne, bo da się „zalać” ocenianie narracją.

Scenariusz 2: „Jedna osoba robi wszystko”. W grupie jedna osoba ma najszybszy dostęp do AI i „dowozi”, reszta traci kontakt z projektem. Efekt: słaba współpraca, brak uczenia się, konflikt o ocenę.

Scenariusz 3: „AI mówi pewnym tonem, więc to prawda”. W projekcie pojawiają się nieistniejące biblioteki, błędne API, zmyślone definicje, a uczniowie nie mają nawyku sprawdzania. Projekt działa „na prezentacji”, ale nie przechodzi prostych testów.

Zasada przewodnia: AI wspiera decyzje i weryfikację, nie zastępuje myślenia

Najbezpieczniej działa podejście: AI jako asystent procesu. Uczeń ma podejmować decyzje projektowe (co budujemy, jakie ograniczenia, jakie testy), a AI ma pomagać: proponować warianty, wskazywać ryzyka, recenzować, generować testy, tłumaczyć błędy. Jeśli AI tworzy „całość” (np. cały kod aplikacji), to projekt staje się pokazem promptowania, a nie nauką informatyki.

To podejście ułatwia też ocenę: ocenia się artefakty procesu (karta projektu, log testów, historia commitów, decyzje), a nie tylko efekt końcowy, który AI potrafi „dopompować” w godzinę.

Dwa warianty organizacyjne: pełny dostęp vs. „minimum”

Wariant pełny: uczniowie mają dostęp do narzędzi AI (indywidualnie lub szkolnie), mogą pracować w domu i w klasie, a nauczyciel zarządza zasadami (kontrakt) oraz dowodami pracy (artefakty).

Wariant minimum przydaje się tam, gdzie są ograniczenia prawne/organizacyjne: brak kont uczniów, brak zgód rodziców, słaby internet. Wtedy AI może działać jako „stacja konsultacyjna” (jedno konto nauczyciela, rotacyjna kolejka) albo jako narzędzie używane wyłącznie do zadań neutralnych (bez danych osobowych, bez wklejania prac uczniów). Projekt nadal może być PBL, tylko rola AI jest bardziej kontrolowana.

Wskazówka 1 — Dobierz temat tak, by wynik był weryfikowalny bez „wiary w AI”

Szybki filtr wyboru tematu projektu (3 pytania)

Temat nadaje się do projektu z AI, jeśli przechodzi trzy proste testy:

• Czy istnieje artefakt techniczny do sprawdzenia? (kod uruchamialny, model bazy danych, prototyp UI z logiką, zestaw danych + analiza)
• Czy da się przygotować testy albo scenariusze użycia, które pokażą „działa/nie działa”?
• Czy uczeń musi podjąć decyzje (architektura, wymagania, priorytety), a nie tylko „wygenerować treść”?

Jeśli odpowiedź brzmi „nie”, temat zwykle kończy się kopiuj-wklej z AI i ocenianiem stylu, a nie kompetencji informatycznych.

Przykłady tematów, które dobrze „trzymają” weryfikację

• Aplikacja webowa „Plan nauki”: logowanie lokalne (bez danych prawdziwych), dodawanie zadań, przypomnienia, eksport do pliku. Wymagane: repozytorium, testy, dane przykładowe, instrukcja uruchomienia.
• Baza danych „Biblioteka szkolna”: model ERD, relacje, klucze, 10 zapytań SQL (w tym agregacje), opis normalizacji. Wymagane: skrypt tworzący bazę + dane testowe.
• Analiza danych „Jakość powietrza/hałas/temperatura”: wczytanie CSV, czyszczenie danych, wykresy, wnioski oparte o obliczenia. Wymagane: notebook, źródło danych, testy sanity check.
• Cyberbezpieczeństwo (edukacyjnie): audyt ustawień prywatności i haseł w środowisku testowym, polityka haseł, menedżer haseł (symulacja), raport ryzyk. Wymagane: lista rekomendacji + uzasadnienie + test w środowisku szkolnym (bez wchodzenia w działania nielegalne).

Co może pójść nie tak: „Projekt o AI” zamiast projektu z AI

Temat typu „prezentacja o sztucznej inteligencji” prawie zawsze kończy się generowaniem slajdów i definicji. Jeśli taki temat ma sens, to tylko z twardym wymaganiem informatycznym, np. stworzenie interaktywnego demo (miniaplikacja, chatbot w środowisku edukacyjnym, klasyfikacja danych w prostym modelu) oraz testów i opisu ograniczeń.

Zabezpieczenie: wpisz w kryteria zaliczenia element „działa lub nie działa” oraz demonstrację na danych testowych przygotowanych przez nauczyciela (uczniowie nie znają ich wcześniej).

Wskazówka 2 — Podziel projekt na krótkie etapy z checkpointami i obowiązkowymi dowodami pracy

Rytm, który działa w szkole: 4 checkpointy zamiast „oddajcie za miesiąc”

Metoda projektu na informatyce wygrywa wtedy, gdy proces jest widoczny. Cztery checkpointy są proste do utrzymania nawet przy 1–2 godzinach tygodniowo:

1. Start: karta projektu + cele + ograniczenia + Definition of Done.
2. Analiza i projekt: wymagania + makiety/prototyp + plan testów.
3. Implementacja iteracyjna: przyrost funkcji + historia zmian + notatki decyzji.
4. Weryfikacja i prezentacja: testy, poprawki, peer review, demonstracja.

W każdym checkpointcie uczeń ma oddać artefakt, którego nie da się sensownie „udawać” samym tekstem.

Przykładowe artefakty na każdym etapie (do skopiowania jako wymagania)

• Karta projektu: problem, użytkownik, zakres (co robimy / czego nie robimy), ryzyka, zasoby, plan.
• Definition of Done: lista warunków zaliczenia (uruchomienie, funkcje, testy, dokumentacja, atrybucje).
• Prototyp UI: makiety ekranów + opis stanów (np. błędy walidacji, pusta lista, brak internetu).
• Plan testów: min. 5 przypadków (w tym 2 brzegowe) + oczekiwane wyniki.
• Repozytorium (nawet lokalne): historia commitów lub dziennik zmian, żeby było widać iteracje.
• Log decyzji: „co zmieniliśmy i dlaczego” (szczególnie gdy AI coś zasugerowało).

Co może pójść nie tak: „zrobimy wszystko na koniec”

Uczniowie często odkładają implementację, bo AI daje złudzenie, że „przecież wygenerujemy później”. Wtedy na finiszu wychodzą błędy, brak testów i chaos w grupie.

Zabezpieczenie: brak zaliczenia bez checkpointów oraz ocena procesu (artefakty, iteracje, testy). Dodatkowo: krótkie 3–5 minutowe przeglądy w trakcie lekcji, gdzie zespół pokazuje aktualny stan (nie opowiada, tylko pokazuje).

Wskazówka 3 — Zamiast „użyjcie AI” wprowadź role AI: konsultant, recenzent, debugger, generator testów

Jak przypisać rolę AI do etapu projektu

AI ma największy sens, gdy uczniowie dostają jasny kontekst: po co pytają model i co mają zrobić z odpowiedzią. Poniżej sprawdzony podział ról:

• Konsultant analizy: pomaga doprecyzować wymagania, użytkownika, ograniczenia, kryteria akceptacji.
• Recenzent: sprawdza spójność wymagań, kompletność stanów UI, sens relacji w bazie.
• Debugger: pomaga zrozumieć błąd na podstawie komunikatu i minimalnego przykładu (MRE).
• Generator testów: proponuje przypadki brzegowe i dane testowe, które uczeń uruchamia i dokumentuje.

Takie role ograniczają zjawisko „AI zrobi wszystko”, bo uczniowie mają korzystać z AI w konkretnym miejscu procesu, a nie zastępować nim całość pracy.

Wzorce promptów (bez „magicznych formułek”), które wymuszają myślenie

Prompty powinny wymagać od AI uzasadnienia i wariantów, a od ucznia decyzji:

• Do wymagań: „Zadaj mi 10 pytań doprecyzowujących wymagania aplikacji X. Potem zaproponuj 2 wersje zakresu: minimalny i rozszerzony. Nie pisz kodu.”
• Do recenzji: „Oceń spójność mojej listy wymagań i wskaż sprzeczności, braki, niejednoznaczności. Zaproponuj kryteria akceptacji dla 5 kluczowych funkcji.”
• Do testów: „Dla funkcji Y zaproponuj przypadki testowe, w tym brzegowe i negatywne. Podaj dane wejściowe i oczekiwane wyniki.”
• Do debugowania: „Mam błąd: [komunikat]. Poniżej minimalny kod, który go wywołuje. Zaproponuj 3 hipotezy i kroki weryfikacji, zanim zasugerujesz zmianę kodu.”

Jeśli uczeń wkleja „zrób mi aplikację”, to projekt jest przegrany na starcie. Rola AI ma zawężać odpowiedź do tego, co uczeń potrafi sprawdzić.

Co może pójść nie tak: AI wymyśli biblioteki i „pewne” rozwiązania

Modele językowe potrafią tworzyć wiarygodnie brzmiące, ale fałszywe API albo parametry. Uczeń skopiuje kod, kompilator krzyczy, a zespół traci czas.

Zabezpieczenie: zasada klasowa: każde twierdzenie AI o składni/API wymaga potwierdzenia w dokumentacji lub testem uruchomieniowym. W praktyce: link do dokumentacji w notatkach zespołu albo zrzut działania testu.

Wskazówka 4 — Naucz minimalnego standardu weryfikacji AI (bez tego projekt się rozsypie)

Procedura „sprawdź zanim zaufasz” w 3 krokach

Weryfikacja nie musi być akademicka. Wystarczy prosty nawyk:

1. Sprawdź na przykładzie: uruchom, policz, przetestuj na danych.
2. Porównaj z dokumentacją/źródłem: oficjalna dokumentacja, podręcznik, materiał kursowy, specyfikacja zadania.
3. Dodaj test lub sanity check: test jednostkowy, sprawdzenie brzegów, walidacja danych.

Jeśli uczniowie robią tylko krok 1, a pomijają 2 i 3, halucynacje wrócą w innym miejscu.

Przykład zadania projektowego: AI generuje funkcję, uczeń broni jej testami

W projekcie programistycznym daj uczniom jasny schemat: AI może zaproponować implementację funkcji (np. filtrowanie listy, walidacja formularza), ale zaliczenie jest dopiero wtedy, gdy uczeń:

• dopisze co najmniej 5 testów (w tym pusta lista, dane niepoprawne, duplikaty),
• opisze dlaczego ten algorytm (np. złożoność, czytelność, ograniczenia),
• wskaże co zmienił w propozycji AI i czemu.

To przenosi ciężar z „generowania” na „rozumienie i kontrolę jakości”.

Praktyczny standard „minimum weryfikacji” da się ubrać w prostą rubrykę: co sprawdziłem, jak sprawdziłem, jaki jest wynik. Jeśli uczeń wkleił kod, ale nie potrafi wskazać testu ani warunku brzegowego, to nie jest „użycie narzędzia”, tylko oddanie odpowiedzi na wiarę. Z kolei jeśli potrafi pokazać, że funkcja zachowuje się poprawnie dla typowych danych i dla dwóch „trudnych” przypadków, to nawet średnio eleganckie rozwiązanie jest do obrony.

Działa też mały rytuał na lekcji: „pokaż błąd i pokaż dowód naprawy”. Najpierw reprodukcja problemu (krótki opis + input + wynik), potem minimalna zmiana, potem ponowne uruchomienie testu. AI może pomóc znaleźć hipotezy, ale dowodem jest dopiero uruchomienie albo test. W projektach webowych takim dowodem bywa też screen z konsoli i link do commita; w bazach danych — zapytanie, które zwraca oczekiwane rekordy na przygotowanym zestawie.

Jeśli uczniowie mają słabszy warsztat, ułatwia sprawę zasada „jedna rzecz na raz”: AI może wygenerować fragment, ale uczeń musi umieć go zawęzić do małej, testowalnej funkcji. Zamiast „zrób mi całą aplikację do fiszek” — „napisz funkcję, która losuje 10 różnych pytań z listy, a potem dopiszemy UI”. Zależnie od języka, testem może być prosty zestaw asercji lub ręczny scenariusz z dokładnie opisanym wejściem i wyjściem.

Najbardziej „szkolny” sygnał ostrzegawczy: odpowiedź AI wygląda świetnie, ale zespół nie umie powiedzieć, co by się stało, gdy… (gdy lista jest pusta, gdy plik ma zły format, gdy użytkownik wpisze spację, gdy brak internetu). Wtedy wraca się do trzeciego kroku procedury: dopisać sanity check albo test negatywny. Bez tego projekt z AI rozjedzie się przy pierwszej prezentacji, bo demo zawsze trafia na stan, którego nikt nie przewidział.

Jeśli proces ma „barierki” (checkpointy, role AI, dowody weryfikacji), AI przestaje być skrótem do oddania pracy, a staje się akceleratorem nauki: szybciej dochodzi się do działającego prototypu, ale ciężar zaliczenia nadal leży w decyzjach, testach i umiejętności pokazania, że rozwiązanie działa w warunkach, które nie wybaczają zgadywania.

Wskazówka 5 — Wymuś jawność użycia AI: kontrakt klasowy + promptbook zamiast polowania na plagiat

Kontrakt na 10 minut, który oszczędza godziny rozmów

Jeśli AI jest dozwolone, to największym problemem przestaje być „czy ktoś użył”, a zaczyna się: czy zespół umie pokazać, jak użył i co z tego wynika. Prosty kontrakt działa lepiej niż straszenie wykrywaczami.

• Jawność: każde użycie AI musi zostawić ślad (prompt + odpowiedź + decyzja zespołu).
• Zakaz danych wrażliwych: nie wklejamy danych osobowych, loginów, nazwisk, numerów, realnych treści z dziennika/wiadomości itp.
• Odpowiedzialność: AI nie jest źródłem prawdy; odpowiedzialność za poprawność i zgodność z wymaganiami jest po stronie zespołu.
• Atrybucja: jeśli AI pomogła w kodzie/tekście/grafice — zaznaczamy to w dokumentacji projektu.
• Zakres dozwolony: np. generowanie pomysłów, testów, refaktoryzacja, tłumaczenie, redakcja opisu; a nie: oddanie całego rozwiązania bez weryfikacji.

Kontrakt warto wkleić do karty projektu i traktować jak wymaganie: brak jawności = brak zaliczenia procesu, nawet jeśli produkt „działa”.

Promptbook: prosty szablon, który „wymusza” myślenie

Promptbook to nie pamiętnik. To dowód pracy i narzędzie kontroli jakości. Wystarczy jedna strona (w dokumencie, zeszycie lub repozytorium), prowadzona na bieżąco.

• Kontekst: nad czym pracujemy (funkcja/moduł/wymaganie), jakie są ograniczenia (język, biblioteki, wersje).
• Prompt: treść pytania do AI (bez danych wrażliwych).
• Odpowiedź (skrót): 3–5 zdań streszczenia, bez wklejania ściany tekstu.
• Decyzja: co bierzemy, co odrzucamy i dlaczego.
• Weryfikacja: link do testu/commita/zrzutu działania lub opis sanity check.

To zdejmuje presję z nauczyciela: nie trzeba udowadniać, że „to AI”. Wystarczy sprawdzić, czy zespół umie przejść ścieżkę: pytanie → decyzja → weryfikacja.

Co może pójść nie tak: promptbook jako „kopiuj-wklej” bez sensu

Zdarza się, że uczniowie wklejają losowe prompty po fakcie, żeby wyglądało na proces. Sygnał: brak decyzji, brak powiązania z commitem, brak testu, odpowiedzi nie pasują do kodu.

Zabezpieczenie: w checkpointach sprawdzaj spójność: jeden wpis z promptbooka ma wskazywać na konkretną zmianę w projekcie (commit, plik, fragment dokumentacji) i na test lub demonstrację. Jeśli tego nie ma, wpis nie liczy się jako dowód pracy.

Wskazówka 6 — Zdefiniuj „Definition of Done”, tak by tekst z AI nie wystarczył do zaliczenia

Warunki zaliczenia, które są odporne na „ładny opis”

Definition of Done (DoD) w projektach z AI powinno mieć twarde kryteria obserwowalne. Chodzi o to, żeby nie dało się przejść projektu bez uruchomienia, testów i decyzji.

• Działa w scenariuszu demo: zespół ma gotowy 2–3 minutowy przebieg pokazujący kluczową funkcję.
• Obsługuje błędy: co najmniej 2 stany „nieidealne” (np. puste dane, zły format, brak połączenia) mają przewidzianą reakcję.
• Testy lub checklista testowa: minimalny zestaw (np. 5 przypadków + 2 brzegowe), wykonany i opisany.
• Dokumentacja techniczna: instrukcja uruchomienia + opis struktury (pliki, moduły, baza).
• Atrybucje i jawność AI: gdzie AI pomogła i jak to zweryfikowano.

Jeśli DoD zawiera „opis działania” bez wymogu uruchomienia i testów, to AI przejmie projekt. Jeśli zawiera uruchomienie + testy + dowody zmian, AI staje się tylko narzędziem.

Przykład DoD dla miniaplikacji webowej (do wklejenia uczniom)

• Aplikacja uruchamia się lokalnie zgodnie z instrukcją (jeden zespół uruchamia na innym komputerze lub w innym profilu).
• Minimum 3 funkcje działają (np. dodaj/usuń/filtruj) i są pokazane w demo.
• Minimum 7 testów lub scenariuszy testowych, w tym: puste wejście, zły format, duplikat.
• Co najmniej 2 poprawki po feedbacku (zapisane w logu decyzji: „co było nie tak” → „co zmieniliśmy”).
• Promptbook zawiera min. 5 wpisów, z czego 3 mają link do commita lub wskazanie pliku i testu.

Co może pójść nie tak: uczeń „przepisuje” DoD na papierze

Zespół potrafi opowiedzieć, że „ma testy”, ale nie potrafi ich uruchomić. Albo „ma obsługę błędów”, tylko nikt nie sprawdził tego na realnym wejściu.

Zabezpieczenie: demo nie jest prezentacją slajdów. Demo to kliknięcia i wyniki. Dobre, krótkie kryterium: „pokaż dwa błędy, które obsługujesz” (np. pusty formularz i plik o złym formacie) oraz „uruchom jeden test na żywo” lub pokaż wynik z narzędzia testowego.

Wskazówka 7 — Oceniaj proces, nie tylko produkt: rubryka + ślady wkładu indywidualnego

Rubryka, która ogranicza „pasażera na gapę” i chaos w grupie

AI potrafi wygładzić końcowy efekt, więc sama jakość produktu przestaje mówić prawdę o nauce. Ocena procesu rozwiązuje dwa problemy naraz: nierówny wkład w grupie i „oddanie z AI”.

• Planowanie i zakres: karta projektu + ryzyka + DoD (czy są konkretne i spójne).
• Iteracje: co najmniej 2–3 wyraźne kroki rozwoju (commit/dziennik zmian, wersje prototypu).
• Jakość techniczna: testy, obsługa błędów, czytelność, zgodność z wymaganiami.
• Weryfikacja AI: czy są dowody „sprawdź zanim zaufasz” (testy, linki do dokumentacji, sanity check).
• Wkład indywidualny: każdy uczeń pokazuje 1–2 własne elementy (kod, test, fragment bazy, poprawka po review) i potrafi je obronić.

Szybka metoda na wkład indywidualny: „obrona modułu”

Na koniec projektu każdy uczeń dostaje 2–3 minuty na krótką obronę tego, co robił. Pytania są konkretne i sprawdzają rozumienie, nie pamięć:

• „Pokaż plik/funkcję, za którą odpowiadałeś. Jakie miała wymagania?”
• „Jakie są dwa przypadki brzegowe i jak je testujesz?”
• „Co AI zasugerowała, czego nie przyjęliście — i dlaczego?”

Jeśli uczeń nie umie przejść przez własny fragment, to jest jasny sygnał do korekty oceny, bez teatralnego „wykrywania AI”.

Co może pójść nie tak: świetny projekt, słaba nauka

Zdarza się, że projekt wygląda imponująco, ale w środku jest nieczytelny, bez testów, a decyzje są przypadkowe. AI często to maskuje, bo generuje spójnie brzmiące opisy i komentarze.

Zabezpieczenie: w rubryce ustaw „twardą bramkę”: bez testów i bez dowodów weryfikacji AI projekt nie może dostać najwyższej oceny, nawet jeśli demo wyszło. To przesuwa motywację na to, co edukacyjnie istotne.

Jeśli uczniowie wiedzą, że liczy się uruchomienie, testy, decyzje i obrona, to AI przestaje być skrótem, a staje się wsparciem. I dokładnie o to chodzi w metodzie projektu na informatyce: produkt jest ważny, ale jest tylko nośnikiem umiejętności.

Wskazówka 8 — Zaplanuj „tryb awaryjny”: projekt ma działać także bez kont, internetu i równego dostępu

Minimum organizacyjne, które ratuje lekcję

Jeśli dostęp do AI jest nierówny (brak kont, zgód, słaby sprzęt, zrywający internet), projekt łatwo zamienia się w frustrację. Rozwiązaniem jest prosty warunek brzegowy: każdy etap musi mieć wariant A (z AI) i wariant B (bez AI). Wtedy AI jest przyspieszeniem, nie „przepustką” do zaliczenia.

• Wariant bez AI: uczniowie mogą wykonać zadanie na podstawie krótkich materiałów startowych (szablon repo, fragmenty dokumentacji, checklista testów).
• Wariant z AI: AI służy do generowania alternatyw, sprawdzania hipotez, propozycji testów, refaktoryzacji i redakcji dokumentacji — ale wynik i tak musi przejść te same checkpointy.
• Artefakt niezależny od narzędzia: każdy zespół oddaje to samo (np. testy, log decyzji, demo), niezależnie od tego, czy AI było dostępne.

Przykład: gdy część klasy nie ma dostępu do czatu

Ten sam etap „projekt API i przypadki testowe” można rozegrać dwiema ścieżkami:

• Bez AI: dostają 8 gotowych przykładów zapytań/odpowiedzi i mają dopisać 5 kolejnych (w tym 2 brzegowe) + uzasadnić, które wymagania pokrywają.
• Z AI: proszą AI o propozycje przypadków brzegowych, a potem wybierają 5 i dopisują uzasadnienie + ręcznie weryfikują na swoim prototypie.

W obu ścieżkach ocenie podlega to samo: jakość testów i związek z wymaganiami, nie „spryt promptu”.

Co może pójść nie tak: AI staje się „nagrodą” dla lepiej wyposażonych

Jeśli projekt wymaga użycia jednego konkretnego narzędzia AI, uczniowie z gorszym dostępem przegrywają organizacyjnie, a nie merytorycznie.

Zabezpieczenie: ustaw zasadę: brak AI nie może blokować realizacji podstawowych wymagań. Jeśli chcesz premiować użycie AI, premiuj je w rubryce jako „optymalizację procesu” (np. lepsze testy, lepsza dokumentacja), a nie jako warunek zaliczenia.

Wskazówka 9 — Ustal zasady danych i licencji: co wolno wkleić do AI i jak opisywać źródła

Trzy kategorie danych, które uczniowie rozumieją

Najwięcej ryzyk w projektach z AI nie dotyczy „oszustwa”, tylko nieświadomego ujawniania informacji albo łamania licencji. Prosty podział porządkuje temat i daje podstawę do szybkich decyzji w trakcie pracy.

• Zielone (OK): własny kod napisany na lekcji, ogólne opisy problemu, dane testowe sztuczne/anonimowe, publiczna dokumentacja narzędzi i bibliotek.
• Żółte (ostrożnie): fragmenty cudzych materiałów (np. znalezione w sieci) — tylko z linkiem do źródła i po sprawdzeniu licencji; screeny interfejsu aplikacji — tylko jeśli nie zawierają danych osobowych.
• Czerwone (zakaz): dane osobowe, loginy, hasła, identyfikatory kont, realne treści rozmów i dzienników, skany dokumentów, niepubliczne materiały szkolne, wyniki uczniów, jakiekolwiek dane pozwalające kogoś zidentyfikować.

Jeśli projekt dotyka danych (np. analiza ankiety, rejestr uczniów, baza kontaktów), lepiej z góry narzucić: pracujemy na danych syntetycznych, a realne dane są poza zakresem.

Atrybucja w praktyce: jedno miejsce w repozytorium

Nie trzeba tworzyć rozbudowanej dokumentacji prawnej. Wystarcza krótki plik AI_AND_SOURCES.md lub sekcja w README z dwoma blokami:

• Źródła: linki do bibliotek, tutoriali, fragmentów kodu (jeśli użyte) + informacja o licencji, jeśli jest istotna.
• Użycie AI: 5–10 linijek: do czego użyto AI (np. „propozycje testów”, „refaktoryzacja funkcji X”), oraz jak to zweryfikowano (testy, uruchomienie, porównanie z dokumentacją).

To działa także wychowawczo: uczniowie uczą się, że „wzięte z internetu” i „wygenerowane” też wymaga opisu pochodzenia.

Co może pójść nie tak: „AI powiedziała, że to wolno”

Modele potrafią z dużą pewnością udzielać złych porad prawnych i licencyjnych. Uczeń w dobrej wierze skopiuje rozwiązanie, które wygląda na „otwarte”, a nie jest.

Zabezpieczenie: w kontrakcie dopisz prostą regułę: AI nie jest autorytetem od licencji. Jeśli zespół nie potrafi wskazać źródła i warunków użycia, traktujemy element jako „niepewny” i nie wchodzi do finalnej wersji.

Wskazówka 10 — Wpleć „recenzję krzyżową” i testy generowane przez AI, ale z odpowiedzialnością po stronie ucznia

Peer review + AI: dwa filtry zamiast jednego

W projektach uczniowskich błędy zwykle nie wynikają z „braku pomysłu”, tylko z braku sprawdzenia. AI może pomóc wygenerować testy i listy kontrolne, a recenzja krzyżowa sprawdza, czy to ma sens w realnym kodzie i wymaganiach.

• AI jako generator: „zaproponuj testy dla funkcji X, uwzględnij przypadki brzegowe i błędy wejścia”.
• Uczeń jako selekcjoner: wybiera testy, usuwa nietrafione, dopisuje brakujące i mapuje je na wymagania.
• Drugi zespół jako recenzent: sprawdza, czy testy faktycznie pokrywają DoD i czy da się je uruchomić.

Mini-procedura na 15 minut (działa w większości klas)

Żeby recenzja nie zamieniła się w „fajnie, działa”, daj uczniom krótką strukturę:

1. 1 minuta: zespół A pokazuje jedno wymaganie i odpowiadającą mu funkcję/moduł.
2. 5 minut: zespół B uruchamia projekt według instrukcji i próbuje wywołać 2 przypadki brzegowe (jeden z listy testów, jeden własny).
3. 5 minut: zespół B wpisuje 3 uwagi: „błąd”, „ryzyko”, „pytanie”. Bez dyskusji.
4. 4 minuty: zespół A wybiera jedną uwagę i robi plan poprawki (co zmieniamy, jak sprawdzimy).

Ten format jest szybki i wymusza konkret: uruchomienie, wejścia, zachowanie programu, reakcja na feedback.

Co może pójść nie tak: testy „na papierze” i recenzja pozorowana

Uczniowie potrafią stworzyć bardzo ładną checklistę, która nie jest wykonywana. Podobnie z peer review: jeśli nie ma uruchomienia, to jest tylko wymiana opinii.

Zabezpieczenie: recenzja liczy się do oceny procesu tylko wtedy, gdy zostawia ślad: link do issue/zgłoszenia + commit poprawki albo wpis „odrzucone z uzasadnieniem”. Jeśli nie ma decyzji i weryfikacji, nie ma punktów.

Gdy AI jest używane w sposób jawny, weryfikowalny i „obarczony” testami oraz checkpointami, metoda projektu odzyskuje sens: uczniowie uczą się procesu inżynierskiego, a nie jednorazowego generowania efektu.

Wskazówka 11 — Oceniaj proces i wkład indywidualny: bez tego AI rozmywa odpowiedzialność

Produkt to za mało: potrzebujesz „dowodów pracy” rozłożonych w czasie

Gdy w projekcie pojawia się AI, końcowy efekt przestaje mówić, kto co zrobił i czego się nauczył. Jeśli ocena opiera się wyłącznie na demo, najszybciej „wygrywa” ten, kto najlepiej sklei tekst i zrzuty ekranu. Rozwiązaniem jest ocena oparta o artefakty procesu, które trudno podrobić jednorazowo na koniec.

• Historia zmian: commity w repo (z opisami), wersjonowanie plików, changelog.
• Log decyzji: krótkie wpisy „co zmieniliśmy i dlaczego” + link do testu/issue.
• Ślad weryfikacji AI: co wygenerowano, co odrzucono, jak sprawdzono (uruchomienie, testy, porównanie z dokumentacją).
• Mini-obrona: 2–3 pytania do każdej osoby o fragment, za który odpowiada.

Prosty model rubryki: 4 obszary, które da się ocenić nawet w zatłoczonej klasie

Jeśli czas jest ograniczony, rubryka powinna być krótka, ale „twarda”. Sprawdza się podział:

1. Wymagania i DoD: czy da się jednoznacznie sprawdzić, że projekt spełnia ustalenia.
2. Jakość techniczna: uruchamialność, struktura, testy, obsługa błędów, czytelność.
3. Proces i weryfikacja: checkpointy, log decyzji, dowody testowania i weryfikacji treści z AI.
4. Wkład indywidualny: przypisane zadania, ślad pracy, obrona fragmentu.

Ten układ „zmusza” ucznia do pokazania umiejętności informatycznych, a nie tylko wygenerowanego opisu.

Przykład: szybka „obrona” wkładu, która nie zamienia się w przesłuchanie

Na prezentacji każdy uczeń losuje jedno z trzech pytań dotyczących własnego modułu:

• „Pokaż błąd i poprawkę” — gdzie był problem, jak go wykryto, jaki test go łapie.
• „Pokaż decyzję” — dwie rozważane opcje + argument, czemu wybrano tę.
• „Pokaż ograniczenie” — co nie działa / jest ryzykiem i jak można to naprawić w kolejnej iteracji.

Jeśli uczeń nie potrafi odpowiedzieć o własnej części, to sygnał, że AI (albo kolega) zrobiło robotę za niego.

Co może pójść nie tak: „wszyscy robią wszystko” i nikt nie odpowiada za nic

W grupach łatwo o rozmycie odpowiedzialności: każdy coś „dopisał”, ale nikt nie potrafi utrzymać modułu ani go obronić. AI dodatkowo pogłębia problem, bo szybko dostarcza gotowe fragmenty, które nie mają właściciela.

Zabezpieczenie: wprowadź zasadę: każdy moduł ma właściciela (odpowiada za uruchomienie i testy) oraz każdy commit ma autora i opis „co i po co”. Zespół nadal współpracuje, ale odpowiedzialność jest przypisana.

Wskazówka 12 — Używaj AI do różnicowania poziomu trudności, ale trzymaj wspólne „minimum zaliczeniowe”

Jedna klasa, trzy poziomy: AI jako przyspieszacz, nie proteza

W informatyce rozstrzał umiejętności jest normalny. AI może pomóc, ale tylko jeśli projekt ma rdzeń, który wszyscy realizują, i rozszerzenia, które nie rozwalają porównywalności ocen.

Sprawdza się schemat: Core + Extensions:

• Core (obowiązkowe): funkcjonalność minimalna, uruchomienie, testy, README, DoD.
• Extensions (dla chętnych): optymalizacja, dodatkowe funkcje, lepsze UX, dodatkowe testy, refaktoryzacja, automatyzacja.

AI jest wtedy legalnym narzędziem do „pchania” projektu dalej, ale nie zastępuje zrozumienia rdzenia.

Konkrety: jak formułować rozszerzenia, żeby nie były „generujcie więcej”

Rozszerzenia powinny być weryfikowalne i techniczne, a nie opisowe. Zamiast „dopisz dokumentację”, lepiej:

• „Dodaj 6 testów, w tym 2 brzegowe i 1 negatywny” (z mapowaniem na wymagania).
• „Zaimplementuj walidację wejścia + komunikaty błędów” (z przykładowymi przypadkami).
• „Zrób refaktoryzację modułu X” (kryterium: mniejsza złożoność, lepsza czytelność, testy nadal przechodzą).
• „Dodaj prosty pipeline uruchamiający testy” (lokalnie lub w narzędziu szkolnym).

Co może pójść nie tak: lepsi uczniowie „odlatują”, a reszta zostaje z tyłu

Jeśli rozszerzenia są atrakcyjne, część zespołów przeskakuje core i idzie w bajery. To kończy się prezentacją bez podstaw: brak testów, brak stabilnego uruchomienia, brak DoD.

Zabezpieczenie: rozszerzenia odblokowują się dopiero po checkpointach. Dopóki core nie ma testów i instrukcji uruchomienia, zespół nie dostaje zielonego światła na dodatkowe funkcje (nie w ocenie, tylko organizacyjnie).

Wskazówka 13 — Przygotuj „bibliotekę promptów”, ale oceniaj wynik i weryfikację, nie sam prompt

Prompt jako szablon pracy, nie sztuczka

Uczniowie szybko kopiują prompty z internetu. To nie problem, jeśli prompt jest traktowany jak narzędzie procesu. Problem zaczyna się wtedy, gdy „ładny prompt” zastępuje myślenie i testowanie. Najlepiej działa szkolna biblioteka 6–8 szablonów promptów, które wymuszają kontekst i kryteria sprawdzenia.

Przykładowe szablony (krótkie i bezpieczne)

• Generator wariantów: „Zaproponuj 3 rozwiązania dla [problem], każde z plusami/minusami. Załóż ograniczenia: [czas/sprzęt/język]. Na końcu podaj kryteria wyboru.”
• Recenzent kodu: „Przejrzyj ten kod pod kątem: błędów, czytelności, edge-case. Zaproponuj poprawki w małych krokach. Nie zmieniaj API.”
• Debugger: „Mam błąd: [komunikat]. Oto minimalny fragment kodu i dane wejściowe. Podaj 3 hipotezy, jak je sprawdzić i jaki test potwierdzi każdą.”
• Generator testów: „Dla funkcji [opis], zaproponuj testy: normalne, brzegowe, negatywne. Do każdego napisz: co sprawdza i jakie wymaganie pokrywa.”

Do biblioteki dopisz krótką zasadę: nie wklejamy danych osobowych i materiałów niepublicznych. To redukuje ryzyka bez długich wykładów.

Co może pójść nie tak: promptbook staje się „ściągą na ocenę”

Jeśli uczeń ma obowiązek pokazać prompty, może zacząć je „upiększać” po fakcie. Wtedy znów oceniamy opowieść, nie pracę.

Zabezpieczenie: promptbook ma być krótki i użytkowy: 3–5 wpisów na cały projekt, każdy z dopiskiem „co z tego weszło do projektu” i „jak to sprawdziliśmy”. Punkty są za decyzje i weryfikację, nie za literacki opis.

Jeśli połączysz checkpointy, dowody pracy i jasne zasady danych z oceną procesu, AI przestaje destabilizować metodę projektu. Zostaje tam, gdzie jest najbardziej użyteczna: w iteracjach, w testowaniu, w recenzji i w doprecyzowaniu decyzji technicznych.

Wskazówka 14 — Ustaw zasady prywatności i praw autorskich zanim padnie pierwszy prompt

Minimum bezpieczeństwa: „czego nie wolno wklejać” i co robić zamiast

Najczęstsza wpadka z AI w projektach szkolnych nie dotyczy kodu, tylko danych. Uczniowie potrafią wkleić do czatu fragmenty dziennika elektronicznego, wyniki ankiet z nazwiskami albo screenshoty z widocznymi danymi. Jeśli projekt ma działać powtarzalnie, potrzebujesz dwóch prostych reguł: zakaz wklejania danych osobowych oraz zakaz wklejania materiałów niepublicznych (np. treści z płatnych podręczników, komercyjnych kursów, prywatnych repo).

Praktyczny zamiennik: uczniowie generują lub anonimizują dane wejściowe. Jeśli projekt wymaga danych, pracują na:

• danych syntetycznych (wymyślonych, ale realistycznych),
• danych publicznych (otwarte zbiory, domena publiczna, licencje CC),
• danych zanonimizowanych (bez nazwisk, maili, identyfikatorów; z usuniętymi metadanymi).

Przykład: projekt „analiza ankiety” bez ryzyka RODO

Jeśli uczniowie robią projekt z analizy danych, zamiast zbierać prawdziwe odpowiedzi z klasy (imiona, komentarze), mogą:

• oprzeć się na 10–20 rekordach syntetycznych i opisać, jakie mają pola oraz ograniczenia,
• dodać osobno plik schema.json albo README z opisem: jakie dane byłyby potrzebne w „realnym” wdrożeniu, ale bez zbierania ich w szkole.

AI może pomóc wygenerować przykładowe rekordy, ale z warunkiem: bez prawdziwych nazwisk, maili, numerów oraz bez kopiowania gotowych zestawów „z internetu” bez licencji.

Co może pójść nie tak: AI „pożycza” fragmenty cudzych treści

Nawet jeśli uczeń nie wkleił nic prywatnego, może wkleić do projektu tekst/obraz wygenerowany „na podstawie” cudzej pracy. W szkołach najbezpieczniejsze podejście to licencjonowanie przez wybór źródeł: materiały własne, domena publiczna albo Creative Commons. Reszta wymaga ostrożności.

Zabezpieczenie: w DoD dodaj punkt: „Lista zasobów z licencją (link + typ licencji) + oznaczenie, co powstało z AI”. To krótki zapis, a uczy realnego nawyku.

Wskazówka 15 — Przygotuj wariant „offline / bez kont”: AI jako stacja nauczyciela albo materiał wejściowy

Gdy nie ma dostępu dla wszystkich, projekt nadal może mieć sens

Jeśli część klasy nie ma kont, sprzęt jest słaby albo internet bywa kapryśny, „AI dla każdego ucznia” zamienia się w nerwową improwizację. Da się to ustabilizować, jeśli AI nie jest warunkiem ukończenia projektu, tylko opcjonalnym narzędziem albo wspólnym zasobem.

Działają trzy modele organizacyjne:

1. Stacja AI (nauczyciel): uczniowie przynoszą krótkie, przygotowane pytania (na kartce lub w pliku), a odpowiedzi AI są „wydawane” jak konsultacja.
2. Paczka startowa: nauczyciel przygotowuje 2–3 wygenerowane warianty (np. pomysły architektury, lista testów, szkic README) i uczniowie wybierają, krytykują, poprawiają.
3. AI tylko w jednym etapie: np. w fazie testów/recenzji, a implementacja jest w pełni „ludzka”.

Przykład: „stacja AI” jako konsultant i recenzent

Ustal prosty protokół: grupa może podejść maksymalnie 2 razy w tygodniu, za każdym razem z jednym pytaniem i jednym artefaktem (fragment kodu / wymaganie / test). Pytanie musi kończyć się prośbą o kryterium weryfikacji, np. „jakim testem to sprawdzić?”.

Zabezpieczenie: jeśli grupa przychodzi z pytaniem typu „napisz nam całą aplikację”, dostaje odpowiedź organizacyjną: „rozbij na 3 zadania, wróć z jednym modułem i testem”. To ogranicza „outsourcing” projektu do AI.

Co może pójść nie tak: nierówny dostęp robi nierówną ocenę

Gdy część uczniów ma AI w domu, a część nie, projekt może nieświadomie premiować dostęp, nie umiejętności. Rozwiązaniem jest wpisanie w zasady: AI nie zwiększa wymagań minimalnych, a rozszerzenia są punktowane tylko wtedy, gdy core jest dopięty i weryfikowalny.

Zabezpieczenie: w rubryce trzymaj osobno „jakość core” i „rozszerzenia”. Dzięki temu uczeń bez AI nie przegrywa, jeśli dostarczy stabilny, przetestowany rdzeń.

Wskazówka 16 — Dobierz typ projektu do obszaru informatyki i przypisz AI do zadań „drugiego rzędu”

AI najlepiej działa tam, gdzie jest dużo iteracji i weryfikacji

W projektach informatycznych AI jest najmniej ryzykowna wtedy, gdy pracuje na rzecz cyklu inżynierskiego: plan → implementacja → test → poprawka → dokumentacja. Jeśli AI robi „serce” rozwiązania bez zrozumienia ucznia, projekt przestaje uczyć. Dlatego przypisz AI do zadań pomocniczych, które i tak wymagają sprawdzenia.

Gotowe dopasowania: obszar → sensowna rola AI

• Programowanie: AI jako debugger i generator testów; uczeń odpowiada za implementację i uruchomienie.
• Bazy danych: AI jako konsultant modelu (normalizacja, klucze), ale decyzje muszą przejść przez przykładowe zapytania i dane testowe.
• Sieci / usługi: AI jako recenzent konfiguracji (np. checklisty bezpieczeństwa), a uczeń dowodzi poprawności logami i testami połączeń.
• Cyberbezpieczeństwo: AI jako generator scenariuszy zagrożeń, ale uczeń mapuje je na konkretne zabezpieczenia i pokazuje testy (np. walidacja wejścia, uprawnienia).
• Multimedia / WWW: AI jako asystent dostępności (kontrast, alt text, struktura), a uczeń weryfikuje w audycie (np. Lighthouse) i poprawia ręcznie.
• Analiza danych: AI jako recenzent interpretacji i generator hipotez, ale wnioski muszą mieć wykres + kod + powtarzalny pipeline.

Co może pójść nie tak: projekt staje się „ładnym opisem” bez działającego artefaktu

AI łatwo produkuje dokumentację, prezentacje i „wizje produktu”. Jeśli nie ustawisz twardych artefaktów, uczniowie dostarczą świetnie brzmiący opis i kilka grafik, a aplikacja nie uruchomi się ani razu.

Zabezpieczenie: w wymaganiach minimalnych dodaj „twardy test uruchomienia”:

• instrukcja startu w 5 krokach (albo jedno polecenie),
• demo na żywo na sprzęcie szkolnym lub w środowisku uzgodnionym wcześniej,
• 2 przypadki testowe: jeden normalny i jeden brzegowy, odpalone podczas prezentacji.

Jeśli projekt ma jasne artefakty, a AI jest przypisana do ról „konsultant–recenzent–tester”, uczniowie szybciej dochodzą do działającego rozwiązania i rzadziej wpadają w pułapkę: dużo tekstu, mało informatyki.