Przedstawiamy Showboata i Rodneya, aby agenci mogli zaprezentować to, co zbudowali

Przedstawiamy Showboata i Rodneya, aby agenci mogli zaprezentować to, co zbudowali

10 lutego 2026 r

Kluczowym wyzwaniem w pracy z agentami zajmującymi się kodowaniem jest to, aby obaj przetestowali to, co zbudowali, i zademonstrowali to oprogramowanie Tobie, swojemu nadzorcy. Wykracza to poza testy automatyczne — potrzebujemy artefaktów, które pokazują ich postęp i pomagają nam dokładnie zobaczyć, co potrafi oprogramowanie stworzone przez agenta. Właśnie wypuściłem dwa nowe narzędzia mające na celu rozwiązanie tego problemu: Showboat i Rodney.

Sprawdzanie, czy kod faktycznie działa

Niedawno pisałem o tym, że zadaniem inżyniera oprogramowania nie jest pisanie kodu, lecz jego działanie dostarczyć kod, który działa. W dużej mierze polega to na udowadnianiu sobie i innym, że kod, za który jesteśmy odpowiedzialni, działa zgodnie z oczekiwaniami.

Staje się to jeszcze ważniejsze i trudniejsze, gdy traktujemy agentów kodujących jako kluczową część naszego procesu tworzenia oprogramowania.

Im więcej kodu tworzymy za pomocą agentów, tym cenniejsze są narzędzia, które zmniejszają ilość czasu potrzebnego na ręczną kontrolę jakości.

Jedną z najciekawszych rzeczy w modelu fabryki oprogramowania StrongDM jest to, w jaki sposób zapewniają, że ich oprogramowanie jest dobrze przetestowane i zapewnia wartość pomimo swojej polityki mówiącej, że „kod nie może być przeglądany przez ludzi”. Część ich rozwiązania obejmuje kosztowne roje agentów kontroli jakości realizujących „scenariusze” w celu wykorzystania swojego oprogramowania. To fascynujące, ale nie chcę wydawać tysięcy dolarów na roboty kontroli jakości, jeśli mogę tego uniknąć!

Potrzebuję narzędzi, które pozwolą agentom jasno zademonstrować mi swoją pracę, minimalizując jednocześnie możliwość oszukiwania w związku z tym, co zrobili.

Showboat: agenci tworzą dokumenty, aby zaprezentować swoją pracę

Łódź pokazowa to narzędzie, które zbudowałem, aby pomóc agentom zademonstrować mi swoją pracę.

Jest to narzędzie CLI (plik binarny Go, opcjonalnie opakowany w Python, aby ułatwić instalację), które pomaga agentowi utworzyć dokument Markdown demonstrujący dokładnie, co potrafi jego nowo opracowany kod.

Nie jest przeznaczony do uruchamiania przez ludzi, ale tak czy inaczej można go uruchomić:

showboat init demo.md 'How to use curl and jq'
showboat note demo.md "Here's how to use curl and jq together."
showboat exec demo.md bash 'curl -s https://api.github.com/repos/simonw/rodney | jq .description'
showboat note demo.md 'And the curl logo, to demonstrate the image command:'
showboat image demo.md 'curl -o curl-logo.png https://curl.se/logo/curl-logo.png && echo curl-logo.png'

Oto jak wygląda wynik, jeśli otworzysz go w VS Code i wyświetlisz podgląd Markdown:

Oto plik demo.md w skrócie.

Zatem sekwencja showboat init, showboat note, showboat exec I showboat image Commands tworzy dokument Markdown po jednej sekcji na raz, z wynikami tychże exec polecenia automatycznie dodawane do dokumentu bezpośrednio po uruchomionych poleceniach.

The image polecenie jest trochę specjalne — szuka ścieżki pliku do obrazu w wynikach polecenia, kopiuje ten obraz do bieżącego folderu i odwołuje się do niego w pliku.

To w zasadzie całość! Jest pop polecenie usunięcia ostatnio dodanej sekcji, jeśli coś pójdzie nie tak, a verify polecenie ponownego uruchomienia dokumentu i sprawdzenia, czy nic się nie zmieniło (nie jestem do końca przekonany co do projektu tego dokumentu) i extract polecenie, które odtwarza polecenia CLI użyte do utworzenia dokumentu.

To całkiem proste — tylko 172 linijki Go.

Spakowałem go za pomocą mojego narzędzia „przejdź do koła”, co oznacza, że ​​możesz go uruchomić nawet bez wcześniejszej instalacji, w ten sposób:

To --help polecenie jest naprawdę ważne: ma na celu zapewnienie agentowi kodującemu wszystko, co musi wiedzieć aby móc korzystać z narzędzia. Oto cały tekst pomocy.

Oznacza to, że możesz otworzyć Claude Code i powiedzieć mu:

Run "uvx showboat --help" and then use showboat to create a demo.md document describing the feature you just built

I tyle! The --help tekst działa trochę jak Umiejętność. Twój agent może przeczytać tekst pomocy i wykorzystać każdą funkcję Showboat, aby utworzyć dokument demonstrujący wszystko, czego potrzebujesz.

Oto zabawna sztuczka: jeśli ustawisz Claude’a na tworzenie dokumentu Showboat, możesz go otworzyć w VS Code i oglądać aktualizację okienka podglądu w czasie rzeczywistym, gdy agent przegląda wersję demonstracyjną. To trochę tak, jakby Twój współpracownik opowiadał Ci o swojej najnowszej pracy podczas sesji udostępniania ekranu.

