AI a zawód programisty: koniec pisania kodu, nie koniec inżyniera

Dawno mnie tu nie było i za to Cię przepraszam. Ostatnie tygodnie zjadły mi prywatne sprawy, które po prostu trzeba było ogarnąć. Nie wyszło to jednak na złe: przy okazji wpadłem na kilka przemyśleń, które nie dawały mi spokoju, a w ostatnim tygodniu zebrałem sporo materiałów i danych, żeby sprawdzić, czy się bronią. Dziś wracam z nimi do Ciebie.

Temat jest mi bliski, bo z wykształcenia i pierwszej miłości jestem programistą. Przez lata pisałem kod w różnych projektach, ostatnio w bankowości, gdzie jeden błąd potrafi kosztować naprawdę dużo. Dziś na co dzień pracuję z agentami AI, więc patrzę na tę zmianę z dwóch stron: jako ktoś, kto pisał kod ręcznie, i jako ktoś, kto dziś zleca go maszynie i bierze odpowiedzialność za to, co z niej wychodzi. Pytanie, które słyszę coraz częściej, brzmi: czy sztuczna inteligencja zabierze programistom pracę? Moja odpowiedź w skrócie: zabierze im dotychczasowy sposób pracy, ale nie sam zawód. Żeby to pokazać, zacznę od historii, bo programiści nie są pierwszymi, których technologia zmusza do zmiany.

Zawody, które przetrwały rewolucje techniczne, ale zmieniły się nie do poznania

Rolnik i ogrodnik

Dawniej praca opierała się na sile fizycznej: orka pługiem ciągniętym przez konie lub woły, ręczny siew, żniwa z sierpem i kosą, a rolnictwo zatrudniało większość społeczeństwa. Dziś rolnik to często operator zaawansowanych maszyn, analityk danych i zarządca. Używa ciągników prowadzonych przez GPS, dronów do monitorowania upraw, automatycznego nawadniania i oprogramowania, które analizuje skład gleby i prognozy pogody.

Architekt, projektant, konstruktor

Dawniej cały proces projektowy odbywał się na desce kreślarskiej. Architekci spędzali setki godzin, ręcznie rysując plany tuszem na kalce, z cyrklem, linijką i suwakiem logarytmicznym, a jedna pomyłka często oznaczała przerysowanie całej planszy. Dziś praca przeniosła się w całości do świata cyfrowego (CAD, BIM, wizualizacje 3D). Architekt tworzy cyfrowe bliźniaki budynków, symuluje zużycie energii i naprężenia konstrukcji, a coraz częściej korzysta z AI przy wstępnych koncepcjach.

Lekarz, zwłaszcza chirurg i diagnosta

Dawniej diagnoza opierała się głównie na wywiadzie, badaniu fizykalnym (stetoskop, palpacja) i podstawowych badaniach laboratoryjnych, a operacje wymagały dużych cięć i bezpośredniego kontaktu rąk chirurga z narządami pacjenta. Dziś lekarz ma do dyspozycji rezonans magnetyczny, tomografię komputerową i sekwencjonowanie DNA. Chirurg coraz częściej operuje małoinwazyjnie z pomocą robotów (np. system da Vinci): steruje precyzyjnymi ramionami z konsoli, patrząc na obraz 3D, zamiast trzymać skalpel w dłoni.

Górnik

Dawniej było to wydobycie kilofem i łopatą w skrajnie niebezpiecznych warunkach, a urobek jechał wózkami pchanymi ręcznie lub ciągniętymi przez konie. Dziś górnik to często operator kombajnów górniczych, wiertnic i systemów zdalnego sterowania. Coraz więcej pracy przenosi się do klimatyzowanych centrów sterowania na powierzchni, skąd nadzoruje się maszyny pracujące pod ziemią.

Księgowy i audytor

Dawniej oznaczało to żmudne wpisywanie każdej transakcji do wielkich papierowych ksiąg, ręczne sumowanie kolumn cyfr i segregatory pełne faktur. Dziś praca polega na weryfikacji i analizie danych, które automatycznie generują systemy ERP i programy finansowo-księgowe. Księgowy przestał być „klepaczem cyfr”, a stał się doradcą podatkowym i analitykiem finansowym.

Mechanik samochodowy

