alt Hacker NewsThere are so many of these "meta" frameworks going around. I have yet to see one that proves in any meaningful way they improve anything. I have a hard time believing they accomplish anything other than burn tokens and poison the context window with too much information. What works best IME is keeping things simple, clear and only providing the essential information for the task at hand, and iterating in manageable slices, rather than trying to one-shot complex tasks. Just Plan, Code and Verify, simple as that.
Replies
The structured spec approach has worked well for me — but only when the spec itself is visual, not more text. I've been designing app navigation flows as screen images with hotspot connections, then exporting that as structured markdown. The AI gets screen-by-screen context instead of one massive prompt. The difference vs writing the spec by hand is that the visual layout catches gaps (orphan screens, missing error states) before you hand anything to the LLM.
I have my own mini framework that marries Claude and Codex. When I see the clangers that Claude by itself produces that Codex catches, I can’t see how I’d ever just let a single agent do its thing.
Once the plan stage is done is it fire-and-forget for you afterwards?
It's basically .vimrc/.emacs.d of the current age.
These meta-frameworks are useful for the one who set them up but for another person they seem like complete garbage.
From my experience they are motivated by these two issues that you run into when using Claude Code (or similar tool):
1. The LLM is operating on more what you'd call "guidelines" than the rules -- it will mostly make a PR after fixing a bug, but sometimes not. It will mostly run tests after completing a fix, but sometimes not. So there's a sentiment "heck, let's write some prompt that tells it to always run tests after fixing code", etc.
2. You end up running the LLM tool against state that is in GitHub (or RCS du jour). E.g. I open a bug (issue) and type what I found that's wrong, or whatever new feature I want. Then I tell Claude to go look at issue #xx. It runs in the terminal, asks me a bunch of unnecessary permission questions, fixes the bug, then perhaps makes a PR, perhaps I have to ask for that, then I go watch CI status on the PR, come back to the terminal and tell it that CI passed so please merge (or I can ask it to watch CI and review status and merge when ready). After a while you realize that all that process could just be driven from the GitHub UI -- if there was a "have Claude work on this issue" button. No need for the terminal.
There was a post from Apenwarr[1] recently that gave it a name: "the AI Developer’s Descent Into Madness", ending with "I need an agent framework. I can have my agent write an agent framework!"
[1]: https://apenwarr.ca/log/20260316