Czy korzystam z AI?
Oczywiście. Pytanie brzmi: jak?

„Korzystasz przy programowaniu z AI?”

To pytanie ostatnio pada dość często.

I za każdym razem mam ochotę odpowiedzieć innym pytaniem.

Korzystasz z kompilatora?

Korzystasz z debuggera? Z autouzupełniania w IDE? Ze wspomagania kierownicy?

A kiedy trzeba pociąć większą ilość drewna, bierzesz piłę spalinową czy ręczną, żeby przypadkiem ktoś nie uznał, że poszedłeś na łatwiznę? :D

Oczywiście, że korzystam z AI.

Bo AI jest narzędziem.

I moim zdaniem ciekawsze pytanie brzmi nie:

„Czy programista korzysta z AI?”

tylko:

„Co potrafi zrobić bez niego i czy rozumie to, co AI zrobiło za niego?”

Programiści korzystają z automatyzacji od zawsze

Programowanie nigdy nie polegało na wykonywaniu wszystkiego ręcznie.

Kompilator przejął tłumaczenie kodu źródłowego na postać wykonywalną. IDE podpowiada składnię, wyszukuje definicje i refaktoryzuje kod. Debugger pozwala zatrzymać program i zobaczyć, co dzieje się w środku.

Systemy kontroli wersji rozwiązują problemy, które wcześniej programista próbował rozwiązywać katalogami:

…nie pytajcie, skąd znam ten przykład :D

Później doszły frameworki, biblioteki, package managery, generatory kodu, statyczna analiza, CI/CD i tysiące innych narzędzi.

I jakoś nikt rozsądny nie mówi, że prawdziwy programista powinien sam napisać bibliotekę TLS, serwer HTTP i najlepiej jeszcze własny kompilator.

Abstrakcja i automatyzacja są częścią historii informatyki. Generatywna AI jest kolejnym narzędziem w tym szeregu.

Ale jest tutaj jedno bardzo ważne „ale”.

AI nie jest kompilatorem

Porównanie do kompilatora dobrze pokazuje, że użycie narzędzia nie odbiera człowiekowi kompetencji. Technicznie jest jednak niedoskonałe.

Kompilator wykonuje bardzo precyzyjnie zdefiniowaną operację. Model językowy generuje odpowiedź na podstawie wzorców poznanych podczas treningu i kontekstu, który właśnie dostał.

Może więc stworzyć świetną funkcję, dobry test albo sensowne wyjaśnienie błędu — a chwilę później wymyślić metodę biblioteki, która nigdy nie istniała.

I zrobić to z dokładnie taką samą pewnością siebie.

Dlatego AI jest dla mnie bardziej elektronarzędziem niż kompilatorem.

Piła spalinowa pozwala zrobić w godzinę coś, co ręczną zajęłoby pół dnia.

Ale nadal dobrze jest wiedzieć, którą stroną ją trzymać.

Czy AI rzeczywiście przyspiesza programowanie?

Tutaj robi się ciekawie, bo odpowiedź brzmi: tak — ale nie zawsze.

W kontrolowanym eksperymencie dotyczącym GitHub Copilota 95 programistów miało za zadanie napisać serwer HTTP w JavaScript. Grupa korzystająca z Copilota ukończyła zadanie średnio 55,8% szybciej niż grupa kontrolna.

To mocny wynik. Pokazuje, że w dobrze zdefiniowanym zadaniu generowanie kodu może realnie skrócić pracę.

Tyle że prawdziwe programowanie rzadko składa się wyłącznie z małych, izolowanych zadań.

A teraz AI spowalnia programistów o 19%

W 2025 roku METR przeprowadził zupełnie inny eksperyment.

Wzięto 16 doświadczonych programistów open source, którzy wykonali łącznie 246 rzeczywistych zadań we własnych, dojrzałych projektach. Repozytoria znali przeciętnie od około pięciu lat.

Część zadań wykonywali z dostępem do ówczesnych narzędzi AI, część bez nich.

Przed badaniem przewidywali, że AI skróci czas pracy o około 24%. Po badaniu nadal oceniali, że byli dzięki niemu około 20% szybsi.

Pomiar pokazał coś odwrotnego: z AI potrzebowali średnio 19% więcej czasu.

Najciekawsze nie jest nawet to, że AI ich spowolniło. Najciekawsze jest to, że byli przekonani, że ich przyspieszyło.

Czyli które badanie jest prawdziwe?

Oba.

I właśnie w tym tkwi problem z prostymi hasłami typu „AI zwiększa produktywność” albo „AI tylko przeszkadza”.

