Quo vadis, inżynierze?

Nigdy tak wielu nie tworzyło oprogramowania, którego nie rozumie

Wiem, jak to zdanie brzmi. Jak początek wykładu starszego pana, który zaraz powie młodzieży, że kiedyś to było. Obiecuję, że nie o to chodzi - piszę ten tekst, bo sam korzystam z tych narzędzi codziennie i bardzo je lubię. Właśnie dlatego uważam, że komuś, kto spędził w tej branży ponad dwadzieścia lat, wypada powiedzieć głośno kilka rzeczy, o których na co dzień wygodniej milczeć.

Zacznijmy od skali, bo ona zmienia wszystko. Kiedy Andrej Karpathy pisał w lutym 2025 roku o vibe codingu - poddajesz się wibracjom, przyjmujesz wszystko, co proponuje model, i zapominasz, że kod w ogóle istnieje - brzmiało to jak opis weekendowej zabawy i tak było to pomyślane. Niecałe półtora roku później Google deklaruje, że sztuczna inteligencja generuje już około trzech czwartych nowego kodu w firmie, z ludzkim przeglądem na końcu (Business Insider, kwiecień 2026). Jesienią 2024 była to jedna czwarta. Taka krzywa nie zna słowa „eksperyment“.

I to samo dzieje się piętro niżej, poza działami IT. Ktoś w zakupach składa sobie panel do analizy dostawców. Ktoś w finansach skleja przez weekend integrację z bankiem. Wszystko działa, wszyscy są zadowoleni. A pytania o to, kto to utrzyma, kto to zabezpieczy i kto za to odpowie, wiszą w powietrzu i czekają na swój moment. Zwykle przychodzi on w najmniej wygodnej chwili.

No i tu dochodzimy do Was. Bo skoro działający system może dziś złożyć każdy, to po co komu człowiek, który latami uczył się, jak systemy buduje się naprawdę?

Może rzeczywiście nie potrzeba inżyniera

Powiem to uczciwiej, niż wypada człowiekowi, który prowadzi firmę inżynierską: do wielu rzeczy inżynier rzeczywiście przestał być potrzebny. I dobrze.

Do prototypu? Nie jest potrzebny. Do wewnętrznego narzędzia dla dziesięciu osób? Zwykle też nie. Do sprawdzenia pomysłu, zanim ktoś wyda na niego budżet? Tu wręcz szkoda inżyniera, niech pomysł najpierw udowodni, że zasługuje na jego czas. To jest realna zmiana na lepsze i udawanie, że jej nie ma, ośmiesza naszą branżę bardziej niż najgorszy vibe coding.

Inżynier staje się potrzebny dokładnie w tej chwili, w której system zaczyna coś znaczyć. Kiedy przechodzą przez niego prawdziwe pieniądze, prawdziwe dane osobowe, prawdziwa produkcja. Kiedy ma działać także drugiego stycznia o trzeciej w nocy, po awarii łącza, przy zdublowanym rekordzie i przy księgowej, która czeka na zamknięcie miesiąca. Granica nie przebiega między tym, kto umie kodować, a tym, kto nie umie. Przebiega między „złożyłem coś, co działa“ a „rozumiem, dlaczego to działa i wiem, kiedy przestanie“.

Złudzenie tempa

Teraz historia, która powinna trafić do podręczników - i to wcale nie dlatego, że stawia AI w złym świetle.

W lipcu 2025 ośrodek badawczy METR opublikował wyniki kontrolowanego eksperymentu. Doświadczeni programiści open source pracowali nad zadaniami we własnych, dobrze znanych projektach, raz z narzędziami AI, raz bez. Przed startem szacowali, że AI przyspieszy ich o jedną czwartą. Po zakończeniu byli przekonani, że przyspieszyło ich o jedną piątą. A pomiar pokazał, że z AI ich zadania trwały o 19 procent dłużej.

Ciąg dalszy jest jeszcze ciekawszy. W lutym 2026 METR ogłosił, że kolejna runda badania wskazuje już na przyspieszenie, ale wyników nie jest w stanie traktować jako wiarygodnych - między innymi dlatego, że coraz trudniej znaleźć programistów gotowych pracować bez AI, mimo wynagrodzenia płaconego w badaniu. Narzędzia w rok zdążyły się poprawić, a badani zdążyli się od nich uzależnić na tyle, że eksperyment przestał się kleić. Badacze rozkładają ręce i projektują metodę od nowa.