Dawniej była to praca czysto mechaniczna: klucze, młotki, wymiana części, regulacja gaźnika „na słuch” i sprawdzanie poziomu oleju. Dziś samochody to komputery na kołach. Mechanik spędza tyle samo czasu przy komputerze diagnostycznym podpiętym do złącza OBD-II, co z kluczem w ręku, i musi znać się na elektronice, oprogramowaniu i układach wysokiego napięcia w autach elektrycznych.

Tłumacz

Dawniej były papierowe słowniki, encyklopedie i maszyna do pisania, a każde słowo wymagało kartkowania ciężkich tomów. Dziś tłumacze rzadko zaczynają od zera. Pracują w modelu post-editingu tłumaczenia maszynowego (PEMT): korzystają z narzędzi CAT i modeli językowych, a sami zajmują się korektą, niuansami kulturowymi, stylem i kontekstem.

Bibliotekarz i archiwista

Dawniej to katalogi kartkowe, układanie książek na półkach, ręczne wypożyczanie i szukanie dokumentów w archiwach. Dziś cyfrowe bazy danych, archiwizacja elektroniczna, digitalizacja zbiorów i e-booki, a do tego rola przewodnika po wiarygodnych źródłach w internecie (tzw. information literacy).

Geodeta i kartograf

Dawniej praca w terenie z teodolitem, taśmą mierniczą i stolikiem topograficznym, a potem ręczne kreślenie map na podstawie mozolnych obliczeń trygonometrycznych. Dziś pomiary wykonuje się odbiornikami GNSS z dokładnością do milimetrów, skanerami laserowymi 3D i dronami fotogrametrycznymi, a mapy powstają w systemach GIS.

Dziennikarz i reporter

Dawniej był to notatnik, budki telefoniczne, maszyna do pisania i materiały wysyłane telegrafem albo kurierem do drukarni. Dziś to treści multimedialne (tekst, wideo, podcast), praca w czasie rzeczywistym w mediach społecznościowych, analiza danych SEO i narzędzia do sprawdzania autentyczności nagrań i zdjęć (fact-checking).

Co łączy te wszystkie zmiany? Przejście od siły fizycznej i żmudnej, odtwórczej pracy do nadzoru, analizy i obsługi zaawansowanych narzędzi. Niemal w każdym przypadku rewolucja nie zlikwidowała zawodu. Zwolniła ludzi z rutyny i przesunęła ich odpowiedzialność na poziom zarządczy i decyzyjny.

Tempo rewolucji AI na tle dawnych przemian

Zawody zmieniały się w historii w różnym tempie, ale obecna rewolucja wyróżnia się kilkoma cechami, których wcześniej nie było.

Ile zwykle trwały takie zmiany?

W dawnych rewolucjach pełna przemiana zawodu trwała, w dużym przybliżeniu, dekady, a nawet pokolenia. Pierwsza i druga rewolucja przemysłowa (rolnictwo, górnictwo) zajęły mniej więcej 50–100 lat, od XIX wieku do połowy XX. Dlaczego tak długo? Trzeba było zbudować ciężką infrastrukturę (kolej, elektryfikacja), fizycznie wymienić parki maszynowe i poczekać na zmianę pokoleniową na wsi i w kopalniach.

Komputeryzacja i cyfryzacja (architektura, księgowość, geodezja) trwały około 15–25 lat, od późnych lat 80. do połowy pierwszej dekady XXI wieku. Poszło szybciej, bo opierały się na oprogramowaniu i komputerach osobistych, ale hamowały je koszty sprzętu, konieczność uczenia pracowników obsługi komputera od podstaw i dopasowywanie systemów.

Czy AI i programowanie wpisują się w ten schemat?

Tak, mechanizm jest dokładnie ten sam, tylko skala zupełnie inna. AI nie likwiduje inżynierii oprogramowania. Przesuwa jej cel i poziom abstrakcji. Praca programisty przestaje polegać na pisaniu (autorstwie) kodu, a zaczyna na architekturze, specyfikowaniu wymagań, weryfikacji i orkiestracji agentów AI. Prace odtwórcze, takie jak proste funkcje CRUD, podstawowe testy jednostkowe, boilerplate czy pierwszy szkielet kodu, przejmują autonomiczne agenty i asystenci AI, więc klepacz kodu przegrywa z architektem systemu. W cenie są za to krytyczny osąd (judgment), głębokie zrozumienie domeny, bezpieczeństwo, audyt wygenerowanego kodu i umiejętność zadawania właściwych pytań.

Co mówią dane: AI przekracza ludzki poziom

