I think we all can agree — we're all looking for results. We're here to up our game by providing ourselves a finely honed knife that cuts through the clutter and delivers the best AI has to offer. Below is a response to one of our members who built a solid workflow around Jake’s Method / ICM, only to keep running into error after error. -------------------------------------------------------------------------- " Exactly — “exposed by a tool, not failed by it.” If you're running into error after error with Jake’s Method or ICM, it’s almost never the method itself. It’s almost always incomplete context. Think of it like this: You’re the best chef in your circle. You’re hosting a backyard barbecue. You spared no expense on ingredients and prepped everything perfectly… but you forgot the one secret ingredient that actually makes the dish hit. What hits the table ends up tasting like generic diner food. Same thing with AI. AI doesn’t fail. It simply delivers exactly what the context allows. No more, no less. When using Jake’s Method or ICM, the difference between clean one-shot builds and constant errors usually comes down to: - Crystal-clear definition of the final desired outcome - Tight, focused context files (I keep mine under 150 lines each) - One task, one outcome — chained together properly Most people fail because they either expect the AI to magically fill in the gaps, or they dump multiple sub-tasks into a single prompt and wonder why it falls apart. Give it the full map up front — role, constraints, success criteria, architecture decisions, everything. Do that consistently and the errors drop dramatically. How’s your Context MD file structured right now? That’s usually where the real leverage is. -------------------------------------------------------------------------- The real skill isn’t finding the perfect prompting framework. It’s learning to brief the AI with the same precision and clarity you’d demand from a top-tier teammate or system architect. Master that, and everything else starts falling into place.

I'm curious what everyone here likes to do for fun (of course building stuff with Claude is fun too lol), and if you've applied any AI to your hobby. For me it's been super useful for DND planning and I find I get to stay in creative flow more. Curious what other people are doing

Well well well. Turns out my favorite troublemaker @David Vogel is only a hop skip and a jump away from me. We took this community to a new place…real life! Appreciate all of you! Continue reaching out and helping each other… who knows maybe we go live sometime.

Anyone want to do a meetup around OC? We can nerd out on our projects, help each other move forward in our businesses, just chill and shoot the breeze…🙋‍♀️🌊🎉 ready to be your resident Ring Leader. 🎪

So I haven't had the chance to dig into the classroom yet so I'm not sure if this is covered anywhere.. but this is my set of general vibe coding rules that I have been working on to use across all projects. This way I have a single "source of truth" for best practices to include on all builds and try to keep things clean. So far it has been working pretty well (from an amateurs perspective haha) and looking forward to stress testing it more. Please take it and use it for yourself if you don't have anything similar yet. Also, I would really appreciate any feedback from the more experienced devs/engineers in the group. 🙏 Edit for clarity: this doc is something I have been applying to all vibe coding projects. Not all projects in general. Another edit for clarity: I am just getting through Jake‘s ICM paper now along with the classroom material. I was not aware that he also refers to the claude.md as a global file to be handed off to the highest level orchestrating agent. This global.md would be better named something more specific and placed around layer 3 of the workflow (someone please correct me if I’m wrong). Anyways, hope this clears up any confusion there may be. Decided to change the name to vibe-code-rules.md for clarity =)