Claude Code as an AI Employee: A Controlled 9-Step System

Direct Answer

To make Claude Code behave more like a reliable employee, do not give it a bigger prompt. Give it an operating system: a bounded workspace, durable project instructions, a reviewed plan, one ticket with a definition of done, a way to see the result, layered review, a schedule, isolated branches, and explicit permissions.

That is the useful core of Greg Isenberg's walkthrough. The phrase "AI employee" is still a metaphor. Claude Code does not own outcomes, understand your business by default, or become accountable because it can run longer. Reliability comes from the management structure around the model.

Watch Greg Isenberg's Claude Code Walkthrough

Creator credit: Greg Isenberg. Watch the original video on YouTube. Greg states that Claude and Anthropic sponsored the episode, so product claims below are checked against Anthropic's current documentation rather than treated as independent evaluation.

What the Current Product Actually Supports

The Nine-Part AI Employee Contract

Build the Repo Brain

Greg demonstrates the system around a missed-lead responder for med spas. The reusable part is the information architecture, not the specific startup idea:

/app          # Product code
/context      # Market, users, decisions, approved research
/customers    # Interview notes and feedback with dates and consent
/spec         # Tickets, acceptance criteria, and product decisions
/demos        # Test scripts, screenshots, and buyer-facing examples
/routines     # Scheduled prompts, outputs, and runbooks
CLAUDE.md     # Project instructions and working conventions
ROADMAP.md    # Current outcome, priorities, and out-of-scope work
REVIEW.md     # Quality, risk, and verification checklist

The transcript's automatic captions call the root file "claw.md." The actual Claude Code convention is CLAUDE.md. Anthropic recommends keeping it concise, specific, and structured. It is loaded as context, so a sprawling company handbook consumes tokens and can reduce adherence.

A practical CLAUDE.md should answer: what are we building, who is it for, what commands prove it works, what patterns already exist, what files are sensitive, what must never happen automatically, and what summary is required at handoff.

Plan First, Then Issue One Ticket

Plan Mode creates a useful pause between understanding and implementation. Claude can inspect the repository and propose an approach without editing source. Ask it to return the smallest implementation, affected files, user flow, risks, verification steps, and deliberate exclusions. Then review the plan before changing modes.

After approval, convert the plan into one ticket. "Improve onboarding" is not a ticket. "After a missed call, create a reviewable draft reply within 60 seconds, show the source lead and opt-out state, and never send without approval" is closer because its finish line can be observed.

Every ticket needs scope, user state, happy path, failure path, prohibited actions, acceptance criteria, test commands, preview steps, and the artifact Claude must return. One ticket at a time limits blast radius and keeps the diff understandable.

Give Claude Eyes, Then Review in Layers

Desktop Preview closes a real gap: Claude can start the app, inspect the rendered interface and console, click through a flow, and respond to visual feedback. For a buyer-facing feature, ask for a short evidence report:

• URLs and viewport sizes tested
• Exact path clicked from entry to completion
• Console warnings and errors
• Empty, loading, failure, and retry states
• What a first-time buyer would see and misunderstand
• Screenshot or recording for the acceptance state

Then review in layers. First, Claude checks its change against REVIEW.md. Second, inspect the local diff. Third, run deterministic tests and static checks. Fourth, use a fresh reviewer or separate session for higher-risk changes. Fifth, a person accepts the real workflow.

The fresh reviewer matters because self-review shares assumptions with the author. Even a separate model review is not proof by itself; it should produce specific findings tied to files, behavior, or failed checks.

Choose Local Schedules or Cloud Routines Deliberately

Anthropic now documents two recurring paths. A local scheduled task runs on your machine and can reach local files and tools, but the desktop app must be open and the machine awake. A cloud routine runs on Claude Code's web infrastructure and can be triggered by a schedule, API call, or supported event without relying on your laptop.

That distinction determines the security and reliability design. Local work inherits the machine's access. Cloud work requires the repository, connectors, and environment to be available remotely. Neither should begin with broad write authority.

