Hi, PapaFam! ☀️ It is no longer news that FABLE, which was recently released, has been shut down for reasons best known to its creators. shout-out to Sonny and every other dev who play with it before it remove However, this post is not really about FABLE. It is about the lessons many of us have learned from following the AI Agent Series Sonny started and watching how software development is gradually evolving before our eyes. First, a special shout-out to our great teacher and the entire team Sonny and Jay who continue to lead from the front, helping us understand what these new AI models can truly do. Through every episode of the series, we have seen ideas transformed into real applications faster than many of us thought possible. At this point, we are no longer surprised that AI can write code. The bigger question is: HOW DO WE POSITION OURSELVES AS DEVELOPERS IN THE AGE OF AI? After following every episode of the AI Agent Series, here are five lessons that stood out to me that we can learn from SONNY. - 1. INSTALL YOUR DEPENDENCIES AND PACKAGES YOURSELF One thing I have noticed repeatedly is that AI does not always recommend the latest packages, versions, or installation methods. Sometimes it suggests outdated dependencies, deprecated libraries, or approaches that are no longer considered best practice. As developers, we should always verify package versions, check official documentation, and understand exactly what we are installing before adding it to our projects. - sonny preach the above a lot the OG should know by now AI CAN ASSIST YOU, BUT IT IS YOUR RESPONSIBILITY TO ENSURE YOUR PROJECT IS BUILT ON THE RIGHT FOUNDATION. - 2. INSTALL ALL THE SKILLS AND PLUGINS REQUIRED FOR YOUR PROJECT An AI agent is only as effective as the tools available to it. Whether it is APIs, MCP servers, SDKs, plugins, databases, or external integrations, the quality of your output often depends on the tools connected to your workflow. Many times, the limitation is not the model itself but the lack of the right tools needed to accomplish the task.

If you’ve ever built a B2B SaaS, you already know the messy part starts when you need organization-specific features like seat limits, team members, subscriptions, invites, roles, checkout flows, emails, and keeping everything in sync. This video is all about how to set up Clerk’s new seat-limited organization plans so you can enforce member limits without building all the custom logic yourself. Clerk now lets you define organization plans with specific seat limits, connect them to checkout flows, manage subscriptions, and control how many members each organization can invite — all without manually syncing Stripe, webhooks, organization data, and your own database logic. I’ll show you how the full flow works inside a real B2B demo app: creating organizations, switching between Growth and Pro plans, inviting members, enforcing seat limits, setting up plans in the Clerk dashboard, and using Clerk’s new components to build both default and custom pricing experiences. We’ll cover: ✅ Why seat limits are painful to build manually in B2B SaaS apps ✅ How Clerk handles organization members, invites, roles, and subscriptions ✅ Creating a demo organization and testing member limits in real time ✅ Using Growth and Pro plans with limited and unlimited seats ✅ How invites count toward available seats before users accept ✅ Setting up organization membership limits inside Clerk ✅ Creating seat-based organization plans in the Clerk dashboard ✅ Using Clerk’s PricingTable, CheckoutButton, PlanDetailsButton, and SubscriptionDetailsButton components ✅ Building a custom pricing page without writing your own checkout or webhook sync logic This is one of those features that removes a huge amount of backend complexity. Fewer custom systems, fewer edge cases, fewer places for your SaaS app to break.

Episode 7 of our new Series 'Code with AI the Right Way' is here! — and this time, we're vibe coding an Airbnb clone LIVE from scratch! This is a LIVE build — mistakes, debugging, and all. That's the point. You learn more watching someone solve real problems in real-time than from a polished, pre-recorded tutorial.

A lot has changed since AI and agents entered the scene. They’ve changed the way software engineers and developers work, build, learn, and solve problems. But one thing is important to understand: being unaware of these changes can cost you more than you realize. The real threat is not AI itself. The real threat is the person who knows how to use AI properly. That is why @Sonny Sangha has the vision to teach these things early. He understands that those who learn how to work with AI will have a huge advantage. As Cal Newport would say: > The person controlling the intelligence machine will become more valuable. After observing @Sonny Sangha thought process, I noticed patterns worth sharing with the Papafam community. Because even as AI becomes smarter, some timeless skills still remain valuable. Scott Young introduced the DROP framework for mastery: See → Do → Feedback And @Sonny Sangha has consistently invested his time, energy, resources, and passion showing us exactly how to do that. As Donald Knuth once said in Coders at Work: > If someone understands how you created something, they can create their own version too. That is real leadership. That is real mentorship. @Sonny Sangha doesn’t hold back. He teaches openly, shares deeply, and helps others grow. That’s why we are all here. And that’s why we appreciate you, Sonny. --- So What Still Remains in the AI Era? - 1. Googling Still Matters If you watch Sonny build, you’ll notice he still searches a lot. Especially the last pizza build This skill existed before AI, and it is here to stay. Knowing what to search, how to search, and how to find answers fast is still powerful. AI can help, but search skills still matter. --- - 2. Reading Code Still Matters Even with powerful agents writing code, Sonny still reads through the output and edits parts himself.

Hey Papfam, Let’s talk about what’s really happening in our editors right now especially in this new era of Opus 4.6 and Codex. You’re building something complex maybe a real-time comment system or a deep auth flow. You get stuck. You prompt your AI. And just like that boom. 200 lines of clean, confident TypeScript. Structured. Typed. Production ready. You paste it. It works. You ship it. Then someone asks: Why is that hook structured that way? What happens if that cache invalidation fails? And suddenly: Em… let me check. --- Welcome to the Age of the Black Box Developer We’ve entered a new phase of development. Not just AI-assisted coding but AI-driven building. Models like Opus 4.6 are designed for deep reasoning and understanding entire systems, while tools like Codex are optimized to execute and ship code fast. Together, they’ve changed the game. You no longer need to struggle through every abstraction. You can generate architecture. You can delegate implementation. You can ship faster But here’s the problem: You can now build systems you don’t understand. --- This Isn’t Just About Speed It’s About Ownership Let’s be honest. We’re not just coding faster we’re thinking less about the code itself. And that creates a new kind of developer: > Someone who can ship features at 10x speed… > but can’t explain 40% of what they shipped. That’s the Black Box Developer. And in the Opus + Codex era, it’s becoming normal. --- Why This Becomes Dangerous AI today isn’t just autocomplete it’s a collaborator. But it has a split personality: According to researchers Opus thinks deeply but may overcomplicate or abstract Codex executes quickly but may skip deeper reasoning If you blindly trust both, you inherit their blind spots. That leads to three real problems: Debugging becomes impossible You don’t know the system you only know the outcome. Architecture becomes accidental Your app works, but no one truly designed it. You lose technical authority