Here is whim-proxy, a client + server combo helping developers tests webhook consumers when running the producer service is not practical (e.g. third-parties like GitHub or Stripe)).

Whim-proxy solves this issue with a whim-server & whim-client combo working as follows:

.1 A public/reachable webhook listener on whim-server receives the events from producers.

.2 Each event is then forwarded to subscribed whim-client processes (pub-sub) running on developer's laptop via WebSocket reverse-tunnels.

.3 Finally, the whim-client takes the event, and reproduces the original webhook, targeting the local consumer being developed/tested.

In all honestly, the tool itself is not that impressive. What impressed me was how quickly I got something working.

With Claude, and from the initial idea, it took me maybe 2 hours for a working prototype. And reaching something looking presentable took barely more than a slightly long evening; logo and demo deployment included.

The tool is probably far from perfect, I highly expect it to be DOSable quite easily for example.

But producing something similar would have probably taken me 1 or 2 weeks pre-AI.

For these kind of small/internal tools, AI as been kind of a blessing. The scope is small and all the code fits in context, also the quality is generally not critical (not on the production path).

For now, it's a far better option in my opinion compared to the old Perl script Joe Nothereanymore wrote 15 years ago. I just hope it will not become a curse, with a jungle of IA generated tools nobody actually understand.

It's kind frightening how little I looked at the actual whim-proxy code. It's small enough that I could probably dive into it. But multiply it by 20 in a corporate settings... well...