Ten trend dobrze widać w danych z niezależnych ośrodków badawczych. Our World in Data w zestawieniu „Test scores of AI systems relative to human performance” zbiera wyniki systemów AI w różnych testach (rozumienie języka, matematyka, egzaminy medyczne i prawnicze) i skaluje je względem poziomu człowieka jako linii bazowej (0). Jeszcze kilkanaście lat temu krzywe leżały głęboko pod kreską. W ostatnich latach większość klasycznych testów została przebita: linie przekroczyły poziom człowieka i idą dalej w górę.

Epoch AI w swoim Epoch Capabilities Index (ECI) pokazuje indeks ogólnych zdolności modeli oraz wykresy mocy obliczeniowej zużywanej do ich trenowania. Nakłady obliczeniowe (FLOP) rosną zgodnie z przewidywalnymi prawami skalowania (scaling laws), a za nimi rosną ogólne zdolności modeli. Z kolei Stanford AI Index Report zestawia, jak AI radzi sobie z rozumowaniem wizualnym, matematyką konkursową i programowaniem na tle ludzkich ekspertów. Widać na nim momenty przełomu, w których architektura Transformer i skalowanie danych pokonały dawne wąskie gardła.

Materiały, z których korzystałem:

• Our World in Data: Test scores of AI systems relative to human performance
• Epoch AI: Epoch Capabilities Index
• Stanford HAI: AI Index Report

Tańszy token: przyspieszenie czy eksplozja popytu?

Spadek kosztu tokena (czyli kosztu inferencji, inference cost) ma dla rynku IT fundamentalne znaczenie, ale jego wpływ nie jest jednowymiarowy. Mogłoby się wydawać, że dużo tańsza sztuczna inteligencja od razu zastąpi programistów. W rzeczywistości wywołuje dwa przeciwstawne zjawiska.

Zjawisko pierwsze: efekt przyspieszenia, czyli więcej automatyzacji

Gdy tokeny są tanie jak woda w kranie, firmy przestają na nich oszczędzać, a zmienia się architektura samych narzędzi. Gdy tokeny były drogie, programista wysyłał krótkie zapytanie i czekał na odpowiedź. Gdy są tanie, w tle pracuje kilka agentów naraz: rozmawiają ze sobą, piszą kod, kompilują go, uruchamiają testy, wyłapują błędy i poprawiają się nawzajem w długich pętlach. Jeden problem może w kilka minut zużyć miliony tokenów.

Niskie koszty pozwalają też agentom pracować w tle (background execution), od początku do końca. Agent może w nocy samodzielnie przejrzeć całe repozytorium, zaktualizować przestarzałe biblioteki, dopisać brakującą dokumentację i przygotować gotowe pull requesty. Maleje przez to zapotrzebowanie na zewnętrznych programistów, czyli outsourcing i software house'y. Projekty, które dawniej wymagały wynajęcia agencji na pół roku (proste aplikacje biznesowe, panele administracyjne, integracje API), firmy potrafią dziś zrobić w kilka dni u siebie, z pomocą narzędzi agentowych.

Zjawisko drugie: paradoks Jevonsa, czyli eksplozja popytu

W ekonomii znany jest paradoks Jevonsa: gdy zasób staje się wydajniejszy i tańszy w użyciu, jego całkowite zużycie rośnie, zamiast spadać. Z kodem dzieje się to samo. Setki tysięcy pomysłów na aplikacje, moduły, usprawnienia i eksperymenty, które wcześniej lądowały w koszu, bo zatrudnienie programistów było zbyt drogie (ROI się nie spinało), nagle przekraczają próg opłacalności.

Każda firma zaczyna budować własne oprogramowanie, integracje i automatyzacje, bo koszt wytworzenia gwałtownie spadł. Oprogramowania na świecie przybywa w tempie wykładniczym, a ktoś musi ten wygenerowany kod zweryfikować, wdrożyć, zabezpieczyć i utrzymać, więc programiści stają się raczej dyrygentami. Rośnie też złożoność infrastruktury: małe systemy ustępują miejsca rozwiązaniom o ogromnej złożoności, bo w tym samym czasie da się zbudować więcej.

Co to oznacza w praktyce? Przyspieszenie, ale kogo i czego?

Tańszy token nie przyspiesza zniknięcia zawodu programisty. Przyspiesza wymieranie dotychczasowego modelu jego pracy.

