Read this: https://rosemeadtu.org/z_archive/wordpress-shortcodes-calcode-and-calbill/

OK, I wasn’t that happy with these shortcodes, and now I know why.

Citations need to be consistent, within reason.

The code handles weird edge cases that could be considered bad or quirky citations.

(The worst part is, it doesn’t gain you that much more laxity, and it didn’t make code I could easily read. When I used to write parsers and text manglers, I would aim for readable, modifiable code, and a bit of slack on the inputs.)

All the extra code to handle inputs is a kind of technical debt. When you want to add features, it’s more code to figure out.

A better trick would be to give a little advice on how to write the citations, so people learn to write them correctly. Maybe they can be led to a tool that would fix their citation.

A feature I wish it had

I wish I could link a bill name like ‘Tenant Protection Act (2019)’ and have it switch from linking to the bill, to linking to the new law, once the bill becomes a law.

This one is a lot trickier, but feasible. It requires a database of bills and codes, and names.

Feature bloat

So, we have a plugin with feature bloat, me, wishing for a feature, and I don’t like the code it cranked out.

I also kept running out of tokens because I used a spec. Now, a spec’s generally a good idea, but when I had the LLM write the spec, it was bloaty.

I suspect that what I really needed to do, was start off with a framework and skeleton, to be a kind of armature for the code, a minimalist spec to guide the code, and a better set of test cases, organized from strict to loose inputs (so I could tell the LLM to make decisions to balance code size against flexibility).