I na koniec kilka przykładów. Oto dokumenty, które Claude stworzył za pomocą Showboat, aby pomóc zademonstrować funkcje, nad którymi pracowałem w innych projektach:

Używam Showboat na tyle często, że przekonałem się o jego użyteczności.

(Widziałem też, jak agenci oszukują! Ponieważ plik demonstracyjny to Markdown, agent czasami edytuje ten plik bezpośrednio, zamiast używać Showboat, co może skutkować wynikami poleceń, które nie odzwierciedlają tego, co faktycznie się wydarzyło. Oto problem z tym związany.)

Rodney: Automatyzacja przeglądarki CLI zaprojektowana do współpracy z Showboat

Wiele projektów, nad którymi pracuję, obejmuje interfejsy internetowe. Agenci często tworzą dla nich zupełnie nowe strony i chcę zobaczyć te reprezentowane w demonstracjach.

Funkcja obrazu Showboat została zaprojektowana, aby umożliwić agentom przechwytywanie zrzutów ekranu w ramach ich demonstracji, pierwotnie przy użyciu mojego narzędzia do skrobania ujęć lub Playwright.

Format Showboat korzysta z narzędzi CLI. Szukałem dobrych opcji zarządzania wieloobrotową sesją przeglądarki z poziomu CLI i nie udało mi się, więc zdecydowałem się spróbować zbudować coś nowego.

Claude Opus 4.6 wskazał mi bibliotekę Rod Go do interakcji z protokołem Chrome DevTools. To fantastyczne — zapewnia kompleksowe omówienie praktycznie wszystkiego, co można zrobić w zautomatyzowanej przeglądarce Chrome, a wszystko to w samodzielnej bibliotece, która kompiluje się do kilku MB.

Jedyne, czego Rodowi brakowało, to CLI.

Pierwszą wersję zbudowałem jako prototyp raportu asynchronicznego, co utwierdziło mnie w przekonaniu, że warto rozkręcić go pod własny projekt.

Nazwałem go Rodney jako ukłon w stronę biblioteki Rod, na której się opiera, oraz jako nawiązanie do Only Fools and Horses – a także dlatego, że nazwa pakietu była dostępna w PyPI.

Możesz uruchomić Rodneya za pomocą uvx rodney lub zainstaluj w ten sposób:

(Lub pobierz plik binarny Go ze strony wydań.)

Oto prosta przykładowa sesja:

rodney start # starts Chrome in the background
rodney open https://datasette.io/
rodney js 'Array.from(document.links).map(el => el.href).slice(0, 5)'
rodney click 'a(href="https://simonwillison.net/for")'
rodney js location.href
rodney js document.title
rodney screenshot datasette-for-page.png
rodney stop

Oto jak to wygląda w terminalu:

Rozwój oparty na testach pomaga, ale nadal potrzebujemy testów ręcznych

Po tym, jak przez całą karierę byłem sceptyczny wobec szkoły tworzenia oprogramowania skupiającej się na pierwszym teście i maksymalnym pokryciu testami (lubię zamiast tego testy obejmujące tworzenie oprogramowania), ostatnio zacząłem skupiać się na procesach opartych na pierwszym testowaniu, aby zmusić agentów do napisania tylko kodu niezbędnego do rozwiązania danego problemu.

Wiele moich sesji agenta kodującego w Pythonie zaczyna się w ten sam sposób:

Run the existing tests with "uv run pytest". Build using red/green TDD.

Poinformowanie agentów, jak przeprowadzać testy, może również służyć jako wskaźnik, że testy w tym projekcie istnieją i mają znaczenie. Agenci będą czytać istniejące testy przed napisaniem własnych, zatem posiadanie czystego zestawu testów z dobrymi wzorcami zwiększa prawdopodobieństwo, że sami napiszą dobre testy.

Wszystkie modele pionierskie rozumieją, że „czerwony/zielony TDD” oznacza, że ​​powinni najpierw napisać test, uruchomić go i obserwować, jak się nie powiedzie, a następnie napisać kod, aby go zaliczyć — jest to wygodny skrót.

Uważam, że znacznie zwiększa to jakość kodu i prawdopodobieństwo, że agent wygeneruje właściwą rzecz przy najmniejszej liczbie podpowiedzi.

Ale każdy, kto pracował z testami, będzie wiedział, że to, że pomyślnie przeszły testy automatyczne, nie oznacza, że ​​oprogramowanie faktycznie działa! Taka jest motywacja stojąca za Showboat i Rodney – nigdy nie ufam żadnej funkcji, dopóki nie zobaczę jej na własne oczy.

Przed zbudowaniem Showboat często dodawałem „ręczny” etap testowania do sesji agenta, na przykład:

Once the tests pass, start a development server and exercise the new feature using curl

Obydwa narzędzia zbudowałem na swoim telefonie

Zarówno Showboat, jak i Rodney zaczynali jako Claude Code w projektach internetowych tworzonych za pośrednictwem aplikacji Claude na iPhone’a. Większość trwających dla nich prac fabularnych przebiegała w ten sam sposób.

Nadal jestem trochę zaskoczony, ile pracy związanej z kodowaniem wykonuję teraz na telefonie, ale szacuję, że większość kodu, który obecnie wysyłam do GitHuba, została napisana dla mnie przez agentów kodujących korzystających z tej aplikacji na iPhone’a.

Początkowo zaprojektowałem te dwa narzędzia do użytku w środowiskach asynchronicznych agentów kodowania, takich jak Claude Code dla Internetu. Jak na razie sprawdza się to naprawdę dobrze.