Najszybciej z rynku wypychani są klepacze kodu i osoby wykonujące schematyczne zadania. Kto do tej pory żył z przepisywania wymagań z Jiry na prosty CRUD bez głębszego rozumienia architektury, jest zastępowany przez agenty najszybciej. Podobnie dzieje się z niskopoziomowym outsourcingiem: model wynajmowania setek juniorów i midów w tańszych krajach do pisania powtarzalnych modułów gwałtownie traci sens.

Zyskują na tym seniorzy i architekci systemów, czyli inżynierowie z dobrym osądem. Tani token daje im do ręki niemal darmową armię wirtualnych juniorów. Programista z wysokimi kompetencjami decyzyjnymi staje się kilka razy wydajniejszy i może sam dowieźć produkt, na który dawniej potrzebował całego zespołu. Zyskują też product engineerowie, czyli programiści, którzy rozmawiają bezpośrednio z biznesem i z pomocą tanich agentów błyskawicznie sprawdzają rynkowe hipotezy.

Taniejące tokeny działają więc jak katalizator: oprogramowania jest coraz więcej i jest coraz gęstsze. Nie zmniejszają zapotrzebowania na myślenie inżynierskie, ale samo pisanie kodu staje się zasobem niemal darmowym, jak transfer danych czy miejsce na dysku. „Zastępowanie klasycznego developera” przyspiesza więc tylko w czynnościach manualnych. Inżynierowie stają się nadzorcami, audytorami i architektami systemów wielokrotnie większych i bardziej złożonych niż dotąd.

Czy tym razem zmiana jest szybsza?

Tak, i to zdecydowanie. Uważam, że to najszybsza transformacja zawodu w historii. Poprzednie rewolucje trwały dekady, a zmiana w inżynierii oprogramowania dokonuje się w ciągu dosłownie 2–5 lat.

Dlaczego idzie to aż tak szybko? Po pierwsze, nie ma fizycznych barier. Nowe modele i agenty kodujące trafiają do ludzi przez internet w kilka sekund, niemal bez kosztu dystrybucji, i nie trzeba budować fabryk ani czekać na dostawę maszyn. Po drugie, rewolucja dzieje się na własnym podwórku programistów: narzędzia AI powstają w świecie cyfrowym, czyli tam, gdzie oni już pracują. Byli pierwszą grupą zawodową, która od razu wpuściła do codziennej pracy (IDE, terminal) asystentów kodu i agenty oparte na modelach językowych. Po trzecie, możliwości rosną wykładniczo. W zadaniach programistycznych modele przeszły od podpowiadania pojedynczych linijek do samodzielnego rozwiązywania całych zadań i błędów w niespełna 2–3 lata. Widać to w testach, w których model dostaje prawdziwy błąd z prawdziwego projektu i ma go samodzielnie naprawić.

Dla rynku pracy oznacza to wyższy próg wejścia. Tradycyjne stanowiska juniorskie, na których uczyło się zawodu, pisząc prosty kod, mocno się skurczyły, a młodzi inżynierowie od pierwszego dnia muszą działać na wyższym poziomie abstrakcji. Mnoży się też produktywność: zamiast budować pięcioosobowy zespół do napisania modułu, senior z dobrymi narzędziami agentowymi dostarcza ten sam produkt w ułamku czasu i pełni rolę dyrektora technicznego dla AI.

Rekrutacja programisty dziś

Jak w praktyce zmieniają się wymagania, zarówno po stronie umiejętności, jak i samego procesu rekrutacji?

Jak zmienił się „stack” inżyniera?

Tradycyjny stack sprowadzał się do zestawu: język, framework i baza danych. Dziś przesuwa się poziom wyżej:

Dlaczego sprawdzanie „składania kodu” traci sens?

Wciąż spotyka się rekrutacje oparte na zadaniach w stylu LeetCode (odwróć drzewo binarne) albo na pisaniu CRUD-a na żywo. Tracą one sens z trzech powodów.

Po pierwsze, model napisze to w 3 sekundy. Schematyczna metoda czy algorytm to dla modelu językowego chwila, więc mierzenie programisty czasem, w jakim napisze pętlę for, sprawdza umiejętność, którą w całości oddelegowaliśmy maszynie. Po drugie, to fałszywy sygnał o kompetencjach. Ktoś może pamiętać każdą metodę z C# czy Pythona, a polec na projekcie infrastruktury, bezpieczeństwie czy logice biznesowej. I odwrotnie. Po trzecie, najdroższe błędy powstają gdzie indziej. W erze AI kosztują nie błędy składni (AI pisze kod poprawny składniowo), ale zła specyfikacja, niezrozumienie domeny biznesowej i halucynacje w trudnych przypadkach brzegowych.