Co z tego wynika dla nas? Nie to, że AI nie działa. Wynika z tego coś ważniejszego: nawet ludzie, którzy zawodowo mierzą takie rzeczy, mają kłopot ze złapaniem prawdy o naszym tempie. A my, w codziennej pracy, oceniamy je po prostu na czuja. Praca z modelem daje cudowne poczucie płynności - coś się dzieje, ekran się zapełnia, zadania się zamykają. Tylko że to poczucie, jak pokazał METR, potrafi rozjechać się z rzeczywistością o czterdzieści punktów procentowych. Jeżeli aż tak mylimy się co do własnej szybkości, to jak bardzo mylimy się co do jakości tego, co przyjmujemy bez czytania?

Nożyce się rozwierają

Z tych obserwacji składa się mechanizm, który uważam za najważniejszą zmianę na rynku kompetencji od dekady. Opowiem go na dwóch osobach.

Pierwsza to architektka, która zna swoje rzemiosło od podszewki. Dla niej te narzędzia są dźwignią, o jakiej nie śniła: sprawdzi trzy warianty architektury przed obiadem, wygeneruje szkielet integracji w godzinę, przejrzy cudzy moduł szybciej, niż kiedyś czytała jego dokumentację. Wie, o co poprosić, i natychmiast widzi, kiedy dostała bzdurę. AI podnosi jej sufit.

Druga osoba fundamentów nie ma i model produkuje na jej zamówienie rzeczy, których nie umie ocenić, w tempie, za którym nie nadąża jej zrozumienie. Jej AI obniża podłogę - im sprawniej generuje, tym szybciej rośnie góra rzeczy przyjętych na wiarę.

Nożyce się rozwierają. Kod stał się tani, a osąd zdrożał - i to jest, moim zdaniem, cała ekonomia tego zawodu w jednym zdaniu.

Najbardziej martwię się przy tym nie o seniorów, tylko o dwie inne grupy. O juniorów, którym vibe coding podkrada okazję do terminowania w zawodzie, bo nikt już nie chce płacić za pisanie tego, co model wypluje w minutę - a przecież właśnie na tym pisaniu my wszyscy uczyliśmy się rozumienia. I o tych doświadczonych, którzy przestali czytać, bo „przecież działa“. Rzemieślnik, który przestaje dotykać materiału, traci wyczucie powoli i bezboleśnie. Orientuje się dopiero wtedy, gdy jest naprawdę potrzebny.

Pod spodem nie ma nikogo

Dochodzimy do części, przez którą ten felieton w ogóle powstał: do bezpieczeństwa. A właściwie do jego złudzenia.

Veracode co roku sprawdza, jak modele radzą sobie z pisaniem bezpiecznego kodu - w programie badawczym, który objął już łącznie ponad sto modeli. Wynik z raportu 2026 (lipiec 2026): 44 procent prób generowania kończy się kodem z podatnością ze znanych kategorii OWASP. I uwaga, bo tu siedzi najważniejsza obserwacja tego roku. Ten wynik praktycznie nie drgnął od zeszłego roku, choć modele w tym czasie wyraźnie zmądrzały. Piszą coraz lepszy kod. Nie piszą bezpieczniejszego. Bezpieczeństwo nie poprawia się „przy okazji“ - trzeba o nie poprosić, a potem sprawdzić, czy prośba została spełniona.

Idźmy głębiej, bo pod kodem jest jeszcze łańcuch dostaw. Modele wymyślają nazwy bibliotek, których nie ma - według badań prezentowanych na USENIX Security 2025 dotyczy to mniej więcej co piątej sugestii pakietu. Napastnicy nauczyli się te wymyślone nazwy rejestrować z wyprzedzeniem i podkładać pod nie złośliwy kod. Zjawisko doczekało się nazwy slopsquatting i pierwszych żywych przypadków. Zainstalujecie taki pakiet jednym enterem, bo przecież model go polecił.

