Coding Agent Playbook: Specifications, Risk Gates and Task-Based Model Routing

A coding agent can produce a large patch before a human has finished deciding what the feature should do. That is not automatically a productivity gain. It can simply move the queue from implementation to clarification, testing and review.

Two contributions approach that problem from different sides:

• Tharwat Samy’s video asks what developers should be responsible for as coding agents do more implementation. Its practical advice covers specifications, fundamentals, reviewing generated code, permissions and coordinating agents. [1]
• Omar M. El Monayar’s post argues for assigning the right model and execution route to each task rather than using the heaviest model everywhere. His shared Claude Code Efficiency Playbook turns that idea into a proposed classify → route → execute → verify → measure loop. [2][3]

Below are ten practical tips, with a starter task brief you can use. This is my synthesis and engineering application of those sources, not a transcript or a claim that I installed the shared system.

What I could actually read and inspect

I retrieved the approximately seven-minute Facebook video, its Arabic automatic captions and sampled video frames. I also cross-checked the closing advice using a separate local automatic speech-recognition pass. Both transcripts contain recognition errors; the timestamps below are approximate navigation aids, not certified quotations.

The second Facebook post was readable, and the Drive attachment downloaded successfully as claude-code-efficiency-playbook-3.md. It declares runtime version 2.1.2 and includes an installer payload. It must be treated as software to inspect, not as harmless prose to execute automatically. [2][3]

I performed a static extraction and syntax check: 42 path-tagged embedded blocks were identified; 16 Python blocks parsed as Python and five JSON blocks parsed as JSON, with no parsing errors in those categories. That is not a runtime test, a security audit or proof of valid Claude Code integration. I did not run the embedded installer, create its hooks, execute its tests, purchase model calls or reproduce its benchmark claims.

The static inspection record preserves the scope and attachment checksum. The original file remains linked in Sources; I am not redistributing the full third-party payload.

1. Write the acceptance brief before asking for code

From the video, around 04:57–05:40: specify the desired behavior, edge cases, what must not change and how success will be checked. [1]

Replace this:

Add CSV export to the dashboard.

With a small brief:

Goal: Export the rows matching the user's current dashboard filters.

In scope:
- Use the same filters, sorting and permissions as the visible list.
- Preserve the agreed column names and date/time convention.
- Handle an empty result and non-ASCII text explicitly.

Do not change:
- Authorization rules, billing logic or unrelated dashboard behavior.
- Production records, deployment configuration or secret files.

Acceptance evidence:
- Tests cover authorized and unauthorized access.
- Tests cover changed filters, empty results and CSV escaping.
- A reviewer checks the diff and the generated example output.

Stop and ask:
- If the permission model or expected date/time behavior is ambiguous.

This is my example, not a promise that the supplied playbook will infer these requirements. The point is to make assumptions reviewable before they become a large patch. Claude Code’s official guidance likewise emphasizes giving the agent a way to verify its work. [4]

Download the starter brief, adapt it to your repository and replace generic acceptance descriptions with its actual test commands.

2. Give the agent a task-shaped context, not a repository-shaped dump

From the video, around 02:21–02:40: the agent does not hold an entire project in active attention simply because it can access the filesystem. [1]

My practical context packet contains:

• The entry point and related implementation paths.
• The relevant interface, schema or contract.
• The closest existing test and the command that runs it.
• Constraints that cannot be discovered reliably from code alone.

Ask the agent to identify downstream callers and consumers before changing a shared contract. If a search is inconclusive, the next step is targeted investigation—not a confident guess.

For a long task, hand off a short record of decisions, changed files, failing checks and remaining questions. The playbook uses a dedicated handoff artifact rather than treating a growing chat as durable project state. Its suggested context percentage is an operating heuristic, not a universal point at which every model loses reasoning ability. [3]

3. Learn the fundamentals needed to challenge the patch

From the video, around 05:40–06:10 and 06:33–06:45: fundamentals and understanding generated code remain important, especially for juniors. [1]

For the CSV example, useful questions include:

• Is permission checked on the server, or only by hiding a button?
• Can changing filters export data outside the intended scope?
• How are time zones, commas, quotes, newlines and spreadsheet formulas handled?
• Does the implementation load an unbounded dataset into memory?
• What happens when a request fails halfway through?

