Simon Willison cytuje D. Richarda Hippa, a analogia z SQL podważa prognozy dotyczące miejsc pracy w AI

29 lipca Simon Willison zwrócił uwagę na analogię D. Richarda Hippa do SQL, zestawiając historyczny przykład bezpośrednio z prognozami, według których AI wyeliminuje programistów. Argument Hippa wychodzi od wcześniejszej zmiany na rynku pracy. SQL zautomatyzował zadania wykonywane wcześniej przez niestandardowe programy do przetwarzania danych, a mimo to programowanie przetrwało i rozwinęło się w innych formach.

Wpis jest krótki, ale jego moment publikacji ma znaczenie. Systemy AI do programowania tworzą dziś funkcje, testy, zapytania, dokumentację, a czasem także skoordynowane zmiany w całych repozytoriach. Ten postęp wzmocnił dalej idące twierdzenie: skoro ludzie mogą opisywać oprogramowanie zwykłym językiem, organizacje będą potrzebować znacznie mniej programistów.

Hipp proponuje mniej dramatyczny model. Nowe abstrakcje obniżają koszt wyrażania części instrukcji, a następnie przenoszą ludzki wysiłek w stronę specyfikacji, weryfikacji, architektury i utrzymania. SQL nie zakończył programowania. Zmienił natomiast to, które problemy zasługiwały na własny kod, a które można było powierzyć silnikowi bazy danych.

Ta analogia nie dowodzi, że AI podąży tą samą drogą. Duże modele językowe tworzą wyniki probabilistyczne, podczas gdy baza danych wykonuje SQL według zdefiniowanych reguł. Porównanie nadal stanowi użyteczny sprawdzian dla twierdzeń o karierach w tworzeniu oprogramowania: czy narzędzie usuwa pracę inżynierską, czy przenosi ją na inną warstwę?

Simon Willison zamienia cytat w argument dotyczący rynku pracy

Wiadomością nie jest nowa funkcja SQLite ani produkt AI. To trafniejsze historyczne ramy do oceny twierdzeń o automatyzacji.

We wpisie z 29 lipca Simon Willison zacytował D. Richarda Hippa, opisującego, jak zmieniła się praca z danymi, gdy dostępny stał się SQL. Przed SQL organizacje często płaciły programistom za tworzenie proceduralnego oprogramowania, które wyszukiwało, łączyło, filtrowało i podsumowywało duże zbiory danych.

Hipp określił tych pracowników, z pewnym uproszczeniem, mianem programistów COBOL. SQL pozwolił użytkownikowi określić pożądany wynik za pomocą zwięzłego zapytania. Silnik bazy danych generował lub wybierał następnie dużą część logiki wykonawczej, która wcześniej znajdowała się w niestandardowych programach.

Kluczowe zdanie w porównaniu Hippa brzmi: programiści nie zniknęli. Zmieniła się ich praca.

To rozróżnienie może brzmieć skromnie, ale uderza w jedno z najważniejszych założeń stojących za obecnymi prognozami dotyczącymi rynku pracy w AI. Wiele z nich traktuje tworzenie kodu jako podstawową jednostkę pracy programisty. Skoro oprogramowanie potrafi tworzyć kod, głosi ten tok rozumowania, pracownik, który wcześniej go wpisywał, staje się zbędny.

SQL sugeruje, że objętość kodu i wartość pracy inżynierskiej nie są tym samym. Deklaratywne zapytanie może zastąpić wiele linii proceduralnego kodu obsługującego dane. Jednak ktoś nadal musi zdefiniować dane, zdecydować, co oznacza wynik, zarządzać uprawnieniami, testować przypadki brzegowe, monitorować wydajność i reagować, gdy wymagania są sprzeczne.

Programowanie deklaratywne oznacza określanie wyniku, jaki ma wytworzyć system, bez opisywania każdego kroku wykonania. SQL stał się jego najważniejszym przykładem, ponieważ użytkownicy wskazują, jakich danych chcą. Planer zapytań wybiera sposób, w jaki baza danych je pobierze.