A agenci z dostępem do infrastruktury dopisali do tej listy własny rozdział. Latem 2025 agent Replita usunął produkcyjną bazę danych podczas ogłoszonej blokady zmian, po czym generował dane maskujące problem. W kwietniu 2026 agent w Cursorze, poproszony o zadanie na środowisku testowym, znalazł w plikach produkcyjny token i w dziewięć sekund skasował produkcyjny wolumen razem z kopiami zapasowymi. Dwa różne narzędzia, ten sam wzorzec: intencja była testowa, uprawnienia były produkcyjne, a bramki z człowiekiem nie było żadnej.

Wszystkie te wektory łączy jedno, i to jest myśl, którą chciałbym, żebyście z tego tekstu zapamiętali: wygenerowany system zawsze sprawia wrażenie kompletnego. Demo wygląda znakomicie, interfejs bywa ładniejszy niż w niejednym komercyjnym produkcie, odpowiedzi przychodzą płynnie. Wrażenie kompletności to najtańsza rzecz, jaką produkuje AI. Pod spodem może być solidna konstrukcja, a może być sklejka z podatności, zależności nieznanego pochodzenia i sekretów wpisanych na twardo. Z zewnątrz tego nie odróżnicie. To widać tylko od środka - a od środka nikt nie zaglądał.

Shadow IT drugiej generacji

W firmach ten mechanizm ma już swoją dojrzałą postać. Kiedyś biznes kupował sobie SaaS na firmową kartę, poza wiedzą działu IT, i nazywaliśmy to shadow IT. Dziś biznes sam sobie oprogramowanie generuje. Mechanizm ten sam, tylko stawka zupełnie inna, bo własnoręcznie wygenerowane narzędzie potrafi mieć dostęp do danych, o jakich SaaS sprzed dekady mógł pomarzyć.

To już nie jest przeczucie, tylko policzone zjawisko. IBM w raporcie Cost of a Data Breach 2025 podaje, że co piąte badane naruszenie danych miało związek z niekontrolowanymi narzędziami AI, a tam, gdzie shadow AI kwitło, średni koszt naruszenia rósł o kilkaset tysięcy dolarów. Większość organizacji przyznaje przy tym, że polityk użycia AI po prostu nie ma. Nie dlatego, że nikt nie chce - dlatego, że tempo adopcji wyprzedziło wszystkich.

Co się nie zdewaluowało

Skoro samo pisanie kodu tanieje z miesiąca na miesiąc, tym cenniejsze staje się nazwanie tego, co nie staniało ani o grosz.

Nie staniało myślenie systemowe - umiejętność zobaczenia całości, od warstwy sieciowej przez systemy i bazy po aplikację i integracje, i przewidzenia, gdzie ta całość pęknie przy dziesięciokrotnym obciążeniu. Model widzi pliki, które mu pokażecie. Człowiek widzi architekturę razem z jej historią, kompromisami i długiem, którego nie ma w żadnym repozytorium.

Nie staniało diagnozowanie. Kiedy o trzeciej w nocy klaster odmawia współpracy, a monitoring uparcie pokazuje zieleń, różnica między „umiem wygenerować playbook“ a „wiem, jak działa DNS, i coś mi mówi, że to certyfikat“ to różnica między kwadransem a dobą przestoju. Tego przeczucia nie da się pobrać. Ono się osadza, latami, po jednej awarii na raz.

Nie staniała odpowiedzialność. Ktoś musi podpisać się pod systemem przed zarządem, przed audytorem, przed regulatorem. Model tego nie zrobi - nie dlatego, że prawo nie nadąża, tylko dlatego, że odpowiedzialność wymaga kogoś, kto rozumie konsekwencje i może za nie odpowiedzieć stanowiskiem albo reputacją.

I nie staniał inżynierski gust: to trudne do nazwania coś, co każe powiedzieć „działa, ale tak tego nie zrobimy“. Gust bierze się wyłącznie z przeczytanych, naprawionych i utrzymanych systemów. Jest efektem ubocznym rozumienia i dlatego nie da się go wygenerować.

Nowy warsztat

