Andrej Karpathy twierdzi, że Techmeme LLMs sygnalizuje nową erę tworzenia, lecz luka w audycie pozostaje

Andrej Karpathy twierdzi, że LLM-y przekroczyły wyraźny próg, choć zachowały podstawową słabość: nadal nie potrafią niezawodnie analizować tego, co budują. Najnowsza dyskusja techmeme llms koncentruje się na systemach tworzących z krótkich instrukcji spersonalizowane, interaktywne światy. Systemy te często jednak polegają na ludziach, którzy zauważają błędną fizykę, źle rozmieszczone obiekty, artefakty wizualne i brakujące interakcje.

Karpathy przedstawił tę zmianę poprzez porównanie ze starszym testem modeli. Prośba, by LLM stworzył SVG pelikana jadącego na rowerze, kiedyś ujawniała jego rozumienie kodu, geometrii i relacji między obiektami. Nowe wyzwanie jest znacznie większe. Model potrafi teraz wygenerować oprogramowanie stojące za eksplorowalną sceną, wraz z animacją, kamerami, oświetleniem i symulowanym zachowaniem.

Ta skala zmienia kryteria sukcesu. Wygenerowanie tysięcy wierszy wiarygodnego kodu to nie to samo co stworzenie spójnego świata. Główna rywalizacja toczy się obecnie między generowaniem a weryfikacją. Modele potrafią rozbudowywać artefakt szybciej, niż są w stanie postrzegać, testować i naprawiać wynikowe doświadczenie.

Techmeme LLMs wychodzi poza test pelikana

Wpis Karpathy'ego oznacza przejście od oceny pojedynczych wyników do oceny kompletnych doświadczeń.

W swoim oryginalnym wpisie Karpathy stwierdził, że branża opuszcza obszar testów takich jak tworzenie SVG pelikana na rowerze. Opisał LLM-y jako zmierzające w stronę hiperspersonalizowanych światów generowanych na żądanie.

Wpis rozszedł się za pośrednictwem dyskusji Techmeme 2 sierpnia 2026 roku. Towarzyszące materiały pokazywały animowaną, trójwymiarową interpretację fikcyjnej sceny. Wydawała się łączyć wygenerowany kod, postacie, elementy otoczenia, ruch i zachowanie kamery.

Publicznie dostępne materiały nie ustanawiają kontrolowanego benchmarku. Nie ujawniają każdego promptu, interwencji, ponownej próby ani ręcznej poprawki. Demonstrację należy więc traktować jako dowód możliwego procesu pracy, a nie jako dowód autonomicznego tworzenia światów.

Nawet z tym zastrzeżeniem zmiana jest znacząca. SVG to ograniczony artefakt o stosunkowo niewielkiej powierzchni problemów. Świat działający w przeglądarce zawiera wiele współdziałających systemów, z których każdy może zawieść niezależnie.

Model musi wybrać pozycje, skale, kolory, materiały i ścieżki ruchu obiektów. Musi zarządzać kodem renderowania, czasem, rozmieszczeniem kamery, stanem animacji i kontrolkami użytkownika. Potrzebuje też przełożyć niejednoznaczną prozę na konkretne decyzje wizualne.

Właśnie dlatego test pelikana stał się użyteczny. Rower ma rozpoznawalne zależności mechaniczne. Model może stworzyć coś przypominającego rower, ale niepoprawnie połączyć ramę, łańcuch, pedały i układ kierowniczy.

Oprogramowanie może ukryć ten sam problem za większym spektaklem. Wygenerowana scena może wyglądać imponująco podczas krótkiego nagrania, a jednocześnie zawodzić przy innym kącie kamery. Obiekt może lewitować, znikać, przenikać przez ścianę albo zmieniać rozmiar, gdy użytkownik się porusza.

Te błędy trudniej streścić niż zniekształcony rysunek. Wynikają z interakcji zachodzących w czasie, a nie z jednej statycznej klatki. Recenzent musi eksplorować świat, pamiętać wcześniejsze stany i rozumieć, które rezultaty naruszają zamierzony projekt.

