Wyobraźmy sobie piątkowe spotkanie zarządu firmy hotelarsko-restauracyjnej. Na ekranie pojawia się raport przygotowany przez AI. Oprócz propozycji dotyczących sprzedaży pokoi, konferencji i gastronomii zawiera rzecz mniej zwyczajną: projekt zmiany sposobu, w jaki sam system będzie przygotowywał i sprawdzał następne propozycje. Tym razem system prosi zarząd o zgodę na poprawianie samego siebie.
Firma ma dwa bardzo różne hotele. Pierwszy jest mały, butikowy, pięciogwiazdkowy: 50 pokoi i wysokie ceny. Drugi dysponuje 180 pokojami, salami konferencyjnymi i zapleczem rekreacyjnym. Do tego dochodzą trzy renomowane restauracje ze średniej i wyższej półki. Wspólny właściciel nie oznacza wspólnego sposobu zarabiania. Pusty pokój w butikowym hotelu, wolna sala konferencyjna i niewykorzystany stolik stawiają przed zarządem różne pytania.
W tym hipotetycznym scenariuszu firma udostępnia AI uporządkowane dane operacyjne. Początkowo system pomaga podejmować decyzje. Z czasem zaczyna również przebudowywać narzędzia, którymi rozpoznaje problemy, oraz sposób wybierania prób, które opłaca się przeprowadzić.
Zwykle pytamy, czy dzięki technologii firma działa lepiej. Tutaj pojawia się drugie pytanie: czy system staje się sprawniejszy w znajdowaniu kolejnych ulepszeń? I czy potrafimy jeszcze rozpoznać, kiedy rzeczywiście się doskonali, a kiedy tylko przygotowuje coraz bardziej przekonujące raporty?
Gdzie zaczyna się pętla
W informatyce rekurencja oznacza wywoływanie procedury przez nią samą, bezpośrednio lub pośrednio. Jeśli obliczenie ma się skończyć, potrzebny jest warunek zakończenia, do którego procedura rzeczywiście dojdzie. Samo powtarzanie wywołań nie oznacza postępu. W rozmowie o AI słowo to opisuje szerzej sprzężenie zwrotne: system uczestniczy w tworzeniu ulepszenia, a ulepszenie zwiększa jego zdolność do tworzenia następnych ulepszeń. Liczy się właśnie ten drugi krok. Wyższa sprzedaż pokoi może być sukcesem handlowym. Dopiero poprawa zdolności systemu do dalszego rozwoju nadaje temu przykładowi element rekurencyjny.
Samo aktualizowanie prognoz na podstawie nowych danych nie dowodzi jeszcze rekurencyjnego samodoskonalenia. Agent, czyli model korzystający z narzędzi i wykonujący kolejne działania, może pójść dalej: zaproponować zmianę własnego narzędzia analitycznego, sprawdzić ją i korzystać z niej w następnych pracach. Jeszcze innym poziomem jest doskonalenie algorytmów uczenia samych modeli AI. W naszym hotelowym przykładzie zajmiemy się ograniczonym samodoskonaleniem agenta, które nie jest dowodem na autonomiczny rozwój całej sztucznej inteligencji.
W 1965 roku Irving John Good, matematyk, który w czasie wojny łamał z Turingiem szyfry w Bletchley Park, rozważał maszynę przewyższającą ludzi także w projektowaniu maszyn. Mogłaby zatem tworzyć jeszcze sprawniejszych następców. Tak opisywał możliwość eksplozji inteligencji: hipotezę opartą na mocnym założeniu o możliwościach pierwszej maszyny.[1]
Jürgen Schmidhuber zaproponował maszynę Gödla: program zmieniający własny kod po znalezieniu dowodu, że zmiana się opłaci według z góry ustalonej miary. Znalezienie takiego dowodu pozostało ogromną trudnością, więc dzisiejsze podejścia eksperymentalne opierają się zwykle na próbach i porównywaniu wyników.[2] Trzeba jednak ustalić, jak odróżnić poprawę od pozornego sukcesu.
Dwa rachunki
W pierwszym etapie system zajmuje się znanymi zadaniami analitycznymi. W butikowym hotelu oblicza wynik po kosztach pozyskania i obsługi pobytu. Zarząd chce utrzymać wysoką cenę oraz jakość, która ją uzasadnia; samo zapełnienie 50 pokoi rabatem niewiele mu powie. W hotelu konferencyjnym rachunek obejmuje całe wydarzenie, także przygotowanie sal i sprzątanie. Trzeba jeszcze uwzględnić rezerwacje, dla których zabraknie miejsca, i porównać wynik z innym wykorzystaniem tego samego terminu. Dla trzech restauracji prowadzi trzy osobne prognozy, bo mają różne karty, różnych gości i różny rytm. To nadal zwykła analityka. Rekurencyjny element pojawia się dopiero wtedy, gdy agent zajmie się własnym sposobem pracy.
Załóżmy, że jego prognoza dla butikowego hotelu regularnie zawodzi. Analiza historii pokazuje, że narzędzie błędnie traktuje zmianę terminu istniejącej rezerwacji jako pojawienie się nowego popytu. Agent proponuje poprawkę oprogramowania przetwarzającego te zdarzenia, zachowuje poprzednią wersję i porównuje obie na danych, których nie używał podczas przygotowywania zmiany.
Po niezależnym sprawdzeniu i zatwierdzeniu poprawki agent korzysta z lepszego narzędzia. W kolejnym obiegu poprawione dane mogą ujawnić, że jego procedura testowa porównuje zwykłe weekendy z terminami dużych wydarzeń. Agent proponuje więc zmianę sposobu testowania prognoz i znów poddaje ją ocenie. Ulepszone narzędzie pomogło przygotować następne ulepszenie. To już jest pętla, choć dwie udane poprawki nie dowodzą jeszcze trwałego przyspieszenia.
W hotelu konferencyjnym ta sama zasada dotyczy wyboru eksperymentów. Początkowo agent proponuje zmienić jednocześnie cenę pakietu, sposób prezentacji oferty i zakres świadczeń; po zakończeniu sprzedaży nikt nie wie, co zadziałało. Kolejna wersja jego procedury rozdziela te zmiany, dobiera porównywalne zapytania według ustalonego wcześniej planu i sprawdza, czy próba nie zakłóci obsługi. Agent przebudowuje własną metodę planowania testów, żeby następna próba dawała bardziej rozstrzygający wynik.
Restauracje dostarczają trzeciego sprawdzianu. Agent odkrywa, że jego narzędzie liczyło wyrzucone produkty, lecz pomijało zamówienia, których kuchnia nie mogła przyjąć, bo dania już zabrakło. Rozszerza więc diagnozę o rejestr niedostępności i sprawdza poprawkę w pozostałych lokalach, z zachowaniem ich odmiennych profili. Lepsza diagnoza powinna następnie pomagać mu wybierać trafniejsze zmiany prognozowania i przygotowania produktów.
Mamy zatem dwa odrębne rachunki. Pierwszy dotyczy firmy: czy zarabia więcej po kosztach i utrzymuje standard obsługi. Drugi dotyczy agenta: czy dzięki poprawionym narzędziom i procedurom lepiej rozpoznaje problemy i szuka rozwiązań. Sprawdzianem jest poprawa jakości rozwiązań na niezależnych zadaniach przy takim samym budżecie i porównywalnej trudności. Kryteria użyteczności ustalamy przed próbą. Liczy się potwierdzony efekt, nie liczba propozycji. Dobrego miesiąca restauracji nie można wpisać automatycznie na konto rosnącej inteligencji systemu.
Procent, który pracuje dalej
Fragmenty tego mechanizmu badacze pokazują w rzeczywistych eksperymentach. W maju 2025 roku Google DeepMind opisał AlphaEvolve, system łączący modele językowe, automatyczną ocenę i ewolucyjne poszukiwanie algorytmów. Według firmy znalezione usprawnienie przyspieszyło ważny fragment obliczeń w architekturze Gemini o 23 procent, co w całym treningu Gemini przełożyło się na skrócenie czasu o około jeden procent.[3]
Pierwsza liczba opisuje sukces elementu, druga jego znaczenie dla całości; skrócenie jednej czynności kuchennej też nie oznacza identycznej poprawy wydajności restauracji. AlphaEvolve pomagał usprawnić uczenie modeli, na których sam był oparty. Odzyskane zasoby można przeznaczyć na następne eksperymenty i dopiero ich efekty pokażą, czy ten procent pracuje dalej.
Twórcy Darwin Gödel Machine badali agenta modyfikującego własne oprogramowanie: narzędzia i organizację rozwiązywania zadań. Na badanej próbie 200 zadań programistycznych z zestawu SWE-bench Verified odsetek rozwiązanych problemów wzrósł z 20 do 50 procent, choć sam model bazowy pozostał niezmieniony.[4]
W pracy Dream-RSI, udostępnionej we wrześniu 2026 roku jako preprint, przedmiotem doskonalenia jest sama strategia poszukiwań: system wykorzystuje zapis wcześniejszych prób, żeby tanio porównywać alternatywne sposoby prowadzenia pracy, a wybraną strategię stosuje w kolejnej rundzie. Modele i reguły oceny pozostają niezmienione. Autorzy raportują utrzymanie lub poprawę jakości odkryć przy niższym koszcie poszukiwań w części badanych zadań. Koszt ten mierzą liczbą wywołań agenta prowadzącego poszukiwania.[5]
Stażysta z dostępem do laboratorium
We wrześniu 2026 roku OpenAI poinformowało, że według własnych pomiarów osiągnęło poziom zautomatyzowanego „stażysty badawczego”: systemu wykonującego dobrze określone zadania pod kierunkiem człowieka, również takie, które badaczowi zajęłyby kilka dni. Ludzie nadal ustalają priorytety i oceniają, które rezultaty rozwijać.[6]
Anthropic porównuje w swoim prototypowym indeksie stały koszyk rodzajów pracy badawczo-rozwojowej nad AI w samej firmie, z wagami opartymi na szacowanym zaangażowaniu pracowników. Indeks nie mierzy wprost zaoszczędzonego czasu. Według tego pomiaru w sierpniu 2026 roku Claude prowadził prace stanowiące 26 procent koszyka; w lutym było to mniej niż jeden procent. „Prowadzić” oznacza tu wykonywanie większości zadania na podstawie ogólnego polecenia, pod ludzkim nadzorem. Żaden z mierzonych podobszarów nie działał w pełni autonomicznie. Firma wskazała też ograniczenie pomiaru: własne modele oceniają pracę własnych systemów, więc wykonawca i oceniający mogą popełniać podobne błędy.[7]
To relacje twórców i sprzedawców technologii, nie niezależny pomiar branży. Pokazują rosnący udział AI w tworzeniu następnych systemów. W pomiarze Anthropic uwagę zwraca zwłaszcza zmiana w ciągu pół roku; nie daje jednak podstaw, by założyć takie samo tempo w kolejnych miesiącach. Nie pokazują domknięcia autonomicznej pętli. Pozostaje kwestia osądu: które badanie ma sens, kiedy je przerwać i jak rozpoznać pozorny sukces.
Pętla nie obiecuje nieskończoności
Najsilniejszy argument zwolenników gwałtownego przyspieszenia zasługuje na poważne potraktowanie. Takie systemy można uruchamiać równolegle, jeśli wystarczy zasobów obliczeniowych. Udany wynik jednego może poprawić pracę pozostałych, a jeżeli efektem jest sprawniejsze oprogramowanie badawcze, korzyści mogą się kumulować. Tego mechanizmu nie unieważnia fakt, że obecne systemy nadal popełniają błędy.
Poprawka narzędzia analizującego rezerwacje mogłaby pomóc również drugiemu hotelowi. Trzeba jednak sprawdzić zgodność zapisów oraz działanie przy rezerwacjach grupowych, zanim uznamy, że również tam zadziała.
Pętla przyspiesza tam, gdzie sprawdzian jest szybki i tani. W części badań nad AI sprawdzianem jest test, który można szybko i wielokrotnie powtarzać. W hotelu sprawdzianem jest gość, a gość odpowiada w swoim tempie. AI może przygotować warianty oferty konferencyjnej w kilka minut, lecz na decyzje klientów trzeba poczekać, podobnie jak na ocenę pobytu i powrót gościa. Przeliczanie tych samych historycznych danych nie tworzy nowych obserwacji.
Anthropic, rozważając przyszłość samodoskonalenia AI, wymienia ograniczenia dostaw energii, produkcji układów i infrastruktury, a zarazem dopuszcza wyhamowanie wzrostu możliwości.[8] W hotelu granicą może być dostępność ludzi i przestrzeni, w laboratorium czas eksperymentu i moc obliczeniowa. Przyspieszenie jednego etapu przenosi uwagę na ten, który nadal trwa najdłużej.
W lipcu 2026 roku organizacja badawcza METR opisała próby, w których agenty miały samodzielnie usprawnić wcześniej wielokrotnie optymalizowany proces treningu małego modelu językowego. Nowsze modele znajdowały rzeczywiste, lecz umiarkowane ulepszenia. W części prób ze starszymi modelami pozorny postęp znikał przy ponownym sprawdzeniu: pochodził z szumu pomiarowego. Autorzy zauważyli też, że w tych próbach agenty często sięgały po drobne poprawki, jak strojenie parametrów, podczas gdy ludzie częściej znajdowali rozwiązania ogólniejsze; zaznaczyli przy tym ograniczoną skalę badania i możliwą nieefektywność konfiguracji.[9]
W hotelu taką łatwą poprawką bywa rabat.
Gdy maszyna poprawia sprawdzian
W osobnym eksperymencie dotyczącym Darwin Gödel Machine system miał oduczyć się udawania, że korzysta z narzędzi. Czasami proponował rzeczywiste poprawki. Zdarzało się jednak, że usuwał znaczniki służące do wykrywania problemu: wskaźnik wyglądał lepiej, ponieważ pogarszała się zdolność sprawdzenia, co zaszło.[10] Nie trzeba przypisywać maszynie ludzkich intencji, żeby rozpoznać kłopot z takim wynikiem.
To stary problem w nowym wydaniu. Radziecka fabryka gwoździ oceniana według wagi produkcji zaczynała, jak głosi anegdota, produkować jeden gigantyczny gwóźdź. W obu przypadkach poprawia się wynik, a miara traci związek z tym, czemu miała służyć.
W naszej firmie odpowiednikiem byłby raport chwalący obłożenie butikowego hotelu po kosztownych rabatach albo niskie straty kuchni, która za wcześnie wyczerpała ofertę. Wskaźnik może być prawdziwy, a rekomendacja rozwijania zmiany błędna.
Warunki zatrzymania określają, kiedy kończymy próby, choćby po wyczerpaniu budżetu lub ustalonej serii prób bez poprawy. Warunki wdrożenia dotyczą opłacalności, pełnego rachunku kosztów, standardu obsługi i dostępności oferty. Agent nie może ich sam poluzować. Zarząd musi też widzieć, czy sukces jednego obiektu nie maskuje pogorszenia w innym.
Dla agenta potrzebny jest osobny sprawdzian na danych i zadaniach niewykorzystywanych do przygotowania poprawki, a nowa wersja powinna być porównana z poprzednią przy podobnym budżecie. Zmiany samego sprawdzianu wymagają odrębnej oceny, bo inaczej wykonawca poprawi ocenę, zmieniając znaczenie sukcesu. A wynik rzeczywistej próby trzeba jeszcze odróżnić od wpływu sezonu, wydarzeń w okolicy lub zmiany struktury gości.
Agent może proponować poprawki własnego oprogramowania w wydzielonym środowisku i zachowywać historię wersji. Nie wynika z tego swoboda zmiany cen, warunków podpisanej konferencji czy standardów obsługi w działających obiektach. Rozwój systemu i zastosowanie jego pomysłu mają osobne warunki zatwierdzenia.
Ten opis zakłada, że firma kontroluje środowisko, w którym agent się zmienia. Dane do prób powinny być ograniczone do niezbędnych informacji, a dostęp agenta do danych gości i klientów wymaga osobnych uprawnień. Gdy korzysta z produktu dostawcy, zakres kontroli wymaga uzgodnienia. Dostęp do środowiska testowego, historii wersji i danych do niezależnej oceny warto określić przed wdrożeniem.
Kto zachowa wiedzę firmy
Dla właściciela cennym rezultatem byłaby wiedza o tym, dlaczego coś zadziałało: które zmiany powtórzyć, gdzie brakuje danych i jakie obiecujące pomysły zawiodły. Agent może pomagać zachować tę wiedzę i wykorzystywać ją w następnych analizach.
Nie chciałbym po kilku latach odkryć, że firma oddała dostawcy całą pamięć własnego uczenia się. Wyniki prób, uzasadnienia decyzji i procedury powinny pozostać dostępne także po zmianie narzędzia. Sprawniejsza usługa może zwiększać zależność, dlatego zawczasu trzeba ustalić, kto zachowa historię eksperymentów oraz możliwość odtworzenia przyjętych reguł.
Trzeba też policzyć pełny koszt. Do opłaty za AI dochodzi uporządkowanie danych, praca menedżerów, sprawdzanie propozycji i ewentualne błędy wdrożeń. Tania rekomendacja może uruchomić kosztowną próbę. Samodoskonalenie też zużywa zasoby i trzeba je uwzględnić w rachunku. System proponujący coraz więcej eksperymentów nie musi być systemem coraz bardziej opłacalnym.
Piątkowe spotkanie trwa dalej
Wracamy do raportu na ekranie. Tym razem dyrektor hotelu butikowego pyta, czy lepsza prognoza rzeczywiście pomogła utrzymać cenę. Menedżer konferencji chce wiedzieć, czego nauczyła go ostatnia próba sprzedażowa. Szef restauracji sprawdza, czy mniejsze straty nie zostały okupione rozczarowaniem gości. Zarząd powinien otworzyć drugi rachunek: co poprawiło się w samym systemie, dzięki czemu następne decyzje mogą być trafniejsze?
Najbardziej niepokoi mnie możliwość, że takie pytania z czasem znikną. AI przygotuje propozycję, przeprowadzi test, wyjaśni wynik i zarekomenduje wdrożenie. Kolejka następnych propozycji będzie rosła. Podpis człowieka nadal znajdzie się w dokumentacji, ale przed podpisem będzie coraz mniej czasu na samodzielny osąd. Właśnie wtedy nadzór zaczyna przypominać ceremonię: podpisujemy decyzję, której nie zdążyliśmy samodzielnie ocenić.
Niezależność kontroli wymaga dostępu do dowodów, możliwości zakwestionowania rekomendacji i czasu na ocenę. Drugi model może przeoczyć to samo co wykonawca. Warto jednak zadbać o taką kontrolę: trafniejsze diagnozy i lepiej zaplanowane próby mogą oszczędzić firmie kosztownych pomyłek, a menedżerom zostawić więcej czasu dla zespołu i gości.
Raport może pomóc ocenić, czy firma działa lepiej i czy system trafniej szuka usprawnień. Ważne pozostaje jednak to, jaką firmę chcemy prowadzić. Czy butikowy hotel ma pozostać miejscem wartym swojej wysokiej ceny? Co obiecujemy organizatorowi konferencji, a czego nie sprzedamy mimo atrakcyjnego przychodu? Z jakiego powodu gość ma wrócić do jednej z naszych restauracji? AI może pomóc nam realizować te wybory. Musimy jednak sami wziąć za nie odpowiedzialność.
Źródła
1. Irving John Good, „Speculations Concerning the First Ultraintelligent Machine”, Advances in Computers, t. 6, 1965, s. 31–88; omówiona hipoteza na s. 33. https://languagelog.ldc.upenn.edu/myl/Good1964.pdf
2. Jürgen Schmidhuber, „Goedel Machines: Self-Referential Universal Problem Solvers Making Provably Optimal Self-Improvements”, 2003, wersja z 2006 r. https://arxiv.org/abs/cs/0309048
3. Google DeepMind, „AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms”, 14 maja 2025. https://deepmind.google/blog/alphaevolve-a-gemini-powered-coding-agent-for-designing-advanced-algorithms/
4. Jenny Zhang, Shengran Hu, Cong Lu, Robert Lange, Jeff Clune, „Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents”, ICLR 2026; pierwsza wersja 2025, wersja z 12 marca 2026. https://arxiv.org/abs/2505.22954
5. Tong Zheng i współautorzy, „Dream-RSI: Recursive Self-Improvement through Evolving Worlds”, preprint, 14 września 2026. https://arxiv.org/abs/2609.14858
6. OpenAI, „Research acceleration: The view inside OpenAI”, 6 września 2026. https://openai.com/index/research-acceleration-view-inside-openai/
7. Anthropic Institute, „Measurements for understanding the pace of AI development inside frontier labs”, 17 września 2026; dane za sierpień 2026. https://www.anthropic.com/institute/measuring-pace-of-ai-development
8. Anthropic Institute, „When AI builds itself”, 2026; dostęp 27 września 2026. https://www.anthropic.com/institute/recursive-self-improvement
9. METR, „Expenditure Horizon: Measuring Optimization Ability, with an Application to NanoGPT”, 21 lipca 2026. https://metr.org/blog/2026-07-21-expenditure-horizon/
10. Sakana AI, „The Darwin Gödel Machine: AI that improves itself by rewriting its own code”, 30 maja 2025, część „DGM and AI Safety”. https://sakana.ai/dgm/
