It s probably not something that original, and I m betting something like that already exist, but here we go: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...