This Just Fixed 90% Of AI Coding

0:00 What actually happens when you force a coding agent to follow the rules? We all have a common struggle when working with Claude and other coding agents. They tend to not follow the instructions and ignore the claw.md file completely. And even when we tried forcing TDD, it just tried to modify the test files itself. So that's when we came across this plugin that was getting popular, gaining 58,000 stars in just 24 hours. But that just shows what the hype cycle around AI tools is like. This plug-in promises strict enforcement of software development methodologies into the workflow. But the question was whether it actually delivers on that. Our team has already seen similar workflows come out and most of them turned out to be just hype. So we put this plug-in into actual workflows to see if it's worth implementing into real world projects or if it's just hype. Superpowers is a

0:45 plugin that enforces the traditional software development methodology right into the AI ID that you're using. Now, some people might think that existing agile frameworks like BMAD and OpenSpec already do the same thing, but this one is different because it's not just some agent system used to write specs of the project. It's an enforcement of the same agile methodology right into the workflow with strict gates that make sure the agent doesn't proceed until the current step passes. These gates are explicit checkpoints to prevent Claude from steering away from what is instructed. The core philosophy behind this plug-in's approach is TDD and a systematic process over guessing. It verifies before claiming the project is successful, having instructions tailored to target the common areas where AI usually fails and fix them. It doesn't proceed to the next step until it gets

1:30 the green signal from the user. So, in short, it uses all the best practices we've been talking about in our previous videos built in natively, removing the need to set up manually like we used to. So the plug-in emphasizes true red green test-driven development and other common programming principles like dry and yagny that we were taught when we were learning software development. It's available for all the AI platforms. But since our team was using claude code, we just copied the register marketplace command first and added that to the claude code project we were using. After which we installed the plug-in from the marketplace and once installed and with the restart of claude code, this superpowers plugin was available for use in the project. Now once we restarted Claude code, we gave it a prompt that we wanted to build a project management software similar to Trello. It activated

2:16 the brainstorming skill on its own and instead of guessing the things that were needed to be built, it used the skill functionalities and first identified what was in the project. It asked a lot of questions in order to clarify the app, who the project would be for and the tech stack we wanted to use and considered the issues each choice might have. Like with the selection of the database, it gave suggestions that our choice might not be the right one and could be a problem for security because the one we selected runs in the browser and cannot be accessed from the server side which we changed. It kept clarifying all of the details until we were satisfied with the options. Once it confirmed everything with us, the next step was to give three approaches from which we had to choose one that was to be implemented. So we chose the option we liked and suggested changes along with the selection. Now once it was done, it gave us the architecture design

3:01 as well. Next, it gave us the UX design in which it mentioned how the boards were to be handled. It confirmed the whole project structure with us as well. And once all the design was approved, it documented all the data in a docs folder. And this is when this plug-in beats others because it had inbuilt Git instructions to commit each of the changes which other frameworks didn't do and we had to manually enforce. So once the brainstorming skill had created the plans, the writing plan skill was invoked and wrote the implementation plan and committed it. The plan broke down the large application into subtasks that were easier to implement. Now, you might think that Claude's built-in plan mode already does all this on its own. But the main difference between this planning and Claude's planning is that Claude code planning is just for guidance to the agent on what it needs to do. It asked for only those questions regarding the tech stack for which it

3:48 actually thinks there is a need of and makes smaller decisions like UI libraries by itself. On the other hand, superpowers is enforcement, meaning that you cannot proceed to the next step until the current step is passed, ensuring that the plan is actually implemented. Now, once the planning phase was over, it asked us how we would like to implement the plan, giving us two options from which we selected the sub aentdriven implementation. Now, Claude also spawned sub aents on its own. But the skills in sub aent-driven implementation were different because it automatically set up a git work tree for each sub aent so that their work did not affect each other. The agent needs to be isolated by work trees in order to make them work better because if they work in the same directory they overwrite each other's work and this is the main thing it handles on its own natively. Now once the planning was finalized claude moved

4:33 to the implementation phase. It started off a task and once the task was done it spun up a separate review subtask to verify the implementation against the specs. And once it had committed to git, it used another superpower skill which is the code reviewer. And only when the code quality was approved by the previous agents did it start off with the next task and keep iterating on the previous ones until the quality was met. Now once each task was completed, reviewed and committed on Git, ensuring the next task does not start until the previous is completed. It asked us whether it should merge into main or create a PR. So we asked it to merge it back into main quickly. It then removed all the work trees and committed the entire project into the main branch itself. Now this process consumes a lot of the context window because of using sub aents and multiple skills. As for us just one iteration used almost 50% of