Jak w takim razie wygląda warsztat inżyniera, który chce być wart swojej stawki w 2026 roku? Podzielę się swoją listą - krótką i na pewno niepełną, potraktujcie ją jako zaproszenie do sporu, nie jako wyrocznię.

Pierwsza rzecz: dekompozycja i specyfikacja. Model robi dokładnie to, o co go poproszono, więc cała wartość przeniosła się do umiejętności poproszenia o właściwą rzecz - rozbicia problemu na części, nazwania warunków brzegowych, powiedzenia wprost, co znaczy „gotowe“. To stara, dobra inżynieria wymagań, tyle że uprawiana teraz codziennie, a nie raz na projekt.

Druga: czytanie kodu jako główna czynność zawodowa. Przez dwadzieścia lat przegląd kodu był dodatkiem do pisania. Ta proporcja właśnie się odwróciła - rdzeniem pracy staje się czytanie i ocenianie maszynowej produkcji. Wiem, że to dla wielu z nas trudna wiadomość, bo pisanie po prostu sprawia więcej frajdy. Ale kto nie polubi czytania, ten będzie w tym zawodzie cierpiał.

Trzecia: bezpieczeństwo jako odruch, nie jako etap na końcu. Skąd pochodzi ten pakiet? Co naprawdę robi ta zależność? Gdzie leżą sekrety? Jakie uprawnienia dostał agent i co się stanie, kiedy ktoś wstrzyknie mu instrukcję przez dane, które przetwarza? Te pytania trzeba zadawać w trakcie pracy, bo po fakcie zadaje je już ktoś inny - zwykle w raporcie z incydentu.

I czwarta, moja ulubiona: fundamenty. Sieci, protokoły, systemy operacyjne, bazy, kryptografia. Brzmi jak program studiów sprzed dwudziestu lat? To właśnie jest puenta. Wiedza, która miała się zdezaktualizować, okazała się jedynym narzędziem oceny tego, co produkuje model. Fundamenty nie są nostalgią. Są warunkiem korzystania z nowości.

Zauważcie, czego na tej liście nie ma. Nie ma „prompt engineeringu“. Rozmawiać z modelem nauczycie się w tydzień, serio. Całej reszty uczy się latami - i właśnie dlatego cała reszta jest coś warta.

Pięć pytań, zanim wpuścicie wygenerowany kod na produkcję

Ta lista nie zmieściła się w 12-stronicowej wersji PDF tego felietonu (znajdziecie ją na końcu wpisu), a jest jego najbardziej praktyczną częścią. Pięć pytań, które w SNOK zadajemy przy przeglądzie bezpieczeństwa każdego systemu z dużym udziałem kodu generowanego. Żadne nie wymaga narzędzi za milion, każde wymaga człowieka, który rozumie odpowiedź.

1. Kto przeczytał ten kod i co z tego czytania wynikło? Nie „kto uruchomił testy“, tylko kto przeczytał. Jeżeli odpowiedź brzmi „nikt“, macie na produkcji tekst nieznanego autorstwa o nieznanych właściwościach. Nazwanie tego wprost zwykle wystarcza, żeby przegląd sam się zorganizował.

2. Skąd pochodzi każda zależność i kto by zauważył, gdyby zniknęła albo zmieniła właściciela? Lista zależności wygenerowanego projektu bywa dłuższa niż sam projekt. Sprawdźcie, czy wszystkie pakiety w ogóle istnieją dłużej niż pół roku - to najprostszy filtr na slopsquatting.

3. Gdzie leżą sekrety? W kodzie generowanym w pośpiechu klucze i hasła lądują na twardo w plikach zaskakująco często, bo tak jest najkrócej, a model optymalizuje pod „działa“. Jedno przeszukanie repozytorium potrafi zepsuć humor na cały tydzień.

4. Co ten system może zrobić w najgorszym razie i kto mu na to pozwolił? Dotyczy zwłaszcza agentów: jakie mają uprawnienia, do jakich danych sięgają, co się stanie, gdy ktoś wstrzyknie im instrukcję przez treść, którą przetwarzają. Uprawnienia nadane „na chwilę, do testów“ mają brzydki zwyczaj zostawać na zawsze.

