I wonder how effective it would be to just put the blog's title as a line in your AGENTS.md...
This is kinda the "this could have been an email" of AI complaints.
As an AI acolyte, I strongly believe that AIs should be being trained for this sort of mode by default, but they tend to be optimized (or at least tested) to solve the single shot benchmarks rather than multi-step stuff that you really need in a long term maintainable project.
There is a https://www.scbench.ai/ SlopCodeBench that checks this and a variety of others. These don't seem to often come up when frontier labs are advertising their new models.
If I was doing this at scale, I'd be looking at two features in particular. Cached input tokens - leveraging the LLM's token cache to get a 10:1 cost advantage, and batch tokens, 2:1 cost saving.
The benefits of doing your own harness here is that you get to explicitly program around those specific things to optimize cost. And they both heavily benefit you in the way that these sorts of jobs work - at least for the hunt side of things.
TLDR - context management is pretty important for cost management when you're doing something repetitive in bulk.
If you examine what you're saying here and slippery slope it a little, examining past effort for misses and correcting them at scale is not worth doing? There are many ways that the second part of your perspective are incorrect (burden / lack of point). I bet that a coding agent could in an automated fasion find at least reasonable additions that you'd say add value and reduce potential for error long term that you'd find valuable. They've probably already done so (I don't know postgres dev at all, so just supposition here. They will 100% do so in the future.
A lot of the signal (github, forums, mailing lists, discord, etc.) can be turned into signal. Right now it's easy enough to collect. In future it will be easy enough to cluster and generate preferences, experience, etc.
Every bug report, code change as a result, PR / commit message, PR comment that steers preferences, etc. is solid signal to generate future tests.
I've been trying to push for this perspective about the error messages of jj vcs. There's some push back from people that don't perceive that making tools work well with LLMs is also making tools work well with humans. (Obviously there's more nuance to the arguments than this one sided perspective).
But here's the rub - if you want your clanker to do those steps, it's usually a simple matter of adding them to your AGENTS.md and then it always does them.
I'm a big fan of the characterization step step being added. And it can be reasonable to add this before or even after the fact as a commit prior to your actual commit (assuming you're familiar with using tools where that's easy to do - e.g. jj or git with rebase). And the agents can do this - they just don't tend to without you saying to do so.
A lot of engineering practice comes from choosing which elements are reasonable to use given the context of what you're building. Providing that is your job. When you do that poorly, you get poor results. But garbage in garbage out has always been a thing. Any advanced automation amplifies ambient assumptions
But in seriousness, this intuitively feels like something (as phrased) that would be easily influenced by loud noise and quantity rather than hard facts. The "piloted poorly" part is applicable to any tool use. AI is no different there other than its adoption rate.
The same comments apply to each OS - scrolling / selection / hotkeys / controls / etc. all feel differently on each OS. macOS just has the general best of breed consistency with its own UX guidelines.
Electron apps tend to fall down in the minutiae of the little things that native apps get right (around things like selection, scrolling, various small affordances across various levels). Would love to see something like this be more native app upfront, than starting out with something that will always leave that top 10% of what makes a nice feeling app unobtainable.
You win hard on this if you have the best possible UX that feels natural to drive. You just also ran if not because obsidian/notion etc. are already there (and have the people to put into those random edge cases that make electron apps bad).
Consider making the first image in the readme either static, or move slowly enough that there's reasonable dwell time to understand the UI when it's done with rendering. Right now there's nowhere on the gif that you can focus on to understand that part of the app in any detail, so it's basically a flashy box of randomness.
I think the reasonable thing that needs to happen here is frontier labs need to look at ways to incorporate better up to date gilded chunks of gold data into their post training. I'd love to be able to throw a chunk of scenarios and expected outputs for using various tooling and have this applied to gpt-next / opus-next. I recently did a test with having Claude do this for generating a skill for jujutsu vcs that was based on eval-ing and ablating many many instructions over hundreds of scenarios. This is good, but skill based post training costs tokens for every user rather than at the model level.
Maybe there should be a submit your post training corpus here thing somewhere.
E.g. this really comes down to advice changing in short time frames that aren't represented in data that satisfies knowledge cutoff which can be as long as 14 months in some things or more for older models. It's not just the problem of knowledge, but the grading of seen output. The models have been trained to produce the older style code because it compiles and solves the problems.
Here, the reframe that likely makes sense noting is that "Deno and runtimes like Cloudflare Workers implement the Web API surface natively", that's the strongest single thing that would help steer an agent to correctly write code for the code in question (assuming the Web API surfaces that are key are in distribution). Add something like - "Where there may be reasonable obvious updates that can be used in 2026, use them" ...
Click the thumbs down report on the output (to better train the model in future to produce better code / provide signal to the people doing training that a common behavior is problematic) and then stick some guidance in your AGENTS.md. It can be fairly whack-a-mole at times on this sort of thing, but sharpening your personal saw with AGENTS.md is an effective approach to generally doing better.
Pattern language sites / books have existed for years.
The right approach is more work out what shared patterns are, make sure a bunch of reasonable ones are post trained into the models so that it's easy to refer to them by name (e.g. "tim pope / chris beams style commit messages", or "make invalid state unrepresentable") and then you're in a world where you can define your personal tasted through labels rather than repetition of the core arguments.