ChatGPT dla programistów Pythona: od promptu do sprawdzonego kodu

ChatGPT dla programistów Pythona może pomagać w analizowaniu kodu, przygotowywaniu małych funkcji, debugowaniu, pisaniu testów i dokumentacji. Nie potwierdza jednak automatycznie, że rozwiązanie działa w Twoim projekcie. Bezpieczny workflow wygląda tak: najpierw definiujesz kontrakt zadania, potem prosisz o niewielką zmianę, uruchamiasz ją lokalnie, sprawdzasz testami i porównujesz użyte API z oficjalną dokumentacją.

Największą wartością ChatGPT nie jest jednorazowe wygenerowanie dużej ilości kodu. Jest nią skrócenie pętli między opisaniem problemu, przygotowaniem hipotezy, wykonaniem testu i poprawieniem rozwiązania. Odpowiedzialność za wynik nadal pozostaje po stronie programisty.

Do czego ChatGPT przydaje się w pracy z Pythonem?

Najlepiej sprawdzają się zadania małe, jasno ograniczone i możliwe do zweryfikowania. Im dokładniej możesz opisać prawidłowy wynik, tym łatwiej ocenisz odpowiedź modelu.

Zadanie	Co przekazać ChatGPT	Czego oczekiwać	Jak sprawdzić wynik
Nowa funkcja	Sygnaturę, typy wejścia, wynik, błędy i przypadki brzegowe	Małą implementację i testy	Uruchomienie lokalne, testy i porównanie z kontraktem
Debugowanie	Minimalny kod, dane odtwarzające problem, pełny traceback i oczekiwane zachowanie	Hipotezę przyczyny, minimalną poprawkę i test regresji	Ponowne odtworzenie błędu oraz uruchomienie całego zestawu testów
Testy jednostkowe	Kod funkcji i wymagania biznesowe	Przypadki poprawne, błędne i brzegowe	Ocena, czy testy sprawdzają wymagania, a nie przypadkową implementację
Code review	Kod, zakres review, standard projektu i zakazane zmiany	Problemy z dowodami, priorytetem i propozycją naprawy	Ręczne review, linter, type checker i testy
Refaktoryzacja	Obecne zachowanie, publiczne API oraz testy regresji	Ograniczoną zmianę z uzasadnieniem	Porównanie diffu, testy i pomiar wydajności, jeśli był celem
Dokumentacja	Kod, rzeczywiste komendy i odbiorcę dokumentacji	Docstring, README lub przykład użycia	Porównanie tekstu z kodem i aktualną dokumentacją zależności

Słabszym zastosowaniem jest polecenie typu „napisz całą aplikację w Django”. Model musi wtedy samodzielnie wymyślić architekturę, wymagania, zasady autoryzacji, strukturę danych i sposób wdrożenia. Wynik może wyglądać kompletnie, mimo że opiera się na niepotwierdzonych założeniach.

Dobry prompt techniczny jest małą specyfikacją

Rola w rodzaju „jesteś senior Python developerem” nie naprawi niepełnego opisu zadania. Ważniejsze są informacje, które ograniczają liczbę rzeczy pozostawionych do zgadnięcia: wersja Pythona, środowisko, dane wejściowe, oczekiwany wynik, dozwolone zależności, zachowanie dla błędnych danych oraz kryteria akceptacji.

Szablon promptu do pracy z kodem Python

Kontekst projektu:
- Python: [wersja]
- system lub środowisko: [Windows, Linux, Docker, CI]
- framework i zależności: [nazwy oraz wersje, jeśli mają znaczenie]

Zadanie:
[opisz jedną konkretną zmianę]

Kontrakt:
- wejście: [typ i przykład]
- wynik: [typ i przykład]
- błędy lub wyjątki: [oczekiwane zachowanie]
- przypadki brzegowe: [lista]

Ograniczenia:
- nie zmieniaj: [publiczne API, format danych, nazwa funkcji]
- nie używaj: [zakazane biblioteki lub techniki]
- zachowaj: [kompatybilność, wydajność, styl projektu]