Rozwijająca się kolekcja pelikanów Simona Willisona pokazuje, dlaczego testy wizualne zyskały uwagę. Różne modele potrafiły napisać poprawny kod SVG, tworząc jednocześnie wyraźnie odmienne interpretacje tej samej prośby. Wynik ujawniał luki, których zwykłe benchmarki programistyczne często nie dostrzegały.

Sukces może jednak nasycić benchmark. Gdy modele odtwarzają znane wzorce testowe, prompt przestaje odróżniać szerokie kompetencje od ukierunkowanego treningu lub zapamiętanych konwencji. Większe, mniej przewidywalne środowisko daje więcej przestrzeni do ujawniania błędów.

Najnowsza debata techmeme llms nie dotyczy więc przede wszystkim tego, czy prezentowany świat zasługuje na artystyczne uznanie. Chodzi o to, czy jednostka tworzenia przez AI się rozszerzyła. Dostępne dowody sugerują, że tak.

Użytkownik nie musi już prosić wyłącznie o obraz, akapit, komponent lub skrypt. Prośba może opisywać tymczasowe doświadczenie dostosowane do jednej osoby. Model może złożyć to doświadczenie z kodu, podczas gdy użytkownik czeka.

To różni się od konwencjonalnego tworzenia gier. Studio buduje wspólny produkt dla szerokiej publiczności i testuje go przed premierą. Generowanie na żądanie traktuje natomiast oprogramowanie jako coś tymczasowego, osobistego i taniego do zamówienia.

Nauczyciel mógłby poprosić o interaktywną reprezentację historycznego miejsca. Dziecko mogłoby poprosić o mały świat oparty na bajce na dobranoc. Zespół produktowy mógłby przekształcić opisany scenariusz w prototyp, po którym można się poruszać, zanim zdecyduje się na produkcję.

Aby miały znaczenie, rezultaty te nie potrzebują filmowego realizmu. Generowane światy o niskiej wierności mogą nadal przekazywać relacje przestrzenne, pomysły na interakcje i sekwencje narracyjne. Ich wartość może wynikać ze specyfiki i szybkości, a nie z dopracowania.

Demonstracja przesuwa zatem pytanie. Nie brzmi ono już po prostu: „Czy LLM potrafi narysować żądany obiekt?”. Trudniejsze pytanie brzmi: „Czy potrafi utrzymać spójny system podczas jego eksplorowania?”.

Światy na żądanie wywierają presję na oprogramowanie kreatywne

Bezpośrednia presja dotyczy narzędzi zakładających, że każde interaktywne doświadczenie wymaga długiego, ręcznego procesu produkcyjnego.

Tradycyjne oprogramowanie kreatywne oddziela pisanie, ilustrację, modelowanie, animację, programowanie i testowanie. Specjaliści przeprowadzają pracę przez te etapy za pomocą plików, edytorów i procesów recenzji. Systemy generatywne kompresują kilka etapów do jednego interfejsu konwersacyjnego.

Ta kompresja zmienia ekonomię prototypów. Koncepcja, która kiedyś pozostawała w dokumencie, może stać się działającą sceną. Zespoły mogą ocenić czas, skalę i interakcję, zanim zainwestują w gotowe zasoby.

Najsilniejszym zastosowaniem w krótkiej perspektywie nie jest zastępowanie kompletnej gry komercyjnej. Jest nim generowanie jednorazowych symulacji, wizualnych wyjaśnień, szkiców fabularnych i eksperymentów z interfejsem. Wyniki te muszą przetrwać tylko na tyle długo, by odpowiedzieć na konkretne pytanie.

Projektant gier mógłby sprawdzić, czy mechanika jest zrozumiała. Filmowiec mógłby przeanalizować wstępne ustawienie sceny. Edukator mógłby stworzyć eksplorowalną lekcję dostosowaną do zainteresowań jednego ucznia.

