Experiment: I had Claude Code port two MuleSoft apps to Go and C# with zero review. The original needed four fixes to run; the ports didn't.

To be clear up front: this is not a showcase, a product or production code. It was a deliberate prompt-and-pray test on a free Friday afternoon. I didn't read, review or correct a single line Fable wrote. I just wanted to see what happens. Input: two Mule 4 apps, a real batch job from GitHub and a small API on the same table. Every line of the Go and C# ports was written by model, one prompt per port in a fresh session, plus one more prompt for tests (229 in C#, twelve Go packages passing, shared fixtures), and some for cleanups. What surprised me: getting the original Mule app to run took four fixes. Two were errors any compiler catches, a nonexistent error type and an unqualified function. Mule only surfaced them at runtime, after a 774 MB image and 18 seconds of startup. In the ports, go build and dotnet build caught them immediately. Footprint, same machine, no tuning: 774 MB image, 1 GB heap, ~18 s to first response for Mule, versus a 20 MB static binary answering in under a second. Caveats: converting was the cheap part. Proving the ports behave the same is the real cost, and I haven't done that rigorously. Premium connectors, Object Store, clustering and so on would make a real migration much harder. Please don't treat the generated code as a reference or use it for anything real. Write-up with every fix and number: https://1figure.github.io/mule2code/ Curious whether anyone has tried this on larger flows, and where it broke.