Jak może wyglądać nowoczesna rozmowa kwalifikacyjna?

Zamiast testów ze składni i pisania kodu na żywo rekrutacja przesuwa się w stronę sprawdzania osądu inżynierskiego (engineering judgment).

Pierwsza forma to kodowanie z AI na żywo, czyli pair programming z agentem. Kandydat dostaje nietrywialne zadanie i pełny dostęp do narzędzi AI, których używa na co dzień. Ocenia się, jak formułuje zadania dla AI, czy ślepo ufa wygenerowanemu kodowi, czy od razu go czyta i testuje, jak szybko wyłapuje błędy i czy potrafi wyprowadzić model z pętli, gdy ten w nią wpadnie.

Druga to przegląd i audyt kodu. Kandydat dostaje fragment złożonego kodu wygenerowanego przez AI z ukrytymi, nietrywialnymi błędami (np. race condition, wyciek pamięci, brak obsługi skrajnego przypadku biznesowego, luka z listy OWASP). Sprawdza się krytyczne myślenie, znajomość dobrych praktyk i umiejętność czytania ze zrozumieniem cudzego albo wygenerowanego kodu.

Trzecia to projektowanie systemu na żywym przykładzie, czyli rozmowa o architekturze konkretnego systemu. Jak zaprojektować przepływ danych, jak obsłużyć awarię zewnętrznego API, jak zapewnić spójność ostateczną (eventual consistency)? Ocenia się wyobraźnię systemową, dojrzałość technologiczną i rozumienie kompromisów (wydajność, koszt, łatwość utrzymania).

Tradycyjne podejście do rekrutacji to spadek po czasach, w których człowiek był „kompilatorem i pisarzem”. Dziś programista staje się dyrektorem technicznym (CTO) własnego środowiska pracy. Najważniejsze nie jest to, czy sam napiszesz pętlę, ale czy wiesz, co dokładnie ma powstać, dlaczego właśnie tak i czy to, co oddało AI, jest bezpieczne, wydajne i gotowe na produkcję.

Kim jest dzisiejszy developer?

Skoro AI przejęła znaczną część samego pisania kodu, naturalne wydaje się przesunięcie roli człowieka w stronę analizy wymagań (Business Analyst), zarządzania produktem (Product Owner) oraz testów i audytu (Quality Assurance).

Widzimy już narodziny product engineerów: programistów, którzy mocno zbliżają się do biznesu i użytkownika, a AI traktują jak siłę roboczą. Pełne zastąpienie developera mieszanką QA, BA i PO ma jednak zarówno konkretne zalety, jak i ogromne, ciche pułapki. Oto argumenty za i przeciw tezie, że programista staje się dziś głównie połączeniem tych trzech ról.

Za: programista płynnie ewoluuje w BA, PO i QA

Wąskie gardło przesuwa się z „jak zrobić” na „co i po co”, i tu wchodzi rola BA i PO. Gdy koszt wygenerowania szablonowego kodu, interfejsu czy struktury bazy danych spada niemal do zera, wąskim gardłem przestają być moce przerobowe programistów. Staje się nim precyzja myślenia biznesowego. Programista musi myśleć jak BA i PO, bo AI potrzebuje dokładnej specyfikacji i znajomości domeny (kontekstu), żeby nie zbudować ładnie wyglądającego, ale biznesowo bezużytecznego systemu. Może też porozmawiać z klientem i w kilkanaście minut, z pomocą agentów, postawić działający prototyp do sprawdzenia hipotezy (rapid prototyping).

Rola staje się też defensywna i audytorska, czyli to rola QA. Kod z modeli językowych powstaje szybko, ale ma nierówną jakość i ryzyko halucynacji (subtelne luki bezpieczeństwa, błędna obsługa stanów brzegowych). Dlatego programista spędza dziś znacznie więcej czasu na czytaniu i audytowaniu kodu napisanego przez AI, sprawdzaniu skrajnych przypadków biznesowych (edge cases) oraz projektowaniu testów regresyjnych, integracyjnych i wydajnościowych. Zamiast twórcy (pisarza) staje się głównym kontrolerem jakości i recenzentem.

Wreszcie zacierają się bariery technologiczne. Tradycyjny developer latami opanowywał niuanse jednej składni czy frameworka. Dziś, z uniwersalnymi narzędziami AI, łatwo przeskakuje między technologiami. O jego wartości przestaje decydować pamięciowa znajomość biblioteki, a zaczyna rozumienie potrzeb użytkownika (PO) i dbałość o niezawodność (QA).

