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).
It was tongue in cheek but the idea was that having a super perfect plan is the Waterfall method while "we" (contemporary software developers) are working Agile now, meaning we are starting somehere and adapting the plan while we go.
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.
Looking at the comments here it's clear that there's a lack of understanding about what skills fundamentally are, they're process or procedure.
The latest frontier models exhibit good process that was trained into them during the RL phase, and whilst that might make them massively more capable in terms of one-shot, or general coding ability, models without skills simply don't have a durable process.
If you have a need for procedure in your use of agents, you absolutely need skills like this. I'm not commenting on the relative merits of this or superpowers, but rather the seemingly religious debate, "skills are good" vs "skills are bad" discussion that keeps coming up.
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.
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.
> The code is 'correct', but it's just not what any of us would have written".
I'd fine with not what we'd have written ... if it worked.
Trying ChatGPT for a simple one page of HTML JS having draggables, I said clamp touch point to visible viewpoint. Fine. Then I said add 3x drag gain. It put that after the clamp, whereas anyone/thing having an ounce of intelligence would have urecognised the only possible purpose of the clamp and so put the gain before.
This is fundamentally why we cannot trust stochastic parrots to code. They lack the human's understanding of purpose which cannot be abstracted from the code yet is essential for success.
1. The models are probabilistic in their output. This is objectively verifiable fact. Give same prompt, repeat and you'll get different output.
2. With these markdown heavy approaches, the system has to keep a track of the system state not just in code but in tons of markdown files as well.
3. As the system evolves due to features, bug fixes, the corresponding markdown files are to be updated as well to keep in sync.
4. This update consumes tokens for sure so now token spend goes through roof.
5. But because the models are probabilistic, the real problem is that it is guaranteed that some of the places would not be updated or updated with misinformation in those markdown files.
6. Next agent run when loading the context from these markdown files would have misinformation in its context that it would discover mid task, would have to rectify the situation. token spend would be quadrupled.
7. Only those edge cases of markdown files would hit that has been visited so there would be many inconsistencies still and they would pile up and compound with the passage of time.
8. Anyone who has significant experience with such approaches would testify to that.
9. There's no solution to that other than just using agents as power tools and holding the context and desired outcome in your own head.
When I hand off work to an agent it always, always, always gets the level of abstraction, important details or just missed context wrong. I'd rather have a lot of reviews than hand off work. Imho it's just not there yet if you care about what is actually generated.
Superpowers has stopped working the past six months, to the point where it’s actively harmful. The main problem is the Writing Plans skill — its directives emphasize that the plan must be written for agents that cannot be trusted. What happens is the agent then writes all the code and the steps become “Copy this code block into foo.rs”. Meanwhile the review skill specifies that the code must follow the plan exactly; but now that it’s at the level of copying code, which hasn’t been tested and compiled*, the reviewer always freaks out about a stray & or comma, launching fixer agents and whatnot.
The last straw was two weeks ago when I discovered on a run Fable accounted for this problem in by first writing all the code in a scratch git repo and running unit tests, before copying that code into the plan. Since then I’ve been back to vibing. I lose overnight runs but gain sanity.
Interesting observation. Plans are abstractions. The missing model capability is the ability to recognize work at different levels of abstraction, and understand which level of abstraction is called for and to be able to work at multiple levels of abstraction at the same time. The LLM architecture elevator has a bias for down.
Theoretically the value of systems like Superpowers should be regulating bias like this.
This is just my opinion, maybe unpopular, and I am not entirely sure of it, but I have a feeling a lot of the power tools efficiency benchmarks are questionable.
I get this sense that because models are great, the work gets done, and the results are perceived as good enough by the user, then it creates this illusion that the tooling is responsible for it.
I feel like it's kinda like saying "if it wasn't for VS Code then my API wouldn't be this good" which is a very strange correlation to put out there.
I see this tendency on measuring workflows and productivity chasing instead of software, this can create an addictive trap and the illusion that the workflow beats looking at the problem, defining it, and optimizing for how it needs to change.
One thing I learned working across several industries and problem domains throughout my life is that there is no "one size fits all" here and most often productivity hacks are not true bottlenecks.
All this upfront planning is a giant waste of tokens and altogether a poor approach. Especially at the level superpowers prescribes, it is quite insane.
We stopped doing big design up-front for a reason, yet it’s roaring back.
We know the devil is in the implementation details and you can’t anticipate everything before you try to implement it. The implement/discover/adjust approach cycle is the best cycle for a reason.
The approach of handing plans down to dumber agents is also a bad idea, for the same reason. A dumber agent will plow right through unanticipated friction in the implementation, and it won’t know to stop and raise an issue.
Even smarter agents will try to complete a plan as written without altering course.
Nothing beats implementing quickly, reviewing, addressing, then reviewing again.
If you’re on a sub, you can afford to waste tokens on this planning theater, I suppose.
I think the MAIN thing on specs is to just make sure you have them, and get the models to ask you clarifying questions. You don't really need a skill or process for that, just ask the model to ask you questions on a spec.
I am not so convinced yet that subagents with haiku and sonnet really deliver better results versus opus, nor if the speed really matters that much if you are truly autonomous. I mean he is talking about saving like 20 minutes here. There are 24 hours a day, you are much more likely to be gated by product specs and knowing what you want and good ideas than engineering if you are hammering things now.
codeugo | 19 hours ago
bitwize | 19 hours ago
esafak | 18 hours ago
CasualSuperman | 18 hours ago
PierceJoy | 18 hours ago
Nursie | 16 hours ago
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.
jghn | 9 hours ago
There are other ways to achieve this same effect without loading the full superpowers suite though.
foldr | 8 hours ago
jghn | 6 hours ago
tarr11 | 18 hours ago
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.
mvkel | 18 hours ago
mostertoaster | 17 hours ago
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.
bearjaws | 9 hours ago
Plan mode tends not to ask as many questions and go as deep, so often edge cases and other details get missed.
jemdiggity | 18 hours ago
adastra22 | 17 hours ago
ofrzeta | 17 hours ago
adastra22 | 17 hours ago
ofrzeta | 16 hours ago
adastra22 | 15 hours ago
zeryx | 9 hours ago
InsideOutSanta | 16 hours ago
mulhoon | 12 hours ago
hmontazeri | 15 hours ago
neuronexmachina | 7 hours ago
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.
fantasticwaddle | 18 hours ago
aroman | 17 hours ago
Tajnymag | 14 hours ago
ra | 17 hours ago
The latest frontier models exhibit good process that was trained into them during the RL phase, and whilst that might make them massively more capable in terms of one-shot, or general coding ability, models without skills simply don't have a durable process.
If you have a need for procedure in your use of agents, you absolutely need skills like this. I'm not commenting on the relative merits of this or superpowers, but rather the seemingly religious debate, "skills are good" vs "skills are bad" discussion that keeps coming up.
DannyBee | 16 hours ago
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.
InsideOutSanta | 16 hours ago
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.
berofeev | 15 hours ago
__alexs | 15 hours ago
option_greek | 17 hours ago
michelb | 15 hours ago
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.
johannessjoberg | 15 hours ago
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.
mkesper | 10 hours ago
hbarka | 15 hours ago
mkirsten | 14 hours ago
chrisjj | 10 hours ago
NetOpWibby | 14 hours ago
Even when starting Claude in dangerous mode, you still need to babysit it! Annoying.
shawabawa3 | 13 hours ago
works for me
ilitirit | 13 hours ago
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...
onli | 13 hours ago
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.
DanielHB | 13 hours ago
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.
ngruhn | 12 hours ago
arccy | 11 hours ago
cyanydeez | 11 hours ago
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.
chickensong | 12 hours ago
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.
chrisjj | 10 hours ago
I'd fine with not what we'd have written ... if it worked.
Trying ChatGPT for a simple one page of HTML JS having draggables, I said clamp touch point to visible viewpoint. Fine. Then I said add 3x drag gain. It put that after the clamp, whereas anyone/thing having an ounce of intelligence would have urecognised the only possible purpose of the clamp and so put the gain before.
This is fundamentally why we cannot trust stochastic parrots to code. They lack the human's understanding of purpose which cannot be abstracted from the code yet is essential for success.
phoghed | 6 hours ago
chrisjj | 6 hours ago
Try rereading the report please.
Chris2048 | 9 hours ago
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.
wg0 | 12 hours ago
Basic issue is this:
1. The models are probabilistic in their output. This is objectively verifiable fact. Give same prompt, repeat and you'll get different output.
2. With these markdown heavy approaches, the system has to keep a track of the system state not just in code but in tons of markdown files as well.
3. As the system evolves due to features, bug fixes, the corresponding markdown files are to be updated as well to keep in sync.
4. This update consumes tokens for sure so now token spend goes through roof.
5. But because the models are probabilistic, the real problem is that it is guaranteed that some of the places would not be updated or updated with misinformation in those markdown files.
6. Next agent run when loading the context from these markdown files would have misinformation in its context that it would discover mid task, would have to rectify the situation. token spend would be quadrupled.
7. Only those edge cases of markdown files would hit that has been visited so there would be many inconsistencies still and they would pile up and compound with the passage of time.
8. Anyone who has significant experience with such approaches would testify to that.
9. There's no solution to that other than just using agents as power tools and holding the context and desired outcome in your own head.
chrisjj | 10 hours ago
The word you're looking for is unreliable.
> But because the models are probabilistic, the real problem is that it is guaranteed that some of the places would not be updated
untrustworthy.
bitwize | 2 hours ago
chrisjj | an hour ago
RamblingCTO | 10 hours ago
chrisjj | 10 hours ago
Fast is easy.
Fast and good, not so much.
jonstewart | 10 hours ago
The last straw was two weeks ago when I discovered on a run Fable accounted for this problem in by first writing all the code in a scratch git repo and running unit tests, before copying that code into the plan. Since then I’ve been back to vibing. I lose overnight runs but gain sanity.
chrisjj | 10 hours ago
You gain sanity only if (insanely) you never test the output.
Selkirk | 5 hours ago
Theoretically the value of systems like Superpowers should be regulating bias like this.
hmokiguess | 8 hours ago
I get this sense that because models are great, the work gets done, and the results are perceived as good enough by the user, then it creates this illusion that the tooling is responsible for it.
I feel like it's kinda like saying "if it wasn't for VS Code then my API wouldn't be this good" which is a very strange correlation to put out there.
I see this tendency on measuring workflows and productivity chasing instead of software, this can create an addictive trap and the illusion that the workflow beats looking at the problem, defining it, and optimizing for how it needs to change.
One thing I learned working across several industries and problem domains throughout my life is that there is no "one size fits all" here and most often productivity hacks are not true bottlenecks.
yearolinuxdsktp | 8 hours ago
We stopped doing big design up-front for a reason, yet it’s roaring back.
We know the devil is in the implementation details and you can’t anticipate everything before you try to implement it. The implement/discover/adjust approach cycle is the best cycle for a reason.
The approach of handing plans down to dumber agents is also a bad idea, for the same reason. A dumber agent will plow right through unanticipated friction in the implementation, and it won’t know to stop and raise an issue.
Even smarter agents will try to complete a plan as written without altering course.
Nothing beats implementing quickly, reviewing, addressing, then reviewing again.
If you’re on a sub, you can afford to waste tokens on this planning theater, I suppose.
moondowner | 7 hours ago
When I saw the title Superlite, I thought it's a Superpowers fork optimised for less token usage...
mchusma | 6 hours ago
I am not so convinced yet that subagents with haiku and sonnet really deliver better results versus opus, nor if the speed really matters that much if you are truly autonomous. I mean he is talking about saving like 20 minutes here. There are 24 hours a day, you are much more likely to be gated by product specs and knowing what you want and good ideas than engineering if you are hammering things now.