Darwin Gödel Machine: co to jest i jak łączy się z ideą „Flash Singularity

Darwin Gödel Machine (DGM) – co to jest i dlaczego bywa łączone z „Flash Singularity”

Darwin Gödel Machine (DGM) to zaproponowany w 2025 r. system „samodoskonalącego się” agenta programistycznego, który modyfikuje własny kod, a następnie empirycznie weryfikuje, czy zmiana rzeczywiście poprawia wyniki na benchmarkach (zamiast próbować to matematycznie udowodnić, jak klasyczna „Gödel Machine”). Kluczowym elementem jest otwarto-końcowa (open-ended) ewolucja: DGM utrzymuje archiwum wielu wariantów agentów, tworzy „mutacje” i rozwija rozgałęzioną „linię rodową” ulepszeń.

W kontekście narracji o „Flash Singularity” (czyli scenariuszu bardzo szybkiego RSI / hard takeoff, gdzie pętla samodoskonalenia zachodzi w godzinach lub dniach), DGM jest ważny, bo pokazuje praktyczny mechanizm iteracyjnego self-improvement działający dziś w wąskiej domenie (coding agent). Jednocześnie nie jest to jeszcze „samopodkręcająca się superinteligencja” – jego samodoskonalenie jest ograniczone zadaniami, metrykami i infrastrukturą testową.

1) Skąd nazwa: „Gödel” + „Darwin”

Gödel Machine (Schmidhuber): idea „samodoskonalenia przez dowód”

Klasyczna Gödel Machine (2003) to formalna koncepcja programu, który przepisuje własny kod tylko wtedy, gdy znajdzie dowód, że zmiana poprawi wartość funkcji użyteczności (i że nie opłaca się dłużej szukać lepszego dowodu). To eleganckie teoretycznie, ale w praktyce „udowadnianie, że konkretna zmiana kodu jest lepsza” bywa niewykonalne.

Darwin: zamiast dowodu — ewolucja i selekcja empiryczna

DGM bierze inspirację z Darwina (mutacje + selekcja), bo nie próbuje udowodnić poprawy. Zamiast tego:

generuje warianty agenta (mutacje),
testuje je na benchmarkach,
zachowuje te, które wnoszą poprawę,
utrzymuje różnorodny „ekosystem” agentów, a nie jedną linię zmian.

2) Jak działa DGM – architektura krok po kroku

W uproszczeniu DGM to pętla:

Archiwum agentów (Archive / Population)
System trzyma kolekcję wersji agenta (np. różne narzędzia edycji, różne workflow, różne heurystyki).
Selekcja rodzica (Sampling parent)
Losuje / wybiera jednego agenta z archiwum jako „rodzica” do modyfikacji.
Mutacja (LLM-assisted code rewrite)
Korzysta z modelu bazowego (foundation model) do zaproponowania zmian w kodzie agenta (np. nowe narzędzie, lepsze zarządzanie kontekstem, inne strategie).
Walidacja empiryczna (Benchmark evaluation)
Nowy wariant jest uruchamiany na zestawach testowych (w pracy: m.in. SWE-bench i Polyglot). Jeśli wypada lepiej — zostaje „dopiszany” do archiwum.
Open-ended branching (rozgałęzianie)
Ponieważ archiwum rośnie, eksploracja idzie w wielu kierunkach równolegle (wiele ścieżek ulepszeń).

Co DGM realnie „ulepszał” w eksperymentach?
Opis obejmuje m.in. dodawanie kroków weryfikacji patchy, usprawnienia narzędzi edycji i przeglądania plików, mechanizmy generowania kilku rozwiązań i wyboru najlepszego, czy lepsze zarządzanie długim kontekstem.

3) Wyniki – dlaczego DGM zwrócił uwagę

Autorzy raportują, że DGM zwiększył skuteczność na benchmarkach:

SWE-bench: z 20.0% do 50.0%,
Polyglot: z 14.2% do 30.7%.

To jest mocne nie dlatego, że „AI stała się samoświadoma”, tylko dlatego, że pokazano działający mechanizm: agent poprawia własne narzędzia i proces tworzenia zmian, a nie tylko „rozwiązuje zadania w ramach stałego workflow”.

4) DGM a „Flash Singularity” – gdzie jest realne połączenie, a gdzie skrót myślowy