Record run time, model usage, accepted outputs, false alarms, failures, and reviewer minutes. A routine is only an employee-like capability when someone owns its missed runs and bad decisions.

Parallel Agents Need Worktree Isolation

Git worktrees give each session a separate checkout and branch. Claude Code's CLI supports the --worktree flag, while the desktop app creates a worktree for new sessions automatically. This prevents two agents from casually overwriting the same working files and makes each assignment reviewable.

Use parallelism for independent work: one session builds the feature, one investigates customer evidence, and one reviews tests. Do not split a tightly sequential change merely to create activity. Parallel sessions multiply token use and coordination overhead.

Write Three Permission Tiers

Claude Code's permission modes are helpful baselines: Plan Mode is read-only exploration, default mode asks before edits and commands, accept-edits mode reduces file-edit prompts, and more autonomous modes require stronger environmental controls. Anthropic explicitly warns that bypassing permissions offers no protection from prompt injection or unintended actions and should be limited to isolated containers or virtual machines.

Use Skills, Connectors, and Hooks for Different Jobs

• Skills: package an on-demand procedure such as writing a ticket, reviewing a diff, or preparing a demo. They are better than stuffing every workflow into CLAUDE.md.
• MCP connectors: give Claude access to external tools and data. Each connector needs least-privilege scopes, an owner, test data, credential rotation, and a list of prohibited actions.
• Hooks: run deterministic actions at lifecycle events. Use them for formatting after edits, blocking dangerous commands, running checks, or requiring evidence before handoff.

Hooks are the strongest fit for rules that should happen consistently, but configuration still matters. A hook that merely prints a warning is not enforcement. Test its event, condition, exit behavior, failure mode, and scope. Keep organization-wide controls in managed settings where possible.

Close the Operating Loop

1. Customer evidence enters /customers with date, source, and permission.
2. The human updates the current outcome and exclusions in ROADMAP.md.
3. CLAUDE.md supplies stable project conventions; REVIEW.md supplies the quality bar.
4. Plan Mode proposes the smallest useful change.
5. One approved ticket defines done.
6. A worktree session implements and verifies the change.
7. Desktop Preview checks the buyer-visible experience.
8. Diff, tests, an independent review, and a human gate decide acceptance.
9. A proven repeated task becomes a routine with narrow permissions and a run log.

Measure accepted-result rate, human review minutes, escaped defects, routine reliability, cost per accepted ticket, permission exceptions, and rollback success. Lines of code, number of sessions, and hours spent running are activity metrics, not business outcomes.

A Seven-Day Rollout

Video Chapters

Final Verdict

Greg Isenberg's strongest idea is to onboard Claude Code the way you would onboard a capable new hire: give it a place to work, the context to understand the job, one clear assignment, a way to inspect the result, and boundaries around authority.

The mature version is less romantic and more useful. The repository is the shared record. The plan is a change proposal. The ticket is a contract. Preview is evidence. Review is layered. The routine has an owner. The worktree limits collisions. Permissions keep consequential decisions human-owned.

Build that loop before trying to build a 24/7 workforce. One accepted ticket with a trustworthy evidence trail is worth more than ten autonomous sessions producing work nobody can safely approve.

Sources and Credits

• Greg Isenberg: Claude Code New Features, Explained (Anthropic-sponsored episode and attached transcript)
• Anthropic: How Claude remembers your project
• Anthropic: Claude Code permission modes and Plan Mode
• Anthropic: Preview, review, and merge with Claude Code
• Anthropic: Schedule recurring tasks in Claude Code Desktop
• Anthropic: Introducing routines in Claude Code
• Anthropic: Run parallel sessions with worktrees
• Anthropic: Extend Claude with skills
• Anthropic: Connect Claude Code to tools through MCP
• Anthropic: Automate workflows with hooks
• Idea Browser (the med-spa missed-lead example source referenced in the episode)