You do not need to reject AI assistance to learn. Use it to explain a change, then verify the explanation against code and tests. Ask what would break if a condition were removed. If you cannot explain a consequential line, “the agent wrote it” is not an acceptance criterion.

4. Restrict capabilities before improving prompts

From the video, around 02:40–02:49 and 06:10–06:28: agents can act through tools, so define what they can touch and when a human must approve a sensitive action. [1]

Use repository-scoped access, disposable data and an appropriate sandbox. Keep production credentials out of the task environment. Separate routine edits and tests from publishing, destructive database operations, permission changes and external messages.

OWASP treats excessive autonomy, tool abuse, indirect prompt injection and high-impact actions as distinct agent-security concerns. A friendly instruction to “be careful” does not replace access controls or approval enforcement. [7]

The shared playbook proposes hook guards and native permission rules, but its own caveats matter: regex filtering is not a complete security boundary, permission bypass modes weaken the design, and a locally saved waiver is not cryptographic proof of who approved it. Those limitations should not disappear when the file is summarized into a social post. [3]

5. Use a search or script before paying for more reasoning

From Omar’s post and the playbook: do not send a simple lookup through an elaborate orchestration chain when a deterministic tool can answer it. [2][3]

Examples:

• Locate a symbol with repository search.
• Validate JSON with a parser.
• Compare output against a known fixture.
• Run a targeted test instead of asking a model whether the code “looks correct.”

A model is valuable for ambiguity, synthesis and choosing a next investigation. It is not the most economical substitute for every calculation, search or repeatable transformation.

This also avoids a common false economy: using a smaller model to perform a task that should not need a model at all.

6. Route by uncertainty and consequence—not model prestige

Omar’s useful idea is role-based routing, not a permanent ranking of model brand names. His post explicitly notes that capabilities change with updates. [2]

A practical routing scheme is:

• Known, mechanical change: direct execution with a targeted check.
• Bounded implementation with a settled plan: an implementation-capable model and the relevant tests.
• Unclear architecture or difficult debugging: invest more reasoning in diagnosis and planning first.
• Authentication, money, migrations or shared contracts: use stronger review requirements regardless of how short the patch looks.

The file’s T/S/M/L/X classes are one proposed policy. File counts, prompt keywords and estimated size help with a first pass; they cannot fully determine business risk. The classifier emits a suggested route; it does not independently switch models or launch the complete workflow. The orchestrating model still has to follow or override that advice. [3]

I am not publishing its named model assignments as proof that one family is always best for exploration and another always best for review. Verify availability, host support and performance on your own tasks. The document is Claude Code-specific; its author describes other-host editions as future work, not delivered compatibility. [2][3]

7. Bound parallel work and repair attempts

From the video’s closing section, around 06:24–06:37, extended by the playbook: separate roles, but do not assume more agents always improve the result. [1][3]

Parallelize independent work: for example, one read-only investigator maps callers while another examines test coverage. Avoid giving two builders overlapping files without isolation and an integration plan.

The shared configuration uses two parallel agents and two repair attempts as defaults. Those are policy choices, not scientifically optimal constants. In the inspected implementation they mainly guide the model: they are not a hard concurrency semaphore, comprehensive retry counter or guaranteed spending cap. Each worker loads instructions and context, consumes model usage and produces a result the parent must inspect. Official subagent documentation confirms that separate contexts still count toward usage limits. [3][5]

When a check fails, return its exact failure and the minimum relevant context to the responsible worker. After the repair budget is exhausted, revisit the plan or escalate. Repeating the full route indefinitely is neither verification nor cost control.

8. Bind “passed” to the current revision and a real check

The most useful implementation detail in the playbook is not the model router. It is the attempt to tie gate results to the code revision and gate configuration so that later edits make old evidence stale. There is a limit: its Git-mode fingerprint uses names and modification times for untracked files, rather than hashing all their contents. It is not complete filesystem-content attestation. Gate bookkeeping also does not itself guarantee that the model obeys the workflow or refuses to announce completion. [3]

My acceptance record would include:

Task:
Revision / worktree state:
Required checks and commands:
Actual exit status:
Behavior/output inspected:
Reviewer and blocking findings:
Anything not run:
Changes made after the checks:

A successful syntax parse does not equal a passing unit suite. A passing unit suite does not equal a verified deployment. A model’s report does not equal the underlying tool output.

