Asystenci AI w codziennej pracy programisty: kiedy pomagają, a kiedy przeszkadzają

Dwa lata temu dyskusja brzmiała “czy warto używać AI w programowaniu”. Dziś pytanie jest inne: jak używać, żeby faktycznie oszczędzać czas, a nie tworzyć sobie nowej kategorii problemów. Po kilkunastu miesiącach intensywnej pracy z różnymi asystentami (Claude Code, Copilot, Cursor) mam kilka obserwacji, które mogą zaoszczędzić Ci rozczarowań.

Gdzie AI realnie wygrywa

Boilerplate i rzeczy powtarzalne. Pisanie testów jednostkowych, generowanie migracji bazy danych, tworzenie struktur DTO, parsowanie obcego formatu XML do własnego modelu. To zadania, gdzie LLM jest szybszy od Ciebie kilkukrotnie i nie robi błędów.

Praca w nieznanym stacku. Kiedy musisz szybko ogarnąć framework, którego nie używałeś od roku, zapytanie asystenta jest szybsze niż przeglądanie dokumentacji. Nie zastępuje to zrozumienia, ale pozwala ruszyć z miejsca.

Refaktoryzacja rutynowa. Zmiana wszystkich var_dump na logger, dodanie type hintów do istniejącego kodu, konwersja z promise chains na async/await. Rzeczy, które zajmują godzinę, robią się w pięć minut.

Review własnego kodu. Przekazanie LLM-owi gotowego PR-a z prośbą o wskazanie potencjalnych problemów często wyłapuje edge case’y, których sam nie zauważyłeś.

Gdzie AI przeszkadza

Projektowanie architektury. LLM widzi fragment, nie całość. Kiedy pytasz “jak powinienem to ustrukturyzować”, dostajesz odpowiedź pasującą do generycznych wzorców, a nie do realiów Twojego projektu. Architekturę dalej projektujesz sam.

Kod bezpieczeństwa. Asystenci AI regularnie generują kod podatny na SQL injection, XSS czy niewłaściwą walidację uploadu plików, szczególnie kiedy prosisz o “prosty formularz kontaktowy” albo “endpoint do uploadu”. Wszystko, co dotyka granicy zaufania, przeglądam ręcznie linijka po linijce.

Debugowanie zaawansowanych problemów. Kiedy masz wyciek pamięci, deadlock albo dziwne zachowanie cache’u, LLM będzie strzelał coraz bardziej desperackie hipotezy. W tych sytuacjach profiler, logi i zdrowy rozsądek biją AI na głowę.

Kod, którego nie rozumiesz. Największe ryzyko: akceptujesz sugestię, bo “działa”, ale nie wiesz dokładnie dlaczego. Za pół roku, kiedy coś się zepsuje, masz w kodzie fragment, którego nikt w zespole nie jest w stanie sensownie utrzymać. Zasada jest jedna: jeśli nie rozumiesz każdej linijki, nie commituj.

Moja praktyka

Traktuję AI jak młodszego kolegę z zespołu, który wie dużo, pisze szybko, ale nie ma kontekstu biznesowego i czasem robi głupie błędy. Delegowanie mu prostych zadań uwalnia mi czas na rzeczy, w których faktycznie potrzeba myślenia. Code review robię tak samo skrupulatnie jak przy juniorze, może nawet bardziej, bo AI pisze pewniej niż junior, co łatwiej uśpić czujność.

Ubuntu 24.04 LTS na produkcji: co zyskujesz po migracji z 22.04

Ubuntu 24.04 “Noble Numbat” jest dostępny od prawie dwóch lat i większość zespołów DevOps ma już za sobą pierwsze wdrożenia. Jeśli wciąż trzymasz produkcję na 22.04, to dobry moment, żeby przemyśleć migrację. Wsparcie standardowe dla Jammy kończy się w 2027, ale nowe projekty zaczynane teraz na starej gałęzi to technologiczny dług od pierwszego dnia.

Nowe wersje stacka bez backportów

Największą zaletą 24.04 jest aktualny stack bez kombinowania z repozytoriami zewnętrznymi. PHP 8.3 w domyślnych pakietach, Nginx 1.24, OpenSSL 3.0, Python 3.12, Node.js 20 LTS. Dla wdrożeń Magento 2.4.8+ czy nowoczesnych aplikacji w Laravelu to oznacza koniec z dodawaniem PPA Ondreja Surý’ego tylko po to, żeby mieć aktualne PHP.