Pracownicy wiedzy mogliby również przekształcać notatki w interaktywne reprezentacje. Osobista baza wiedzy AI może zachować materiał źródłowy stojący za takimi prośbami. Ten kontekst staje się ważny, gdy generowane doświadczenie wymaga możliwości śledzenia pochodzenia informacji.

Większą szansą jest personalizacja. Konwencjonalne media zwykle oferują ten sam artefakt każdemu odbiorcy. Oprogramowanie generatywne może zmieniać postacie, złożoność, tempo, język lub tematykę dla każdej sesji.

Spersonalizowany świat może reagować na informacje podane chwilę wcześniej. Może uwzględniać projekt użytkownika, fikcyjne postacie, cele edukacyjne lub preferowany styl wizualny. Zbliża to wynik do wygenerowanej aplikacji, a nie statycznego materiału medialnego.

Google DeepMind rozwijał pokrewny kierunek poprzez modele światów, które symulują ewolucję środowisk po działaniach. Badania Genie 3 opisują światy, po których można się poruszać, generowane z tekstu w rozdzielczości 720p i z szybkością 24 klatek na sekundę.

DeepMind podał, że środowiska te mogły pozostawać spójne przez kilka minut. Przyznał również, że przestrzenie działań są ograniczone, modelowanie wielu niezależnych agentów jest trudne, a dokładność geograficzna niedoskonała. Te ograniczenia pokazują, dlaczego sam imponujący obraz wideo nie wystarcza.

Przykład Karpathy'ego reprezentuje inną drogę techniczną. LLM może pisać konwencjonalny kod graficzny wykonywany przez przeglądarkę. Dedykowany model świata generuje przyszłe stany wizualne bardziej bezpośrednio, na podstawie wcześniejszych klatek i działań użytkownika.

Obie drogi są ukierunkowane na responsywne środowiska, lecz ujawniają odmienne tryby awarii. Wygenerowany kod oferuje strukturę programu możliwą do inspekcji oraz deterministyczne wykonanie. Nadal może zawierać błędne założenia dotyczące geometrii, fizyki lub znaczenia narracyjnego.

Model świata może tworzyć bardziej naturalne obrazy bez jawnego konstruowania każdego obiektu. Jego wewnętrzny stan może być trudniejszy do zbadania przez programistów. Spójność może także pogarszać się, gdy interakcja wykracza poza efektywną pamięć modelu.

Podejścia te mogą ostatecznie się połączyć. Agent mógłby pisać logikę sceny, wywoływać generatywne modele mediów, obserwować wyrenderowany wynik i poprawiać oba elementy. Gotowy system łączyłby strukturę symboliczną z generowaniem obrazu.

Ta perspektywa wywiera presję na uznane silniki gier, narzędzia projektowe i pakiety kreatywne, aby stały się łatwiejsze w obsłudze dla agentów. Ich interfejsy zbudowano dla ludzi, którzy widzą płótno i rozumieją subtelne informacje zwrotne wizualne.

LLM działający za pośrednictwem tekstu nie otrzymuje automatycznie takiego samego doświadczenia. Może znać każdy obiekt w kodzie źródłowym, a jednocześnie nie wiedzieć, jak wygląda finalna scena. Twórcy narzędzi muszą udostępniać zrzuty ekranu, grafy scen, kontrolki testowe i ustrukturyzowaną diagnostykę.

Agenci programistyczni już pokazują, jak szybko może nastąpić ta zmiana. Anthropic przeanalizował około 400 000 sesji Claude Code przeprowadzonych między październikiem 2025 a kwietniem 2026 roku. Jego badanie agentów programistycznych wykazało, że pomiary weryfikacyjne nadal częściowo zależały od wyraźnego potwierdzenia w rozmowach.