Oczekiwana odpowiedź:
1. Najpierw wypisz założenia i brakujące informacje.
2. Następnie pokaż minimalną implementację.
3. Dodaj testy odzwierciedlające kontrakt.
4. Wskaż ryzyka i sposób lokalnej weryfikacji.

Jeśli brakuje danych potrzebnych do poprawnego rozwiązania, nie zgaduj. Wypisz pytania lub jawne założenia.

Nie wszystkie pola są potrzebne w każdym zadaniu. Do prostego wyjaśnienia funkcji wystarczy kod i informacja, dla jakiego poziomu ma być wyjaśnienie. Przy błędzie produkcyjnym potrzebujesz natomiast wersji zależności, danych odtwarzających problem, logów oraz dokładnego tracebacku.

Słaby prompt i prompt, który można zweryfikować

Słaby prompt: „Napisz funkcję do grupowania e-maili”. Nie wiadomo, jaki ma być format wyniku, jak obsłużyć błędne adresy, czy normalizować wielkość liter ani czy wolno użyć zewnętrznej biblioteki.

Lepszy prompt: określa sygnaturę funkcji, zasady walidacji, sposób normalizacji domeny, typ wyjątku, wymagane testy i wersję Pythona. Dzięki temu kod można porównać z konkretnym kontraktem zamiast oceniać go na podstawie tego, czy „wygląda dobrze”.

Workflow 1: wygeneruj małą funkcję razem z testami

Poniższy przykład pokazuje zamknięte zadanie, które łatwo uruchomić i sprawdzić. Celem nie jest pełna walidacja adresów zgodna ze wszystkimi regułami poczty elektronicznej, lecz prosta walidacja strukturalna opisana w kontrakcie.

Napisz funkcję:

group_emails_by_domain(emails: Iterable[str]) -> dict[str, list[str]]

Środowisko:
- Python 3.11 lub nowszy
- bez zewnętrznych bibliotek

Wymagania:
- usuń spacje z początku i końca każdego adresu;
- adres musi zawierać dokładnie jeden znak @;
- część lokalna i domena nie mogą być puste;
- adres nie może zawierać białych znaków;
- zamień domenę na małe litery przez casefold();
- zachowaj wielkość liter części lokalnej;
- grupuj znormalizowane adresy według domeny;
- dla pierwszego niepoprawnego adresu rzuć ValueError z wartością wejściową;
- funkcja ma przyjmować także generator, nie tylko listę.

Najpierw pokaż implementację, potem testy pytest. Dodaj test grupowania, test generatora i parametryzowane testy błędnych danych. Nie rozszerzaj walidacji poza podany kontrakt.

Jedna spójna implementacja może wyglądać tak:

from collections import defaultdict
from collections.abc import Iterable


def group_emails_by_domain(emails: Iterable[str]) -> dict[str, list[str]]:
    grouped: dict[str, list[str]] = defaultdict(list)

    for raw_email in emails:
        email = raw_email.strip()

        if email.count("@") != 1:
            raise ValueError(f"Nieprawidłowy adres e-mail: {raw_email!r}")

        local_part, domain = email.split("@")

        if not local_part or not domain or any(char.isspace() for char in email):
            raise ValueError(f"Nieprawidłowy adres e-mail: {raw_email!r}")

        normalized_domain = domain.casefold()
        normalized_email = f"{local_part}@{normalized_domain}"
        grouped[normalized_domain].append(normalized_email)

    return dict(grouped)

Testy powinny sprawdzać kontrakt, a nie tylko przechodzić dla jednego przykładu:

import pytest

from emails import group_emails_by_domain


def test_groups_addresses_and_normalizes_domain() -> None:
    result = group_emails_by_domain(
        [
            "Anna@Example.COM",
            "piotr@example.com",
            "biuro@firma.pl",
        ]
    )

    assert result == {
        "example.com": ["Anna@example.com", "piotr@example.com"],
        "firma.pl": ["biuro@firma.pl"],
    }


