Sztuczna inteligencja potrafi dziś napisać niemal każdy fragment aplikacji w kilka sekund. Nie oznacza to jednak, że nauka programowania stała się zbędna – zmieniło się to, czego warto się uczyć i jak wykorzystywać zdobytą wiedzę.

Jak zacząć uczyć się programowania w erze AI?

Jeszcze kilka lat temu stworzenie działającej aplikacji wymagało wielu tygodni nauki, pisania kodu, przeglądania dokumentacji i rozwiązywania błędów. Dzisiaj, korzystając z narzędzi opartych na sztucznej inteligencji, projekt, który wcześniej zajmował miesiąc, można zbudować nawet w dwa dni.

Czy to oznacza, że nie trzeba już uczyć się programowania?

Wręcz przeciwnie.

Zmieniło się jednak to, czego warto się uczyć i w jaki sposób wykorzystywać zdobytą wiedzę.

AI potrafi pisać kod, ale nie bierze za niego odpowiedzialności

Modele AI potrafią wygenerować kontroler API, model bazy danych, logowanie użytkowników, komponent interfejsu, testy, konfigurację Dockera, a nawet znaczną część całej aplikacji.

Problem polega na tym, że wygenerowany kod może:

działać tylko w prostym przypadku,
posiadać luki bezpieczeństwa,
nie radzić sobie z większym ruchem,
nieprawidłowo obsługiwać współbieżność,
tworzyć problemy z pamięcią,
być trudny w rozwijaniu,
zawierać błędne założenia architektoniczne.

Kod może się kompilować, aplikacja może się uruchamiać, a ekran może wyglądać poprawnie. To jednak nie oznacza jeszcze, że rozwiązanie jest dobre.

„AI zrobiło, działa, więc jest dobrze” — to obecnie jedno z największych zagrożeń dla początkujących programistów.

Podstawy nadal są potrzebne

W erze AI nadal trzeba wiedzieć, czym są i do czego służą:

programowanie obiektowe,
zasady SOLID,
klasy i obiekty,
interfejsy,
dziedziczenie i kompozycja,
konstruktory,
destruktory oraz finalizery,
typy danych,
zarządzanie pamięcią,
wielowątkowość,
synchronizacja dostępu do danych,
obsługa błędów,
testy,
bezpieczeństwo aplikacji.

Nie chodzi o to, aby każdą definicję recytować z pamięci. Trzeba jednak rozumieć konsekwencje podejmowanych decyzji.

Programista powinien wiedzieć, czym różni się long od float, dlaczego liczby zmiennoprzecinkowe nie zawsze nadają się do przechowywania pieniędzy oraz kiedy zastosować decimal, double, int lub long.

Powinien też rozumieć, kiedy metoda lub pole może być static, a kiedy powinno należeć do konkretnego obiektu.

static nie jest magicznym sposobem na łatwiejszy dostęp do kodu. Nadużywane może prowadzić do globalnego stanu, problemów z testowaniem, konfliktów między wątkami i trudnej do kontrolowania architektury.

Obiekt czy metoda statyczna?

Wyobraźmy sobie system płatności.

Możemy utworzyć statyczną metodę:

PaymentService.ProcessPayment(order);

Na początku wygląda to wygodnie. Z czasem okazuje się jednak, że potrzebujemy:

dostępu do bazy danych,
loggera,
konfiguracji,
różnych operatorów płatności,
testów jednostkowych,
osobnych ustawień dla różnych klientów.

W takim przypadku obiekt utworzony za pomocą konstruktora i mechanizmu dependency injection będzie najczęściej znacznie lepszym rozwiązaniem.

public class PaymentService
{
private readonly IPaymentProvider _paymentProvider;
private readonly ILogger<PaymentService> _logger;

public PaymentService(
IPaymentProvider paymentProvider,
ILogger<PaymentService> logger)
{
_paymentProvider = paymentProvider;
_logger = logger;
}
}

AI może wygenerować obie wersje. To programista musi ocenić, która z nich lepiej pasuje do projektu.

Trzeba rozumieć cykl życia obiektów

Konstruktor służy do przygotowania obiektu do działania. Może przyjmować zależności, ustawiać wymagane wartości i zabezpieczać obiekt przed powstaniem w niepoprawnym stanie.

Destruktor lub finalizer, zależnie od języka, jest związany ze zwalnianiem zasobów. W wielu współczesnych językach pamięcią zarządza garbage collector, ale nadal istnieją zasoby, których nie można pozostawić bez kontroli:

pliki,
połączenia sieciowe,
połączenia z bazą danych,
uchwyty systemowe,
strumienie,
blokady.

Dlatego trzeba rozumieć mechanizmy takie jak IDisposable, using, try/finally czy odpowiedniki dostępne w innych językach.

AI może poprawnie otworzyć plik. Nie zawsze poprawnie go zamknie w każdej możliwej ścieżce wykonania.

Lock i Semaphore to nie to samo

