Is it safe to point Claude at our private repo?

For your source, the diff, and stack traces, yes — that's everyday cloud-tool territory, and on Desktop the open folder is the boundary, so Claude only ever sees what you open. The line is secrets and customer data — credentials, tokens, PII, and production data never go in the chat; keep them in env files and your secret manager. Open only the repo the task needs, and approve each read in the "Ask permissions" prompt.

Does Claude merge code without a human reviewing it?

No. A human reads every diff before it lands and is the author of record — treat Claude's output like a PR from a fast, eager junior: usually right, occasionally confidently wrong, never merged unread. Claude drafts; a person reviews, approves, and merges. That review gate is the whole safety model, and it doesn't change because the AI wrote the code.

How do we know a fix is real and not a confident guess?

Make it prove itself. Every fix ships with a test that fails on the old behaviour and passes on the new one — a change without a failing test it turned green is a guess, no matter how convincing the explanation. Wire the test suite, type-checker, and linter so the agent runs your real loop and you can trust the red. Confidence in the prose is not evidence.

Will this replace my engineers?

No. It removes the blank-page and grind tax — the first implementation, the test backfill, the mechanical migration, the codebase tour — so your engineers spend their time on judgment, design, review, and the calls only an accountable human can make. Claude is the fastest junior on the team, tireless and without ego; it has no accountability, so a senior human still owns every merge.

Engineering with Claude: the operating guide

Your team has the Engineering playbooks — the worked systems for mapping a codebase, shipping a feature, backfilling tests, running a migration. Those tell your engineers what to do. This guide is the layer underneath: the operating model that keeps the work reviewed, proven, accountable, and safe while they do it. It’s written for an engineering leader rolling Claude Code out across a team of people who already know how to code — not for a solo experimenter.

The single mistake that turns an AI rollout into an incident isn’t a bad prompt — it’s the absence of a rule about who reads the diff, what proves a fix, and who can answer for the merge. None of what follows is heavy process. It’s the handful of guardrails that let your team move fast because the boundaries are clear.

The operating model: Claude drafts the code, you’re the author of record

Start with the one principle everything else hangs off: Claude drafts; humans decide. It is the fastest junior engineer you’ve ever had — tireless on first implementations, reads, tests, and migrations — and it has no judgment, no accountability, and a habit of being confidently wrong.

So the division of labour is fixed:

Claude does the zero-to-draft work: implement the feature, write the tests, map an unfamiliar repo, run the mechanical migration, assist the review.
A person does the deciding: read the diff, prove the change with a test, approve it, and merge.

A team that internalizes this gets the speed without the risk. A team that forgets it merges a confident wrong change at 5pm on Friday. The playbooks are all built around this line — they take you to a strong draft fast and then hand the judgment back to you on purpose. You stay the author of record: your name is on the commit, so your eyes are on the diff.

On Desktop, the open folder is the boundary — Claude only sees what you open — and the “Ask permissions” prompt asks before each read. That makes the data rule simple to state and easy to follow:

Safe to share: your source repo, the diff under review, stack traces and failing output, your own docs and tickets, and public dependencies.
Keep out of the chat: secrets, credentials, API keys, and tokens; customer data and PII; anything under NDA; and production data. These don’t belong in a prompt, ever.

Two habits make this automatic. First, open only the repo the task needs — a one-file bug fix doesn’t need the whole monorepo and three sibling services in context. Second, keep secrets where they belong — in env files and your secret manager, read at runtime, never pasted into a chat or committed to the repo. The project-context playbook bakes this into your CLAUDE.md: it documents where credentials live so they stay out of context, and it never holds a key itself.

The review-and-prove gate

The fastest way to lose the trust you’re building is to let speed skip the reviewer. So put one gate between draft and merge, and make it explicit:

Every diff is read by a human — the author of record reads it line by line before approving. On Desktop that’s the visual accept/reject diff, so you’re reviewing as it builds, not rubber-stamping a wall of code at the end.
Every fix proves itself with a test that fails on the old behaviour and passes on the new one. A change without a failing test it turned green is a guess. Make the agent show you the red, then the green.
Non-trivial work gets a plan first. Use plan mode to get the approach in prose and read it while it’s cheap — correcting a wrong paragraph costs a minute; unwinding a wrong 300-line diff costs an afternoon.
The agent runs your real loop, and you trust the red. Wire the test suite, type-checker, and linter so Claude sees its own failures and self-corrects. An agent that can see the red is worth ten that can only reason about the code.

