Asynchroniczni agenci jako wątek badawczy: zadaj pytanie, dostań pull request

Asynchroniczni agenci kodujący zmieniają rytm pracy badawczej. Zamiast siedzieć przy edytorze i przełączać się między dokumentacją, terminalem a przeglądarką, zadajesz pytanie, pozwalasz agentowi pracować na serwerze i zajmujesz się czymś innym.

Willison wysyła 2-3 projekty badawcze dziennie i dostaje z powrotem pull requesty

Simon Willison opisał konkretny workflow: agenci jak Claude Code, Codex Cloud, Google Jules czy GitHub Copilot agent otrzymują zadania badawcze, pracują asynchronicznie na serwerze i gdy skończą, zgłaszają pull request do dedykowanego repozytorium na GitHubie. Willison szacuje, że uruchamia 2-3 projekty dziennie przy minimalnym nakładzie czasu.

Kluczowe szczegóły jego konfiguracji: osobne repozytoria (jedno publiczne, jedno prywatne) zmniejszają ryzyko bezpieczeństwa. Agenci mają pełny dostęp do sieci, by instalować zależności i pobierać dane. GitHub Workflow z GitHub Models automatycznie generuje podsumowania README dla nowych projektów.

Konkretne przykłady z jego publicznego repozytorium simonw/research: benchmark siedmiu bibliotek Markdown z wygenerowanymi wykresami, kompilacja rozszerzenia C dla WebAssembly, sugestie tagów oparte na ML z użyciem klasyfikacji tekstu oraz uruchamianie Python WebAssembly w Node.js.

Kod jako dowód, nie tylko tekst

Nie chodzi o to, że agent napisze ładny opis rozwiązania. Chodzi o to, że działający kod jest empirycznym dowodem wykonalności. Willison ujmuje to precyzyjnie: kod nie kłamie. Jeśli agent napisał kod, który działa, wiesz, że to możliwe.

W przypadku zadań badawczych i spike to istotna zmiana. Klasyczna eksploracja przebiega szeregowo: sam przekształcasz pytanie w kod, uruchamiasz, iterujesz. Agent przetwarza je równolegle, a PR pozwala zdecydować, co faktycznie zintegrować.

Proof of concept to mocna strona; produkcja to inna dyscyplina

Asynchroniczny agent jest użyteczny, ale dobre wyniki zależą od jakości briefów i umiejętności rozróżnienia zadań, gdzie wystarczy proof of concept, od tych wymagających kodu produkcyjnego. Projekty eksploracyjne i spike sprawdzają się dobrze; krytyczna infrastruktura ze złożoną logiką nie.

Pojawia się też nowa dyscyplina pracy: trzeba przyjść do PR, zrozumieć wynik, zdecydować co zintegrować, a co odrzucić. Jeśli mergujemy PR bez sprawdzenia, agent wyprodukował tylko stos diffów, których nikt nie jest właścicielem.

Kluczem będzie skalowanie na trudniejsze zadania

Willison pokazuje działający workflow na projektach eksploracyjnych, gdzie agent może się pomylić bez poważnych konsekwencji. Interesujące pytanie brzmi, jak to działa przy wieloetapowych zadaniach badawczych lub projektach, gdzie agent musi utrzymać kontekst przez wiele plików.

Warto też obserwować granice bezpieczeństwa: współdzielone repozytoria, uprawnienia sieciowe i zachowanie agenta przy nieoczekiwanym wejściu to rzeczy tolerowane w kontekście eksploracyjnym, ale nie w produkcyjnym.

Werdykt Lilith

Willison pokazuje, że agent nie musi pisać kodu produkcyjnego, żeby być użyteczny. Wystarczy, że wróci z PR mówiącym, czy coś jest wykonalne. Przejście z pętli edytorowej do asynchronicznego wątku badawczego może być większą zmianą, niż wygląda.