There 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.
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!"
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.
It's a tool called Drawd (drawd.app). You upload screen mockups onto an infinite canvas, draw rectangles over tap areas to define hotspots, then connect screens with arrows to map the navigation flow. Each hotspot carries an action type — navigate, API call, modal, conditional branch. When you're done, it exports structured markdown files (screen inventory, navigation map, build guide) that you feed to the LLM as context. The visual step is what catches gaps before you burn tokens on a broken spec.
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.
After a while many people then realize this often produces worse results by injecting additional noise in context like the overhead of invoking the gh cli and parsing json comments or worse the mcp.
But they get the dopamine loop of keeping the loop alive, flashing colors, high score/token use, and plausible looking outputs — so its easy to deceive oneself into thinking something remarkable was discovered
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.
Brandon Sanderson often says in interviews that "laying bricks" is the best job a writer can have. He also says being a software engineer is particularly bad job for writers because you cannot do it on autopilot. I can confirm.
Back then, all jobs moved at a much slower pace. There was a lot more off time during work hours.
I think discord has been terrible for the internet. A lot of open information has become gated. And now it's gated behind a platform that many of us are not willing to use anymore. Let's hope this pushes out people and communities back to forums and such, but in reality other platform will take over.
Same here, tested a bunch and cursor has been given little noise and usually decent suggestions. In this case its on a react app, so other projects might not find it as good.
When I have to put together a quick fix. I reach out to Claude Code these days. I know I can give it the specifics and, Im my recent experience, it will find the issue and propose a fix. Now, I have two options: I can trust it or I can dig in myself and understand why it's happening myself. I sacrifice gaining knowledge for time. I often choose the later, and put my time in areas I think are more important than this, but I'm aware of it.
If you give up your hands-on interaction with a system, you will lose your insight about it.
When you build an application yourself, you know every part of it. When you vibe code, trying to debug something in there is a black box of code you've never seen before.
That is one of the concerns I have when people suggest that LLMs are great for learning. I think the opposite, they're great for skipping 'learning' and just get the results. Learning comes from doing the grunt work.
I use LLMs to find stuff often, when I'm researching or I need to write an ADR, but I do the writing myself, because otherwise it's easy to fall into the trap of thinking that you know what the 'LLM' is talking about, when in fact you are clueless about it. I find it harder to write about something I'm not familiar with, and then I know I have to look more into it.
I think LLMs can be great for learning, but not if you're using them to do work for you. I find them most valuable for explaining concepts I've been trying to learn, but have gotten stuck and am struggling to find good resources for.
> I think the opposite, they're great for skipping 'learning' and just get the results.
yes, and cars skip the hours of walking, planes skip weeks of swimming, calculators skip the calculating ...
This is a good guide on how to use Claude code. My perspective (from an early adopter of LLMs for coding) is similar. Though, open code has a lot of potential as well. So I'm happy that Claude Code is not the only option.
But a key aspect imo is that, using these tools is also a skill; And there's a lot of knowledge involved in making something good with the assistance of Claude code vs doing slop. Specially as soon as you deviate from a very basic application / work in a larger repo with multiple people. There's a layer of context that these tools don't quite have, and it's very difficult to consistently provide them with. I can see this being less the case as context windows and the reliability of larger context retrieval is solved.
Vs code became unusable on a not so big monorepo on a MacBook Pro M4, which is concerning. Zed has been much smoother, even there are a couple of extensions or features that I miss.
reply