W pracy inżynierskiej z informatyki granica między „dozwolonym wspomaganiem” a „wytworzeniem treści” jest trudniejsza do wyznaczenia niż w pracy opisowej — bo częścią pracy jest sam kod, nie tylko tekst rozdziałów. Zarządzenie nr 115 Rektora Uniwersytetu Jagiellońskiego z 27 listopada 2025 r., które reguluje wykorzystanie SI w dydaktyce, w tym w pracach dyplomowych, wprost zalicza „asystentów kodu np. GitHub Copilot” do narzędzi opartych na SI (§2 pkt 2), a wśród zasad wskazuje, że narzędzia generujące „teksty, kody i obrazy” wymagają „transparentności i rzetelnego oznaczania” (§3 ust. 2 pkt 2). Obowiązek wyraźnego oznaczania części pracy wygenerowanych z wykorzystaniem SI (§6 pkt 3) dotyczy więc także kodu aplikacji w pracy inżynierskiej — a poniżej dokładnie, jak go zastosować do specyfiki projektu informatycznego, nie tylko do tekstu. Poniżej trzy poziomy udziału AI w kodzie, wzór deklaracji dopasowany do implementacji, zasady prowadzenia dziennika promptów dla plików projektu oraz to, czego pod żadnym pozorem nie wolno robić z danymi rzeczywistymi w narzędziach zewnętrznych.
Co dokładnie trzeba zadeklarować przy kodzie wygenerowanym z pomocą AI
Zgodnie z logiką zarządzenia UJ (§1 ust. 2 wyłącza spod jego stosowania funkcje SI „zintegrowane z innym powszechnie używanym oprogramowaniem”, o ile mają „jedynie cele wspomagające”, ale §2 pkt 2 wprost obejmuje asystentów kodu), w pracy inżynierskiej z informatyki warto rozróżnić trzy poziomy udziału AI w kodzie:
- Podpowiedzi składniowe w edytorze (dopełnianie linii, poprawa literówek w nazwach zmiennych) — przypominają wspomaganie pisowni w edytorze tekstu, ale ponieważ zarządzenie UJ wprost wymienia asystentów kodu wśród narzędzi opartych na SI, nie zakładaj automatycznie, że są zwolnione z oznaczania — ustal to z promotorem, bo nie każda uczelnia ma jednoznaczną interpretację dla asystentów kodowania.
- Wygenerowanie całych funkcji lub modułów na podstawie opisu zadania — to bezpośredni odpowiednik „wygenerowania kodu do analizy danych”, które w tabeli z naszego poradnika o oznaczaniu AI zaliczamy do czynności wymagających deklaracji, i wymaga oznaczenia: narzędzie, wersja, zakres wykorzystania, co zostało zweryfikowane samodzielnie.
- Wygenerowanie struktury całego projektu lub architektury systemu — to poziom najbliższy „wytworzeniu treści” w rozumieniu zarządzenia i wymaga najpełniejszej deklaracji, łącznie z uzasadnieniem, które decyzje architektoniczne student podjął samodzielnie, a które zaproponowało narzędzie.
Jak opisać to w rozdziale metodologicznym pracy inżynierskiej
Wzór deklaracji analogiczny do tego stosowanego dla tekstu, zaadaptowany pod kod: „W trakcie implementacji systemu korzystano z narzędzia [nazwa i wersja] na następujących etapach: (1) generowanie szkieletu klas encji na podstawie zaprojektowanego wcześniej modelu danych; (2) generowanie testów jednostkowych na podstawie zaimplementowanej logiki biznesowej. Narzędzie nie było wykorzystywane do projektowania architektury systemu, doboru technologii ani logiki biznesowej kluczowych modułów. Treść promptów i zakres wykorzystanych fragmentów kodu zestawiono w załączniku [numer]. Za poprawność, bezpieczeństwo i przetestowanie całego kodu odpowiada autor.” Ostatnie zdanie jest tu równie ważne jak samo oznaczenie — deklarujesz użycie narzędzia, ale nie przenosisz na nie odpowiedzialności za jakość finalnego kodu. To zdanie warto zapamiętać dosłownie — recenzenci, którzy widzieli już prace z niedbale wygenerowanym, niesprawdzonym kodem, zwracają na nie szczególną uwagę przy ocenie rozdziału metodologicznego.
Dziennik promptów dla kodu — co zapisywać inaczej niż przy tekście
Dziennik promptów dla kodu potrzebuje dodatkowej kolumny względem wzoru tekstowego: nazwy pliku lub modułu, którego dotyczył prompt, oraz informacji, czy wygenerowany kod trafił do repozytorium bez zmian, czy został poprawiony. Ta ostatnia informacja jest przydatna nie tylko dla deklaracji — pomaga też samemu studentowi śledzić, które fragmenty systemu wymagały największej liczby poprawek po wygenerowaniu, co bywa dobrym materiałem do sekcji ograniczeń w rozdziale z wynikami.
Testy wygenerowane przez AI — osobna kategoria do zadeklarowania
Testy jednostkowe i integracyjne wygenerowane z pomocą AI to częsty przypadek w pracach inżynierskich i podlegają tej samej zasadzie co kod aplikacji — jeśli AI wygenerowało treść (w tym przypadku przypadki testowe), podlega to oznaczeniu. Dodatkowo warto samodzielnie zweryfikować, czy wygenerowane testy rzeczywiście sprawdzają to, co deklarują w nazwie, a nie tylko przechodzą bez realnego pokrycia logiki — AI potrafi wygenerować test, który technicznie „przechodzi”, ale nie testuje niczego istotnego, co jest błędem, który recenzent bardzo łatwo wychwytuje przy przeglądzie repozytorium.
Dokumentacja projektu (README, komentarze w kodzie) — czy to też trzeba deklarować
Tak, na tych samych zasadach co reszta tekstu pracy — jeśli README lub komentarze w kodzie zostały wygenerowane lub istotnie przeredagowane przez AI, a trafiają do pracy jako załącznik lub są cytowane w tekście, podlegają deklaracji analogicznie do innych fragmentów tekstu wygenerowanych z pomocą narzędzia. W praktyce wielu studentów pomija ten element, traktując dokumentację techniczną jako „mniej ważną” niż główny tekst pracy — to błąd, bo z perspektywy zarządzenia liczy się to, czy treść trafia do ocenianej pracy, a nie jej gatunek.
Co zdecydowanie nie wolno — bez wyjątków
- Cytowanie odpowiedzi modelu językowego jako źródła wiedzy naukowej w bibliografii — zarządzenie UJ (§7 ust. 2) wprost tego zakazuje, niezależnie od tego, czy chodzi o tekst, czy o wyjaśnienie techniczne dotyczące kodu.
- Wklejanie danych osobowych użytkowników testowych lub rzeczywistych danych z systemu produkcyjnego do zewnętrznego narzędzia AI — to bezpośrednie naruszenie ochrony prywatności i danych, jednej z zasad wymienionych w §3 ust. 2 zarządzenia UJ, szczególnie istotne przy projektach z realnymi danymi firmowymi.
- Twierdzenie, że cały system został napisany samodzielnie, gdy istotne moduły powstały z wygenerowanego kodu bez deklaracji — to prowadzi do tych samych konsekwencji dyscyplinarnych co nieujawnienie użycia AI w tekście.
- Poleganie wyłącznie na deklaracji ogólnej bez przypisania konkretnych fragmentów kodu do konkretnych promptów — recenzent nie ma wtedy możliwości zweryfikowania zakresu wykorzystania.
Code review własnego kodu po użyciu AI — co sprawdzić przed wgraniem
Kod wygenerowany przez AI wymaga tego samego (a często większego) poziomu przeglądu co kod napisany samodzielnie, zanim trafi do finalnego repozytorium pracy. Warto systematycznie sprawdzić pięć rzeczy: czy kod faktycznie robi to, co deklaruje nazwa funkcji lub metody; czy obsługuje przypadki brzegowe (puste dane wejściowe, wartości null), które model mógł pominąć; czy nie zawiera nieużywanych fragmentów lub martwego kodu wygenerowanego „na wszelki wypadek”; czy styl kodowania jest spójny z resztą projektu, a nie odróżnia się stylistycznie jako „wklejony z zewnątrz”; oraz czy nie zawiera podatności bezpieczeństwa charakterystycznych dla wygenerowanego kodu (np. brak walidacji danych wejściowych, zahardkodowane dane dostępowe). Ten ostatni punkt jest szczególnie ważny w pracach dotyczących aplikacji z logowaniem użytkowników lub przetwarzaniem danych wrażliwych.
Czy warto prowadzić osobny plik AI_USAGE.md w repozytorium projektu
To nie jest wymóg żadnego zarządzenia, ale dobra praktyka, która ułatwia późniejsze przygotowanie deklaracji i załącznika: plik w repozytorium (np. AI_USAGE.md) z bieżąco aktualizowaną listą commitów lub plików, przy których wykorzystano AI, wraz z krótkim opisem zakresu. Taki plik, prowadzony równolegle z pracą nad kodem, eliminuje problem odtwarzania z pamięci na końcu semestru, które AI dokładnie w jakim pliku wygenerowało — dokładnie ten sam problem, który dotyczy dziennika promptów dla tekstu, tylko przeniesiony na poziom repozytorium kodu.
Poziom licencjacki, inżynierski a magisterski — czy oczekiwania się różnią
Na poziomie inżynierskim (I stopnia) większość wydziałów informatyki skupia się na tym, czy student rozumie i potrafi wyjaśnić każdy fragment kodu w projekcie, niezależnie od tego, czy powstał samodzielnie, czy z pomocą AI — kluczowe jest, żeby podczas obrony student potrafił swobodnie omówić dowolny fragment własnego repozytorium. Na poziomie magisterskim oczekiwania bywają wyższe: promotorzy częściej oczekują, że kluczowe, oryginalne elementy pracy (np. autorski algorytm, nietypowe rozwiązanie architektoniczne, będące właściwym wkładem naukowym pracy) powstały w całości samodzielnie, a AI wspierało wyłącznie elementy rutynowe, jak boilerplate czy testy. Jeśli nie masz pewności, gdzie leży ta granica na Twoim wydziale, zapytaj promotora wprost, zanim zaczniesz intensywnie korzystać z generowania kodu w kluczowych modułach pracy.
Jak to wygląda w praktyce — przykład jednego modułu
Student implementujący aplikację do zarządzania zadaniami wykorzystał AI do wygenerowania szkieletu kontrolera REST API na podstawie już zaprojektowanego wcześniej modelu danych i opisu endpointów. Deklaracja w rozdziale metodologicznym: „Szkielet kontrolera TaskController (metody CRUD) wygenerowano z wykorzystaniem [narzędzie, wersja] na podstawie zaprojektowanego wcześniej schematu bazy danych i specyfikacji endpointów z rozdziału analizy. Logikę walidacji danych wejściowych oraz obsługę wyjątków dopisano samodzielnie. Prompt nr 7, załącznik 2.” Ten fragment jest wystarczająco konkretny, żeby promotor i recenzent dokładnie wiedzieli, gdzie kończy się wkład narzędzia, a zaczyna samodzielna praca.
Checklist AI w pracy inżynierskiej z informatyki
- Rozróżniłaś/rozróżniłeś podpowiedzi składniowe od wygenerowanych całych funkcji lub modułów.
- Deklaracja w rozdziale metodologicznym wymienia narzędzie z wersją i zakresem wykorzystania w kodzie.
- Dziennik promptów dla kodu zawiera nazwę pliku lub modułu przy każdym wpisie.
- Testy wygenerowane przez AI zostały samodzielnie zweryfikowane pod kątem realnego pokrycia logiki.
- Żadna odpowiedź modelu nie trafiła do bibliografii jako źródło wiedzy technicznej.
- Dane rzeczywiste lub testowe użytkowników nie trafiły do zewnętrznego narzędzia AI.
FAQ — AI w pracy inżynierskiej z informatyki
Czy asystent kodowania zintegrowany z edytorem (podpowiedzi w trakcie pisania) trzeba deklarować tak samo jak ChatGPT?
To zależy od interpretacji Twojego wydziału — zarządzenie UJ wyłącza asystenta pisania w Word jako funkcję wspomagającą, ale jednocześnie wprost wymienia asystentów kodu (np. GitHub Copilot) wśród narzędzi opartych na SI, więc nie zakładaj, że podpowiedzi w edytorze kodu są automatycznie zwolnione z deklaracji. To pytanie warto zadać wprost promotorowi, bo nie każda uczelnia doprecyzowała tę granicę dla narzędzi programistycznych. Zapisanie tej odpowiedzi mailowo, tak jak w przypadku uzgodnienia zakresu dla tekstu, jest równie wartościowym zabezpieczeniem przy kodzie.
Czy mogę użyć AI do debugowania błędu w kodzie, bez deklaracji?
Jeśli AI tylko wskazuje przyczynę błędu, a poprawkę piszesz samodzielnie, to bliżej funkcji wspomagającej; jeśli AI generuje gotową poprawkę, którą wklejasz bez zmian, to bliżej wytworzenia treści i wymaga deklaracji — w razie wątpliwości bezpieczniej zadeklarować.
Czy promotor może zabronić używania AI do pisania kodu w ogóle?
Tak, promotor ma prawo ustalić własne ograniczenia dla konkretnej pracy, nawet jeśli regulamin uczelni dopuszcza AI w ogólnym zakresie — dlatego krok „uzgodnij zakres z promotorem” jest równie ważny przy kodzie, co przy tekście.
Czy komisja na obronie może poprosić o pokazanie, który kod był generowany przez AI?
Może poprosić o wyjaśnienie procesu powstawania kodu — dziennik promptów z nazwami plików jest wtedy najprostszą, gotową odpowiedzią.
Czy mogę wykorzystać AI do napisania całej dokumentacji technicznej projektu?
Możesz, ale musisz to zadeklarować tak samo jak inne wygenerowane fragmenty tekstu trafiające do pracy — dokumentacja techniczna nie jest wyjątkiem od ogólnej zasady.
Czy muszę deklarować użycie AI do napisania skryptów pomocniczych (np. do wdrożenia lub konfiguracji środowiska)?
Tak, jeśli te skrypty trafiają do repozytorium jako część projektu ocenianego przez recenzenta — logika deklaracji jest ta sama niezależnie od tego, czy chodzi o główną logikę aplikacji, czy o skrypty pomocnicze.
Co jeśli korzystałam/korzystałem z AI intensywnie na początku projektu, a potem coraz mniej w miarę nauki?
Zadeklaruj to uczciwie, z podziałem na etapy — deklaracja może wprost stwierdzać, że wsparcie AI było większe na wczesnym etapie (np. przy nauce nowego frameworka) i malało w miarę postępu prac, co jest naturalnym i wiarygodnym opisem procesu uczenia się.
Pełne siedem kroków oznaczania wykorzystania AI w pracy dyplomowej, zgodnych z zarządzeniem UJ nr 115/2025 i wytycznymi UW, opisaliśmy w jak oznaczyć i opisać wykorzystanie AI w pracy dyplomowej. Zasady poszczególnych polskich uczelni dotyczące ChatGPT i innych narzędzi porównaliśmy w czy można używać ChatGPT do pracy dyplomowej. Strukturę pracy inżynierskiej z informatyki, rozdział po rozdziale, opisaliśmy w jak napisać pracę inżynierską z informatyki. Rozdział z wynikami testów i dyskusją dla pracy inżynierskiej znajdziesz w rozdziale z wynikami w pracy inżynierskiej z informatyki.