Jeśli zadanie polega na wygenerowaniu standardowego kodu, przygotowaniu struktury, napisaniu boilerplate'u albo znalezieniu rozwiązania typowego problemu, AI może być niezwykle szybkie.

Jeżeli jednak doświadczony programista porusza się po dużym systemie, którego architekturę zna od lat, musi zrozumieć zależności między wieloma elementami, a potem jeszcze zweryfikować wygenerowaną zmianę — koszt obsługi AI może zjeść całą oszczędność.

• napisz prompt,
• doprecyzuj kontekst,
• przeczytaj odpowiedź,
• sprawdź ją,
• popraw,
• wygeneruj jeszcze raz.

I funkcja, którą sam napisałbyś w dziesięć minut, powstaje przez piętnaście.

Granica możliwości AI jest poszarpana

Dobrym określeniem tego zjawiska jest jagged technological frontier — poszarpana granica możliwości technologii.

W eksperymencie przeprowadzonym z Boston Consulting Group badacze objęli 758 konsultantów wykonujących realistyczne zadania wiedzy.

W zestawie 18 zadań mieszczących się w zakresie możliwości GPT-4 osoby korzystające z AI wykonywały średnio 12,2% więcej zadań i kończyły je 25,1% szybciej, osiągając przy tym lepszą jakość.

Ale przygotowano także złożone zadanie znajdujące się poza możliwościami modelu.

Wtedy osoby wspierane przez AI były o 19 punktów procentowych mniej skłonne do uzyskania poprawnego rozwiązania niż osoby pracujące bez niego.

AI może więc być fantastyczne w zadaniu A, świetne w B, przeciętne w C i kompletnie wprowadzić człowieka w maliny w zadaniu D — mimo że D na pierwszy rzut oka wygląda podobnie.

Najtrudniejsze jest to, że przed rozpoczęciem pracy nie zawsze wiadomo, po której stronie tej granicy właśnie jesteśmy.

Im mniej wiesz, tym bardziej AI może pomagać. I tym bardziej może być niebezpieczne.

Badanie Brynjolfssona, Li i Raymond objęło 5 179 pracowników obsługi klienta korzystających z asystenta AI.

Średni wzrost produktywności wynosił około 14%. W grupie początkujących i słabiej radzących sobie pracowników poprawa sięgała około 34%, podczas gdy efekt u najbardziej doświadczonych był niewielki.

To ma sens. AI potrafi bardzo szybko dostarczyć mniej doświadczonej osobie wzorce i wiedzę, których sama musiałaby długo szukać.

W programowaniu działa to podobnie.

Nie pamiętasz składni? AI podpowie. Nie znasz biblioteki? Wyjaśni podstawy. Potrzebujesz przykładu? Dostaniesz go w kilka sekund.

Ale właśnie początkujący ma najmniejsze możliwości oceny, czy wygenerowana odpowiedź jest prawidłowa.

Doświadczony programista zobaczy: „chwila, tutaj mamy problem”. Początkujący może zobaczyć tylko: „działa”.

Programiści już korzystają z AI. Ale jej nie ufają.

Stack Overflow Developer Survey 2025 dobrze pokazuje ten paradoks.

84% respondentów korzystało albo planowało korzystać z narzędzi AI w procesie tworzenia oprogramowania. Wśród zawodowych programistów 51% używało ich codziennie.

Jednocześnie 46% deklarowało brak zaufania do poprawności odpowiedzi AI, a tylko 33% deklarowało zaufanie.

Najczęściej wskazywaną frustracją były rozwiązania, które są „prawie poprawne, ale nie do końca” — problem wskazało 66% respondentów. 45% narzekało też, że debugowanie kodu wygenerowanego przez AI potrafi zajmować więcej czasu.

Każdy, kto trochę z tym pracował, prawdopodobnie zna ten przypadek.

Pierwsze 90% rozwiązania pojawia się w kilkanaście sekund.

A potem przez pół godziny zastanawiasz się, dlaczego ostatnie 10% nie działa.

„Działa” to jeszcze nie to samo co „jest dobrze”

Jest jeszcze bezpieczeństwo.

W badaniu opublikowanym przed obecną falą znacznie nowszych modeli uczestnicy rozwiązujący zadania związane z bezpieczeństwem z pomocą asystenta opartego na Codexie tworzyli mniej bezpieczny kod niż grupa bez asystenta. Jednocześnie częściej byli przekonani, że napisany przez nich kod jest bezpieczny.

To starsze badanie i nie powinno być bezpośrednio przenoszone na każdy współczesny model. Mechanizm, który pokazuje, pozostaje jednak aktualny: pewność użytkownika nie jest testem poprawności kodu.