5:20 the context window meaning that we have to be careful when working with this process. The project that it created was simple and had basic functionality. We wanted these lists to be ordered by the current states which were to-do, in progress and done. And even though these individual cards were there, we wanted these lists to be movable as well. So we went back to Claude code and asked it to handle that. But it first started the way Claude normally does without the plug-in skills. This must be because too much of the context was consumed and we had to remind it to use the superpowers plugin. And after reminding it, it set off doing the tasks the same way it did previously. Now once we had gone through all the steps, Claude spawned agents to work on separate work trees. But this is where these agents get better because they are using the test-driven development approach natively. These agents first write tests for each part that was to be implemented. And once the

6:06 tests had been written, it ensured that the agent wrote the code for it without any modifications to the test cases and ensured that the tests passed. The plug-in skills used strong prompt cues that prevented it from modifying the tests themselves. Basically invalidating all excuses Claude tends to make while trying to skip steps. These cues look like explicit instructions, like if there is a 1% chance of using a skill, use it. This ensured that each task was done in a proper structured way. One thing to note is that these agents were sequentially performing one task. So it took longer than the usual to complete one task as compared to the way Claude does it natively. But since it enforced strict guidelines, it ensured that the application worked as intended. As we mentioned earlier, the context is consumed at a fast rate with this plug-in where only a few tasks lead to

6:51 only 5% context left. So before proceeding with any further tasks, we ran the compact command so that we don't lose any of the context when Claude is brainstorming for the next task. Once the conversation had been compacted, we gave it a prompt on the next feature we wanted to implement, and it set off the same way. But the best part about this session was that it did not do things by itself by guessing implementations. It kept asking questions from multiple angles, making sure the app was built the way we wanted. This plug-in pushed Claude from all angles, clarifying edge cases in the brainstorming session, like how the columns would look when they were empty, which is something so small that Claude on its own might have just guessed and implemented. Now, the guidelines for using this plug-in better is available in AI Labs Pro. For those who don't know, it's our recently launched community where you get ready

7:37 to use templates that you can plug directly into your projects for this video and all previous ones. If you found value in what we do and want to support the channel, this is the best way to do it. the links in the description. Another one of the strengths of this is its ability to use systematic debugging. We encountered a bug with the saving of data on refreshes and we gave Claude a vague prompt not specifying where we found the bug and asked it to use systematic debugging to fix that. It loaded the systematic debugging skill to do the task. The skills work was divided into four phases. The first phase identified the root cause by asking us questions about that. From our answer, it tried to investigate and traced from the direction we gave and found the right file that might have some issue. And once the root cause was identified, phase two targeted toward isolating the bug, and while phase three narrowed down

8:22 the actual reason the bug occurred so that it could be fixed. And phase four was applying the fix. It used the whole process and made sure the debugging was more structured than probing around the codebase and looking for what went wrong. And it ended the fix with testing. Now, there are a lot of tasks that do not require the full plug-in workflow where using it would be much more than needed. Like when we had to change the UI of the app we were working on, but we didn't want to wait 15 minutes for just a UI change. So, for these kinds of tasks that do not need the full process, we can implement them in a simpler way. Since we didn't have a particular goal in mind for how we wanted the app to look, we asked it to improve the UI and told it not to proceed to the implementation part, just do the brainstorming and planning. It started with brainstorming and asked us which visual direction we wanted by asking clarifying questions on different

9:07 aspects of the design. Claude then stopped after just planning as mentioned in the prompt after which we asked it to implement the plan without using the process. The whole app's UI was changed in a significantly shorter time than the process-driven way would have taken. And despite that, it still committed the changes into Git with the same format the process enforced. The app went from a basic layout with minimal styling to having improved color scheme, hover card states, and a more functional layout overall. This is what makes the framework practical to actually use. You let Claude handle things without the process when it's already good at them and bring in the full process for those cases where it tends to fumble and mess up the implementation. That brings us to the end of this video. If you'd like to support the channel and help us keep making videos like this, you can do so by using the super thanks button below. As always, thank you for watching and

9:53 I'll see you in the next one.