Ten szczegół ma znaczenie wykraczające poza rozwój oprogramowania. Jeśli sukces zależy od tego, że model deklaruje ukończenie zadania, wynik może wyglądać na bardziej niezawodny, niż jest w rzeczywistości. Interaktywne światy uwidaczniają ten problem pomiarowy.

Wygenerowana aplikacja może się kompilować i uruchamiać, a mimo to nie spełniać swojego celu. Kontrolki mogą być niewygodne. Scena może błędnie przedstawiać źródło. Najważniejsza interakcja może nigdy nie zadziałać.

Narzędzia kreatywne znajdują się więc pod presją, by dostarczać informacje zwrotne, z których agenci mogą faktycznie korzystać. Udana integracja musi pomagać modelowi analizować zachowanie, a nie jedynie generować więcej kodu.

Generowanie wyprzedziło natywną percepcję

Centralny kompromis jest prosty: modele potrafią tworzyć większą przestrzeń stanów, niż są w stanie niezawodnie eksplorować i audytować.

Przestrzeń stanów to zbiór warunków, w jakie system może wejść w wyniku różnych działań. Nawet niewielki interaktywny świat może zawierać wiele pozycji, widoków kamery, stanów obiektów i kombinacji zdarzeń. Testowanie każdej ścieżki szybko staje się niepraktyczne.

LLM-y generujące kod działają dobrze, gdy informacje zwrotne docierają w formie tekstu. Kompilator może wskazać błąd składni i odpowiedni wiersz. Test może zwrócić jasny wynik pozytywny lub negatywny.

Jakość wizualna rzadko zapewnia tak jednoznaczną informację zwrotną. Program może wykonywać się poprawnie, a mimo to prezentować niemożliwą lub dezorientującą scenę. Nie pojawia się żaden wyjątek, gdy stopy postaci ślizgają się po ziemi.

Model potrzebuje percepcji, aby znaleźć tę klasę problemów. Musi przechwycić wyrenderowany wynik, rozpoznać obiekty, porównać je z instrukcją i zdecydować, czy ich relacje mają sens. Następnie musi powiązać widoczną wadę z właściwym kodem.

Obecne systemy multimodalne potrafią wykonywać części tego cyklu. Mogą interpretować zrzuty ekranu i rozumować o wielu elementach wizualnych. Mogą również poprawiać kod po otrzymaniu opisu usterki od użytkownika.

Jednak te możliwości nie gwarantują niezawodnej samooceny. Ten sam model, który stworzył błędny układ, może powtórzyć swoje założenie podczas przeglądania zrzutu ekranu. Może przeoczyć subtelne błędy lub uzasadnić je jako zamierzony element projektu.

Badania nad multimodalnym sprzężeniem zwrotnym pokazują zarówno szansę, jak i ograniczenie. Badanie Volcano wykazało, że wizualne informacje zwrotne mogą ograniczać halucynacje, pomagając modelowi poprawić początkową odpowiedź. Wymagało to zaprojektowanego procesu informacji zwrotnej, a nie samego generowania.

To rozróżnienie stanowi sedno argumentu Karpathy’ego. Model może tworzyć składniki świata, nie posiadając ciągłego, naturalnego doświadczenia tego świata. Jego dostęp często zależy od narzędzi, które rejestrują wybrane klatki lub opisują wybrane stany.

Ludzki programista jednocześnie dostrzega ruch, tempo, równowagę i hierarchię wizualną. Może przesunąć kamerę, wypróbować nieoczekiwany element sterowania i zauważyć, że coś jest nie tak. Te obserwacje pojawiają się, zanim zostaną przekształcone w instrukcje słowne.

LLM zwykle otrzymuje uboższą reprezentację. Może sprawdzić jeden zrzut ekranu, dziennik konsoli albo tekstowy graf sceny. Każdy z tych formatów pomija część informacji dostępnych ludzkiemu recenzentowi.

Zrzut ekranu zatrzymuje czas. Dziennik rejestruje zaprogramowane zdarzenia, ale nie wygląd. Graf sceny opisuje obiekty, lecz nie pokazuje, czy kompozycja przekazuje zamierzone znaczenie.