Nie oznacza to „nie używaj AI do programowania”.

Oznacza:

Kod wygenerowany przez AI jest kodem, który trzeba zreviewować, przetestować i za który ktoś musi wziąć odpowiedzialność.

Dokładnie tak samo jak kod napisany przez człowieka.

Tyle że AI potrafi produkować kod znacznie szybciej. A więc może również znacznie szybciej produkować błędy.

Dla mnie AI najlepiej sprawdza się jako drugi człowiek przy biurku

Nie taki, któremu mówię:

„Zrób mi aplikację. Wracam za godzinę.”

Raczej taki, któremu mogę powiedzieć:

• „zobacz ten fragment — tu dzieje się coś dziwnego, daj mi trzy hipotezy”,
• „potrzebuję zrobić X — jakie mamy sensowne możliwości?”,
• „sprawdź, czy czegoś tutaj nie przeoczyłem”,
• „napisz boilerplate, bo szkoda mi na niego czasu”,
• „przeczytaj ten błąd i pokaż, gdzie szukać”,
• „zrobiłem to tak — spróbuj znaleźć powód, dla którego to jest głupi pomysł”.

I właśnie wtedy robi się naprawdę użyteczne.

Nie jako wyrocznia.

Jako bardzo szybki partner do odbijania piłeczki.

Największym błędem jest oddanie AI odpowiedzialności

Można oddać narzędziu część pracy.

Nie powinno się oddawać mu odpowiedzialności.

Jeśli publikuję stronę klienta, nie mogę później powiedzieć:

„formularz wysyła dane w kosmos, ale AI tak napisało”.

Jeżeli aplikacja ma podatność, „model zaproponował tę bibliotekę” również nie jest szczególnie dobrą odpowiedzią.

Klient nie zatrudnia modelu.

Zatrudnia człowieka, który korzysta z narzędzi.

I to ten człowiek powinien wiedzieć, co zostało wdrożone.

Kompetencja potrzebna do kontroli narzędzia

Korzystając z kalkulatora, dobrze jest mniej więcej wiedzieć, czy 19 × 23 powinno dać wynik bliższy 400 czy 40 000.

Nie muszę wykonywać działania ręcznie.

Ale powinienem zauważyć wynik kompletnie absurdalny.

Z AI jest podobnie.

Im więcej oddajemy narzędziu, tym ważniejsza staje się umiejętność oceny jego odpowiedzi.

I paradoksalnie może się okazać, że AI najmocniej zwiększa możliwości człowieka wtedy, gdy ten potrafi zdecydować:

AI jako wzmacniacz

Podobny wniosek pojawia się w badaniach DORA dotyczących wykorzystania AI przy tworzeniu oprogramowania.

Raport State of AI-assisted Software Development 2025 opisuje główną rolę AI jako wzmacniacza: technologia potęguje istniejące mocne strony organizacji, ale również jej słabości.

Dobrze działający proces może dzięki niej działać szybciej.

Bałagan może dzięki niej produkować bałagan jeszcze szybciej.

I chyba jest to najlepsze podsumowanie całego tematu.

Czy korzystam z AI?

Tak.

Korzystam też z IDE. Z bibliotek napisanych przez innych ludzi. Z wyszukiwarki. Z dokumentacji. Z kompilatora. Z debuggera.

I nie widzę szczególnego powodu, żeby świadomie rezygnować z narzędzia, które w odpowiednim miejscu pozwala zrobić coś szybciej albo lepiej.

Ale jest zasadnicza różnica pomiędzy:

„użyłem AI, żeby zrobić tę pracę”

a:

„AI zrobiło coś, czego nie rozumiem, ale wygląda dobrze, więc publikuję”.

Pierwsze jest wykorzystaniem narzędzia.

Drugie jest hazardem.

Piła spalinowa nie sprawia, że przestajesz odpowiadać za to, gdzie upadnie drzewo. Wspomaganie kierownicy nie podejmuje za ciebie decyzji, gdzie skręcić.

A AI nie zwalnia człowieka z obowiązku rozumienia tego, co właśnie wypuszcza w świat.

Dlatego pytanie „czy korzystasz z AI?” jest dla mnie coraz mniej interesujące.

Czy bez AI potrafiłbyś ocenić, czy to, co AI właśnie zrobiło, jest dobre?

Bo dopóki odpowiedź brzmi tak, AI jest narzędziem.

Kiedy odpowiedź zaczyna brzmieć „nie wiem” — wtedy zaczyna się problem.