Programowanie z AI: co realnie zmienia się w pracy programisty
Programowanie z AI nie usuwa pracy programisty — przesuwa ją. Tanieje pisanie kodu, drożeje specyfikowanie, przeglądanie i decydowanie o architekturze. Największym ryzykiem jest przyjmowanie generowanego kodu bez weryfikacji, bo pewność siebie rośnie szybciej niż jakość.
Co tanieje, a co drożeje
| Umiejętność | Kierunek | Dlaczego |
|---|---|---|
| Pisanie kodu z pamięci | Tanieje | Model zna składnię lepiej niż ty |
| Znajomość API konkretnej biblioteki | Tanieje | Podpowiedź jest natychmiastowa |
| Precyzyjne formułowanie wymagań | Drożeje | Niedopowiedzenie staje się błędem w kodzie |
| Czytanie cudzego kodu | Mocno drożeje | Większość kodu w projekcie napisał ktoś inny — model |
| Projektowanie granic systemu | Mocno drożeje | Model optymalizuje lokalnie |
| Debugowanie nieoczywistych błędów | Drożeje | Kod, którego nie pisałeś, znasz gorzej |
Przegląd kodu jako główna czynność
Skoro 92% deweloperów używa narzędzi AI codziennie, a tylko około 29% ufa ich wynikom, przegląd przestał być etapem po pracy i stał się pracą. Dobry przegląd generowanego kodu wygląda inaczej niż przegląd kodu kolegi: nie szukasz nieuwagi, tylko przekonująco wyglądających wymysłów.
- Sprawdź, czy wywoływane funkcje i pola faktycznie istnieją — to najczęstszy rodzaj wymysłu.
- Sprawdź obsługę błędów. Modele domyślnie piszą ścieżkę optymistyczną.
- Sprawdź autoryzację po stronie serwera, nawet jeśli interfejs ukrywa przycisk.
- Sprawdź, czy zmiana nie ruszyła plików spoza zakresu, o który prosiłeś.
- Sprawdź zależności: nowa paczka w package.json to decyzja, nie szczegół.
Czego nie oddawać modelowi
Są decyzje, których koszt błędu jest asymetryczny — poprawka po fakcie kosztuje wielokrotnie więcej niż zastanowienie się wcześniej. To one zostają po stronie człowieka: wybór licencji i zależności, model uprawnień, schemat danych, granice między usługami oraz to, co w ogóle budujecie.
Reszta może iść szybko. Rozróżnienie tych dwóch kategorii jest dziś ważniejszą kompetencją niż znajomość jakiegokolwiek konkretnego narzędzia.
Praktyczny punkt startowy
Jeśli programowanie z AI ma dawać realną przewagę, najwięcej zyskujesz nie na szybszym pisaniu, tylko na tym, że nie zaczynasz od zera. Dobrze dobrany projekt open source daje architekturę, licencję i listę znanych problemów — a katalog RepoLoot opisuje każdy z nich pod kątem tego, co można na nim zbudować i jak trudne będzie wdrożenie.
Najczęstsze pytania
- Czy AI zastąpi programistów?
- Nie w tej formie, ale przesuwa punkt ciężkości pracy. Tanieje pisanie kodu i znajomość API, drożeje precyzyjne formułowanie wymagań, czytanie cudzego kodu i projektowanie granic systemu.
- Jak przeglądać kod wygenerowany przez AI?
- Szukaj przekonująco wyglądających wymysłów, nie nieuwagi: sprawdź, czy wywoływane funkcje i pola istnieją, czy obsłużone są błędy, czy autoryzacja jest po stronie serwera, czy zmiana nie ruszyła plików spoza zakresu i czy nowe zależności są uzasadnione.
- Czego nie należy oddawać modelowi AI?
- Decyzji o asymetrycznym koszcie błędu: wyboru licencji i zależności, modelu uprawnień, schematu danych, granic między usługami oraz tego, co w ogóle budujecie.