2005, DHH, prezentacja Ruby on Rails: „Spójrz na ten cały kod, którego nie napisałem”.
Powodem do zachwytu był config, którego nie trzeba było pisać. Nazwa kontrolera mapowała się na widok, framework wiedział co zrobić, a programista mógł zająć się czymś pożyteczniejszym.
Kiedyś architektura Rails usuwała z pracy programisty konfigurację. Dwadzieścia jeden lat później agent AI ma usuwać z niej samo ręczne pisanie kodu.
Ta sama filozofia, tylko inna skala. Kiedyś chodziło o fragment procesu, dziś o praktycznie cały produkt. Rails usuwał konieczność ręcznego opisywania tego, co framework mógł przewidzieć sam. Agent usuwa ręczne pisanie implementacji.
Nie programistę. Kod.
To rozróżnienie jest ważne, bo ta wizja nie sprowadza się do tego, że człowiek staje się zbędny. Wręcz przeciwnie. Nadal ma wymyślać, decydować, korygować kierunek, sprawdzać rezultat i brać odpowiedzialność za produkt. Znika za to konieczność własnoręcznego przekładania każdej decyzji na setki czy tysiące linii implementacji.
„Spójrzcie na ten cały kod, którego nie napisałem. I na te wszystkie podpowiedzi, których udzieliłem”.
Tak dziś brzmi dokończenie tego samego hasła.
I właśnie stąd bierze się najciekawsza konsekwencja.
Jeżeli AI nie tylko przyspiesza pisanie kodu, ale realnie obniża koszt całej implementacji, zaczyna usuwać kompromisy, które przez lata wydawały się nieuniknione.
W tym sensie może wręcz uzdrawiać rynek, bo wybór technologii znowu może wynikać z tego, co jest najlepsze dla produktu, a nie tylko z tego, na co stać zespół.
Dobrym przykładem są aplikacje webowe. Wiele z nich powstało w przeglądarce nie dlatego, że była to idealna forma produktu, ale dlatego, że mały zespół nie był w stanie utrzymywać kilku osobnych klientów natywnych. Jedna aplikacja działająca wszędzie była tańsza, prostsza i zwyczajnie bardziej realistyczna.
Stąd React Native, Hotwire Native i podobne rozwiązania. Ich zadaniem było ograniczenie kosztu utrzymywania wielu wersji tego samego produktu. W zamian można było zaakceptować pewną warstwę pośrednią, mniejszą integrację z systemem czy gorsze dopasowanie do konkretnej platformy.
Ten kompromis miał sens tak długo, jak długo koszt osobnej aplikacji był rzeczywiście wysoki. Jeżeli agenci obniżają go na tyle mocno, że kilka wersji natywnych może powstawać równolegle bez proporcjonalnego zwiększania zespołu, cały rachunek wygląda inaczej. Nagle można znowu zapytać nie „co jesteśmy w stanie utrzymać?”, tylko „co będzie najlepsze dla użytkownika?”.
To nie oznacza śmierci webu. Przeglądarka nadal wygrywa tam, gdzie liczy się brak instalacji i natychmiastowy dostęp. Jeśli ktoś ma wejść na chwilę, wykonać jedną czynność i zniknąć, trudno znaleźć wygodniejsze rozwiązanie.
Zmiana dotyczy raczej tych aplikacji, które były webowe z konieczności. Jeżeli ich twórcy wybierali przeglądarkę tylko dlatego, że na osobne wersje nie było ludzi, czasu i pieniędzy, ten argument zaczyna słabnąć. I właśnie dlatego pojawia się możliwość powrotu do natywnych klientów tam, gdzie wcześniej były po prostu za drogie.
To jednak nie wydarzyło się z dnia na dzień. To jest prcoes. Ale punktem zwrotnym była premiera Opusa 4.5, 24 listopada 2025 roku.
Różnica nie polegała już tylko na lepszym autouzupełnianiu czy sprawniejszym generowaniu funkcji. Modele miały zacząć przyjmować całe problemy i oddawać rozwiązania bez prowadzenia ich krok po kroku przez implementację. To właśnie ten moment przesuwa pracę programisty o poziom wyżej.
Autouzupełnianie nadal zakładało, że człowiek prowadzi cały proces na poziomie kodu.
Agent, któremu można przekazać problem i wrócić później po gotowy rezultat, zmienia samą logikę pracy. I z tego właśnie wyrasta „pencils down”.
Ręczne pisanie kodu przestaje być normalnym trybem pracy i staje się wyjątkiem. Jeśli człowiek musi coś dopisać sam, można oczywiście naprawić konkretny przypadek, ale później należałoby wrócić do procesu i ustalić, dlaczego agent sobie nie poradził.
Nie chodzi więc o zakaz pisania kodu, tylko o odwrócenie domyślności. Najpierw próbujemy rozwiązać problem bez ręcznej implementacji, a dopiero później sięgamy po nią tam, gdzie rzeczywiście jest potrzebna.
Dopiero w praktyce widać, jak daleko sięgają skutki takiego podejścia. HEY jest przykładem aplikacji, która może odejść od jednej dominującej wersji webowej w stronę kilku klientów natywnych. Jeszcze niedawno taki ruch wymagałby znacznie większego zespołu i trudno byłoby go uzasadnić ekonomicznie.
Podobny mechanizm działa na backendzie. Rust może być trudniejszy, bardziej rozwlekły i mniej przyjazny dla człowieka, ale jeśli kod generuje agent, część tych wad po prostu przestaje mieć takie znaczenie.
To z kolei zmienia kryteria wyboru technologii. Przez lata języki programowania oceniano również pod kątem tego, jak dobrze człowiek może w nich pisać i czytać kod. Jeżeli człowiek coraz rzadziej robi obie te rzeczy osobiście, większego znaczenia nabierają wydajność, zużycie pamięci, szybkość uruchamiania czy bezpieczeństwo.
Ten sam efekt widać przy optymalizacji. Wcześniej wiele usprawnień przegrywało z ekonomią: łatwiej było dorzucić więcej pamięci albo następny serwer niż przeznaczyć kilka dni pracy dobrego programisty na wyciskanie kolejnych procentów wydajności. Agent obniża koszt kolejnej iteracji, więc to, co wcześniej było technicznie możliwe, ale biznesowo nieopłacalne, zaczyna wracać do gry.
I tutaj całość dochodzi do najbardziej radykalnego wniosku. Jeśli kod może powstawać szybciej, taniej i w coraz większym stopniu poza bezpośrednim udziałem człowieka, zmienia się nie tylko sposób jego tworzenia, ale również zakres odpowiedzialności programisty.
Programista coraz mniej odpowiada za ręczne napisanie kodu, a coraz bardziej za rezultat, który ten kod daje.
To nie jest rezygnacja z odpowiedzialności. Wręcz przeciwnie. Odpowiedzialność przesuwa się z poziomu pojedynczej implementacji na poziom całego produktu: czy działa, czy spełnia wymagania, czy jest szybki, bezpieczny i przewidywalny.
Kod może przy tym stać się czarną skrzynką. Nie trzeba znać każdej linii, jeśli potrafi się wiarygodnie ocenić zachowanie systemu. I właśnie to może być najtrudniejszą do zaakceptowania częścią tej zmiany.
Przez lata dobry programista miał wiedzieć, co dzieje się pod maską. Rozumieć abstrakcje, kontrolować implementację, czytać kod i wiedzieć, dlaczego system zachowuje się w określony sposób.
Teraz ten punkt ciężkości się przesuwa. Coraz ważniejsze staje się to, czy człowiek potrafi dobrze określić cel, ocenić wynik i rozpoznać, kiedy rozwiązanie jest właściwe, a kiedy tylko pozornie działa.
Nie oznacza to, że kod przestaje być ważny. Przestaje być tylko centralnym przedmiotem pracy człowieka. Programista nie znika z procesu, ale jego miejsce przesuwa się z poziomu składni na poziom decyzji.
I tutaj wracamy do Rails. Kiedyś rewolucyjne było to, że programista nie musiał pisać konfiguracji, którą framework potrafił wywnioskować sam. Dzisiaj ta sama logika zaczyna obejmować coraz większą część implementacji.
Najważniejsze pytanie nie brzmi więc, czy agent napisze kod szybciej od człowieka. Bardziej interesujące jest to, czy branża zaakceptuje model, w którym człowiek nadal odpowiada za oprogramowanie, ale jego podstawową pracą nie jest już ręczne pisanie tego oprogramowania.
#linux #programista15k #programowanie #webdev #windows #sztucznainteligencja #technologia #filozofia #ekonomia #biznes #artificialintelligence #
Migfirefox
2026-10-05 16:02:05
+1
BooB
2026-10-05 16:19:56
+0
