Apresentando Showboat e Rodney, para que os agentes possam demonstrar o que construíram

Apresentando Showboat e Rodney, para que os agentes possam demonstrar o que construíram

10 de fevereiro de 2026

Um desafio importante ao trabalhar com agentes de codificação é fazer com que ambos testem o que construíram e demonstrem esse software para você, seu supervisor. Isso vai além dos testes automatizados: precisamos de artefatos que mostrem seu progresso e nos ajudem a ver exatamente o que o software produzido pelo agente é capaz de fazer. Acabei de lançar duas novas ferramentas voltadas para esse problema: Showboat e Rodney.

Provar que o código realmente funciona

Recentemente escrevi sobre como o trabalho de um engenheiro de software não é escrever código, mas sim entregar código que funcione. Grande parte disso é provar a nós mesmos e a outras pessoas que o código pelo qual somos responsáveis ​​se comporta conforme o esperado.

Isso se torna ainda mais importante — e desafiador — à medida que adotamos os agentes de codificação como parte central do nosso processo de desenvolvimento de software.

Quanto mais código produzimos com os agentes, mais valiosas são as ferramentas que reduzem a quantidade de tempo de controle de qualidade manual que precisamos gastar.

Uma das coisas mais interessantes sobre o modelo de fábrica de software StrongDM é como eles garantem que seu software seja bem testado e agregue valor, apesar de sua política de que “o código não deve ser revisado por humanos”. Parte de sua solução envolve enxames caros de agentes de controle de qualidade que percorrem “cenários” para exercitar seu software. É fascinante, mas não quero gastar milhares de dólares em robôs de controle de qualidade se puder evitar isso!

Preciso de ferramentas que permitam aos agentes demonstrar claramente seu trabalho para mim, minimizando ao mesmo tempo as oportunidades para eles trapacearem sobre o que fizeram.

Showboat: Agentes criam documentos para demonstrar seu trabalho

Barco de exposição é a ferramenta que desenvolvi para ajudar os agentes a demonstrarem seu trabalho para mim.

É uma ferramenta CLI (um binário Go, opcionalmente empacotado em Python para facilitar a instalação) que ajuda um agente a construir um documento Markdown demonstrando exatamente o que seu código recém-desenvolvido pode fazer.

Ele não foi projetado para ser executado por humanos, mas veja como você o executaria de qualquer maneira:

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'

Este é o resultado se você abri-lo no VS Code e visualizar o Markdown:

Aqui está o arquivo demo.md em um Gist.

Então uma sequência de showboat init, showboat note, showboat exec e showboat image comandos constrói um documento Markdown, uma seção por vez, com a saída daqueles exec comandos adicionados automaticamente ao documento diretamente após os comandos que foram executados.

O image O comando é um pouco especial – ele procura um caminho de arquivo para uma imagem na saída do comando e copia essa imagem para a pasta atual e faz referência a ela no arquivo.

Isso é basicamente tudo! Há um pop comando para remover a seção adicionada mais recentemente se algo der errado, um verify comando para executar novamente o documento e verificar se nada mudou (não estou totalmente convencido com o design desse) e um extract comando que faz engenharia reversa dos comandos CLI que foram usados ​​para criar o documento.

É muito simples – apenas 172 linhas de Go.

Eu o empacotei com minha ferramenta go-to-wheel, o que significa que você pode executá-lo sem sequer instalá-lo primeiro, assim:

Que --help comando é realmente importante: ele foi projetado para fornecer a um agente de codificação tudo o que precisa saber para usar a ferramenta. Aqui está o texto de ajuda completo.

Isso significa que você pode abrir o Claude Code e dizer:

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

E é isso! O --help o texto funciona um pouco como uma habilidade. Seu agente pode ler o texto de ajuda e usar todos os recursos do Showboat para criar um documento que demonstre tudo o que você precisa demonstrar.

Aqui está um truque divertido: se você definir Claude para criar um documento Showboat, poderá abri-lo no VS Code e observar a atualização do painel de visualização em tempo real enquanto o agente executa a demonstração. É como se seu colega de trabalho falasse sobre seu trabalho mais recente em uma sessão de compartilhamento de tela.