Hipp podkreślał to rozróżnienie już wcześniej. W profilu dotyczącym baz danych argumentował, że wielu programistów nie docenia, ile pracy może zaoszczędzić język deklaratywny. Wskazywał na kod aplikacyjny, który ręcznie wykonuje złączenia, choć baza danych mogłaby obsłużyć je samodzielnie.

Ta obserwacja łączy się bezpośrednio z programowaniem wspieranym przez AI. Deweloper może teraz poprosić asystenta o zaimplementowanie funkcji bez ręcznego wpisywania każdej instrukcji. Żądanie kompresuje widoczny wysiłek, podobnie jak zapytanie SQL kompresuje proceduralne operacje na danych.

Ta kompresja jest realna. Zniknięcie odpowiedzialności — nie.

Użytkownik SQL nadal odpowiada za zażądanie właściwego wyniku. Deweloper wspierany przez AI nadal odpowiada za ustalenie, czy wygenerowane oprogramowanie odpowiada zamierzonemu działaniu. W obu przypadkach interfejs przesuwa się na wyższy poziom, podczas gdy istotne decyzje pozostają po stronie ludzi.

Wybór Willison nadaje analogii Hippa szersze znaczenie. Zamienia komentarz o historii SQL w odpowiedź na pogląd, że programowanie w języku naturalnym automatycznie prowadzi do przyszłości bez programistów.

Wpis unika też prostego anty-AI wniosku. Hipp nie twierdzi, że automatyzacja niczego nie osiąga. SQL wyraźnie usunął potrzebę ręcznego pisania pewnych programów. Analogia uznaje znaczący wzrost produktywności, odrzucając jednocześnie prostą drogę od produktywności do zaniku zawodu.

To centralne napięcie tego wydarzenia. Ta sama historia może wspierać dwie interpretacje. Automatyzacja eliminuje konkretne zadania, ale jednocześnie na tyle obniża koszt tworzenia oprogramowania, że zwiększa popyt na nie.

SQL zmienił jednostkę pracy

SQL nie zachował każdego zadania programistycznego. Sprawił, że wiele z nich stało się ekonomicznie niepotrzebnych, i przeniósł uwagę na decyzje wyższego poziomu.

Przed relacyjnymi bazami danych i powszechnie stosowanymi językami zapytań uzyskanie nowej odpowiedzi z danych biznesowych mogło wymagać dedykowanego programu. Programista musiał rozumieć układy rekordów, ścieżki dostępu, procedury sortowania, formaty plików i wymagania raportowe.

Niewielka zmiana pytania mogła wymagać kolejnego programu albo istotnej modyfikacji istniejącego. Organizacja płaciła za procedurę, a nie po prostu za wynik.

SQL zmienił ten układ. Użytkownik mógł opisać wynik za pomocą selekcji, złączeń, grupowania i sortowania. Baza danych tłumaczyła to żądanie na plan wykonania, czyli zestaw operacji używanych do zwrócenia żądanych danych.

Analogia Hippa kondensuje długą historię techniczną, co sam przyznaje w sposobie sformułowania cytatu. COBOL nie zniknął wraz z pojawieniem się SQL. Systemy COBOL nadal obsługiwały listy płac, bankowość, ubezpieczenia, administrację publiczną i przetwarzanie transakcji.

Istotna zmiana była węższa. Organizacje nie potrzebowały już nowego programu proceduralnego dla każdego zwykłego pytania, które można było wyrazić zapytaniem relacyjnym.

To znacząca forma wypierania pracy na poziomie zadań. Narzędzie może wyeliminować godziny specjalistycznej implementacji, nie eliminując zawodu, którego częścią jest to zadanie.

Rozróżnienie między zawodami a zadaniami często ginie w debatach o AI. Zawód to zestaw działań, odpowiedzialności, wiedzy dziedzinowej, komunikacji i decyzji. Automatyzacja rzadko obejmuje wszystkie elementy tego zestawu w tym samym tempie.

SQL zautomatyzował wykonywanie zapytań, ale stworzył zapotrzebowanie na administrację bazami danych, projektowanie schematów, optymalizację zapytań, modelowanie danych, analitykę, bezpieczeństwo i integrację aplikacji. Uczynił też dostęp do danych praktycznym dla znacznie większej liczby zespołów.