Wideo może zachować ruch, ale jego analizowanie wprowadza kolejne wyzwanie. Model musi zidentyfikować istotne momenty w wielu klatkach i połączyć je ze stanem programu. Długie nagrania zużywają też znaczne zasoby kontekstu i obliczeń.

Powstaje w ten sposób asymetria. Wygenerowanie kolejnego tysiąca linii kodu może być tanie i szybkie. Staranna weryfikacja efektu w wielu stanach może wymagać wielokrotnego renderowania, percepcji, rozumowania i poprawek.

System może zatem zwiększać złożoność szybciej niż pewność. Każda wygenerowana interakcja dodaje kolejną ścieżkę, która może zawierać ukrytą wadę. Większa ilość wyniku zwiększa potrzebę lepszej oceny.

Problem ten przypomina przejście od autouzupełniania do agentów programistycznych. Autouzupełnianie proponuje niewielką zmianę, którą programista od razu widzi. Agent może zmienić wiele plików i uruchomić polecenia, zanim człowiek sprawdzi rezultat.

Generowanie interaktywne wzmacnia ten schemat. Model może zbudować kompletną scenę, zanim ktokolwiek zweryfikuje kamerę, fizykę, sterowanie, zgodność z narracją lub dostępność. Pozorna kompletność wyniku może zniechęcać do uważnej kontroli.

Określenie „natywna percepcja” wymaga tu ostrożności. Współczesne modele multimodalne potrafią przetwarzać obrazy, wideo, dźwięk i tekst. Różnica dotyczy tego, jak niezawodnie percepcja jest integrowana z autonomiczną pętlą produkcyjną.

Model nie potrzebuje ludzkiej świadomości, aby audytować oprogramowanie. Potrzebuje niezawodnego dostępu do istotnych dowodów, odpowiednich kryteriów oceny oraz zdolności do wprowadzania poprawek bez tworzenia nowych błędów.

Wymagania te pozostają trudne, ponieważ wiele twórczych ocen ma charakter subiektywny. Nie musi istnieć jeden właściwy kąt kamery ani jedna właściwa prędkość animacji. Inne problemy są jednak wystarczająco obiektywne, by je testować.

Obiekty nie powinny niespodziewanie się przenikać. Elementy sterowania powinny wywoływać udokumentowane działanie. Wymagane postacie powinny się pojawić. Żądana sekwencja powinna nastąpić we właściwej kolejności.

Przydatny system audytowy musi oddzielać te mechaniczne kontrole od preferencji estetycznych. Może automatycznie testować kolizje i ukończenie zdarzeń, jednocześnie prosząc człowieka o ocenę tonu i kompozycji.

Przyszły system prawdopodobnie połączy kilku ewaluatorów. Analiza statyczna może sprawdzać kod. Zautomatyzowane testy mogą wykonywać interakcje. Modele wizyjne mogą analizować klatki, a ludzie rozstrzygać niejednoznaczne wybory twórcze.

Dopóki ten zestaw narzędzi nie stanie się niezawodny, generowane światy pozostaną bliższe ambitnym prototypom niż gotowym produktom. Ich wartość jest realna, lecz o ich poprawności nie można wnioskować na podstawie skali.

Demo nie jest jeszcze ogólnym benchmarkiem budowania światów

Imponująca wygenerowana scena nie dowodzi, że model rozumie przestrzeń fizyczną, intencję narracyjną ani własne błędy.

Publiczny przykład tworzy kilka luk w weryfikacji. Obserwatorzy nie mają pełnego zapisu procesu tworzenia promptów. Nie mogą też ustalić, ile selekcji nastąpiło, zanim pojawił się prezentowany rezultat.

Mocna demonstracja może wynikać z jednego polecenia, wielu ponownych prób albo intensywnego ludzkiego prowadzenia. Każdy z tych procesów ujawniałby inną zdolność. Bez tego kontekstu stanowcze wnioski o autonomii byłyby przedwczesne.