Przeciw: głęboka wiedza inżynierska jest ważniejsza niż kiedykolwiek

Pierwszy kontrargument to iluzja „kodu bez developera”, czyli dług technologiczny i architektura. Programista, który porzuci podstawy inżynierskie na rzecz samych ról BA i PO, szybko wpadnie w pułapkę. AI pisze kod spójny lokalnie, ale bez twardej ręki architekta projekt z czasem zamienia się w tzw. Big Ball of Mud, wielką kulę błota. Spójność ostateczna, optymalizacja zapytań pod obciążeniem, zarządzanie pamięcią, bezstanowość mikroserwisów czy bezpieczeństwo sieci wymagają głębokiej wiedzy programistycznej. Agenty świetnie piszą fragmenty kodu, ale rzadko potrafią długofalowo pilnować spójności całego, wielomilionowego repozytorium.

Drugi to paradoks zaufania: kto sprawdzi sprawdzającego? Jeśli programista straci umiejętność samodzielnego pisania kodu i rozumienia podstaw (jak działa framework pod spodem, wskaźniki, wielowątkowość), straci też zdolność bycia QA dla AI. Żeby wychwycić subtelny błąd wygenerowany przez AI (np. race condition przy dużym obciążeniu), trzeba mieć ogromną praktykę. Developer bez twardych kompetencji stanie się tylko bezkrytyczną pieczątką, która przybija wszystko, co wyjdzie z modelu.

Trzeci: inżynieria to rozwiązywanie trudnych problemów, a nie tylko CRUD-y. Praca programisty w około 80% składała się z powtarzalnych zadań, które przejmuje AI. Pozostałe 20% to unikalne, skrajnie trudne wyzwania: wydajność, systemy rozproszone, własne algorytmy, integracje ze starymi systemami (legacy). W tych obszarach AI nadal zawodzi albo podaje błędne rozwiązania. Biznes nie zapłaci inżynierowi za bycie słabszym PO, ale zapłaci za rozwiązanie problemu, na którym poległy automaty.

Jak sam pracuję z AI

Skoro piszę o tym, jak zmienia się ta praca, uczciwie pokażę, jak wygląda u mnie. Traktuję agenta AI jak bardzo szybkiego i bardzo pewnego siebie juniora: robi dużo, ale za wynik odpowiadam ja. Moje zasady są proste:

• Najpierw specyfikacja, potem kod. Zanim agent napisze linijkę, opisuję cel, ograniczenia i kontekst projektu. Im lepszy opis, tym mniej poprawek.
• Małe kroki i sprawdzenie każdego z nich. Testy, build i podgląd po każdej zmianie, zanim pójdę dalej.
• Czytam każdą zmianę. Kod, którego nie rozumiem, nie trafia dalej, nawet jeśli działa.
• Decyzje zostawiam sobie. Architektura, bezpieczeństwo i to, co trafia do ludzi, to moja odpowiedzialność, nie modelu.

Dzięki temu AI przyspiesza mnie kilka razy, a nie dokłada długu, który ktoś będzie spłacał za rok. Moim zdaniem to właśnie odróżnia inżyniera, który korzysta z AI, od kogoś, kto tylko kopiuje jego odpowiedzi.

Kim więc staje się programista?

Współczesny programista nie przestaje być developerem. Przesuwa się na poziom dyrektora technicznego (CTO, tech leada) małego fragmentu systemu. Tak, według moich szacunków, zmienia się podział jego czasu. Dawny programista głównie pisał kod (ok. 80%), a do tego robił podstawowe QA i BA (ok. 20%). Dzisiejszy inżynier poświęca BA i PO około 30% czasu, architekturze i projektowaniu systemów kolejne 30%, QA i audytowi pracy AI jeszcze 30%, a na głęboki kod i debugowanie zostaje około 10%.

Programista nie staje się czystym QA, BA ani PO, bo żadna z tych ról w tradycyjnym wydaniu nie ma wystarczających kompetencji technicznych, żeby ocenić poprawność architektury i bezpieczeństwo rozwiązania.

A Ty, jeśli piszesz kod, ile z Twojego dnia to dziś pisanie, a ile czytanie i sprawdzanie tego, co napisało AI? Daj znać pod wpisem, chętnie porównam z moimi szacunkami.