Likewise, a hook showing that a reviewer ran does not prove independent or correct review—a limitation the playbook acknowledges. Give the reviewer the acceptance brief and diff, ask it to challenge assumptions, and resolve blocking findings. Humans still own high-impact decisions. [3]

Prompt guidance and CLAUDE.md are useful, but they rely on model compliance. Hooks and permission settings are different mechanisms with their own semantics and failure modes; check the current host documentation instead of assuming a Markdown rule is an enforced gate. [4][6]

9. Measure completed work, not attractive token totals

Omar’s proposed loop ends with measurement and optimization. The attachment makes an important distinction between measured, derived, estimated, partial and unavailable data. [2][3]

Track at least:

• Whether the task met acceptance criteria.
• Total model use, including parent, workers, retries and review.
• Wall-clock completion time and human review effort.
• Cache usage and model-specific prices where applicable.
• Missed telemetry and uncertain attribution.

An API-equivalent estimate is not a subscription invoice. A missing price is not zero. A context-window percentage is not cumulative token consumption. Fewer generated tokens do not prove a cheaper correct result if retries or manual repair increased.

The playbook’s own specification says that a savings percentage should come from comparable benchmark runs, not telemetry alone. I did not run those benchmarks, so I make no percentage-saving claim for this attachment. [3]

10. Turn repeated lessons into a small, maintained workflow

The goal is not to paste a huge operating manual into every conversation.

Keep a concise project instruction file, link specialized procedures when needed, and promote a repeated successful workflow into a script or skill. Save the failure lesson with its scope: which assumption failed, which evidence caught it and when the rule applies.

The playbook separates a short kernel from routing policy, agent definitions, scripts and reports. That is a reusable design idea. It also means the supplied Markdown is an installer specification with executable payloads, not merely a collection of tips. [3]

Before trying it, inspect its proposed edits, back up existing assistant settings and evaluate it in a disposable project. Check the host’s actual events and model aliases. Do not grant global access because an attachment tells an agent to do so. This article is not an installation instruction or an endorsement of unrestricted execution.

A small practice exercise

Apply the ideas to one non-production change:

1. Write a short task brief with three meaningful failure cases.
2. Locate the relevant code and tests with ordinary tools.
3. Choose direct execution or delegation and explain why in one sentence.
4. Make one bounded patch; run the actual checks.
5. Review the current diff and one observable output.
6. Record failures, retries and unfinished checks without smoothing them into “done.”

That exercise is more useful than choosing a model solely because it tops a leaderboard. It tests whether your workflow turns a requirement into verified behavior.

What I am deliberately not claiming

The video’s 2027 framing is a forecast, not a description of a future that has already happened. Its labor-market and productivity statistics need their original studies, denominators, dates and causal limitations; I have not used them as the numerical foundation of this practical guide.

Similarly, the attachment’s test tables, hook-overhead figures and release-readiness vocabulary describe the author’s implementation and reported process. My static parsing does not reproduce them. No installer payload or model orchestration was exercised in this review.

The earlier 20-rule AI-operator article is related background. This article adds a source-attributed task brief, a risk-aware routing loop, revision-bound evidence and explicit inspection limits. It does not turn a context percentage or a model assignment from either guide into a universal engineering law.

The developer’s responsibility is not disappearing into the agent. It moves into deciding what should happen, limiting what may happen, and proving what actually happened.

Sources

[1] https://www.facebook.com/share/v/1F2ujUnHKK/?mibextid=wwXIfr — Tharwat Samy video: developer responsibilities with coding agents [2] https://www.facebook.com/100001405474156/posts/pfbid02J2TwpwtAxsDw7GnQG7eomubchSYwADreZSqwT9BEDxcFc3uVotJm2AtYhF356me1l/?mibextid=wwXIfr — Omar M. El Monayar: task-based model orchestration [3] https://drive.google.com/file/d/1zhiD-K79p6yqbN756eQuROEYjRWzwPZH/view?usp=drivesdk — Shared Claude Code Efficiency Playbook, runtime 2.1.2 [4] https://code.claude.com/docs/en/best-practices — Claude Code official engineering best practices [5] https://code.claude.com/docs/en/sub-agents — Claude Code official subagent documentation [6] https://code.claude.com/docs/en/hooks — Claude Code official hooks reference [7] https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html — OWASP AI Agent Security Cheat Sheet