Materiał źródłowy wydaje się też powiązany ze znanym fikcyjnym uniwersum. Popularne historie mają w internecie bogate zasoby tekstów, obrazów, komentarzy i materiałów fanowskich. Taka ekspozycja treningowa może pomóc modelowi wnioskować o oczekiwanych postaciach i sceneriach.

Mocniejszy test wykorzystywałby nieznany materiał źródłowy. Ewaluatorzy mogliby dostarczyć nową scenę, która nie występuje w korpusie treningowym. Model musiałby wtedy osadzić swój świat w dostarczonym opisie.

Test powinien również zachować kompletną historię interakcji. Badacze potrzebują promptów, wywołań narzędzi, wygenerowanych plików, poprawek i nieudanych prób. Krótkie wideo nie może ujawnić, w jaki sposób osiągnięto wynik.

Najnowsza dyskusja Andreja Karpathy’ego o LLM-ach obejmuje z tego powodu zarówno entuzjazm, jak i krytykę. Zwolennicy widzą większe płótno dla spersonalizowanego tworzenia. Krytycy dostrzegają atrakcyjną wizualnie demonstrację pozbawioną kontrolowanej oceny.

Obie reakcje wskazują na coś ważnego. Wynik może być użyteczny, nie dowodząc ogólnej inteligencji. Prototyp może oszczędzać czas, nawet gdy wymaga ludzkiej kontroli.

Nazywanie systemu „budowniczym światów” grozi również zatarciem technicznych rozróżnień. Scena przeglądarkowa wygenerowana w JavaScript nie jest odpowiednikiem wyuczonego symulatora. Działa według reguł zakodowanych w programie.

Reguły te mogą przybliżać zachowanie fizyczne, nie reprezentując rozumienia fizyki. Spadający obiekt może poruszać się zgodnie z prostym równaniem. Nie oznacza to, że model potrafi przewidzieć każdą konsekwencję symulowanego systemu.

Z drugiej strony pisanie spójnego kodu graficznego wymaga istotnych kompetencji. Model musi odwzorować język na współrzędne, obiekty i transformacje. Odrzucanie wyniku jako zwykłego autouzupełniania ignoruje pracę integracyjną, której wymaga.

Właściwa interpretacja leży między tymi skrajnościami. Generowanie światów przez LLM-y pokazuje szerszą syntezę oprogramowania. Nie pokazuje jeszcze pełnej wizualnej samoweryfikacji.

Zespoły rozważające ten sposób pracy powinny ocenić całą pętlę. Powinny mierzyć, jak często pierwszy wynik działa, ile poprawek jest potrzebnych oraz które defekty omijają automatyczne kontrole.

Powinny też testować zmienność. Model, który odnosi sukces w jednej ikonicznej scenie, może zawieść, gdy zmienią się postacie, pozycje kamery lub ograniczenia. Niezawodne systemy muszą radzić sobie z żądaniami wykraczającymi poza popularne przykłady udostępniane online.

Bezpieczeństwo rodzi kolejne obawy. Wygenerowane interaktywne oprogramowanie może obejmować zależności, uprawnienia przeglądarki, wywołania sieciowe lub niebezpieczny kod. Sukces wizualny nic nie mówi o tym, czy te komponenty są odpowiednie.

Wydajność również ma znaczenie. Scena może działać płynnie na komputerze twórcy, a jednocześnie zawodzić na sprzęcie mobilnym. Wygenerowana geometria, tekstury i pętle animacji mogą zużywać pamięć lub czas procesora bez wyraźnych ostrzeżeń.

Łatwo też pominąć dostępność. Nawigacja klawiaturą, czytelne etykiety, kontrola ruchu i opisy alternatywne rzadko pojawiają się automatycznie w efektownych demonstracjach. Te cechy wymagają jasnych specyfikacji i testów.

