This looks cool but does it build as well as superpowers? One thing about using more than one implementation agent is agents may end up working on each others work. How does this prevent that?
I thought superpowers was the coolest thing for about 1 day. Then the endless approval prompts and huge time increase killed it for me. I'm finding Opus 5.5 does a pretty thorough job without anything like superpowers. What would I be getting from superlite that Opus 5.5 doesn't do by itself already, and are those things actually important, or do they mostly only serve to give you peace of mind?
My opinion is that it’s a lot like the brief trend for describing yourself as a prompt engineer when getting images out of models like DALL-E 2.
Yeah, for five minutes you needed to use a specific style, very specific language patterns and what have you, in order to get results that were a cut above. But then the models and the harnesses got better and that moment passed.
I do like the brainstorm mode as I find that having a though partner walk me through the phase of speccing things out often shapes and reshapes my understanding of the problem. And that enhances the quality of what comes out the other end.
There are other ways to achieve this same effect without loading the full superpowers suite though.
But does that mode offer anything you can't get just by giving Claude a vague problem statement and then telling it to ask you clarifying questions? I agree that this can be a productive way of working with an agent, but with the latest models and harnesses you can work this way naturally without any special configuration.
And we thought the world was changing fast in the es6 days of JavaScript.
We use to say “web development is changing fast” when a thing changed after two years, and now it looks like it was changing at a snail’s pace compared to AI.
Like others I found superpowers helpful maybe 4 months ago. The models don't seem to need it anymore. I also don't have the same prompting issues the author has. Opus 5.5 tends to develop the spec, assumes I agree, and builds it. I make my sandwich and come back to a spec md, a diff, other evidence of completion. I use cc cli with a cmux-like platform it can control (ie open tabs showing specs, diffs itself).
I have agents working on plans for days on their own with just a plan doc and a relatively simple prompt. I usually check the commits once in a while to see what's happening. I'm not sure how superlite would improve that.
I imagine by this point the models already have the plugin code in their training corpus, plus plenty of RL data from users interacting with the plugins.
I don't think the model is needed anymore. I think given the new kind of things that are happening in the AI world, I've been using Gemini 3.8 Flash for a long time, I've been using Claude, Opus 5.5 and Sonnet 5.5 and literally find no reason at all to use SuperPars or SuperLight for that matter.
Most of the comments here seem to focus on specific things people were trying to get out of skills, and whether those are still needed.
That is going to vary a lot.
If your goal with something like superpowers was to have a process that made your model work "properly" on tasks, sure that's probably not needed anymore.
If your goal with something like superpowers was to get a consistent set of artifacts alongside what was developed (quality varying, so i mean consistent here as "one design plan, one implementation plan", not "good"), nothing has changed, models do not do this consistently, in a durable fashion, without something telling them to do this.
Yes, for example, newer Opus will often decide to write a spec. But not always, and not with any consistent format or ...
If you want that to happen, you'd still need a skill making it happen.
If you don't care about that, then sure, you don't need the skill anymore.
People seem to have used various skills to achieve different things, and so have wildly different views on what is still necessary.
I think I don't understand what you mean by process. I just tell the LLM what process I want it to follow, e.g. follow the plan document, use cheaper subagents when appropriate, respond to PR comments before merging, etc. It's usually a short paragraph.
I do use skills for other things, I don't believe that skills are bad. I'm just not sure what they add in this case.
may be needed with lower tier or older models. my experience with the newer models are that these actively hurt their performance and burn tokens needlessly. You still need an agents.md specific to your project but not broad skills anymore. Because the software development best practices seem to have been baked into them at post training time.
I've been using Compound Engineering by Every for a long time now. I like the brainstorm and plan features. Similarly I like the /grill-me skill by Matt Pocock. As a mediocre programmer, they help me get my ideas refined, documented and implemented.
I have found most of the other skills to emulate an 'enterprisy' way of developing, having everything checked multiple time by 'councils' and whatnot, making things slow, vacuum tokens like mad and the whole process reeks of cargo culting.
Same here. I turned off everything in superpowers except brainstorming
Making active decisions and weighing different alternatives improves my understanding, and I think the result is better, though that might just be because I understand it. Which is worth it on its own.
This is why I built this out. I needed what superpowers gave in terms of detail without spending a day being asked more and more detail. With a prototype the spec I need it to function basically well. In a company with lots of documentation and tickets with AC the agents should be able to drag context and figure out what to do.
Over the last 8-9 months I worked on a very difficult codebase (distributed trading system running multiple US option strategies, real-time.) I began using agents after writing the core of it over ~2.5 years. So I basically worked out how to give coding agents just enough structure to be correct and not turn the codebase into slop. For me, I never really used "skills" or "prompts" but I just ask a ton of questions to Claude and try to pull out why something will or won't work design wise.
Too many people IMO are sitting here deliberately describing what they think is the best implementation, and that hinges on their experience, familiarity, or breadth of exposure to different circumstances. So, if you invert this, and ask questions to the AI about your design, its pitfalls, where things might bite you, etc. This is how you take a block of marble and chisel away at a problem to make it beautiful.
There are a few tricks to using coding agents successfully. You do not always need a specification, but it helps in a lot of projects. What you do need is decision depth, meaning you need to be able to trace decisions back through the project history and create some sort of ledger of intention. Without writing a short paper on this, I built a system to use agents in a codebase that DEMANDS accuracy.
You do not always need a spec, but it helps in some projects. What you do need in almost every project is coherency and decision depth; i.e., you need to be able to trace decisions back through the project history and create some sort of ledger of intent. Why was it coded this way? What happened with this bug, etc. This becomes increasingly challenging in larger codebases, way beyond "agent memory".
Building up an institutional knowledge around your codebase is sort of what Pullboard does, by giving each work item (feature, bug, etc.) a thread and history. This, along with shouts between agents, commits, and the combined depth of decisions and intent give your agents coherency to make smarter decisions than otherwise possible. Yes, independent verification is great, but the combined effect is what makes it work.
When I read misspelled words in a headline, I find myself flipping between - on nice, this is really created by a human. And, oh - this is just to make it seem like created by a human.
I've all but given up on these types of approaches. Models will often just ignore your process instructions at the most inopportune moments. For work, I've resorted to mostly just using single agents for smallish pieces of work that I orchestrate myself. I treat it as a tool, with me being the craftsman.
Everyone is pushing Agent Fleets and Swarms, and I'm sure that there are many success stories, but from our internal experiments many devs don't see any speed advantage for complex work. Here's what one of them told us recently: "The speed advantage is offset by the manual refactoring work. The code is 'correct', but it's just not what any of us would have written".
Now one could argue that you could just ignore the code if it's working (that is in fact what Ex Co instructed us to do) and just keep running these fleets if the end result "works", but I'm not fully convinced this will end well in the long term.
Then again, I'm stuck with decades of legacy code and systems that noone understands that were introduced by humans...
> Then again, I'm stuck with decades of legacy code and systems that noone understands that were introduced by humans...
But that's despite many efforts made to keep that code understandable, maybe even documented. If now that's not even tried the results will be a thousand times worse - and the dependency on the LLM absolute.
The only time I ever few like I need agent swarms is when I am doing mechanical whole-codebase migrations/verification.
The LLMs are so much faster than I can check the output anyway. If I have a long-running task I just work on another one in parallel while I wait on the first one.
First I wasn't sure if technical debt still matters but I think it absolutely does. As long as I'm involved in the planning phase at all, the complexity of the code base still bubbles up to me. Claude will say: ok we can build that but how should we handle legacy code paths A,B,C,D that no one needs and I wasn't even aware existed.
I think the current LLMs benefit from the modular design, but also from things humans would hate: arbitrary uniqueness. If you have three services, your main() function better just be a single call to a unique function else they're going to slowly lose track of which one you're talking about.
I broke apart a 1k length script into functional components because the local AI just couldn't figure out where edits landed. But once that was complete, it had no problem tweaking features in those scopes.
I think the real TAM is local coding models starting around 32GB sometime in 2027. Obviously, Capitalism gets to decide what we're blessed with but knowing that you can get Qwen3.8-Flash-Next running at around 40GB VRAM with SSD offloading means data centers are either going to become way more efficient, or they're going to die on the vine.
It's also a way to make the system more reliable in terms of doing the work!
But I think many people are still missing the point about how AI systems should learn. Arguably, with people we tend to hire and "grow" in-house experts as opposed to outsourcing everything, so why shouldn't we build a system that learns from experience, from its failures?
At first I thought the key was in skills, but skills are static, while you need a continuously learning system
Agreed on all counts. Once you set up an alignment and verification system, you really see how many gaps are present in initial code generation, regardless of what might have been specified.
Even if you have a basic skill-based workflow, a rudimentary retrospective > process improvements artifact that can be ingested on the next run can have a positive impact.
Brother what “report” are you talking about? Do you mean your comment? The one with your story that ended before the resolution of your problem was reached?
The advantage is not so with speed, but with autonomity and doing MORE work. The benefits are clear when you stop micromanage your agents and start scaling their work
91 comments
[ 16.7 ms ] story [ 73.5 ms ] threadYeah, for five minutes you needed to use a specific style, very specific language patterns and what have you, in order to get results that were a cut above. But then the models and the harnesses got better and that moment passed.
There are other ways to achieve this same effect without loading the full superpowers suite though.
Why not just tell Claude to figure it out and build what it needs? Why do I need a plugin or a factory or whatever.
I just ask “can you go faster?” And claude suggests some stuff and mostly just works autonomously.
We use to say “web development is changing fast” when a thing changed after two years, and now it looks like it was changing at a snail’s pace compared to AI.
Plan mode tends not to ask as many questions and go as deep, so often edge cases and other details get missed.
I imagine by this point the models already have the plugin code in their training corpus, plus plenty of RL data from users interacting with the plugins.
Most of the comments here seem to focus on specific things people were trying to get out of skills, and whether those are still needed.
That is going to vary a lot.
If your goal with something like superpowers was to have a process that made your model work "properly" on tasks, sure that's probably not needed anymore.
If your goal with something like superpowers was to get a consistent set of artifacts alongside what was developed (quality varying, so i mean consistent here as "one design plan, one implementation plan", not "good"), nothing has changed, models do not do this consistently, in a durable fashion, without something telling them to do this.
Yes, for example, newer Opus will often decide to write a spec. But not always, and not with any consistent format or ...
If you want that to happen, you'd still need a skill making it happen.
If you don't care about that, then sure, you don't need the skill anymore.
People seem to have used various skills to achieve different things, and so have wildly different views on what is still necessary.
I do use skills for other things, I don't believe that skills are bad. I'm just not sure what they add in this case.
I have found most of the other skills to emulate an 'enterprisy' way of developing, having everything checked multiple time by 'councils' and whatnot, making things slow, vacuum tokens like mad and the whole process reeks of cargo culting.
Making active decisions and weighing different alternatives improves my understanding, and I think the result is better, though that might just be because I understand it. Which is worth it on its own.
Too many people IMO are sitting here deliberately describing what they think is the best implementation, and that hinges on their experience, familiarity, or breadth of exposure to different circumstances. So, if you invert this, and ask questions to the AI about your design, its pitfalls, where things might bite you, etc. This is how you take a block of marble and chisel away at a problem to make it beautiful.
There are a few tricks to using coding agents successfully. You do not always need a specification, but it helps in a lot of projects. What you do need is decision depth, meaning you need to be able to trace decisions back through the project history and create some sort of ledger of intention. Without writing a short paper on this, I built a system to use agents in a codebase that DEMANDS accuracy.
The methodology for agents is here:
https://github.com/pullboard-dev/pullboard
Building up an institutional knowledge around your codebase is sort of what Pullboard does, by giving each work item (feature, bug, etc.) a thread and history. This, along with shouts between agents, commits, and the combined depth of decisions and intent give your agents coherency to make smarter decisions than otherwise possible. Yes, independent verification is great, but the combined effect is what makes it work.
https://github.com/pullboard-dev/pullboard
Even when starting Claude in dangerous mode, you still need to babysit it! Annoying.
works for me
Everyone is pushing Agent Fleets and Swarms, and I'm sure that there are many success stories, but from our internal experiments many devs don't see any speed advantage for complex work. Here's what one of them told us recently: "The speed advantage is offset by the manual refactoring work. The code is 'correct', but it's just not what any of us would have written".
Now one could argue that you could just ignore the code if it's working (that is in fact what Ex Co instructed us to do) and just keep running these fleets if the end result "works", but I'm not fully convinced this will end well in the long term.
Then again, I'm stuck with decades of legacy code and systems that noone understands that were introduced by humans...
But that's despite many efforts made to keep that code understandable, maybe even documented. If now that's not even tried the results will be a thousand times worse - and the dependency on the LLM absolute.
The LLMs are so much faster than I can check the output anyway. If I have a long-running task I just work on another one in parallel while I wait on the first one.
I broke apart a 1k length script into functional components because the local AI just couldn't figure out where edits landed. But once that was complete, it had no problem tweaking features in those scopes.
I think the real TAM is local coding models starting around 32GB sometime in 2027. Obviously, Capitalism gets to decide what we're blessed with but knowing that you can get Qwen3.8-Flash-Next running at around 40GB VRAM with SSD offloading means data centers are either going to become way more efficient, or they're going to die on the vine.
Swarms don't necessarily need to be about speed. You can get a lot of value from small swarms doing things like analysis or verification work.
But I think many people are still missing the point about how AI systems should learn. Arguably, with people we tend to hire and "grow" in-house experts as opposed to outsourcing everything, so why shouldn't we build a system that learns from experience, from its failures?
At first I thought the key was in skills, but skills are static, while you need a continuously learning system
Even if you have a basic skill-based workflow, a rudimentary retrospective > process improvements artifact that can be ingested on the next run can have a positive impact.
Many are using a sub, which means (AFAIK) you can't override the system prompt:
https://platform.claude.com/docs/en/release-notes/system-pro...
I imagine it's harder to follow relevant instructions once they are buried in a mass of otherwise irrelevant, but undifferentiated instructions.