Jeszcze niedawno rozmowa o sztucznej inteligencji w programowaniu koncentrowała się głównie na jednym pytaniu: czy AI zabierze pracę programistom? W 2026 roku to pytanie zaczyna być zwyczajnie nieaktualne. AI już pisze kod, tworzy testy, analizuje repozytoria, proponuje poprawki, przygotowuje pull requesty, a coraz bardziej zaawansowane agenty potrafią wykonywać całe sekwencje zadań bez ręcznego prowadzenia developera krok po kroku.
Zmienił się więc problem.
Nie pytamy już tylko, czy AI potrafi programować.
Pytamy, kto odpowiada za oprogramowanie, które AI zaprogramowała.
I to jest znacznie ważniejsze pytanie.
Kodowanie stało się szybsze. Budowanie dobrego software'u - niekoniecznie
Warto zacząć od jednej rzeczy: nie ma sensu udawać, że AI w programowaniu jest chwilową modą. Nie jest.
Narzędzia AI coraz głębiej wchodzą w codzienny proces tworzenia oprogramowania. Z prostych podpowiedzi do pojedynczych fragmentów kodu przeszliśmy do agentów, którzy potrafią analizować większy kontekst projektu, modyfikować wiele plików, uruchamiać testy, reagować na błędy i przygotowywać zmiany do weryfikacji przez człowieka. Rynek narzędzi rozwija się właśnie w kierunku agentowego tworzenia oprogramowania, a nie tylko klasycznego autocomplete.
To ogromna zmiana produktywności.
Programista nie musi już pisać od zera każdego fragmentu kodu. Może przekazać AI zadanie, otrzymać pierwszą implementację, przetestować ją, poprawić i przejść do kolejnego problemu.
I właśnie tutaj pojawia się pewien paradoks.
Im łatwiej jest napisać kod, tym mniej wartości ma samo napisanie kodu.
Za to coraz więcej wartości ma odpowiedź na pytanie: co właściwie powinno zostać napisane, jak powinno działać i jak sprawdzić, czy zostało zrobione właściwie?
To jest różnica między generowaniem kodu a inżynierią oprogramowania.
"Działa" to dopiero początek
Każdy developer zna sytuację, w której coś działa. Endpoint zwraca odpowiedź. Formularz się wysyła. Rekord zapisuje się w bazie. Przycisk wykonuje akcję. Test przechodzi. Można więc powiedzieć: gotowe.
Tylko że dobry software engineering zaczyna się właśnie w tym momencie.
Bo później pojawiają się pytania:
- Czy rozwiązanie jest bezpieczne?
- Czy działa przy dużym obciążeniu?
- Co się stanie, gdy użytkownik poda nieoczekiwane dane?
- Czy obsługuje błędy?
- Czy można je łatwo rozszerzyć?
- Czy kolejny programista zrozumie ten kod za rok?
- Czy rozwiązanie jest zgodne z architekturą całego systemu?
- Czy nie powiela logiki znajdującej się już w innym miejscu?
- Czy nie tworzy długu technicznego?
- Czy test rzeczywiście sprawdza właściwe zachowanie, czy tylko potwierdza, że kod robi dokładnie to, co sam autor założył?
AI może pomóc odpowiedzieć na część tych pytań. Może też pomóc stworzyć testy, znaleźć potencjalne problemy czy zaproponować refaktoryzację. Ale nie zwalnia organizacji z odpowiedzialności za odpowiedź.
Najgroźniejszy kod to nie ten, który nie działa
Kod, który od razu się wywraca, jest stosunkowo łatwy do znalezienia.
Znacznie bardziej niebezpieczny jest kod, który działa wystarczająco dobrze, żeby trafić na produkcję, ale ma problemy, których nie widać na pierwszy rzut oka.
Może być niepotrzebnie skomplikowany. Może powielać fragmenty istniejącego rozwiązania. Może zawierać błędy związane z obsługą wyjątkowych przypadków. Może mieć problemy z wydajnością. Może wykorzystywać biblioteki lub wzorce, których zespół nie chce stosować w danym projekcie.
I może wyglądać bardzo profesjonalnie.
To właśnie jest jedna z pułapek generatywnego AI; Kod może być przekonujący, zanim będzie dobry.
Badanie Sonar opublikowane w 2026 roku wskazuje, że 53% badanych developerów przypisywało AI negatywny wpływ na technical debt poprzez generowanie kodu, który wyglądał poprawnie, ale okazywał się zawodny.
To nie oznacza, że AI tworzy wyłącznie zły kod.Oznacza coś znacznie bardziej praktycznego: większa ilość wygenerowanego kodu nie jest automatycznie większą ilością wartości.
AI może przyspieszyć także produkcję długu technicznego
Wyobraźmy sobie klasyczny projekt.
Przed AI developer potrzebował dwóch dni na stworzenie określonej funkcji. Po wdrożeniu narzędzi AI robi ją w pół dnia. Świetnie.
Ale co, jeśli jednocześnie liczba zmian w projekcie wzrośnie kilkukrotnie?
Co, jeśli zamiast jednej dobrze przemyślanej implementacji powstaje pięć podobnych?
Co, jeśli kolejne funkcje są dopisywane szybciej, niż zespół jest w stanie przeprowadzić refaktoryzację?
Co, jeśli kod jest regularnie generowany przez różne modele, z różnymi założeniami dotyczącymi architektury?
Wtedy AI nie tylko zwiększa produktywność. Może również zwiększyć tempo narastania długu technicznego.
Analiza GitClear obejmująca 211 mln linii kodu wskazuje na wzrost duplikacji kodu w analizowanym okresie, a autorzy raportu wiążą ten trend między innymi z popularyzacją AI-assisted coding. To nie jest dowód, że każda linia wygenerowana przez AI jest gorsza, ale jest mocnym sygnałem, że większa szybkość zmian wymaga równie mocnej kontroli jakości.
I tutaj dochodzimy do bardzo ważnej zasady: Jeżeli AI zwiększa tempo pisania kodu, proces jego weryfikacji również musi się rozwijać.
Nie można po prostu podwoić produkcji kodu i zostawić całej reszty procesu bez zmian.
"AI sama sprawdzi swój kod"
To brzmi kusząco. AI napisała funkcję. Inna AI ją sprawdzi. Jeszcze inna przygotuje testy.
Problem rozwiązany? - Niekoniecznie.
W 2026 roku coraz częściej obserwujemy nawet sytuacje, w których jeden agent tworzy kod, a drugi agent dokonuje jego review. Powstaje więc swoisty zamknięty obieg AI-to-AI: agent tworzy zmianę, drugi ją analizuje, a organizacja może zaakceptować wynik bez wystarczającego udziału człowieka. Badania nad takim modelem pokazują, że AI-to-AI code review rzeczywiście rośnie, choć nadal stanowi mniejszość analizowanej aktywności agentów.
To może być bardzo wartościowe. Ale ma też fundamentalne ograniczenie - dwie AI mogą popełnić ten sam rodzaj błędu.
Jeżeli agent tworzący kod przyjął błędne założenie biznesowe, agent dokonujący review może go nie zauważyć. Jeżeli oba systemy bazują na podobnych wzorcach, mogą również przeoczyć podobny problem.
Dlatego człowiek nadal potrzebuje być częścią procesu. Nie jako ktoś, kto ręcznie przepisuje kod. Jako ktoś, kto rozumie system, kontekst biznesowy, ryzyko i konsekwencje decyzji technicznych.
Programista przyszłości nie będzie pisał mniej odpowiedzialnie. Będzie odpowiadał za więcej
To bardzo ważna zmiana.
Można wyobrazić sobie developera, który dawniej spędzał 70% czasu na implementacji, a dziś dzięki AI może przeznaczyć znacznie więcej czasu na analizę, architekturę, testowanie, review i rozwiązywanie problemów.
To jest pozytywny scenariusz.
Programista nie musi być maszyną do pisania kodu. Może stać się jeszcze bardziej inżynierem. Problem pojawia się wtedy, gdy organizacja interpretuje wzrost produktywności wyłącznie jako możliwość zmniejszenia liczby godzin potrzebnych na wykonanie zadania.
Bo wtedy łatwo dojść do absurdalnego modelu: "Skoro AI zrobiła to w godzinę, to dlaczego wcześniej potrzebowaliśmy trzech dni?"
Tylko że te trzy dni mogły obejmować analizę, architekturę, testy, review, poprawki, integrację, dokumentację i wdrożenie.
Kod był tylko jednym elementem pracy.
A co z bezpieczeństwem?
Tutaj sprawa robi się jeszcze poważniejsza.
Wygenerowany kod może zawierać podatności, błędne założenia dotyczące autoryzacji, niewłaściwą walidację danych czy niebezpieczne wykorzystanie bibliotek.
Nie wystarczy więc powiedzieć: "Przecież AI sprawdziła kod".
Badania dotyczące AI-powered code review pokazują, że narzędzia tego typu nie powinny być traktowane jako zamiennik dedykowanych mechanizmów bezpieczeństwa i ręcznego audytu. W jednym z badań dotyczących GitHub Copilot Code Review autorzy wskazali problemy z wykrywaniem części istotnych podatności, między innymi SQL injection, XSS czy insecure deserialization.
To prowadzi do bardzo zdrowej zasady: AI może być elementem procesu bezpieczeństwa. Nie powinna być jedynym zabezpieczeniem tego procesu. Zwłaszcza gdy mówimy o aplikacjach przetwarzających dane klientów, płatności, dokumenty, dane pracowników czy informacje biznesowe.
Największy problem zaczyna się wtedy, gdy nie wiadomo, kto podjął decyzję
W tradycyjnym procesie można prześledzić zmianę.
Developer stworzył kod.
Pull request został przygotowany.
Ktoś go zreviewował.
Testy zostały wykonane.
Zmiana trafiła na produkcję.
W świecie agentowego programowania ten proces staje się bardziej skomplikowany. Agent może wykonać kilkadziesiąt operacji. Może zmienić wiele plików. Może wygenerować testy. Może sam poprawić błędy. Może przygotować pull request.
Dlatego coraz ważniejsze stają się zasady governance dla AI w procesie wytwarzania software'u.
Kto może uruchamiać agenta?
Do jakiego repozytorium ma dostęp?
Czy może zmieniać kod produkcyjny?
Czy może wykonywać migracje bazy?
Czy może instalować zależności?
Czy może korzystać z danych produkcyjnych?
Kto zatwierdza jego zmiany?
Czy każda zmiana ma ślad audytowy?
Czy można odtworzyć, dlaczego dana decyzja została podjęta?
To nie są pytania z kategorii "AI kiedyś będzie miała znaczenie". To są pytania dotyczące procesu tworzenia oprogramowania już teraz.
Nieprzypadkowo narzędzia dla zespołów developerskich zaczynają dodawać funkcje związane z kontrolą kontekstu, standardami kodowania, review agentów i monitorowaniem wykorzystania agentów. Sam fakt, że takie mechanizmy stają się częścią narzędzi developerskich, pokazuje kierunek rozwoju rynku: agent nie może być tylko "dodatkowym programistą", musi być elementem kontrolowanego procesu inżynierskiego.
"Vibe coding" jest świetne. Do pewnego momentu
Nie ma nic złego w eksperymentowaniu.
Chcesz stworzyć prototyp? AI jest fantastyczna.
Potrzebujesz szybko sprawdzić pomysł? Świetnie.
Chcesz zrobić proof of concept? Jeszcze lepiej.
Mały wewnętrzny automat? Być może AI zrobi większość pracy.
Problem pojawia się wtedy, gdy prototyp zaczyna być traktowany jak produkt.
Bo nagle: "zróbmy coś na szybko" zamienia się w: "podłączmy do tego CRM".
Potem: "dodajmy płatności".
Następnie: "niech korzysta z tego 500 użytkowników".
A miesiąc później: "dlaczego ten system działa tak wolno i dlaczego nikt poza autorem nie wie, jak go rozwijać?"
Prototyp może być szybki. Produkt musi być zaprojektowany. To ogromna różnica.
AI nie zabiera odpowiedzialności. Przesuwa ją wyżej
I to jest chyba najważniejszy wniosek całej dyskusji.
Jeżeli kiedyś programista odpowiadał przede wszystkim za poprawne napisanie kodu, dziś coraz częściej odpowiada za znacznie szerszy proces: rozumienie problemu, wybór rozwiązania, kontrolę jakości wygenerowanego kodu, bezpieczeństwo, testy, architekturę, utrzymywalność i zgodność z wymaganiami biznesowymi.
AI może wykonać część pracy. Ale nie powinna automatycznie przejmować odpowiedzialności.
Zresztą aktualne wydarzenia w świecie AI pokazują, że problem kontroli nie dotyczy już wyłącznie teorii. W ostatnich dniach pojawiły się informacje o incydentach związanych z działaniem agentów AI w środowiskach programistycznych, w tym o agentach OpenAI, które miały ingerować w RubyGems podczas działań testowych. OpenAI potwierdziło udział swoich agentów i prowadziło wyjaśnienia dotyczące zdarzenia.
To bardzo dobry przykład tego, dlaczego wraz ze wzrostem autonomii AI rośnie znaczenie ograniczeń dostępu, sandboxingu, monitoringu i kontroli człowieka.
AI może mieć dostęp do kodu. Nie oznacza to jeszcze, że powinna mieć dostęp do wszystkiego.
Co więc powinien robić dobry software house?
Przede wszystkim nie udawać, że AI nie istnieje. Wręcz przeciwnie.
Warto wykorzystywać ją tam, gdzie realnie zwiększa produktywność zespołu: przy analizie kodu, prototypowaniu, dokumentacji, testach, refaktoryzacji, generowaniu powtarzalnych elementów czy analizie problemów.
Ale jednocześnie trzeba zachować klasyczne zasady inżynierii oprogramowania.
Architektura nadal ma znaczenie.
Code review nadal ma znaczenie.
Testy nadal mają znaczenie.
Bezpieczeństwo nadal ma znaczenie.
Dokumentacja nadal ma znaczenie.
Doświadczenie developera nadal ma znaczenie.
A przede wszystkim nadal ma znaczenie człowiek, który potrafi powiedzieć: "Tak, AI wygenerowała ten kod. Ale zanim go wdrożymy, sprawdźmy, czy w ogóle powinniśmy go tak napisać."
Najdroższe może być nie to, ile zapłacisz za napisanie kodu
To jest perspektywa, którą warto zmienić.
Jeżeli AI pozwala stworzyć funkcję za ułamek wcześniejszego czasu, to świetnie. Ale koszt software'u nie kończy się na jego pierwszym wdrożeniu.
System będzie rozwijany.
Będzie integrowany z kolejnymi usługami.
Będą zmieniały się wymagania.
Pojawią się nowe urządzenia, przeglądarki, systemy płatności, przepisy i potrzeby klientów.
Ktoś będzie musiał wrócić do kodu po roku.
Ktoś będzie musiał znaleźć błąd o 2:00 w nocy.
Ktoś będzie musiał wykonać migrację.
Ktoś będzie musiał zabezpieczyć system.
I wtedy okaże się, czy firma rzeczywiście zaoszczędziła na szybkim tworzeniu software'u, czy tylko przesunęła koszt na później.
Dlatego prawdziwa wartość nie polega na tym, żeby AI napisała jak najwięcej kodu.
Wartość polega na tym, żeby dzięki AI zbudować lepszy software szybciej, bez utraty kontroli nad tym, co zostało zbudowane.
W Web24 patrzymy na AI jak na narzędzie, nie jak na zastępstwo dla inżynierii
AI może być świetnym członkiem zespołu.
Może przyspieszać pracę.
Może przejmować powtarzalne zadania.
Może pomagać programistom analizować ogromne ilości kodu.
Może skrócić drogę od pomysłu do pierwszego działającego rozwiązania.
Ale między "działa" a "jest gotowe do życia przez następne pięć lat" znajduje się ogromna przestrzeń.
To właśnie tam zaczyna się prawdziwa inżynieria oprogramowania. Bo dzisiaj coraz łatwiej jest wygenerować kod. Trudniej jest zbudować system, za który można spokojnie wziąć odpowiedzialność. I być może właśnie to będzie jedną z najważniejszych kompetencji software house'ów w kolejnych latach.
Nie samo pisanie kodu.
Nie samo korzystanie z AI.
Ale umiejętność połączenia AI, doświadczenia człowieka, architektury, bezpieczeństwa i odpowiedzialności za cały system.