def test_accepts_generator() -> None:
    emails = (value for value in ["a@EXAMPLE.com", "b@example.COM"])

    assert group_emails_by_domain(emails) == {
        "example.com": ["a@example.com", "b@example.com"]
    }


@pytest.mark.parametrize(
    "raw_email",
    ["bez-malpy", "@example.com", "anna@", "a@b@c", "a @example.com"],
)
def test_rejects_malformed_email(raw_email: str) -> None:
    with pytest.raises(ValueError, match="Nieprawidłowy adres e-mail"):
        group_emails_by_domain([raw_email])

Po otrzymaniu kodu sprawdź, czy model nie dodał reguł, których nie było w wymaganiach. Przykładowo wymóg kropki w domenie odrzuciłby adresy używane w części środowisk testowych, mimo że nie został zapisany w kontrakcie. Jeżeli potrzebujesz pełniejszej walidacji, zdefiniuj ją osobno i oprzyj na wymaganiach produktu.

Oficjalna dokumentacja pytest opisuje instalację, wykrywanie testów, asercje i sprawdzanie wyjątków. Porównaj z nią składnię wygenerowanych testów, zwłaszcza gdy model używa fixtures, parametryzacji lub pluginów.

Workflow 2: debugowanie na podstawie minimalnego reproduktora

Sam komunikat „kod nie działa” zwykle prowadzi do zgadywania. Przygotuj minimalny reproduktor: najmniejszy fragment kodu i danych, które nadal wywołują błąd. Wklej traceback jako tekst, ponieważ zawiera typ wyjątku, kolejność wywołań i numery linii.

def sum_paid_orders(orders: list[dict[str, object]]) -> float:
    return sum(
        order["amount"]
        for order in orders
        if order["status"] == "paid"
    )


orders = [
    {"status": "paid", "amount": 19.99},
    {"status": "paid", "amount": None},
]

W tym przykładzie problemem nie jest sama funkcja sum(), lecz brak jednoznacznej polityki dla wartości None. Czy rekord ma zostać pominięty, odrzucony, czy potraktowany jako zero? ChatGPT nie powinien podejmować tej decyzji za projekt.

Prompt do znalezienia przyczyny i przygotowania testu regresji

Pomóż mi zdebugować błąd w Pythonie.

Kontekst:
- wersja Pythona: [wersja]
- środowisko: [lokalne, Docker, CI]
- funkcja ma sumować kwoty tylko dla zamówień ze statusem paid;
- nie wolno zmieniać publicznej sygnatury funkcji.

Aktualny kod:
[wklej minimalny fragment]

Dane odtwarzające błąd:
[wklej minimalne dane]

Pełny traceback:
[wklej traceback jako tekst]

Oczekiwane zachowanie dla None:
[odrzuć rekord / pomiń rekord / rzuć konkretny wyjątek]

Wykonaj zadanie w tej kolejności:
1. Wskaż pierwszą linię naszego kodu, która prowadzi do błędu.
2. Oddziel bezpośredni symptom od przyczyny danych lub kontraktu.
3. Zaproponuj minimalną poprawkę, bez przepisywania całego modułu.
4. Dodaj test pytest, który najpierw odtwarza błąd, a potem chroni przed jego powrotem.
5. Wypisz założenia, których nie da się potwierdzić na podstawie materiału.

Po otrzymaniu odpowiedzi najpierw uruchom test na starej wersji kodu. Powinien nie przejść z powodu opisywanego błędu. Dopiero potem zastosuj poprawkę i uruchom test ponownie. Dzięki temu wiesz, że test rzeczywiście chroni przed regresją, a nie tylko przechodzi niezależnie od zmiany.

Workflow 3: code review i refaktoryzacja bez utraty zachowania