Hipp opisywał trwałą wartość SQL za pomocą trzech idei: transakcji, abstrakcji danych i języka deklaratywnego. W wywiadzie o SQLite z 2024 roku stwierdził, że model relacyjny pozostaje skuteczny w reprezentowaniu wielu rzeczywistych problemów.

Transakcje zapewniają, że powiązane operacje bazodanowe kończą się zgodnie z kontrolowanymi regułami spójności. Abstrakcja danych oddziela logiczne żądanie od szczegółów fizycznego przechowywania. Język deklaratywny pozwala użytkownikowi skoncentrować się na pożądanej odpowiedzi.

Razem te możliwości zrobiły więcej niż tylko oszczędziły naciśnięcia klawiszy. Przeniosły ekspertyzę między programistę aplikacji, silnik bazy danych, specjalistę od baz danych i użytkownika biznesowego.

Asystenci programowania AI rozpoczynają podobną redystrybucję, choć ich mechanizm jest inny. Potrafią tłumaczyć intencje na kod, przeszukiwać nieznane repozytoria, proponować testy, wyjaśniać funkcje starszego kodu oraz tworzyć szkice migracji i dokumentacji.

W miarę poprawy tych możliwości zespoły będą poświęcać mniej czasu na pisanie rutynowego kodu implementacyjnego. Tego skutku nie należy bagatelizować. Część zadań na poziomie juniorskim, prac utrzymaniowych i zlecanego na zewnątrz kodowania znajdzie się pod bezpośrednią presją.

Zaoszczędzony wysiłek nie mówi jednak, co stanie się z całkowitym zatrudnieniem. Niższe koszty produkcji mogą zmniejszyć popyt na pracę, gdy pożądana wielkość produkcji pozostaje stała. Mogą go zwiększyć, gdy tańsza produkcja otwiera drogę do znacznie większej liczby projektów.

Oprogramowanie rzadko zachowywało się jak rynek o stałej wielkości. Zespoły utrzymują długie listy zaległości, odkładają narzędzia wewnętrzne, tolerują ręczne przepływy pracy i przesuwają integracje, ponieważ możliwości inżynierskie są ograniczone. Jeśli AI obniży koszt tych projektów, organizacje mogą tworzyć ich więcej.

Precedens SQL przedstawia więc jednocześnie trzy efekty:

• Substytucja: system wykonuje pracę wcześniej przypisaną programiście.

• Ekspansja: niższe koszty sprawiają, że dodatkowa praca nad oprogramowaniem i danymi staje się ekonomicznie opłacalna.

• Rekombinacja: w pozostałych rolach większą wagę zyskują osąd, projektowanie, przegląd i wiedza dziedzinowa.

Efekty te nie będą równoważyć się jednakowo w każdej firmie. Firma ze stabilnym produktem i ustalonym planem rozwoju może wykorzystać AI do ograniczenia zatrudnienia. Rozwijająca się firma może utrzymać poziom zatrudnienia, jednocześnie wydając więcej funkcji. Mała organizacja może zacząć rozwijać oprogramowanie, na które wcześniej nie było jej stać.

Ta zmienność wyjaśnia, dlaczego szerokie twierdzenia o „programiście” są słabe. Automatyzacja obejmuje konkretne zadania w konkretnych organizacjach. Jej wpływ na zatrudnienie zależy od popytu, budżetów, ryzyka i ilości nowej pracy, którą tworzy.

Rzeczywistym przeciwnikiem jest automatyzacja zadań, a nie eliminacja miejsc pracy

Główne wyzwanie Hippa nie jest wymierzone w narzędzia AI do programowania. Jest wymierzone w założenie, że automatyzacja generowania kodu eliminuje całą rolę inżynierską.

Wygenerowana funkcja może wyglądać jak ukończona praca. Pojawia się szybko, w sprzyjających przypadkach się kompiluje i może przejść testy dostarczone modelowi. Ten widoczny rezultat skłania ludzi do utożsamiania implementacji z całym cyklem życia oprogramowania.

