Datasette Apps 0.2a0: agent testuje własne UI w niewidocznym iframe

Simon Willison wydał datasette-apps 0.2a0, mały alpha release celujący dokładnie tam, gdzie agentyczne UI pada najczęściej: w feedback po wygenerowaniu aplikacji.

Agent dostał app_debug() i może obmacać apkę bez klikania użytkownika

Nowy tool app_debug() otwiera Datasette App w iframe z opacity: 0 i pointer-events: none. Użytkownik jej nie widzi i z nią nie wchodzi w interakcję. Agent wstrzykuje własny JavaScript do tego sandboxowanego iframe, mierzy elementy, sprawdza, czy UI w ogóle się wyrenderowało, i odpala smoke test.

Obok pojawił się app_list(): agent wypisuje aplikacje, które użytkownik może edytować, zamiast zgadywać slugi albo sięgać poza uprawnienia. Oba zmiany celują w workflow, w którym Datasette Agent apki tworzy i edytuje, a nie tylko opisuje.

Technicznie stoi to na context.browser_task() z datasette-agent 0.4a0. Plugin pozwala agentowi uruchamiać JavaScript bezpośrednio w przeglądarce użytkownika. Datasette Apps jest pierwszym konkretnym konsumentem tej pętli.

Przy małych wewnętrznych apkach zmienia się, kto łapie zepsuty render

Datasette Apps hostuje własne aplikacje HTML i JavaScript wewnątrz instancji Datasette, często nad danymi SQLite. Typowy use case to szybkie wewnętrzne narzędzie: filtr, dashboard, mały formularz. Gdy pisze je agent, największym bólem rzadko jest SQL. To cichy fail w DOM, CSS albo uprawnieniach.

app_debug() skraca dystans między „wygenerowane” a „sprawdzone”. Agent nie musi czekać, aż człowiek kliknie i napisze „scroll nie działa”. Może zmierzyć layout i złapać trywialne regresje od razu. app_list() trzyma pętlę edycji w modelu uprawnień Datasette, co w instalacjach multi-user liczy się bardziej niż efektowne demo.

Dla osób, które biorą Datasette jako cienki runtime aplikacyjny nad danymi, sygnał jest jasny: agent przesuwa się z autocomplete SQL do ciaśniejszego cyklu build-test w tym samym produkcie.

Alpha release wciąż stoi na modelu zaufania i jednej przeglądarce

To jest 0.2a0. API i zachowanie mogą się ruszać, a Willison nie sprzedaje tego jako enterprise computer-use. Smoke test w niewidocznym iframe lepiej łapie grube awarie niż subtelne regresje UX, flaky stany async albo dziury bezpieczeństwa w danych.

Uruchamianie JavaScriptu dostarczonego przez agenta w przeglądarce użytkownika jest silne i wrażliwe. Ma sens tylko przy twardym modelu uprawnień, audycie tool calls i jasnej zgodzie użytkownika. Bez tego wygodna pętla debug staje się kanałem bocznym do większego kontekstu sesji, niż zakładasz.

Trwałość pokaże, czy pętla debug przeżyje poza apkami demo

Patrz, czy browser_task rozleje się na inne pluginy Datasette, nie tylko Apps. Drugi sygnał: czy app_debug() urośnie do realistycznych asercji (stany auth, ścieżki zapisu, empty states), czy zostanie przy mierzeniu szerokości diva. Trzeci to operacje: czy granice uprawnień trzymają, gdy agent edytuje kilka apek z rzędu we wspólnej instancji.

Jeśli pętla się utrzyma, Datasette pokaże praktyczny wzorzec małych narzędzi budowanych przez agenta: wygeneruj, przetestuj niewidocznie, dopiero potem pokaż człowiekowi. Jeśli nie, zostanie eleganckim detalem alpha dla fanów ekosystemu pluginów.

Werdykt Lilith

Willison ustawił agentowi lustro jednokierunkowe: apkę obmacuje JavaScriptem w niewidocznym iframe, zanim w ogóle ci ją pokaże. To moment, w którym generator HTML zaczyna wyglądać jak prawdziwy cykl build-test.