📝 SUMMARY This week's call featured a rotating show-and-tell covering personal agent harnesses, enterprise AI adaptation strategies, and mobile deployment tactics. Members demoed custom tools for tracking AI model usage across projects, automating subscription management, and running agentic workflows from mobile devices. Discussions ranged from rebuilding Codex functionality on banned networks to hiring philosophies for the AI-augmented era, with deep dives into cross-platform mobile stacks and biometric verification services. 💡 KEY INSIGHTS Scott Rippey demonstrated that hybrid-scanning local project folders alongside provider APIs can create a "Model Radar" to track which AI models are active versus deprecated across multiple client apps. He also showed how machine-to-machine sync via Bonjour keeps session databases consistent across multiple Macs. Ty Wells revealed an automation setup that switches between Claude and Codex subscriptions based on remaining usage percentage, preventing work loss from hitting quotas. His "intent capsules" concept—self-contained context bundles—allows cold agent sessions to execute plans without prior conversation history, enabling remote work continuation from anywhere including mobile devices. Patrick Chouinard explained how to recreate Codex review mechanics on GitHub Copilot CLI when OpenAI tools are banned at work, satisfying security requirements while maintaining access to frontier models. He emphasized that fully autonomous AI development is a misnomer because human intent is always required, and that goal-based automation only works with hard, testable facts rather than opinions. He also highlighted that just-in-time training via composable skills beats static courses, which become obsolete before completion. Daniel Zivkovic shared that requirements elicitation works better as an iterative "optometry" process (showing prototypes and asking "this or that") rather than upfront specification. He noted that running multiple AI-generated implementations in parallel causes conflicts, while sequential overnight runs create a morning review queue without collisions.

📝 SUMMARY This coaching call brought together founders and developers navigating the tension between product development and market validation. Brandon Hancock shared a candid business update on EMS SOAP pivoting its ideal customer profile from slow-moving fire departments to faster-closing private ambulance companies under cash-flow pressure. Patrick Chouinard detailed his enterprise Claude Code rollout expanding from 250 to 2,500 users, including a self-improving support knowledge base and automated training generation. The group also demoed diverse projects including Agent Task for cross-agent orchestration, a multi-model security review system, fully automated ERP pipelines, an AI photo booth, and school pickup management software. Throughout, Brandon coached on sales segmentation frameworks, disciplined outreach habits, and productizing internal tools while technical discussions covered cross-model review strategies, local model use cases, and AI architecture decisions. 💡 KEY INSIGHTS Whale/Minnow/Tuna Segmentation: Brandon introduced a sales framework distinguishing whales (huge slow contracts taking a year or more), minnows (small deals handled via automation), and tunas (mid-size $20-40k accounts closing in months). Most startups should focus limited selling time on tunas for sustainable growth. Cash-Flow Driven ICP Pivots: While standard advice suggests staying with one avatar until saturated, burning startups may need to pivot ICPs specifically to accelerate sales cycles when survival is at stake. Sales Enablement as Champion Creation: Providing prospects with case studies, ROI calculators, and one-pagers they can hand up their chain of command turns customers into internal advocates who sell to both department heads and budget authorities. Cross-Model Review Discipline: Never use the same model family to review code it generated. Using Claude for generation and Codex (or another vendor) for review surfaces different cognitive biases and catches issues the original model misses.

With July 7th coming up, I’ve been thinking less about using Fable and more about capturing its value. My approach has been to spend my remaining time with Fable on work that only Fable can realistically do. Not writing code. Not debugging. Not implementing features. Instead, I’ve been asking it to design systems, challenge architectures, and produce implementation specifications for projects that are simply too large or too interconnected for me to have tackled with previous models. The key is this: The output isn’t the final product. The output is a specification detailed enough that Opus, GPT-5.5, Codex, or another implementation model can execute it later. In other words, I’m using Fable to build my implementation backlog. By the time July 7 arrives, I don’t want to have “used” Fable for a few conversations. I want to have months of high-quality architectural work waiting to be implemented. It’s almost like borrowing the brain of a senior architect for a limited time, then leaving the office with a stack of blueprints your engineering team can build from over the coming months. If you still have access, I’d encourage you to spend less time asking it to do the work and more time asking it to define the work. That knowledge doesn’t disappear when access ends. In many cases, it’s the most durable asset you’ll get from the entire preview.

**THIS IS A BRANDON WEEK, don't miss him** Last week we watched an entire video production pipeline run itself end-to-end while Claude somehow compressed two months of estate paperwork into a single weekend. If you've ever wanted to talk to your codebase like it's a senior dev over coffee—or just automate the boring stuff so you can focus on the fun stuff—this is the week to jump back in. 📞 HOW THE CALLS WORK The calls can run 2+ hours. We want to make sure we're respecting everyone's time. Especially those of you who actually show up. Here's the structure: 👉 Reply to this post with your questions before the call 👉 If you submit a question and you're on the call, you go first 👉 We work through questions in the order they came in 👉 Then we open it up for everyone else If you can't make the call but want your question answered, drop it in the comments. We'll get to it. But priority goes to people who are there. The goal is simple: if you're taking the time to show up, you shouldn't have to wait behind questions from people who aren't even on the call. Scott is bringing back that fully automated video pipeline for a larger demo plus a new voice-based codebase conversation tool, while Ty continues building out his CodeTalk voice interface on Proxmox. Morgan is also stress-testing AirLLM to see if consumer hardware can really handle 32B+ models—if you've been curious about local inference without the enterprise price tag, come see how the experiment turns out. 🔗 ZOOM LINK (save this) https://us06web.zoom.us/j/81995207847?pwd=Xe6u6LmIQOmCP5VTnOwWYjDBfZNKGB.1 📅 WHEN Tuesday June 30th at 6PM ET Looking forward to seeing you on the call!

Here's a fun way (prompt) you can use the claude code security skill / slash command to run on your whole codebase instead of just PR's or uncommitted changes if you are wondering about how it stacks up to start: Run Anthropic's built-in /security-review on my ENTIRE codebase, not just a diff, then restore my git state exactly as it was. The built-in /security-review only scans `git diff origin/HEAD...` (branch vs remote default), so to scan everything you must present the whole tree to it as the diff: 1. Capture my current state first: current branch, whether origin/HEAD is set, and stash any uncommitted changes (git stash push -u) so nothing is lost. 2. Build an empty-base structure so the full tree shows as the diff: - empty=$(git commit-tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 -m "scan base") - w=$(git commit-tree $(git rev-parse HEAD^{tree}) -p $empty -m "scan tree") - git checkout -b secscan-tmp $w - git update-ref refs/remotes/origin/HEAD $empty - verify `git diff --name-only origin/HEAD...` lists all files 3. Invoke the actual built-in /security-review skill (its genuine identify → parallel false-positive filtering → confidence≥8 methodology). Do NOT substitute a manual review or a multi-agent workflow — I want the real feature. 4. ALWAYS restore afterward, even if the scan errors: checkout my original branch, delete secscan-tmp, restore origin/HEAD to its prior state (or delete the ref if it wasn't set), and pop my stash. Confirm `git status` matches the starting state. 5. Give me the final findings report, then a one-line confirmation that git is restored. Don't commit anything. Don't push.