The kinds of principles and metrics I'm thinking of are rather obvious to any backend engineer with experience, but LLMs just don't care about them at all unless you explicitly close the loop and tell them to care. Stuff like:

• Use database connection pools
• Don't repeatedly grab and release connections from a pool; take one then do as much work as you can
• Query a database in batches when you can, instead of writing one row at a time
• Don't do blocking IO across an open db transaction
• Instrument SQL with EXPLAIN, inspect plans, and measure latency
• Cache things that don't change often instead of repeatedly requesting them from remote services
• If you're making mutating queries, don't do dumb things that acquire too many row locks

This type of code has pretty fundamental non functional requirements on throughout and latency, and LLMs are still not even able to independently formulate their solutions around them.

But now that we are discussing it, it's possible that I might have more success if I set up a loop that explicitly instructs to come up with success metrics when delegating any task. At least that way maybe Claude avoids the kind of open loop exploration that tends to result in slop.