Nierozstrzygnięte pozostają również kwestie praw autorskich i tożsamości. Użytkownik może żądać światów opartych na chronionych postaciach, rozpoznawalnych osobach lub istniejących grach. Techniczna zdolność do ich generowania nie rozwiązuje kwestii praw ani dystrybucji.

Te słabości nie podważają obserwacji Karpathy’ego. Określają pracę potrzebną do przekształcenia tej obserwacji w niezawodną kategorię produktów.

Wiarygodny benchmark powinien wykorzystywać ukryte prompty, nieznane odniesienia i powtarzalne punktowanie. Powinien oceniać spójność przestrzenną, ukończenie interakcji, dokładność wizualną, wydajność, bezpieczeństwo oraz odzyskiwanie sprawności po wykrytych błędach.

Co najważniejsze, powinien testować samokorektę. Model powinien otrzymać dostęp do działającego świata, zidentyfikować celowo wprowadzony defekt, znaleźć jego przyczynę i naprawić go bez szczegółowego ludzkiego prowadzenia.

To mierzyłoby więcej niż samą produkcję. Ujawniłoby, czy generowanie i percepcja stają się jedną niezawodną pętlą.

Co powinno wydarzyć się po momencie Techmeme LLMs

Trzy sygnały pokażą, czy światy na żądanie stają się niezawodnymi narzędziami, czy pozostają imponującymi demonstracjami.

Pierwszym sygnałem będzie pojawienie się odtwarzalnych ocen budowania światów. Testy te powinny publikować prompty, środowiska, zasady punktacji i kompletne ślady działań agentów. Ukryte przypadki testowe ograniczyłyby szansę, że modele będą optymalizować się pod znane viralowe przykłady.

Przydatna ocena punktowałaby zarówno tworzenie, jak i skuteczność audytu. Model mógłby zbudować scenę na podstawie nieznanego opisu, a następnie sprawdzić ją z wielu pozycji kamery. Ewaluatorzy mogliby wprowadzać defekty i mierzyć, czy system je znajduje.

Jeśli takie benchmarki pokażą konsekwentne postępy w niepowiązanych zadaniach, teza Karpathy’ego zyska na sile. Dziedzina mogłaby wykazać, że modele uczą się przenośnych umiejętności przestrzennych i interaktywnych. Sukces w pojedynczych postach społecznościowych miałby mniejsze znaczenie.

Porażka osłabiłaby to twierdzenie. Jeśli wydajność załamie się poza rozpoznawalnymi historiami lub preferowanymi bibliotekami graficznymi, pozorne przejście może odzwierciedlać wyspecjalizowaną biegłość w kodowaniu. Nie oznaczałoby jeszcze ogólnego tworzenia światów na żądanie.

Drugim sygnałem będzie ściślejsza integracja percepcji z agentami programistycznymi. Programiści powinni obserwować agentów, którzy automatycznie uruchamiają wygenerowane aplikacje, przechodzą przez interfejsy, rejestrują klatki, analizują ruch i łączą widoczne błędy z kodem źródłowym.

Sama obsługa zrzutów ekranu nie wystarczy. Agent potrzebuje pamięci czasowej i systematycznej eksploracji. Musi wiedzieć, które stany już przetestował, a które pozostają niepokryte.

System powinien również zachowywać dowody. Recenzent potrzebuje dzienników pokazujących, co agent zaobserwował, jakie kryteria zastosował i dlaczego uznał wynik za kompletny. Taki zapis może przyspieszyć przegląd bez wymagania od użytkowników zaufania do podsumowania.

Jeśli czołowi agenci wprowadzą niezawodne wizualne testy regresji, luka audytowa się zmniejszy. Wizualne testy regresji porównują renderowany wynik między wersjami, aby identyfikować niezamierzone zmiany. Agenci mogą rozszerzyć tę metodę, wyjaśniając prawdopodobną przyczynę.