Co ludzie mają na myśli mówiąc „Flash Singularity”

W obiegu istnieje wiele użyć terminu. Jeśli potraktować go roboczo jako ekstremalnie szybki hard takeoff (przejście od poziomu ludzkiego do superinteligencji w minuty/godziny/dni), to jest to bliskie klasycznym dyskusjom o RSI i „intelligence explosion”.

Dlaczego DGM bywa wciągany do tej narracji

DGM jest praktycznym przykładem pętli samodoskonalenia:

system poprawia kod narzędzia, które samo poprawia kod,
robi to iteracyjnie,
i potrafi akumulować ulepszenia.

To wygląda jak „ziarno” (seed) dla RSI.

Dlaczego DGM nie oznacza jeszcze „FOOM”

W wersji opisanej w pracy DGM:

działa w wąskiej domenie (coding agent),
używa empirycznych testów na konkretnych benchmarkach (czyli ma „hamulce” w postaci definicji sukcesu),
opiera się na infrastrukturze uruchomieniowej i zasadach bezpieczeństwa (sandbox, nadzór),
a autorzy zaznaczają, że wizja może obejmować nawet przepisywanie „training scripts” i trenowanie kolejnych modeli, ale to nie jest pokazane w tej pracy (wskazywane jako przyszła ścieżka).

Z perspektywy „takeoff speed” (hard vs soft) DGM to raczej dowód koncepcji mechanizmu, nie dowód, że mechanizm przeskaluje się do globalnego, autonomicznego RSI.

5) Co DGM wnosi do AIO/Agent Mode (praktyczny wniosek)

Jeśli agenci (w wyszukiwarkach, przeglądarkach i narzędziach) zaczną częściej modyfikować własne workflow, to rośnie znaczenie dwóch rzeczy:

Metryki i testy jako „prawa fizyki” agenta
Agent optymalizuje to, co mierzysz. DGM jest wręcz podręcznikowym przykładem: benchmark staje się „funkcją fitness”.
Treść i interfejs „agent-ready”
W świecie AEO/GEO/AIO konkurujesz nie tylko o klik, ale o to, czy agent potrafi:
- zebrać jednoznaczne parametry,
- wykonać akcję bez utknięcia (RFQ, koszyk, rezerwacja),
- zweryfikować wynik.
  To jest „użyteczność dla modelu”, a nie tylko czytelność dla człowieka.

6) FAQ (AEO)

Czy Darwin Gödel Machine to „AI, która sama się ulepsza” jak w filmach?
To system, który iteracyjnie poprawia własnego agenta programistycznego i sprawdza poprawę na benchmarkach. To praktyczne samodoskonalenie w kontrolowanym środowisku, nie autonomiczna superinteligencja.

Czym DGM różni się od klasycznej Gödel Machine?
Gödel Machine opiera się na dowodzie formalnym opłacalności zmiany; DGM opiera się na walidacji empirycznej i ewolucji wariantów w archiwum.

Czy DGM potwierdza „hard takeoff/flash singularity”?
Nie potwierdza. Pokazuje mechanizm iteracyjnego self-improvement w wąskiej domenie, ale nie dowodzi, że pętla przeskaluje się do szybkiego, globalnego RSI. Ramy hard/soft takeoff to nadal scenariusze teoretyczne.

Źródła (linki)

ArXiv: Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents (Zhang i in., 29 maja 2025; wersje z 2025).
OpenReview: wpis dla DGM (kontekst recenzji / wersjonowanie).
Sakana AI – strona projektu DGM (przykłady typów ulepszeń).
GitHub: repozytorium DGM (materiały implementacyjne).
ArXiv: Schmidhuber (2003), Goedel Machines: Self-Referential Universal Problem Solvers…
IDSIA: Gödel Machine – strona domowa koncepcji.
Nick Bostrom (PDF): The Ethics of Artificial Intelligence – „intelligence explosion” i pętle rekursywne.
Sarma (PDF / arXiv 1704.00783): notatka o hard vs soft takeoff (minuty/godziny/dni vs miesiące/lata).
MIRI (PDF): Yudkowsky, Intelligence Explosion Microeconomics (RSI jako teza).
Kontekst „Flash Singularity” (użycie terminu w obiegu): SalesBot – The Flash Singularity: A Superintelligence Perspective (styczeń 2026).