While building the library WordPress Export File Generator, I was thinking how this can be useful for other tech stacks as well. So after finishing the PHP version, I wanted to work on the porting it. LLMs are perfect for this type of work, so I quickly re-implemented in JavaScript using Codex.

Then I stopped and never released it. What is the point? I’ll be operating in tech stacks I’m not familiar with and won’t have a real life project to test against. Plus, porting to other languages one-by-one also won’t scale. I did the PHP version myself and I guess I can port it to handful of others but options and tech stacks are endless.

So I built a version of wefg that has no code.

It has the recipe but not the implementation: AGENTS.md file describing requirements for WXR (WordPress eXtended RSS) files, links to WordPress’ export and import code, and testing tools to verify the output against a real WordPress installation.

(As I type it out, maybe I should also point it to the original PHP implementation that is mostly built by a human?)

Using this no-code version, I again quickly re-implemented the library in JavaScript and Ruby. They seem to work… But I didn’t use it with a production codebase so hard for me to judge it.

So it’s mostly for fun but also to explore and philosophize where our industry will go.

I think a codeless library works here because:

Oracles: this is a oracle rich domain. WXR files are easily verifiable. WordPress’ code is our spec. We use wp-cli to import the generated file into a WordPress site and verify it.

Language Agnosticsm: I don’t know what the demand will be to wefg, but it seems like it can benefit being language agnostic. Any platform could decide to migrate to WordPress and maybe WXR will work for them.

Inversion of ownership: Normally when you pull in a library with a package manager, you don’t actually own the code. You may not know the internals and only get exposed to its API. Package manager alos can update it automatically, depending on your apetite to stay up-to-date.

But here, if you choose to implement your own library using wefg-no-code, code is yours. You’ll generate it and you’ll own it. Would you like to maintain such a code? I don’t know.