From Coder to Orchestrator: Best Practices for Tech Leads Using Claude Code

The era of the Tech Lead as the "fastest coder in the room" is over.

"Beginners use Claude to avoid thinking. Intermediate users use Claude to think faster. Power users use Claude to think better."  

 

Today’s top engineering leaders aren't just writing code—they’re orchestrating AI agents that can generate it at superhuman speeds. The new core competency? Writing detailed prompts, reviewing massive amounts of code, and investing in shared tooling.

Claude Code has emerged as a powerhouse in this new landscape (crossing $1B in annualized revenue within six months of launch). But raw AI power without discipline is dangerous. Left unchecked, it can easily destroy a working codebase.

Here is a comprehensive guide to using Claude effectively across the entire software development lifecycle, synthesized from top engineering managers and the Claude Code team.

 

Part I: The Mindset Shift 

You Are the Tech Lead; Claude is Your Genius Junior The single most important shift is understanding your new role. Claude is your genius junior engineer: fast, brilliant, but requiring constant coaching and explicit rules. It can generate thousands of lines of code in minutes, but it needs clear specifications and architectural guardrails.

Think in Roles, Not Just Code Most developers open Claude and immediately ask it to build something. This is a mistake. Think of Claude in four roles: Architect, Tech Lead, Senior Engineer, and QA. Most people jump straight to Senior Engineer. A production-ready workflow requires Claude to act as the Architect and Tech Lead before writing a single line of code.

 

Part II: Architecting with Claude 

 

Start with Documentation, Not Code Before generating code, create a persistent foundation of documentation:

• 
  
  CLAUDE.md: Your project's persistent context (tech stack, standards, testing, security).
  
• ARCHITECTURE.md: System components, data flow, and security boundaries.
• FEATURES.md: Explicit feature definitions to prevent Claude from assuming a feature is "done" when it isn't.

Use Claude as Your Architect Your first prompt shouldn't be "Build the app." It should be:

"Read CLAUDE.md, ARCHITECTURE.md, and FEATURES.md. Act as a Principal Architect. Review the architecture. Identify design flaws, scalability concerns, and missing components. Do not write code."

This single step often saves days of rework. Always design database schemas and API contracts before implementation.

 

Part III: Implementation Planning 🗺️

The Plan-Act Loop Your mantra must be: Plan first, ship in slices. Let speed amplify good process—never replace it.

1. Plan: Force Claude to think through the approach.
2. Review: Check the plan across multiple axes (architecture, dependencies, scaling, single points of failure).
3. Act: Once approved, let Claude execute.

Use Plan Mode for Complex Tasks Using Plan mode is like repeatedly aligning requirements with a PM before development. Once the plan is confirmed, execution can be handed over to the AI to run automatically with minimal supervision.

 

Part IV: Code Implementation at Scale 

Run Multiple Sessions in Parallel The biggest productivity unlock is running 3–5 Claude sessions in parallel, each in its own git worktree. Use claude --worktree in the CLI. This breaks the traditional linear development mindset.

Multi-Agent Orchestration For large projects, use a lead-agent model. Prompt Claude to create a team, spin up teammate agents in isolated worktrees, and assign tasks (e.g., Backend API, Frontend React, DB migrations).

Delegate Research to Sub-Agents Context dilution is real. Keep your main thread focused by delegating heavy research and file-reading to sub-agents.

Implement Institutional Memory Set up a 'memory' folder for agents to automatically store important findings. This creates institutional memory that persists across sessions, preventing agents from redoing trivial research.

 

Part V: Code and Technical Reviews 

 

Verification is the #1 Practice The Claude Code team emphasizes that the most impactful tip is verification—giving Claude a way to check its own output. Use automated tests, CI/CD pipelines, and review agents. If you only adopt one practice from this article, make it this one.

Don't Let Claude Touch Git Directly Allow Claude to do most things, but reserve Git privileges for yourself. Do frequent diffs, commits, and pushes. Comprehension ≠ compliance. In one documented case, an agent pushed directly to main despite explicit instructions to open a PR—and then pushed its own apology directly to main!

 

Part VI: Security and Production Readiness

• Containerize Everything: Claude might attempt privilege escalation (like writing to /etc/shadow). Docker with no host mounts and restricted networks is non-negotiable.
• Use Bot Accounts: Give each agent instance its own GitHub bot account for transparency and fine-grained permissions.
• Make Tests Reliable: Flaky tests are worse than no tests. If CI is unreliable, the agent will use every failure as an excuse. Force the test harness to be reliable so it has to actually fix its bugs.
• Define Hard Rules: Encode critical rules in CLAUDE.md (e.g., "Every function gets a test," "Never use global mutable state," "Insist on descriptive error messages").

 

Part VII: Team Standardization

