Most people treat Claude Code like a chatbox.
Type a prompt, get some code, complain when it guesses wrong.
Greg Isenberg just published a full setup that treats it like something else entirely: an employee. One with a workspace, a memory, a manager (you), a review process, and a schedule. Set it up his way and it works while you sleep.
The episode is sponsored by Anthropic, so yes, it's partly a product tour. But the system underneath is real, and it maps almost exactly to how the best solo founders I know are already running their companies.
Here's the whole thing, broken down.
The frame: hire it like you'd hire a person
Greg's core idea is stupidly simple.
If you hired a junior employee, you wouldn't throw them into an empty room and yell "make the app better." You'd give them a desk, context on the business, a clear assignment, a way to check their own work, and boundaries on what they can touch.
Claude Code needs the exact same things. He lists nine pieces:
→ A workspace (the repo)
→ Memory (context files)
→ A brief (plan mode)
→ A ticket (one clear assignment)
→ Eyes (it opens and clicks through your app)
→ Review (your standards, written down)
→ A schedule (recurring routines)
→ Parallel sessions (multiple employees at once)
→ Permissions (what it can't touch)
Miss one and it's a chatbot. Stack all nine and it starts to feel like headcount.
The repo brain: 6 folders and 3 files
The demo business Greg builds through the whole episode is a missed-lead responder for med spas. Someone fills a form or calls after hours, the business replies too late, the lead books somewhere else. Classic problem: most local businesses have no lead nurturing strategy at all, so every slow reply is money walking out the door. His pitch: respond to every missed lead before they book with a competitor.
For that idea, he sets up one repo with six folders:
→ /app for the product
→ /context for the business brain
→ /customers for sales calls, support notes, objections
→ /spec, /demos, /routines for the rest
Plus three markdown files at the root, which are the actual magic:
claude.md tells Claude how to work. Small reviewable changes, explain the plan before editing, summarize what changed and what needs human review.
roadmap.md tells it what matters this week. Landing page, waitlist form, demo flow, send Looms to 10 med spa owners. And just as important, what's out of scope: payments, CRM integrations, admin dashboards.
review.md tells it what good work looks like. Can a first-time visitor understand the offer in 5 seconds? Is the CTA visible? Does the page use words customers actually say?
His line on this stuck with me: "Claude gets way more useful when the project explains itself."
You don't even write these files by hand. His setup prompt is one paragraph: help me set up this repo as an AI employee workspace, here's the product, the buyer, the pain, the promise, ask me for any missing context, keep V1 simple. Claude asks a few questions and builds the whole thing.
Plan mode is the brief, tickets are the assignment
The mistake almost everyone makes: vague prompts. "Make this pop." "Add AI." "Build the whole thing."
Once Claude has to guess what matters, Greg says, "you're no longer managing the work. You're cleaning up the work."
So before any meaningful change, he uses plan mode. The prompt pattern: inspect the current app plus claude.md, roadmap.md and review.md, then give me the files that need to change, the smallest clean implementation, the risks, how we'll verify it, and what you're intentionally leaving out of V1. Wait for my approval before editing.
Measure twice, cut once.
Then the ticket. A good ticket has one task, one finish line, one reviewable change. "Add a waitlist form to the landing page. Collect name, email, company. Show a success message after submit. Keep it consistent with the brand." That's it.
He admits Fable 5 has gotten scary good at guessing what you meant. But small tickets aren't about the model's IQ. They're about you being able to actually read the diff and trust what shipped.
The eyes: this is the new part
This is where the episode earns the "new features" title.
Claude Code can now open your app and use it. Not read the code. Use the product, in a browser, like a customer.
Greg's prompt: start the app, open the landing page in desktop preview, check the experience from the perspective of a med spa owner seeing this for the first time. Tell me what the buyer understands in the first 5 seconds, what feels confusing or low trust, whether the form works, what happens after submission. Then make one focused pass on the highest impact issue.
On camera, Claude submits the empty form to test the error state, verifies the success state renders, checks the backend wrote the record, scans the console for errors. Then it comes back with this:
"The page asks a cold med spa owner to hand over their email with no reassurance about what the waitlist is or whether they'll get spam. This is the single biggest friction point."
And it fixes it by adding expectation-setting microcopy at the CTA.
That's not code review. That's a QA person and a conversion consultant in one loop. Greg's take: "It's amazing how few people actually use the eyes."
Review: must fix, should fix, okay to ship
Once Claude builds fast, your bottleneck moves to judgment. Did it solve the right problem? Did it touch files it shouldn't have?
Layer one is your own read of the diff. The question to ask: is there anything surprising in here? Surprising changes are where the risk lives. If the ticket was a waitlist form and the diff touches auth and routing, you want to know immediately.
Layer two is Claude reviewing itself against review.md, sorting everything into must fix, should fix, and okay to ship.
And for the scary stuff, payments, auth, anything production-adjacent, there's /review and its bigger sibling /ultrareview, which spins up a remote deep-review session on your repo before you ship.
Routines: the night shift
This is where people have the aha moment.
Claude Code has a feature called routines: recurring work on a schedule. Greg sets up three.
Morning brief, 7am every weekday. Read /customers and /context, then write a brief with the top customer pain point, one product risk, one recommended build task for today, and one question to ask customers. Under 500 words, no code edits.
Weekly ops review, Friday 3pm. Review open issues and customer notes, group duplicates, suggest the single most valuable fix for the week.
PR review loop. Every time a pull request opens, review it against review.md and post what looks good, what needs attention, and whether it's ready for a human.
Each one took seconds to set up. And notice what he did NOT automate first: shipping production code while he sleeps. He starts with the boring operator work, the reading and summarizing and prioritizing that keeps a company moving. That's the right call.
This is exactly the pattern from Allie K. Miller's 34-agent workforce: the agents that matter most aren't the flashy ones, they're the ones that watch things for you every single day.
Parallel employees and permissions
One employee is nice. The unlock is running several.
In Claude desktop, each session runs with its own context, and worktree isolation keeps the changes separate. Greg's example morning: session one fixes the onboarding redirect bug, session two rewrites the landing page hero so a med spa owner gets it in 5 seconds, session three turns customer notes into a demo script.
Debugging, product copy, sales enablement. Three different jobs, three sessions, same repo brain.
The rule that makes it work: every session hands back a small packet you can inspect, accept, revise, or reject. What you don't want is "a giant pile of AI work at the end of the day that you have to untangle."
On permissions, he splits actions three ways. Safe: reading files, running tests, small branches, draft PRs. Ask first: dependencies, migrations, auth, payments, deleting files. Human-owned: production deploys, customer data, billing, security. Going full yolo mode, in his words, is "a bit too risky."
Skills, connectors and hooks round it out. A skill is any prompt you keep retyping, saved (his examples: a landing page teardown, a customer-notes extractor that pulls exact objections and buying triggers). Connectors plug in GitHub, Linear, Slack, Drive. Hooks run your formatters and tests automatically around every change.
The 7-day plan
If you want to actually try this, Greg's week looks like:
→ Day 1: create the repo brain (the 3 files, the folders)
→ Day 2: run plan mode on one small task
→ Day 3: build one visible improvement
→ Day 4: make Claude click through the app in preview
→ Day 5: review the diff against review.md
→ Day 6: send the demo to 10 real people, put their replies in /customers
→ Day 7: create the morning brief routine
He says you can compress it into 7 hours or stretch it to 31 days. The order is the point, not the pace.
My honest take: this is the least sexy AI video Greg has made, and probably the most useful. No "$100K in 30 days" hook. Just the operating manual. If you've been reading this blog, you've watched founders like Greg's Fable 5 playbook guests circle around this exact idea for months. This episode is the setup doc they all skipped.
FAQ
Do I need to be technical to set this up?
Less than you'd think. Every step in the video is a plain-English prompt, and Claude writes the config files itself. If you can describe your product, your buyer and their pain in a paragraph, you can build the repo brain. The desktop app also keeps you out of the terminal entirely.
What are the three files I should create first?
claude.md (how to work), roadmap.md (what matters this week, plus what's out of scope), review.md (your quality bar). Greg's takeaway applies to every project: Claude gets way more useful when the project explains itself.
What should my first routine be?
A morning brief. It reads your customer notes and open issues, then hands you one pain point, one risk, and one build task per day. It's useful, it's controlled, and it touches zero production code. Save the autonomous shipping for when your review files have earned your trust.
Is this overkill for a solo founder?
It's built FOR solo founders. The whole point is getting the output of a small team without hiring one. You're not managing more work, you're managing smaller, clearer packets of it.
Want more playbooks like this from founders actually running them?
Every week on the Profitable Founder Podcast I sit down with bootstrapped SaaS founders doing $100K to $10M a year and pull out the systems behind the numbers.
Listen to the latest episode