5. Kto to utrzyma za rok? Autor narzędzia z działu zakupów awansuje, odejdzie albo straci zapał. System zostanie. Jeżeli nikt nie umie wskazać właściciela z imienia i nazwiska, to nie jest system, tylko przyszły incydent z odroczonym terminem.

Jeżeli na trzy z pięciu pytań odpowiedź brzmi „nie wiemy“, to nie znaczy, że trzeba wszystko wyłączyć. Znaczy, że warto zrobić inwentaryzację, zanim zrobi ją za Was audytor albo napastnik - z tych dwóch audytor jest zdecydowanie przyjemniejszy.

Jak się w tym odnaleźć

Na koniec trzy rady, których sam się trzymam. Nie piszę ich z pozycji sceptyka - prowadzę firmę, w której AI pracuje na każdym poziomie i przynosi nam realną wartość. Piszę je jako ktoś, kto chce z tych narzędzi korzystać jeszcze za dziesięć lat, na własnych warunkach.

Używajcie AI codziennie, ale w trybie pilota, nie pasażera. Różnica jest prosta: pilot wie, dokąd leci, i co chwilę zerka na przyrządy. Pasażer ma wygodnie, ogląda chmury i nie ma żadnego wpływu na lądowanie. Obaj lecą tym samym samolotem.

Raz w tygodniu przeczytajcie do dna coś, co model dla Was wygenerował. Do dna - czyli razem z zależnościami, z konfiguracją, z pytaniem „dlaczego akurat tak“. To najtańszy trening osądu, jaki znam, i najszybszy sposób, żeby odkryć, ile rzeczy ostatnio przyjęliście na wiarę. Wynik bywa otrzeźwiający, mówię z doświadczenia.

I pielęgnujcie przynajmniej jedną domenę, w której jesteście głębiej niż model. Wszystko jedno, czy to będzie HANA, BGP, czy księgowość projektowa. Głębia w jednym miejscu daje rzecz bezcenną: punkt odniesienia. Wiecie wtedy, jak smakuje prawdziwe zrozumienie - i natychmiast czujecie, kiedy w innym obszarze go Wam brakuje.

Dokąd zmierzasz, inżynierze

Tytułowe pytanie zostawiłem na koniec, bo odpowiedź jest krótsza niż cały ten tekst.

Przez trzydzieści lat można było uważać, że inżynieria to pisanie kodu i konfigurowanie systemów, a rozumienie przychodzi samo, przy okazji. AI właśnie zabrało nam tę wygodną wersję zawodu. Maszyny przejęły pisanie - najłatwiejszą część tej pracy, dlatego automatyzacja zaczęła właśnie od niej. Nie przejęły rozumienia, rozstrzygania ani odpowiedzialności. I nic nie wskazuje, żeby miały je przejąć w cenie tokena.

Więc dokąd zmierzasz, inżynierze? Moja odpowiedź: w głąb własnego zawodu. Bliżej fundamentów, bliżej architektury, bliżej odpowiedzialności. Tam jest dziś więcej pracy niż kiedykolwiek - i, pierwszy raz od dawna, znacznie mniej tłoku.

Pobierzcie felieton w PDF

Źródła

• Andrej Karpathy, wpis o „vibe coding“, X/Twitter, luty 2025
• Business Insider, „Google says AI now generates about 75% of new code…“, 22.04.2026
• METR, „Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity“, 10.07.2025
• METR, „We are Changing our Developer Productivity Experiment Design“, 24.02.2026
• Veracode, „2026 GenAI Code Security Report“, lipiec 2026 (pass rate 56 procent, ok. 44 procent zadań z podatnością; wynik płaski rok do roku)
• USENIX Security 2025, badania nad halucynowanymi nazwami pakietów (ok. 20 procent sugestii); zjawisko slopsquatting
• Sprawa SaaStr/Replit, lipiec 2025 - The Register, Fortune
• Sprawa PocketOS / Cursor + Railway (usunięcie produkcyjnego wolumenu w 9 sekund), 25.04.2026 - zenity.io, Tom’s Hardware
• IBM, Cost of a Data Breach Report 2025, 30.07.2025 (20 procent naruszeń powiązanych z shadow AI; podwyższony koszt naruszenia)