This isn’t bureaucracy bolted on — it’s a single named step in the workflow. The code-review and ship-a-feature playbooks run every change through it by construction. And regulated or security-sensitive code clears the usual review, the security sign-off, and the compliance check — not a waved-through “the AI wrote it.”

Who owns what (a light RACI)

Speed dies in ambiguity about who can merge. You don’t need a formal RACI matrix — you need four roles named for any piece of work:

Drafts — the engineer running the playbook with Claude.
Reviews — peers, plus the code owner for the area being touched.
Approves — the tech lead or whoever is accountable for that surface.
Ships / Merges — a person presses merge, owns the result, and can answer for it.

The point is that Claude is never any of these four. It’s the tool the Drafts role uses — not a reviewer, not an approver, and never the name on the merge. Write these four names down once per surface (the service, the package, the area), and most “who approved this?” fire drills disappear. The accountability has to land on a human because the agent has none to give.

Working in two languages: Arabic and English

For a MENA team, bilingual isn’t a translation step bolted on at the end — it’s how the team actually works. The rule that matters: adapt, don’t machine-translate.

Code stays English; the discussion follows the reviewer. Identifiers, function names, and commit subjects stay English — that’s the universal layer every tool and teammate reads. But design docs, ADRs, RFCs, PR descriptions, and review comments are worth writing in the language the reviewer actually reads.
Adapt, don’t translate. Ask Claude to write the ADR or the PR description natively in Arabic, not to translate an English draft — a design doc that reads native in Arabic carries the reasoning better than one that reads machine-translated. Same for the English.
Same gate, both languages. An Arabic design doc or PR description clears the same review as an English one. Don’t let the second language skip the sign-off because nobody on the approval chain reads it — find a reviewer who does. The review-and-prove gate applies whatever language the prose is in; the test suite is language-agnostic and stays the final word.

Treated this way, Arabic is a first-class peer of English in your engineering org, not an afterthought — which, in this region, is what makes the documentation actually get read.

The capability path: from first read to full modernization

The playbooks are arranged as a staged path, not a flat menu, because the later ones genuinely depend on the earlier ones. Run a team through it in order:

Stage 1 — Foundations. The read before any write: map a codebase you’ve never seen, then distill that read into the project context — the CLAUDE.md that grounds every later task in your real conventions and the exact command that runs your tests. Skip these and every later task starts from a guess.
Stage 2 — Repeatable systems. The weekly loops, each behind the review-and-prove gate: debug from a trace, backfill the tests you never wrote, refactor safely behind a green suite, ship a feature end to end, run the code review before a human does, and keep a clean git workflow with logical commits that explain the why.
Stage 3 — Orchestration. The big, multi-file moments that pull every foundation and system together: the mechanical migration, a full subsystem modernization, and taking ownership of an inherited codebase end to end.

On the Engineering team hub the path is laid out stage by stage with a progress bar, and your team can mark each playbook done as they go — so “we’re upskilling the team” becomes a number you can actually see, not a hope. (Progress is tracked on each person’s device; a shared, manager-level team view is the natural next step once you’ve run the path.)

Rolling it out: a 30/60/90 plan

Don’t roll everything out to everyone on day one — that’s how rollouts fizzle. Stage it the same way the path is staged. Here’s the whole arc as a checklist you can copy into your own doc:

30/60/90 — rolling Claude out across an engineering team

First 30 days — Foundations
- Pick 2–3 willing engineers across the surfaces that matter most.
- Build the repo CLAUDE.md: architecture, the real dev commands, conventions.
- Agree the one-page guardrail: what's safe to share, who merges.
- Each engineer runs a first Stage-1 playbook end to end (map + context).

Days 30–60 — Repeatable systems
- Put the weekly loops on Claude: debug, tests, refactor, ship, review, git.
- Capture the prompts that work into CLAUDE.md and slash commands.
- Name the four RACI roles per surface: drafts / reviews / approves / merges.

Days 60–90 — Orchestration
- Run one real modernization or migration end to end through the playbooks.
- Stand up the review-and-prove gate as named steps: read the diff, prove
  the fix with a test, plan mode on non-trivial work, regulated code reviewed.
- Review the capability path: who's completed which stage, where the gaps are,
  and which seats to add next.

The urge to mandate it for everyone at once is the urge to resist. Adoption is a habit that spreads, not a switch you flip. Start a few engineers on the foundations, give them the repo CLAUDE.md and a one-page rule, let them capture what works — and by day 90 you have a team that’s run a real migration through the system, a review-and-prove gate everyone trusts, and the proof you need to widen it. The general team rollout playbook goes deeper on the cross-role mechanics when you’re ready to scale it past engineering.