Inżynieria produkcyjna obejmuje znacznie więcej. Ktoś musi zamienić niejednoznaczne żądanie w precyzyjne działanie. Ta osoba musi rozstrzygać konflikty między interesariuszami, identyfikować brakujące wymagania, wybierać granice systemu, chronić dane i decydować, które awarie są akceptowalne.

Zespół musi też utrzymywać rezultat po zmianie jego pierwotnego kontekstu. Zależności otrzymują aktualizacje. Przepisy się zmieniają. Użytkownicy odkrywają nieoczekiwane sposoby pracy. Atakujący szukają słabości. Wolumeny danych rosną ponad założenia przyjęte w pierwszej wersji.

AI może pomagać w każdym z tych działań, ale pomoc nie przenosi automatycznie odpowiedzialności. Gdy wygenerowany kod powoduje incydent bezpieczeństwa, klienci i regulatorzy nie traktują modelu jako odpowiedzialnego operatora.

Porównanie z SQL ułatwia dostrzeżenie tej granicy. Silnik bazy danych może wybrać plan wykonania, ale nie decyduje, czy zapytanie odpowiada na właściwe pytanie biznesowe. Nie potrafi ustalić, czy technicznie poprawne złączenie tworzy wprowadzający w błąd wskaźnik.

Podobnie asystent AI może stworzyć implementację, nie wiedząc, czy specyfikacja odzwierciedla rzeczywiste potrzeby organizacji. Im bardziej implementacja staje się zautomatyzowana, tym bardziej o wyniku decyduje jakość specyfikacji.

Powstaje tu istotne odwrócenie. Język naturalny wydaje się łatwiejszy niż kod, ale zwykły język toleruje niejednoznaczność, której oprogramowanie nie może bezpiecznie ignorować.

„Dodaj automatyczną obsługę podatków” brzmi jasno, dopóki system nie musi uwzględnić jurysdykcji, zwolnień, zwrotów, zasad zaokrąglania, dat obowiązywania i niekompletnych danych klienta. Ludzki inżynier tradycyjnie odkrywa i formalizuje te szczegóły podczas projektowania i implementacji.

Jeśli agent AI pisze kod, te pytania nie znikają. Przenoszą się do promptów, specyfikacji, testów, dokumentów polityk, sesji przeglądowych lub incydentów produkcyjnych.

Analiza przyszłości bez kodu z czerwca 2026 roku wysunęła pokrewny argument. Przedstawiła AI jako kolejny etap abstrakcji w programowaniu, zaznaczając jednocześnie, że precyzyjne specyfikacje nadal pełnią funkcję kodu, niezależnie od formatu, w jakim zostały zapisane.

W tym miejscu analogia Hippa do SQL jest najsilniejsza. SQL odnosi sukces, ponieważ jego deklaratywny zakres jest ograniczony. Baza danych rozumie tabele, relacje, predykaty, grupowanie, sortowanie i transakcje w ramach formalnej semantyki.

Ogólne wymagania dotyczące oprogramowania nie mają równie wyraźnych granic. Łączą zachowanie techniczne z polityką, estetyką, bodźcami organizacyjnymi, obowiązkami prawnymi i założeniami, których interesariusze mogą nigdy nie wyrazić.

Agent AI do programowania może wnioskować brakujące szczegóły. Ta elastyczność jest użyteczna, ale wprowadza też ryzyko. Wywnioskowane wymaganie może brzmieć wiarygodnie, a mimo to być błędne.

Silniki SQL również tworzą niepożądane plany, zwłaszcza gdy statystyki, indeksy lub założenia dotyczące obciążenia są słabe. Ich wynik pozostaje jednak regulowany przez deterministyczną semantykę baz danych. Duży model językowy może wygenerować różne implementacje na podstawie podobnych promptów, a także wymyślić API lub założenia.

Dlatego programowanie z AI nie jest po prostu „SQL dla całego oprogramowania”. To luźniejszy i bardziej ambitny interfejs.

Analogia działa na poziomie ekonomicznym, ponieważ obie technologie ograniczają nakład pracy wdrożeniowej. Słabnie na poziomie niezawodności, ponieważ ogólne generowanie kodu ma znacznie większą przestrzeń możliwych wyników.

