If you're still writing code line by line while Claude Code sits idle — or worse, treating it like a glorified autocomplete — you're working two levels below your new job title. The moment you started using Claude Code effectively, you stopped being an individual contributor. You became a Director of Engineering with a Chief Architect's taste for how systems should fit together.
The problem is that nobody told you. So you're still prompting like a developer instead of directing like an executive. Here's the system I use to ship merge-ready features in a single session — the same system we use to build TurboDocx's API and SDK. It works because it treats Claude Code the way high-functioning engineering orgs actually work: with clear roles, a defined chain of command, and specialists who each own their lane.
You Got Promoted. Act Like It.
Here's the mental model that changed everything for me:
You
Director of Engineering & Chief Architect. You own the product vision, the technical direction, and the acceptance criteria. You decide what gets built and why. You set the quality bar. You don't write implementation code — you write requirements, review output, and make judgment calls.
Claude Code
Your Engineering Manager. It takes your direction, asks clarifying questions, studies the codebase and documentation, builds an execution plan, and coordinates the work. It doesn't need you hovering over every function signature. It needs clear intent and room to operate.
Tools & Plugins
The Development Team. Your skills, Context7, Chrome MCP, code reviewer — they're the specialists. One handles frontend polish. Another handles documentation lookups. Another runs the code review checklist. They execute. The Engineering Manager orchestrates them.
“Directors direct, managers manage, engineers engineer.”
— An old VP I worked with
If this sounds familiar, it should. Garry Tan — Y Combinator's CEO — independently built the same role-based hierarchy into gstack, a set of six Claude Code skills that map CEO, Eng Manager, Staff Engineer, and Release Engineer roles onto AI agents. When the person running the world's most influential startup accelerator arrives at the same mental model independently, it's not a coincidence — it's convergent evolution. I wrote a full breakdown of gstack and how it compares to our workflow.
This isn't a metaphor you paste into a prompt. It's a shift in how you think about the work. When you internalize this hierarchy, you stop micromanaging implementation details and start doing the thing that actually matters: setting clear direction and reviewing output with sharp judgment. It's the same principle behind how we approach our open-source projects — clear ownership and separation of concerns compound over time.
The Four Steps
1Write the Brief, Not the Code
Your first job as Director is to write a feature brief. Not pseudocode. Not implementation hints. A real brief — the kind you'd hand to a senior engineering manager and expect them to run with.
Include the user problem you're solving, the acceptance criteria, any design constraints or preferences, and how the feature integrates with existing systems. Be specific about what “done” looks like.
“Add a document signing workflow to the TurboDocx Templating preview. Users should be able to drag and drop signature fields directly onto the template preview, and generate the signed document in one step — combining the templating and signing workflows. This should use our existing auth layer, follow the TurboDocx component patterns, and work with the Document clone workflow too. Success means a user can place fields and sign a document in under 60 seconds without leaving the template preview.”
Notice what's not in there: no file names, no function signatures, no “use React hook X.” You're setting the target, not drawing the flight path. That's the Engineering Manager's job.
Before you hand off the brief, make sure your toolkit is stacked. Load the skills and plugins that match the work — feature development, frontend design, documentation lookup, code review. Your manager is only as good as the team behind them. This is also where a well-structured CLAUDE.md pays for itself — it gives your Engineering Manager the codebase context it needs to make smart decisions without you spelling out every convention.
2Hand It Off and Let the Manager Work
Run /batch with your brief and explicitly frame the delegation:
/batch [Your detailed feature brief] Use the feature development skill, frontend design skill, and existing codebase rules. Dive into CLAUDE.md and our project docs. Ask me clarifying questions before you start building.
Here's what happens next — and it's the part most people skip because they're impatient.
Claude Code doesn't immediately start writing code. It reads your project documentation. It studies your CLAUDE.md. It maps your requirements against existing patterns in the codebase. Then it comes back with questions.
Why the questions matter
These questions are scope clarification. They're the Engineering Manager saying “Before I send the team off to build this, I want to make sure we're aligned on these three things.” This is where ambiguity gets caught. This is where scope creep gets killed before it costs you hours.
Answer the questions. Refine the scope if the questions reveal gaps in your brief. Then let the manager execute.
3Run the Review Before You Think You're Done
Once Claude Code delivers the implementation, you're going to feel done. You're not. This is where most people ship bugs.
Run /simplify.
This triggers a multi-agent review — three specialists looking at the code from different angles. An efficiency pass catches unnecessary iterations, missed concurrency opportunities, and redundant logic. A correctness pass finds logic errors, integration issues, and missing edge cases. A maintainability pass ensures the code is readable and consistent with your project patterns.
What makes this powerful is that /simplify reads your CLAUDE.md, project rules, documentation references, and imports to evaluate code against your actual project conventions — not generic best practices. It reviews with the same context your Engineering Manager used to build the feature.
In my experience, this catches three to five issues per feature branch that would otherwise slip through. These aren't cosmetic issues. They're the kind of bugs that show up in production two weeks later when a user hits an edge case you didn't test.
Think of it this way
/simplify is the senior staff engineer who reviews every PR before it ships. You wouldn't skip that review in a real org. Don't skip it here.
4Test Like a Human, Then Run Final Review
Now you put on the QA hat. Run the feature. Click through every flow. Try the edge cases. Try to break it. Do the things an automated test won't catch — does it feel right? Is the UX intuitive? Does it handle the sad path gracefully?
If you find issues, run another /batch with your feedback. Be specific: “The signature placement doesn't snap to the field boundary on mobile viewports. Fix the touch event handling so it aligns within 2px of the target.” Director-level feedback. Not “it's buggy.”
Once you're satisfied, run the code review skill for a final pass:
/code_review Deep review this PR before merge. Focus on security, performance, and standards compliance.
This is the last gate. It catches the things that /simplify isn't designed to find — security vulnerabilities, performance regressions, API contract violations. It's the difference between “it works” and “it's production-ready.”
Why This System Works
It mirrors how real engineering organizations operate. Directors don't write code. Managers don't set product strategy. Engineers don't decide what to build. Each role has a lane, and the system breaks when roles bleed into each other. Most people using Claude Code are playing all three roles simultaneously, which is why their output is inconsistent.
The batch command is orchestration, not generation. /batch isn't a fancy autocomplete. It's a delegation framework. When you pair it with a detailed brief and give Claude Code space to think before building, you eliminate the rework that comes from ambiguous requirements. That rework is where 80% of wasted time lives.
Review before you feel ready. /simplify before every PR should be reflexive. You can't objectively review your own work after hours of focused implementation — neither can your Engineering Manager. The multi-agent review provides the fresh perspective that catches what both of you missed.
You're working with the tool's strengths. The least efficient way to use Claude Code is prompt → get code → iterate when it's wrong. That's a developer workflow grafted onto a management tool. The most efficient way is brief → delegate → review → ship. That's a Director's workflow, and it's what the tool was built for.
One More Thing: Isolate Your Context
If you're running multiple features, use git worktrees to isolate each one:
git worktree add ../project-feature-name -b feature-name cd ../project-feature-name claude
Each worktree gets a fresh Claude session with no context bleed from previous features. It's the equivalent of assigning each feature to a different team — they don't interfere with each other, and each one gets your Engineering Manager's full attention.
The Playbook: TLDR
Here's the full system, end to end:
YOU — Director Mode
Write the feature brief. Define the problem, acceptance criteria, and constraints.
/batch — Manager & Delegation Mode
Hand off the brief. Answer clarifying questions. Refine scope.
/simplify — Engineering Peer Review Mode
Multi-agent review for efficiency, correctness, and maintainability.
HUMAN — Acceptance Testing & Baseline QA
Test the feature manually. Click through every flow. Try to break it.
/code-review — Final Gate QA & Security Engineering
Deep review for security, performance, and standards compliance.
SHIP IT
Draft the PR. Merge.
Total time: 45 to 90 minutes
For a feature that's genuinely merge-ready. Not “it compiles” ready. Not “it works on my machine” ready. Merge-ready.
The Shift That Matters
The bottleneck in AI-assisted development was never the model. It's how you position yourself relative to the model.
If you're writing prompts that say “write me a function that does X,” you're an individual contributor using an expensive autocomplete. If you're writing briefs that say “here's the problem, here's what done looks like, here are the constraints — go figure out the implementation,” you're a Director of Engineering with an Engineering Manager who never sleeps, never forgets your codebase rules, and has a team of specialists on call. Whether you're building document generation APIs, workflow automations, or internal tools — the system is the same.
You got promoted. The tools are waiting. Start directing.
Related Resources
How to Write a CLAUDE.md That Actually Works
Best practices for structuring your Claude Code context file — the foundation that makes this entire workflow possible.
The Developer's Guide to CLAUDE.md
Comprehensive reference covering file types, @imports system, structure patterns, and comparisons with other AI config files.
API Integration Best Practices
Production-ready patterns for authentication, error handling, webhooks, and rate limiting.
Best Claude Code Plugins, Skills & MCP Servers
The 7 tools that power this workflow. What each one does, when to reach for it, and how they fit together.
Ship Features Faster with TurboDocx
The same workflow that powers this blog post powers our product. See how document automation and e-signatures can accelerate your team.