Jeśli postęp pozostanie ograniczony do generowania bardziej złożonego kodu, luka będzie się powiększać. Użytkownicy otrzymają większe artefakty z większą liczbą ukrytych stanów i bez proporcjonalnego wzrostu pewności.

Trzecim sygnałem będzie konwergencja między scenami kodowanymi a wyuczonymi modelami świata. Prace Google DeepMind pokazują bezpośrednie generowanie środowisk w czasie rzeczywistym. Kodowanie oparte na LLM-ach zapewnia edytowalną strukturę i dostęp do ugruntowanych narzędzi programistycznych.

Połączony system mógłby wykorzystywać kod do reguł, interfejsów i trwałego stanu. Model świata mógłby dostarczać szczegóły wizualne, warianty i symulowane zachowanie. Agent audytujący mógłby porównywać oba wyniki z pierwotnym żądaniem.

Taka konwergencja wspierałaby zastosowania wykraczające poza rozrywkę. Symulacje szkoleniowe mogłyby dostosowywać się do uczącego się. Zespoły produktowe mogłyby generować realistyczne scenariusze użycia. Roboty mogłyby ćwiczyć w zróżnicowanych środowiskach przed wejściem do przestrzeni fizycznych.

Zwiększyłaby również koszt błędów. Wadliwa symulacja może nauczyć agenta niewłaściwego zachowania. Spersonalizowana lekcja może przedstawiać fałszywe zależności z przekonującymi szczegółami wizualnymi.

Z tego powodu personalizacji musi towarzyszyć możliwość ustalenia pochodzenia. Użytkownicy powinni móc prześledzić, które materiały źródłowe wpłynęły na wygenerowany świat. Powinni również wiedzieć, które elementy zostały wywnioskowane, a nie pobrane.

Narzędzia do łączenia wiedzy mogą pomóc utrzymać wygenerowane wyjaśnienia w powiązaniu z kontekstem źródłowym. Nie zastępują walidacji, ale mogą zmniejszyć dystans między doświadczeniem a materiałami, które je wspierają.

Najbliżsi zwycięzcy niekoniecznie stworzą najbardziej spektakularne demo. Zamkną pętlę między zapytaniem, tworzeniem, obserwacją, testowaniem i korektą.

Ta pętla potrzebuje również rozsądnych reguł zatrzymania. Agent, który wielokrotnie modyfikuje działającą scenę, może wprowadzić regresje, dążąc do drobnych ulepszeń wizualnych. Musi rozróżniać defekt blokujący od preferencji estetycznej.

Weryfikacja przez człowieka pozostanie ważna, zwłaszcza w kwestiach znaczenia i gustu. Celem nie jest usunięcie recenzenta. Chodzi o to, by model wykrywał oczywiste błędy, zanim poprosi o zatwierdzenie.

Szersza teza Andreja Karpathy’ego dotycząca LLM-ów jest więc mniej triumfalna, niż początkowo się wydaje. Generowanie rozszerzyło się z artefaktów na systemy, ale ocena nie rozwijała się w tym samym tempie.

Ta nierównowaga będzie kształtować projektowanie produktów w ciągu najbliższych kilku miesięcy. Więcej firm będzie promować natychmiastowo tworzone aplikacje, gry, symulacje i interaktywne historie. Ich decydującą cechą powinny być dowody na to, że te doświadczenia zostały faktycznie sprawdzone.

Moment techmeme llms daje deweloperom użyteczny test dla każdej nowej demonstracji: co stworzył model i jakie dowody wskazują, że zrozumiał rezultat?

Zadaj to samo pytanie w odniesieniu do własnego projektu wygenerowanego przez AI. Poproś agenta o wymienienie stanów, które sprawdził, defektów, które znalazł, oraz dowodów potwierdzających ukończenie. Następnie przetestuj ścieżkę, o której nigdy nie wspomniał. Jeśli projekt tam zawiedzie, brakującą funkcją nie jest kolejny model generujący. Jest nią wiarygodna pętla audytu.