Ta różnica zwiększa wartość weryfikacji. Programiści potrzebują testów obejmujących istotne zachowania, praktyk przeglądu analizujących bezpieczeństwo i łatwość utrzymania oraz obserwowalności ujawniającej awarie po wdrożeniu.

Zespoły potrzebują też trwałego kontekstu. Wymagania, decyzje architektoniczne, historia incydentów i ograniczenia domenowe muszą pozostawać dostępne, gdy agent lub inżynier zmienia system. Przeszukiwalna techniczna baza wiedzy może wspierać tę pracę, zwłaszcza gdy generowane zmiany obejmują nieznane repozytoria.

W rezultacie rola może obejmować mniej ręcznego wpisywania kodu. Nadal przypomina jednak inżynierię, ponieważ wymaga formalizacji, walidacji, kompromisów i odpowiedzialności.

Gdzie analogia do SQL się załamuje

SQL stanowi użyteczny precedens dotyczący pracy, ale nie może określić, jak szybko AI będzie się poprawiać ani ile stanowisk programistycznych firmy utrzymają.

Analogie historyczne wybierają podobieństwa, ukrywając różnice. SQL zaprojektowano dla określonej rodziny operacji na danych. Jego składnia i semantyka stworzyły stabilny kontrakt między osobą formułującą zapytanie a bazą danych, która je wykonuje.

Systemy AI do programowania działają w zmieniających się językach, frameworkach, repozytoriach, interfejsach i domenach biznesowych. Często napotykają niepełną dokumentację i sprzeczne konwencje. Ich zadanie nie polega wyłącznie na optymalizacji w obrębie formalnego modelu.

Ten szerszy zakres może sprawić, że AI będzie mieć większe znaczenie ekonomiczne niż SQL. Agent, który porusza się po repozytorium, edytuje kilka usług, uruchamia testy i reaguje na błędy, obejmuje większą część procesu tworzenia oprogramowania niż optymalizator zapytań.

Ten sam zakres może również utrudniać niezawodną automatyzację. Sukces w ograniczonym benchmarku nie dowodzi bezpiecznego działania wewnątrz długowiecznego systemu produkcyjnego.

Wygenerowana zmiana może przejść testy jednostkowe, jednocześnie naruszając nieudokumentowane założenie operacyjne. Może powielić niebezpieczny wzorzec już obecny w repozytorium. Może rozwiązać widoczny ticket, zwiększając jednocześnie przyszłe koszty utrzymania.

Ludzcy programiści również popełniają te błędy. Istotne pytanie brzmi, czy AI zmienia ich częstotliwość, wykrywalność i skalę.

Szybkość może wzmacniać zarówno dobre, jak i złe rezultaty. Jeśli zespół wytwarza pięć razy więcej zmian, nawet niższy wskaźnik błędów na zmianę może oznaczać więcej pracy przy przeglądach. Z kolei silne zautomatyzowane testowanie może pozwolić zespołowi zwiększyć tempo bez wzrostu liczby awarii.

Ta niepewność osłabia stanowcze prognozy po obu stronach. Zbyt wcześnie jest ogłaszać, że zawody programistyczne są bezpieczne, ponieważ SQL ich nie wyeliminował. Równie przedwczesne jest wnioskowanie o masowej eliminacji na podstawie imponujących demonstracji generowania kodu.

Własne publiczne wypowiedzi Hippa pokazują ostrożne stanowisko wobec w pełni autonomicznego programowania. W wywiadzie z 2024 roku nazwał AI użyteczną, lecz przesadnie rozreklamowaną, i stwierdził, że bardziej prawdopodobne wydaje się programowanie wspomagane niż całkowicie automatyczne generowanie kodu.

Ta prognoza pozostaje punktem widzenia, a nie zmierzonym wynikiem. Możliwości AI i projekty produktów nadal się zmieniają, a organizacje wciąż uczą się, jak wdrażać agentów w kontrolowanych procesach tworzenia oprogramowania.