Przy prostych aplikacjach problemy ze współbieżnością mogą długo pozostawać niewidoczne. Pojawiają się dopiero wtedy, gdy z systemu zaczyna korzystać wielu użytkowników jednocześnie.

lock najczęściej pozwala zagwarantować, że tylko jeden wątek w danym momencie wykonuje chroniony fragment kodu.

lock (_syncObject)
{
balance -= amount;
}

Semaphore lub SemaphoreSlim pozwala natomiast określić, ile operacji może być wykonywanych równolegle.

Przykładowo aplikacja może zezwolić maksymalnie pięciu zadaniom na jednoczesne korzystanie z zewnętrznego API.

await _semaphore.WaitAsync();

try
{
await SendRequestAsync();
}
finally
{
_semaphore.Release();
}

Jeżeli programista nie rozumie różnicy pomiędzy tymi mechanizmami, może zaakceptować kod wygenerowany przez AI, który działa podczas lokalnego testu, ale przestaje działać pod większym obciążeniem.

W najgorszym przypadku może dojść do:

zakleszczenia,
utraty danych,
wielokrotnego wykonania tej samej operacji,
przekroczenia limitów zewnętrznej usługi,
niepoprawnego naliczenia salda,
trudnych do odtworzenia błędów produkcyjnych.

OOP i SOLID nie zniknęły

Zasady programowania obiektowego oraz SOLID bywają przedstawiane jako teoria oderwana od praktyki. W rzeczywistości są szczególnie przydatne właśnie podczas pracy z AI.

Model może wygenerować jedną klasę, która:

pobiera dane z bazy,
waliduje użytkownika,
wysyła wiadomość e-mail,
zapisuje logi,
nalicza płatność,
generuje dokument PDF.

Kod może działać, ale rozwijanie go szybko stanie się problemem.

Znajomość zasady pojedynczej odpowiedzialności pozwala zauważyć, że taka klasa robi zbyt wiele.

Znajomość dependency inversion pomaga ocenić, czy kod nie jest zbyt mocno związany z konkretną bazą danych, operatorem płatności albo biblioteką.

Znajomość open/closed principle pozwala projektować system tak, aby można było dodawać nowe funkcje bez ciągłego przepisywania istniejącego kodu.

AI przyspiesza implementację. SOLID pomaga sprawić, aby efekt tej implementacji nie rozsypał się po kilku kolejnych zmianach.

Najważniejszą umiejętnością jest dziś weryfikacja

Współczesny programista coraz rzadziej musi wpisywać każdą linię kodu ręcznie. Coraz częściej musi natomiast umieć odpowiedzieć na pytania:

Czy ta architektura będzie łatwa do rozwijania?
Czy dane użytkownika są właściwie zabezpieczone?
Czy hasła są hashowane, a nie szyfrowane lub zapisywane wprost?
Czy użytkownik może uzyskać dostęp do danych innej osoby?
Czy kod jest odporny na SQL Injection?
Czy aplikacja poprawnie waliduje dane wejściowe?
Czy tokeny i klucze nie trafiają do repozytorium?
Czy operacje są bezpieczne przy wielu jednoczesnych żądaniach?
Czy rozwiązanie nie wykonuje setek niepotrzebnych zapytań do bazy?
Czy aplikacja poradzi sobie z większą liczbą użytkowników?
Czy kod można przetestować?
Co stanie się, gdy zewnętrzne API przestanie odpowiadać?

AI potrafi wygenerować rozwiązanie. Programista musi umieć przeprowadzić jego przegląd.

Bezpieczeństwo nie może być dodatkiem

Bardzo łatwo poprosić AI o stworzenie logowania i autoryzacji. Trudniej ocenić, czy zostały wykonane poprawnie.

Wygenerowany system może:

używać zbyt słabego sekretu JWT,
nie sprawdzać właściciela zasobu,
zwracać zbyt wiele danych,
przechowywać poufne informacje w logach,
nie ograniczać liczby prób logowania,
ufać danym przesyłanym przez frontend,
posiadać nieprawidłowo skonfigurowany CORS,
ujawniać szczegóły błędów produkcyjnych.

Dlatego podczas nauki nie warto ograniczać się do pytania:

„Jak zrobić logowanie?”

Lepiej zapytać:

„Jakie zagrożenia występują w tym sposobie logowania, jak mogę je przetestować i dlaczego ta implementacja jest bezpieczna?”

To właśnie w ten sposób AI może stać się nauczycielem, a nie tylko generatorem kodu.

Wydajność również wymaga zrozumienia

Aplikacja może działać szybko dla jednego użytkownika, a przestać odpowiadać dla tysiąca.

AI nie zawsze wie:

ile danych znajduje się w bazie,
ilu użytkowników będzie korzystać z systemu,
jakie są limity infrastruktury,
czy dane powinny być cache’owane,
czy zapytanie wymaga indeksu,
czy operacja może być wykonywana asynchronicznie,
czy wynik powinien być stronicowany,
czy kod powoduje problem N+1,
czy obiekt zajmuje niepotrzebnie dużo pamięci.