Przy code review nie proś od razu o przepisanie pliku. Model może zmienić publiczne API, kolejność efektów ubocznych albo sposób raportowania błędów, chociaż celem była tylko poprawa czytelności. Lepszy jest proces dwuetapowy: najpierw diagnoza z dowodami, potem ograniczona poprawka.

Wykonaj code review poniższego modułu Python.

Zakres review:
- błędy logiczne;
- obsługa wyjątków;
- niejawne efekty uboczne;
- czytelność i nazewnictwo;
- testowalność;
- zgodność z typami;
- ryzyka bezpieczeństwa wynikające bezpośrednio z kodu.

Ograniczenia:
- nie zmieniaj publicznych nazw funkcji;
- nie zmieniaj formatów zwracanych danych;
- nie proponuj nowego frameworka;
- nie traktuj preferencji stylistycznej jako błędu krytycznego;
- nie przepisuj jeszcze kodu.

Dla każdego problemu podaj:
1. Priorytet: krytyczny, wysoki, średni lub niski.
2. Dokładny fragment kodu będący podstawą wniosku.
3. Konkretny scenariusz awarii lub koszt utrzymania.
4. Najmniejszą rozsądną poprawkę.
5. Test, który potwierdzi poprawkę.

Kod:
[wklej kod]

W kolejnym poleceniu wybierz tylko problemy, które chcesz naprawić, i poproś o patch lub pełną wersję jednej funkcji. Zawsze porównaj diff. Jeżeli model twierdzi, że refaktoryzacja przyspiesza kod, wymagaj benchmarku przed i po zmianie.

PEP 8 jest punktem odniesienia dla stylu kodu Python, ale zgodność stylistyczna nie potwierdza poprawności logiki, bezpieczeństwa ani zgodności z architekturą projektu. Nie pozwól, aby review sprowadziło się wyłącznie do długości linii i nazw zmiennych.

Jak sprawdzić kod wygenerowany przez ChatGPT?

1. Uruchom kod w odizolowanym środowisku

Nie instaluj przypadkowo zaproponowanych pakietów w globalnym interpreterze ani w środowisku produkcyjnym. Moduł venv tworzy oddzielne środowisko z własnym interpreterem i zestawem pakietów.

python -m venv .venv

W PowerShell aktywuj je poleceniem .venv\Scripts\Activate.ps1. W bash lub zsh użyj source .venv/bin/activate. Jeżeli projekt ma własny sposób zarządzania środowiskiem, zachowaj jego istniejące zasady zamiast narzucać nowy toolchain.

2. Uruchom testy, a nie tylko pojedynczy przykład

python -m pip install -U pytest
pytest -q

Najpierw uruchom testy dotyczące zmienianej funkcji, a następnie cały zestaw projektu. Kod może naprawić jeden przypadek i jednocześnie zepsuć zachowanie innego modułu.

3. Dobierz linting i sprawdzanie typów do projektu

Ruff może wykrywać problemy jakościowe i formatować kod, a mypy sprawdza typy statycznie. Mypy daje najwięcej informacji w kodzie z adnotacjami typów; nie zastępuje testów uruchomieniowych.

python -m pip install ruff mypy
ruff check .
mypy src

Nie dodawaj tych narzędzi do projektu wyłącznie dlatego, że pojawiły się w odpowiedzi modelu. Jeżeli repozytorium używa innego lintera, type checkera lub konfiguracji CI, uruchom istniejący zestaw kontroli.

4. Porównaj użyte API z oficjalną dokumentacją

ChatGPT może podać nieistniejącą metodę, pomieszać wersje biblioteki albo użyć starego parametru. Sprawdź nazwę funkcji, sygnaturę, typ zwracany i zachowanie wyjątków w dokumentacji wersji rzeczywiście zainstalowanej w projekcie.

5. Przejrzyj przypadki, których prompt nie wymienił