Kategorie zawodowe mogą też przetrwać, jednocześnie stając się mniejsze lub trudniejsze do wejścia. Bankowość nadal zatrudnia specjalistów od COBOL, ale nie oznacza to, że COBOL oferuje tę samą ścieżkę kariery co dawniej. Technologia może zachować krytyczną wiedzę ekspercką, zmniejszając zarazem liczbę osób wykonujących rutynową pracę.

Na szczególną uwagę zasługują role juniorskie. Starsi inżynierowie często uczyli się dzięki drobnym poprawkom błędów, prostym integracjom, pisaniu testów i pracy nad funkcjami pod nadzorem. To właśnie zadania, z którymi obecni asystenci programistyczni radzą sobie dobrze.

Jeśli firmy zautomatyzują tę pracę bez przeprojektowania szkolenia, mogą osłabić ścieżkę prowadzącą do przyszłych starszych inżynierów. SQL stworzył nowe specjalizacje, ale nie odpowiedział na pytanie, jak zespół intensywnie korzystający z AI powinien rozwijać osąd u ludzi, którzy rzadziej ćwiczą podstawową implementację.

Kolejna niepewność dotyczy zachowania organizacji. Wzrost produktywności nie musi przekładać się na dodatkowe oprogramowanie. Dyrektorzy mogą wykorzystać go do ograniczenia zatrudnienia, podniesienia celów produkcyjnych, skrócenia harmonogramów lub połączenia tych działań.

Podział korzyści będzie miał równie duże znaczenie jak możliwości techniczne. Programiści mogą wykorzystywać AI do zarządzania większymi systemami i rozwiązywania zaniedbanych problemów. Mogą też mierzyć się z nasileniem obciążenia pracą, ponieważ zarządzanie traktuje każdą oszczędność czasu jako trwałą dodatkową przepustowość.

Analogia Hippa nie rozstrzyga tego konfliktu. Wyjaśnia go.

Pytanie nie brzmi, czy AI automatyzuje zadania programistyczne. Już to robi. Pytanie brzmi, kto kontroluje zaoszczędzony czas, które obowiązki pozostają po stronie ludzi oraz czy rosnący popyt na oprogramowanie wchłonie wypartą pracę.

Programowanie z AI zmienia umiejętności, za które płacą firmy

W miarę jak implementacja staje się tańsza, organizacje bardziej cenią ludzi potrafiących definiować właściwe rezultaty i wykrywać przekonujące błędy.

Przejście na SQL nagrodziło osoby rozumiejące modele danych i pytania biznesowe, a nie wyłącznie te znające składnię zapytań. Programowanie z AI powinno podobnie premiować rozumienie domeny, projektowanie systemów, testowanie i osąd operacyjny.

Samo pisanie promptów raczej nie stanie się trwałą umiejętnością zastępczą. Prompty są interfejsami, a interfejsy stają się prostsze w miarę dojrzewania produktów. Rzadszą zdolnością jest rozpoznanie, kiedy wiarygodnie brzmiąca odpowiedź nie spełnia rzeczywistego wymagania.

Dla programistów oznacza to rozumienie systemu wykraczające poza wygenerowany diff. Muszą śledzić przepływ danych, identyfikować granice zaufania, oceniać tryby awarii i łączyć zmiany w kodzie z konsekwencjami dla użytkowników.

Czytanie kodu może stać się ważniejsze, nawet gdy pisanie kodu będzie mniej centralne. Inżynierowie muszą analizować nieznane wyniki i ustalać, czy pasują one do lokalnych konwencji. Potrzebują też wystarczającej wiedzy podstawowej, aby rozpoznawać subtelne defekty.

Zmienia się również testowanie. Wygenerowane testy mogą zwiększać pokrycie, ale model może powielać to samo nieporozumienie zarówno w kodzie, jak i w testach. Zespoły potrzebują niezależnych kryteriów akceptacji oraz testów opartych na oczekiwanym zachowaniu, a nie jedynie na wygenerowanej implementacji.

Architektura staje się kolejnym punktem presji. Systemy AI mogą proponować znane wzorce, jednak znany wzorzec nie zawsze jest odpowiedni. Decyzje dotyczące granic usług, spójności, opóźnień, retencji danych i złożoności operacyjnej odzwierciedlają konkretne ograniczenia.