Lepsza wydajność I/O

Kernel 6.8 przynosi realne usprawnienia w io_uring oraz w obsłudze dysków NVMe. W testach na serwerach bazodanowych (MariaDB, PostgreSQL) widać różnicę rzędu kilkunastu procent przy intensywnych operacjach zapisu. To nie jest rewolucja, ale na serwerach obsługujących zatłoczone sklepy różnica jest zauważalna.

AppArmor 4.0 i większa domyślna izolacja

Nowa wersja AppArmor wprowadza bardziej restrykcyjne profile domyślne. Wymaga to odrobinę więcej uwagi przy konfiguracji własnych usług, ale zwiększa odporność na eskalację uprawnień po udanym włamaniu. W praktyce: jeśli napastnik dostanie się przez PHP-FPM, nie dostanie od razu dostępu do całego systemu plików.

Netplan jako standard

Konfiguracja sieci przez Netplan jest teraz jedyną domyślną opcją. Dla osób przyzwyczajonych do /etc/network/interfaces to zmiana mentalności, ale YAML-owa składnia jest czytelniejsza, a integracja z systemd-networkd znacznie lepsza przy bardziej złożonych topologiach (VLAN-y, bondy, bridge’e dla kontenerów).

Czego unikać przy migracji

Kilka rzeczy, które sprawdziłem na własnej skórze:

Nie migruj przez do-release-upgrade na produkcji. Postaw nowy serwer, przenieś dane, przetestuj, przełącz DNS. Upgrade in-place zawsze zostawia śmieci.
Sprawdź wersje klientów MySQL. MariaDB 10.11 w repozytoriach może być problemem, jeśli aplikacja oczekuje MySQL 8. Rozważ pakiety z repozytorium Percony.
PHP-FPM pule. Domyślna konfiguracja pm.max_children jest zachowawcza. Po migracji przelicz wartości pod realny RAM serwera.

5 najczęstszych luk bezpieczeństwa w sklepach e-commerce w 2026 roku

Ataki na sklepy internetowe w ostatnich miesiącach wyraźnie przyspieszyły. Napastnicy coraz rzadziej szukają spektakularnych exploitów. Zamiast tego polują na te same, banalne błędy, które administratorzy popełniają od lat. Poniżej pięć najczęstszych wektorów, z którymi spotykam się w praktyce podczas reagowania na incydenty.

1. Webshelle w katalogach uploadów

Klasyk, który nie odchodzi do lamusa. Napastnik wykorzystuje źle zabezpieczony endpoint REST API lub formularz uploadu, wrzuca plik PHP do pub/media albo wp-content/uploads, a następnie używa go jako furtki. Rozwiązanie jest proste: blokada wykonywania PHP w katalogach uploadów poprzez konfigurację serwera WWW (Nginx/Apache) oraz walidacja typu i zawartości plików na poziomie aplikacji.

2. Nieaktualne wtyczki i moduły

Szczególnie bolesne w ekosystemie WordPress/WooCommerce. Jedna zapomniana wtyczka sprzed trzech lat potrafi otworzyć drzwi do całej instalacji. Regularny audyt wtyczek, usuwanie nieużywanych oraz automatyczne aktualizacje to minimum, które powinno być standardem.

3. Ekspozycja REST API bez rate limitingu

Magento 2 i WooCommerce domyślnie udostępniają REST API, które przy złej konfiguracji staje się wektorem ataku. Brak ograniczeń liczby zapytań pozwala na brute-force na endpointy logowania lub masowy upload plików. Varnish VCL z normalizacją żądań plus fail2ban to rozwiązanie, które zajmuje godzinę, a ratuje dni pracy.

4. Słabe hasła panelu administracyjnego

Brzmi oczywiście, ale wciąż widzę w produkcji konta admin z hasłem admin123. Wymuszenie MFA dla kont administracyjnych oraz whitelista IP dla ścieżki /admin eliminują tę klasę ataków niemal całkowicie.

5. Brak monitoringu integralności plików

Większość infekcji pozostaje niezauważona tygodniami, bo nikt nie sprawdza, czy w katalogu z modułami nie pojawił się nowy plik. Narzędzia typu AIDE, Tripwire albo nawet prosty skrypt cron porównujący checksummy katalogów potrafią wykryć backdoor w kilka godzin od jego wrzucenia.