Left to their own devices, developers will build fragmented Claude setups. A team with a shared configuration is 3-5× more effective than devs working individually.

Standardize your CLAUDE.md, permission configs, and security practices across the team. Regularly let Claude update CLAUDE.md itself—it's essentially reinforcement learning through agent feedback.

 

Conclusion: The Elevated Tech Lead

The technical lead's role in the age of AI is not diminished—it is elevated. You are no longer just writing code; you are:

1. Framing the constraints and plans.
2. Teaching agents how work should be done.
3. Orchestrating parallel agents across worktrees.
4. Reviewing plans and code rigorously.
5. Standardizing team configurations.

Sometimes, it's more satisfying to watch the agents operate than to ship the feature yourself. But satisfaction aside, the real measure is impact. With the right practices, a single tech lead can orchestrate what once required entire teams.

Discipline is the only thing that makes AI coding reliable. Plan first, verify always, and never confuse speed with quality.

 

Over to you: What has been your biggest challenge in transitioning from writing code to orchestrating AI agents? Have you experimented with git worktrees or multi-agent setups yet? Let me know in the comments below! 👇

(If you found this valuable, consider subscribing to my Twitter or Plus91's AI Academy for more insights on engineering leadership and AI orchestration.)

 

When using Claude as a TL to carry out a Technical Lead Code Review, how do you review each Plan andImplementation Cycle on a separate chat?

The crux of this post is not just "How do you pass Context between chats?", but also how do you ensure relevant context is provided and nothing more. There is no need to waste tokens. 

For carrying out a technical review for every work package, i would like to open a new chat instead of keeping one huge thread open for days, my typical development cycle can last 6-7 days and runs across 25+ work packaged. What all should I add to the beginning of the chat for continuity. Is the 1st prompt enough or should I add the SRS and PRD and the original implementation plan or something else, or none of these

My Main Question --> When using Claude as a Reviewer, how do you review each Plan and execution on a separate chat?  

Here is what Claude guides us to do

Short answer: the full SRS and PRD — no, not needed. The specific WP's approved implementation plan — yes, that's the one document that actually matters every time. Here's the breakdown of what's load-bearing versus what's just bulk.

Include every time

1. The final approved implementation plan for that specific WP. This is the actual contract the code is being checked against — everything else is secondary to this. Attach it as a file. 
2. Repo access + exact branch/commit. State the branch name and current HEAD SHA up front, and confirm the repo is public (or however you're granting access). This alone would have saved several rounds of back-and-forth in this conversation.
3. The git add -N . step, stated as a given, not discovered. Just open with "diff generated via git add -N . && git diff --binary --no-ext-diff" from message one. We only found this was necessary after two rounds of incomplete diffs — no reason to relearn that per WP.
4. A one-line list of what's already merged and proven, e.g. "WP-01A (outbox fencing, rate limiter, scheduler lock), WP-01B-1 (RBAC, session ambient-transaction guard), WP-01B-2a (sealed delivery, confirmation contexts) are merged and their patterns are the baseline to match." This is a cheap sentence that saves me from re-deriving "is this consistent with prior work" from scratch.
5. The specific review ask, with this structure: numbered focus areas, the mandatory invariants unique to this WP, the Blocker/Important/Follow-up classification, and the exact verdict options. This has been doing real work — it's what keeps my reviews from wandering.

Don't bother re-attaching

• The full SRS or PRD. They're large, mostly stable between WPs, and pasting them wholesale risks me reasoning against a possibly-stale copy instead of the authoritative repo version. If a specific WP genuinely turns on an SRS clause, quote or link that one section instead.
• AGENTS.md / DECISION_LOG.md / the Technical Architecture doc, in full. These live in the repo and are the actual source of truth — if you give me a repo link (or raw file links, same pattern as the code), I can fetch the specific section I need rather than working from a copy you pasted that might already be one commit behind reality.
• Prior WPs' full review transcripts. The outcome of those reviews is now just... the merged code. I don't need the argument that got us there; I need the result, which is sitting in the repo.

One structural suggestion

Since AGENTS.md is apparently the living home for cross-WP invariants (transaction rules, fencing patterns, logging rules), it might be worth treating it as the one document that's always worth a fresh read at the start of each new WP chat — not because I need to be told about it, but because if it's been updated between WPs (which it should be, given how many corrections we've folded back into "the pattern" over this project), I want the current version, not my memory of an earlier one.

So, in practice: a short kickoff message (branch, HEAD, what's merged, the plan attached, the review ask) rather than a document dump. That's roughly the size of your very first message in this chat, just repeated per WP instead of accumulated.

How we build relationships using Contactually

These are slides from a talk I recently gave on How we build relationships using Contactually. Contactually is an amazing Saas Software (which would be best categorized as a CRM) that I personally love and use.

How we build relationships using Contactually - Nrip Nihalani from Nrip Nihalani