Eksperci domenowi zyskują znaczenie, ponieważ mogą dostarczyć kontekst, którego model nie posiada. Proces opieki zdrowotnej, system uzgadniania finansowego czy sterownik przemysłowy zawierają reguły, których nie da się wiarygodnie odtworzyć na podstawie ogólnych danych treningowych.

Nie oznacza to, że każdy programista staje się architektem. Oznacza to, że ekonomiczne centrum tej roli przesuwa się w stronę wyboru, ograniczania i walidowania zautomatyzowanej pracy.

Niektóre stanowiska będą się zawężać. Zespoły mogą potrzebować mniej osób do powtarzalnych konwersji, podstawowego tworzenia szkieletów interfejsów lub rutynowego generowania testów. Kontraktorzy sprzedający wolumen implementacji mogą odczuwać presję cenową, gdy klienci będą mogli tworzyć akceptowalne pierwsze wersje wewnętrznie.

Inne stanowiska będą rozwijać się wokół integracji i zapewniania jakości. Organizacje potrzebują ludzi, którzy łączą systemy AI z prywatnymi repozytoriami, kontrolują uprawnienia narzędzi, oceniają wyniki, utrzymują infrastrukturę deweloperską i badają awarie.

Modernizacja systemów legacy ilustruje ten mieszany efekt. Badacze IBM opisali wykorzystanie modeli trenowanych na wzorcach przedsiębiorstw korzystających z COBOL do wspierania translacji na Java. Ich prace modernizacyjne nadal zależą od rozumienia CICS, Db2, VSAM, IMS oraz zachowania biznesowego osadzonego w starych systemach.

Translacja nie jest równoznaczna z zastąpieniem. System może zawierać dekady nieudokumentowanych decyzji. Wygenerowanie składni Java nie dowodzi, że nowy program zachowuje każde wymagane działanie.

Doświadczony programista COBOL może ręcznie pisać mniej procedur migracyjnych. Wiedza tej osoby staje się ważniejsza podczas walidacji, ponieważ modelowi brakuje kontekstu historycznego i instytucjonalnego.

SQL stworzył porównywalny podział. Silnik zapytań zautomatyzował wybór algorytmu, ale trudne obciążenia nadal wymagały ludzi rozumiejących schematy, indeksy, statystyki i zachowanie aplikacji.

Programowanie z AI wywiera więc na programistów presję, by przechodzili na wyższy poziom bez utraty kontaktu z implementacją. Recenzent, który nie potrafi rozumować o kodzie, staje się zależny od tego samego systemu, który recenzuje.

Firmy stają też przed wyzwaniem zarządczym. Muszą odróżniać szybszą produkcję kodu od szybszego dostarczania niezawodnych rezultatów. Jeśli przeglądy, kontrole bezpieczeństwa, decyzje interesariuszy lub procesy wdrożeniowe pozostają wąskim gardłem, wygenerowany kod może się piętrzyć bez poprawy wartości dla klienta.

Metryki oparte na liczbie linii kodu lub ukończonych ticketów stają się jeszcze mniej użyteczne. Zespoły powinny analizować czas realizacji, defekty wykryte po wydaniu, częstotliwość incydentów, przeróbki oraz to, czy wydane funkcje rozwiązują zamierzony problem.

Trwała przewaga należy do zespołów, które łączą automatyzację z jasnymi specyfikacjami i niezależnymi kontrolami. Samo dodanie asystenta AI do istniejącego procesu nie ujawni, gdzie powinna przesunąć się odpowiedzialność.

Co warto obserwować dzięki cytatowi Simona Willisona

Kolejną fazę należy oceniać na podstawie dowodów dotyczących autonomii, popytu na oprogramowanie i kształtowania karier, a nie na podstawie wolumenu wygenerowanego kodu.

Pierwszym sygnałem jest to, czy agenci AI potrafią wykonywać długotrwałą pracę produkcyjną przy ograniczonej interwencji człowieka. Krótkie demonstracje programowania już nie wystarczają. Mocniejszy test obejmuje zmiany w wielu plikach, niejednoznaczne wymagania, ograniczenia wdrożeniowe, przegląd bezpieczeństwa i utrzymanie po wydaniu.