• puste kolekcje, puste stringi i wartości None;
• nieprawidłowe typy danych;
• duże wejścia i ograniczenia pamięci;
• kodowanie znaków, strefy czasowe i separator dziesiętny, jeśli dotyczą zadania;
• błędy sieci, timeouty i ponowienia dla integracji zewnętrznych;
• zapisy do plików, bazy danych lub innych zasobów;
• logowanie danych wrażliwych;
• wpływ zmiany na kompatybilność publicznego API.

Weryfikacja nie kończy się na tym, że kod nie zgłasza wyjątku. Musi jeszcze spełniać wymagania biznesowe, być zgodny z resztą projektu i zachowywać się przewidywalnie dla błędnych danych.

Czy ChatGPT może uruchamiać kod Python?

ChatGPT może wyświetlać kod w osobnych blokach, a w obsługiwanych przypadkach także uruchamiać kod Python w środowisku odizolowanym. OpenAI zaznacza, że dostępne akcje zależą między innymi od planu, urządzenia, ustawień workspace, modelu i etapu wdrażania funkcji.

Takie uruchomienie przydaje się do szybkiego sprawdzenia czystej funkcji lub małego zestawu danych. Nie zastępuje środowiska projektu. W sandboxie mogą być inne wersje pakietów, brak usług sieciowych, brak bazy danych i inna konfiguracja systemu. Ostateczny test wykonuj przy użyciu interpretera, zależności i ustawień używanych przez aplikację.

Bezpieczeństwo i prywatność kodu

Do debugowania zwykle nie potrzebujesz całego repozytorium ani prawdziwych danych. Przygotuj minimalny fragment i zastąp informacje wrażliwe jednoznacznymi wartościami, takimi jak API_KEY_REDACTED, USER_ID_123 lub example.internal.

• Nie wklejaj kluczy API, tokenów, haseł, prywatnych certyfikatów ani pełnych plików .env.
• Usuń dane klientów, adresy e-mail, identyfikatory i treść dokumentów z logów.
• Nie wysyłaj kodu objętego NDA lub polityką firmy bez upoważnienia.
• Jeżeli sekret został ujawniony, nie wystarczy usunąć go z rozmowy — unieważnij go i wygeneruj nowy.
• Przed użyciem zewnętrznego narzędzia sprawdź zasady organizacji dotyczące kodu, danych i retencji.

Zgodnie z informacjami OpenAI o danych w usługach konsumenckich, treści przesyłane do ChatGPT mogą być wykorzystywane do ulepszania modeli zależnie od ustawień użytkownika. OpenAI opisuje inne domyślne zasady dla ofert biznesowych, takich jak API, ChatGPT Business i Enterprise. Nie zakładaj więc, że wszystkie produkty i konta mają identyczne warunki.

OWASP Secrets Management Cheat Sheet traktuje klucze API, dane dostępowe do baz, klucze SSH i certyfikaty jako sekrety wymagające kontrolowanego przechowywania, dostępu, rotacji i unieważniania. Chat nie jest systemem zarządzania sekretami.

Najczęstsze błędy przy używaniu ChatGPT do kodu Python

• Zlecanie całej aplikacji w jednym poleceniu. Podziel pracę na kontrakty, moduły i małe zmiany, które można osobno przetestować.
• Brak wersji Pythona i zależności. Składnia oraz API bibliotek mogą różnić się między wersjami.
• Akceptowanie wymyślonego API. Sprawdź każdą nieznaną metodę, klasę i parametr w oficjalnej dokumentacji.
• Pozwalanie modelowi zmienić zachowanie podczas refaktoryzacji. Zapisz publiczny kontrakt i uruchom testy regresji.
• Proszenie o optymalizację bez pomiaru. Wymagaj benchmarku oraz opisu warunków testu.
• Testowanie implementacji zamiast wymagań. Testy nie powinny utrwalać przypadkowych szczegółów wewnętrznych.
• Kopiowanie kodu bez zrozumienia. Jeżeli nie potrafisz wyjaśnić zmiany podczas review, nie wdrażaj jej do produkcji.
• Wklejanie sekretów i danych firmowych. Minimalizuj materiał i anonimizuj go przed wysłaniem.