E finalmente, alguns exemplos. Aqui estão os documentos que Claude criou usando o Showboat para ajudar a demonstrar recursos nos quais estava trabalhando em outros projetos:

Já usei o Showboat com frequência suficiente para me convencer de sua utilidade.

(Também vi agentes trapaceando! Como o arquivo de demonstração é Markdown, o agente às vezes edita esse arquivo diretamente em vez de usar o Showboat, o que pode resultar em saídas de comando que não refletem o que realmente aconteceu. Aqui está um problema sobre isso.)

Rodney: automação do navegador CLI projetada para funcionar com Showboat

Muitos dos projetos em que trabalho envolvem interfaces web. Os agentes costumam criar páginas inteiramente novas para elas, e quero ver aquelas representadas nas demonstrações.

O recurso de imagem do Showboat foi projetado para permitir que os agentes capturem capturas de tela como parte de suas demonstrações, originalmente usando minha ferramenta de raspador de imagens ou Playwright.

O formato Showboat se beneficia dos utilitários CLI. Procurei boas opções para gerenciar uma sessão de navegador multivoltas a partir de uma CLI e não consegui, então decidi tentar construir algo novo.

Claude Opus 4.6 me indicou a biblioteca Rod Go para interagir com o protocolo Chrome DevTools. É fantástico: fornece um wrapper abrangente para basicamente tudo o que você pode fazer com o Chrome automatizado, tudo em uma biblioteca independente que compila em alguns MBs.

Tudo o que faltava a Rod era uma CLI.

Construí a primeira versão como um protótipo de relatório assíncrono, o que me convenceu de que valia a pena desenvolver seu próprio projeto.

Chamei-o de Rodney como uma homenagem à biblioteca Rod na qual ele se baseia e uma referência a Only Fools and Horses – e porque o nome do pacote estava disponível no PyPI.

Você pode executar Rodney usando uvx rodney ou instale-o assim:

(Ou pegue um binário Go na página de lançamentos.)

Aqui está um exemplo simples de sessão:

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

Aqui está o que parece no terminal:

O desenvolvimento orientado a testes ajuda, mas ainda precisamos de testes manuais

Depois de ser um cético de longa data em relação à escola de desenvolvimento de software com teste primeiro e cobertura máxima de teste (em vez disso, gosto de testes incluídos no desenvolvimento), recentemente comecei a testar os processos primeiro como uma forma de forçar os agentes a escrever apenas o código necessário para resolver o problema em questão.

Muitas das minhas sessões do agente de codificação Python começam da mesma maneira:

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

Dizer aos agentes como executar os testes também funciona como um indicador de que os testes neste projeto existem e são importantes. Os agentes lerão os testes existentes antes de escrever os seus próprios, portanto, ter um conjunto de testes limpo com bons padrões aumenta a probabilidade de eles escreverem seus próprios bons testes.

Todos os modelos de fronteira entendem que “TDD vermelho/verde” significa que eles devem escrever o teste primeiro, executá-lo e observá-lo falhar e então escrever o código para fazê-lo passar – é um atalho conveniente.

Acho que isso aumenta muito a qualidade do código e a probabilidade de o agente produzir a coisa certa com a menor quantidade de prompts para orientá-lo.

Mas qualquer pessoa que já trabalhou com testes sabe que só porque os testes automatizados foram aprovados não significa que o software realmente funciona! Essa é a motivação por trás do Showboat e do Rodney: nunca confio em nenhum recurso antes de vê-lo funcionando com meus próprios olhos.

Antes de construir o Showboat, eu costumava adicionar uma etapa de teste “manual” às minhas sessões de agente, algo como:

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

Eu construí essas duas ferramentas no meu telefone

Tanto Showboat quanto Rodney começaram como Claude Code para projetos web criados por meio do aplicativo Claude para iPhone. A maior parte do trabalho contínuo de recursos para eles aconteceu da mesma maneira.

Ainda estou um pouco surpreso com a quantidade de meu trabalho de codificação que faço no meu telefone agora, mas estimo que a maior parte do código que envio para o GitHub atualmente foi escrita para mim por agentes de codificação conduzidos por meio daquele aplicativo para iPhone.

Inicialmente projetei essas duas ferramentas para uso em ambientes de agente de codificação assíncrona, como Claude Code para a web. Até agora está funcionando muito bem.