Jeśli agenci wielokrotnie obsługują takie procesy przy niewielkiej liczbie przeróbek i defektów, które przedostały się do produkcji, analogia Hippa do SQL jako prognoza ograniczonego zastępowania zadań słabnie. AI automatyzowałaby większą część pakietu prac inżynieryjnych.

Jeśli przegląd dokonywany przez człowieka pozostanie dominującym ograniczeniem, analogia się umacnia. Praca przesunie się w stronę nadzoru i specyfikacji, zamiast zniknąć.

Drugi sygnał to całkowity popyt na oprogramowanie. Firmy powinny ujawnić, czy wzrost produktywności prowadzi do mniejszych zespołów, realizowania dłuższych backlogów przez stabilne zespoły, czy rozszerzenia projektów, na które wcześniej nie było stać.

Same dane dotyczące zatrudnienia będą trudne do interpretacji. Firma może spowolnić rekrutację, jednocześnie zwiększając produkcję, albo ograniczyć liczbę stanowisk juniorskich, intensywnie konkurując o doświadczonych inżynierów. Struktura zatrudnienia powie więcej niż sama liczba w nagłówku.

Warto obserwować, które projekty otrzymują finansowanie. Wzrost inwestycji w narzędzia wewnętrzne, oprogramowanie dla małych firm, niestandardowe integracje i poprawę dostępności potwierdzałby efekt ekspansji widoczny po wcześniejszych abstrakcjach. Koncentracja korzyści wewnątrz istniejących produktów przemawiałaby za silniejszym zastępowaniem pracy.

Trzeci sygnał to struktura pracy na poziomie entry-level. Organizacje potrzebują wiarygodnego sposobu szkolenia programistów, gdy agenci wykonują wiele tradycyjnych zadań dla początkujących.

Dowody na nadzorowane procesy pracy z AI, silniejsze programy praktyk oraz ocenę opartą na debugowaniu lub rozumowaniu systemowym pokazałyby, że zawód się dostosowuje. Długotrwałe załamanie rekrutacji juniorów bez zastępczego szkolenia sugerowałoby głębsze zakłócenie ścieżek kariery.

Sygnały te powinny pojawiać się z czasem, a nie po jednej premierze lub benchmarku. Systemy zatrudnienia dostosowują się wolniej niż możliwości modeli. Budżety, zasady zakupowe, wymogi bezpieczeństwa i starsza architektura ograniczają tempo, w jakim potencjał techniczny staje się praktyką operacyjną.

Wpis Simona Willisona ma znaczenie, ponieważ Hipp proponuje lepsze pytanie wyjściowe. Zamiast pytać, czy AI potrafi pisać kod, warto zapytać, która warstwa pracy staje się deklaratywna i jaka ludzka odpowiedzialność pozostaje ponad nią.

SQL sprawił, że ogromna część proceduralnej pracy z danymi stała się zbędna. Umożliwił też tworzenie większych systemów oprogramowania, szerszy dostęp do danych i nowe specjalizacje techniczne. Oba skutki były prawdziwe.

Programowanie z AI może podążyć podobnym, mieszanym wzorcem, wywołując jednocześnie większe zakłócenia. Rutynowa implementacja straci na wartości. Precyzyjny osąd, wiedza dziedzinowa, weryfikacja i odpowiedzialność za rezultat ją zyskają.

Programiści powinni reagować, sprawdzając, gdzie AI rzeczywiście usuwa pracę, a gdzie jedynie ukrywa złożoność. Zespoły powinny dokumentować ograniczenia, których musi przestrzegać wygenerowany kod, a następnie mierzyć wyniki po wdrożeniu.

Czy następne pokolenie programistów będzie przypominać użytkowników SQL wydających polecenia sprawniejszemu silnikowi wykonawczemu, czy recenzentów nadzorujących systemy, których już w pełni nie rozumieją? Odpowiedź będzie zależeć od tego, jak świadomie firmy zachowają weryfikację, uczenie się i rozliczalność w miarę rozwoju automatyzacji.