Programista nie musi od pierwszego dnia być ekspertem od optymalizacji. Powinien jednak nauczyć się rozpoznawać miejsca, które mogą stać się problemem.

Jak uczyć się programowania z AI?

Najgorszą metodą jest poproszenie modelu o stworzenie całego projektu, skopiowanie kodu i uznanie zadania za zakończone.

Znacznie lepszy proces wygląda następująco.

1. Zacznij od małego problemu

Zamiast prosić o wykonanie kompletnego systemu rezerwacji, zacznij od pojedynczej funkcji:

dodawania rezerwacji,
sprawdzania dostępności terminu,
anulowania rezerwacji,
wysyłania potwierdzenia.

2. Spróbuj zaprojektować rozwiązanie samodzielnie

Przed wygenerowaniem kodu zastanów się:

jakie obiekty będą potrzebne,
jakie dane będą przechowywane,
gdzie powinna znajdować się logika,
jakie błędy mogą wystąpić,
które operacje wymagają zabezpieczenia.

3. Poproś AI o krytykę projektu

Zamiast od razu prosić o kod, przedstaw swój plan i zapytaj:

jakie posiada wady,
gdzie narusza SOLID,
jakie ma zagrożenia bezpieczeństwa,
jak zachowa się pod obciążeniem,
jakie przypadki brzegowe pomijasz.

4. Generuj kod etapami

Twórz osobno:

modele,
serwisy,
repozytoria,
kontrolery,
walidację,
testy.

Po każdym etapie analizuj wynik.

5. Każdy fragment kodu powinieneś umieć wyjaśnić

Jeżeli nie potrafisz wyjaśnić, dlaczego kod korzysta ze static, async, lock, interfejsu, konstruktora albo konkretnego typu danych, nie powinieneś jeszcze uznawać go za gotowy.

Poproś AI o wyjaśnienie, ale następnie sprawdź tę wiedzę w dokumentacji i w praktyce.

6. Celowo psuj rozwiązanie

Sprawdź, co się stanie, gdy:

użytkownik prześle błędne dane,
dwa żądania dotrą jednocześnie,
baza danych przestanie odpowiadać,
zewnętrzna usługa zwróci błąd,
plik będzie pusty,
lista będzie zawierała milion elementów,
użytkownik spróbuje odczytać cudze dane.

Właśnie wtedy zaczyna się prawdziwa nauka.

AI zmienia rolę programisty

Dawniej dużą część pracy zajmowało ręczne tworzenie powtarzalnego kodu. Dzisiaj można wygenerować go w kilka sekund.

Nie oznacza to jednak, że programista staje się niepotrzebny.

Jego rola przesuwa się z samego pisania kodu w stronę:

projektowania,
podejmowania decyzji,
weryfikowania,
testowania,
zabezpieczania,
optymalizowania,
łączenia różnych elementów systemu,
rozumienia potrzeb użytkownika i biznesu.

Największą przewagę nie będzie miała osoba, która całkowicie rezygnuje z AI. Nie będzie jej miała również osoba, która bezmyślnie akceptuje każdą wygenerowaną odpowiedź.

Największą przewagę będzie miał programista, który zna podstawy i potrafi dzięki AI pracować wielokrotnie szybciej.

Projekt w dwa dni zamiast miesiąca

AI rzeczywiście pozwala tworzyć rozwiązania znacznie szybciej.

Można w dwa dni przygotować prototyp, który dawniej powstawał przez miesiąc. Można szybciej testować pomysły, tworzyć MVP, automatyzować powtarzalne zadania i sprawdzać różne warianty produktu.

Trzeba jednak odróżnić:

prototyp od gotowego produktu,
kod działający od kodu bezpiecznego,
kod wygenerowany od kodu zweryfikowanego,
aplikację uruchomioną lokalnie od systemu gotowego na prawdziwych użytkowników.

AI skraca czas implementacji. Nie usuwa odpowiedzialności za efekt.

Podsumowanie

W erze sztucznej inteligencji nadal warto uczyć się programowania. Trzeba jednak robić to inaczej niż kilka lat temu.

Nie chodzi już wyłącznie o zapamiętywanie składni i ręczne pisanie każdego fragmentu aplikacji. Kluczowe staje się rozumienie:

architektury,
bezpieczeństwa,
wydajności,
typów danych,
cyklu życia obiektów,
współbieżności,
testowania,
zasad OOP i SOLID.

AI może napisać kod szybciej od człowieka. Człowiek nadal musi zdecydować, czy ten kod powinien znaleźć się w produkcji.

Ucz się podstaw, korzystaj z AI i nigdy nie kończ analizy na stwierdzeniu: „działa, więc jest dobrze”.

Dobrze wykorzystana sztuczna inteligencja nie zastępuje wiedzy programistycznej. Ona ją wzmacnia.