Codzienny workflow: od problemu do sprawdzonej zmiany

1. Zdefiniuj sukces. Zapisz wejście, wynik, błędy i przypadki brzegowe.
2. Ogranicz zakres. Wybierz jedną funkcję, błąd lub zmianę zamiast całego systemu.
3. Przygotuj kontekst. Dodaj wersje, minimalny kod i dane odtwarzające problem.
4. Poproś o jawne założenia. Niech model wskaże, czego nie wie, zanim wygeneruje kod.
5. Wygeneruj mały patch. Zachowaj publiczne API i istniejący styl projektu.
6. Uruchom kod lokalnie. Użyj właściwego środowiska i wersji zależności.
7. Dodaj test regresji. Powinien nie przechodzić przed poprawką i przechodzić po niej.
8. Sprawdź narzędziami projektu. Uruchom testy, linting, type checking i CI.
9. Porównaj dokumentację. Zweryfikuj wszystkie nowe lub nieznane API.
10. Zrób ludzkie review. Przejrzyj diff, bezpieczeństwo, efekty uboczne i zgodność z wymaganiami.

Jeżeli test nie przechodzi, wróć do rozmowy z rzeczywistym komunikatem błędu i aktualnym fragmentem kodu. Nie proś modelu o kolejną losową wersję. Każda iteracja powinna bazować na nowym dowodzie: tracebacku, wyniku testu, logu lub fragmencie dokumentacji.

FAQ

Czy ChatGPT potrafi napisać poprawny kod Python?

Może przygotować poprawną implementację, szczególnie dla małych i dobrze opisanych zadań, ale nie daje gwarancji. Kod może zawierać błąd logiczny, nieaktualne API lub założenie sprzeczne z projektem. Traktuj odpowiedź jako propozycję wymagającą uruchomienia, testów i review.

Czy początkujący programista powinien używać ChatGPT?

Tak, jeżeli używa go do wyjaśniania kodu, tworzenia ćwiczeń, analizy tracebacku i porównywania rozwiązań. Dobrą zasadą jest proszenie o wyjaśnienie każdej istotnej linii oraz samodzielne napisanie lub uzupełnienie testów. Kopiowanie rozwiązania bez zrozumienia utrudnia naukę i ukrywa błędy.

Czy ChatGPT zastępuje dokumentację Pythona i bibliotek?

Nie. ChatGPT może pomóc znaleźć właściwe pojęcie lub wyjaśnić fragment dokumentacji, ale źródłem prawdy dla sygnatur, wersji, wyjątków i zachowania funkcji pozostaje dokumentacja projektu. Jest to szczególnie ważne dla szybko rozwijanych frameworków i SDK.

Czy warto wklejać cały plik albo repozytorium?

Zwykle lepiej zacząć od minimalnego fragmentu potrzebnego do rozwiązania problemu. Pełniejszy kontekst jest potrzebny przy błędach architektonicznych lub zależnościach między modułami, ale nadal należy usuwać sekrety, dane klientów i niepotrzebne pliki. Zakres materiału powinien wynikać z zadania oraz zasad organizacji.

Czy ChatGPT zastąpi programistę Pythona?

Nie zastępuje odpowiedzialności za wymagania, architekturę, testy, bezpieczeństwo i utrzymanie systemu. Może przyspieszyć część pracy, ale to programista musi rozpoznać błędne założenia, ocenić kompromisy i zatwierdzić zmianę.

Jak najlepiej używać ChatGPT jako programista Pythona?

Traktuj ChatGPT jak narzędzie do przygotowywania hipotez i małych, sprawdzalnych zmian. Podawaj kontrakt zamiast ogólnego celu, wymagaj testów odzwierciedlających wymagania i wracaj z rzeczywistymi wynikami uruchomienia. Im lepsza jest Twoja pętla weryfikacji, tym większa szansa, że pomoc modelu skróci pracę zamiast dodać ukryty błąd.