The Hybrid Method is an organization of work in which the user stays in Claude.ai, the conversational chat interface, while long-running engineering tasks are delegated in the background to Claude Code, the command-line autonomous agent. The delegation is invisible: the chat itself writes the professional engineering prompt adapted to the situation, launches the executor, supervises its work through the local filesystem and the git history, and reports the result back to the user in the same conversation. The user never opens a terminal, never types a prompt for Claude Code, never leaves the chat.
The name follows the automotive analogy. A hybrid car coordinates two engines with complementary strengths — a combustion engine for sustained load, an electric engine for instant response — through a transmission that selects which one is engaged at each moment. Claude.ai and Claude Code map onto these two engines structurally. The driver presses one pedal; the system handles the allocation underneath.
I have been using this method daily on projects in production since April 21, 2026. After a month of measured use, it is the most useful AI-assisted engineering organization I have encountered: throughput gain of approximately an order of magnitude over single-agent use, higher output quality, and a context-switching cost close to zero because the user never leaves the conversational interface. As of May 20, 2026, a review of the public literature on the Claude ecosystem indicates that this exact assembly is not documented anywhere — the individual pieces are public, the combination appears to be new. That is what motivates this article.
1. The context that makes this method necessary
Claude.ai and Claude Code cover different work regimes. Claude.ai is a conversational interface — web or desktop — suited to decisions, exploration, document work, and short tool calls through Model Context Protocol (MCP) servers. Claude Code is a command-line agent suited to autonomous engineering work over hours at a time: reading codebases, running tests, refactoring, committing.
Most developers use the two tools separately. They reach for the chat to think and decide, and for Claude Code to build. This separation has a hidden cost. When the work to be done exceeds what the chat can do comfortably — a multi-file refactor, an audit followed by structured corrections, a multi-hour sprint with tests and tagged releases — the developer becomes the orchestrator between the two interfaces. They hold the plan in their head, switch between contexts, re-prompt every fifteen minutes, supervise every step. Three hours of Claude Code’s work cost three hours of the developer’s attention.
For users without a strong prompt engineering practice, the situation is worse. The prompts they can write for Claude Code extract only a fraction of what the tool can produce in autonomous mode. Claude Code’s agentic mode expects a structured brief most users do not know how to write: explicit phases, acceptance criteria, operational rules, escalation protocol. Without that brief, the tool underperforms or drifts.
The Hybrid Method resolves both problems through the same mechanism: it delegates the engineered prompt writing AND the execution to the system, while keeping the user in their single conversational environment. The chat translates the user’s natural-language intent into a structured engineering brief, hands it to the executor, supervises the work, and returns a natural-language summary. The user’s contribution is restricted to expressing intent, reviewing the plan, and validating the outcome — which is the work only the user can do.
2. Principle and description of the method
The Hybrid Method runs two distinct Claude agents on the same project — one conversational, one executor — and treats them as functionally distinct engines coordinated by a small transmission layer.
The conversational engine is Claude.ai. It is the interface the user already uses to think, to ask, to decide, to draft. It excels at conversation, at intent disambiguation, at long shared context with the user, at single MCP tool calls. It does not sustain hours of autonomous filesystem work. That is not what the chat is for.
The executor engine is Claude Code, the command-line agent provided by Anthropic. Once given a structured prompt and a permission profile, it operates autonomously: it explores the repository, plans, writes, tests, commits, fixes, iterates, until the prompt’s acceptance criteria are met or the work is blocked. It does not require human turn-taking during execution. It is unsuited to short conversational exchanges.
Neither agent alone covers the full range of work in a serious software project. The Hybrid Method runs both, with the conversational engine acting as supervisor of the executor. When the user describes a goal that exceeds the conversational lane’s capacity, the chat translates that goal into a structured engineering prompt for the executor, launches the executor as a background process, polls its progress periodically, intervenes when necessary, and reports the outcome back to the user in natural language. The user never opens a terminal. The user never writes a prompt for Claude Code. The user stays in the chat.
The automotive analogy gives the method its name and clarifies its underlying logic. A hybrid car runs two engines simultaneously: an internal combustion engine that sustains long-distance work under heavy load but has a measurable startup cost, and an electric engine that starts instantly and handles low-load, short-distance work efficiently. A combustion engine started for a short trip wastes more fuel in startup than the trip itself requires. An electric engine asked to handle a long-haul drive becomes the limiting factor. A hybrid car does not choose. It runs both, and a transmission system selects the engine that is engaged at any given moment based on the conditions of the trip. The driver presses one pedal; the system manages the allocation underneath.
Claude.ai and Claude Code map onto these two engines structurally, not figuratively. Claude.ai has the properties of the electric engine: instant startup because the user is already in the chat session, excellent low-load handling, smooth transitions, and the user-facing interface where decisions live. Claude Code has the properties of the combustion engine: a measurable cold-start cost (typically 5 to 15 seconds while it loads the project’s memory file and explores the repository), sustained autonomous performance once running, native access to file systems and version control. The asymmetry of strengths and costs between the two engines is what makes their coordination valuable.
| Property |
Claude.ai (conversational engine) |
Claude Code (executor engine) |
| Startup cost |
Negligible (existing chat session) |
5–15 seconds (cold context, repo exploration) |
| Sustained autonomous work |
Bounded per conversational turn |
Multi-hour |
| User context retention |
Excellent (long chat memory) |
Per-session, reset between runs |
| Repository-scale operations |
Slow via MCP, bounded by tool calls |
Native, unbounded |
| Conversational quality |
Optimized for it |
Not its purpose |
| Cost per unit of useful work |
Lower for short tasks |
Lower for long tasks |
Used alone, each engine has a regime where it dominates and a regime where it is the wrong choice. Used together, with an explicit allocation policy and a small transmission layer, they cover the full operational envelope of a real software project.
3. Technical architecture
The transmission layer between the two engines does not rely on any custom communication protocol. It is built from three components that already exist on any standard development machine: the local filesystem, the version control system, and a small MCP server that exposes a Bash tool to the conversational engine.
The MCP server is the only piece that needs to be installed and configured. Roughly two hundred lines of Python using Anthropic’s official MCP Python SDK are sufficient. Several community implementations are also available. The server exposes a tool — call it bash_local — that allows the conversational engine to execute shell commands on the host machine. This tool is the bridge between the two engines: the conversational engine uses it to launch the executor as a background subprocess, and later to poll status files and read the git log.
The launch command itself is a standard nohup invocation that spawns Claude Code with a multi-page engineered prompt on standard input:
nohup bash -c 'echo "$PROMPT" | claude -p
--model opus-4-7 --effort xhigh
--dangerously-skip-permissions
> /tmp/sprint_run.log 2>&1' &
Once the executor is launched, the two engines communicate exclusively through artifacts written to the filesystem. The executor maintains a progress file (typically at /tmp/sprint_progress.md) that reflects its current state in human-readable form. If blocked, it writes a blocking file (/tmp/sprint_blocked.md) and proceeds to the next subtask. Commits are pushed to the git repository as work is completed. The conversational engine, at intervals of five to ten minutes, polls these three sources — the progress file, the existence of a blocking file, the last entries of git log — through its bash_local tool. No callbacks, no streaming, no WebSocket connection. The filesystem is the channel; git is the distributed clock.
A subtle but important component of the architecture is the project memory file conventionally named CLAUDE.md. Anthropic built into Claude Code the convention that any file with this name at the root of the working directory is automatically loaded into context at the start of every session. It serves as the executor’s persistent project memory.
In the Hybrid Method, the conversational engine also reads this same file — explicitly, through its bash_local tool, at the start of any project-related conversation. Both engines therefore begin from the same shared understanding of the project: its identity, its current state, its architectural conventions, the strict rules governing what each engine is allowed and forbidden to do, the required reading list, the escalation protocol. This shared memory is what makes the transmission reliable. When the conversational engine writes a sprint prompt for the executor, it does not need to repeat any project context — the executor already has it from CLAUDE.md. The prompt can focus entirely on the specifics of the current sprint: which subtasks, with what acceptance criteria, in what order, with what operational rules. A well-maintained CLAUDE.md is the most underrated artifact in this configuration.
Schematically, the data flow is the following:
User (natural language)
│
▼
Claude.ai (conversational engine)
│ uses MCP tool: bash_local
│ launches: nohup claude -p ... &
▼
Claude Code (executor engine, background subprocess)
│ reads CLAUDE.md automatically
│ reads engineered prompt from stdin
│ works autonomously for 1–3 hours
│ commits and pushes incrementally
▼
Git repository (single source of truth)
│ Claude.ai polls every 5–10 minutes:
│ - last entries of git log
│ - /tmp/sprint_progress.md
│ - /tmp/sprint_blocked.md (if present)
▼
Claude.ai reports back to user in natural language
Nothing in this architecture requires a cloud service, a custom transport protocol, or a software development kit beyond what the two Claude products already provide.
4. The task allocation matrix
The transmission layer described in the previous section is only economically rational if there is a clear policy for which engine is engaged for which kind of work. The wrong policy wastes either the responsiveness of the conversational engine or the autonomy of the executor.
The matrix below is the policy I have settled on after a month of measurement in daily production use. It is empirical rather than theoretical: each row reflects a regime in which one engine is measurably more efficient than the other.
| Task profile |
Engine engaged |
Justification |
| Less than 5 minutes, single-purpose (a one-line fix, a targeted SQL update, a service restart) |
Conversational |
The executor’s cold-start cost exceeds the work itself. Engaging the chat through its existing MCP tools is faster end-to-end. |
| 5 to 15 minutes, multi-file, conversational context already loaded |
Conversational |
The context is hot. Re-loading it into a fresh executor session would cost more than executing directly through MCP tool calls. |
| 5 to 15 minutes, multi-file, cold context |
Executor (foreground) |
Cold context means the executor is faster than re-explaining everything to the chat through MCP. |
| More than 15 minutes, or open-ended exploration |
Executor (background) |
Launched as nohup claude -p ... &. The chat polls progress files and the git log. The user is freed for other work. |
| Multi-module refactor, cross-cutting changes |
Executor |
Native grep, read, and write across the repository without MCP round-trips. |
| Document, article, or strategy synthesis |
Conversational |
Narrative structure is conversational. The executor treats narrative as a side task; the chat treats it as its primary mode. |
| Audit, plan, decide |
Conversational, sometimes assisted by a read-only executor fact-finding pass |
The chat holds the strategic context. If specific facts about the codebase are needed, it spawns a read-only executor pass first, then reasons over the result. |
The cost asymmetry that drives this matrix is empirical. A cold Claude Code session has a measurable startup time of approximately 5 to 15 seconds before any useful work happens, plus the time required to load CLAUDE.md and explore the relevant directories. For a task whose entire useful work is 30 seconds, that startup dominates the total elapsed time. For a task whose useful work is 30 minutes, it is negligible. The matrix simply tracks the crossover point.
This allocation policy is the substantive intellectual content of the Hybrid Method. The transmission infrastructure — a Bash tool exposed through MCP, status files in a known location, git as the source of truth — is mechanical and obvious once described. The discipline of knowing when to engage which engine is what makes the configuration economically rational rather than wasteful, and it is what cannot be improvised. It is built through measurement.
5. Deployment: local or server
The Hybrid Method is neutral to the location of the executor. The same pattern operates without modification in two configurations.
In the local configuration, the executor runs as a subprocess on the developer’s own machine. A local MCP server (a small Python program installed on the developer’s laptop) exposes the Bash tool that the conversational engine uses to launch and supervise. This is the configuration most appropriate for personal development on personal hardware. No sandboxing is necessary because the developer is working on their own files. This is the configuration in which the illustration discussed in section 7 took place.
In the server configuration, the executor runs on a Linux server under a dedicated low-privilege Unix user, isolated from the rest of the system. The MCP server provides remote access — typically through SSH — allowing the conversational engine running on the user’s device to launch and supervise the executor remotely. This is the configuration most appropriate for continuous production work on systems whose state must persist across user sessions. It is the configuration I have used since April 21, 2026 across several projects.
The transmission layer — filesystem, git, MCP bridge — does not care where the executor lives. This neutrality of deployment is one of the properties that distinguish the Hybrid Method from the alternatives discussed in section 9: Cowork is bound to a managed virtual machine, AWS AgentCore is bound to AWS infrastructure, Slack delegation is bound to Anthropic’s cloud. The Hybrid Method is bound to nothing beyond standard MCP. It runs wherever the user chooses to run it.
For an agent operating on a non-developer user’s machine — for example, in the context of a consumer product that exposes Claude Code’s capabilities to users without engineering backgrounds — the Bash tool must be carefully sandboxed. That is a different conversation and is not the subject of this article.
6. Application in practice
The user-facing experience of the Hybrid Method is straightforward. The user opens Claude.ai, formulates an intent in natural language, and the conversational engine handles the rest.
A typical session begins with the user describing a goal. “The recent audit identified thirteen findings on the project. Eight are critical or high. Can we close them this evening across two or three tagged releases?” The conversational engine reads the audit report through its bash_local MCP tool, reads the project’s recent release history and CLAUDE.md, and proposes a plan in the same conversational language: which findings belong in which release, with what acceptance criteria, which to defer with documented justification. The user reviews the plan in the chat and approves.
The conversational engine then writes a multi-page engineered prompt for the executor. This prompt is structured in four phases — read, plan, implement, verify — with explicit acceptance criteria per subtask, with strict operational rules attached (no force-push, tests required before every commit, mandatory status file updates), and with an escalation protocol specifying what the executor should do if blocked for more than thirty minutes on a single subtask. The user does not read this prompt. The user trusts the writer.
The launch is invisible: the conversational engine calls its Bash tool, executes the nohup ... claude -p ... & invocation, and returns to the user with confirmation that the sprint is running. The user closes the laptop or moves on to other work. The executor is now alone with its prompt, its CLAUDE.md, and the codebase.
For the next several hours, the user is out of the loop. The conversational engine polls progress every five to ten minutes. If everything appears normal, no action is taken. If a regression appears in the commit stream, the conversational engine investigates: it reads the relevant diffs, evaluates whether the regression is real or apparent, and either patches in place or rolls back. When the work is complete, the conversational engine produces a summary in the user’s preferred language, with the list of commits, the closed findings, the deferred items with their justifications, any incidents that occurred and how they were handled, and a pointer to where the artifacts can be reviewed.
At no point in this session does the user open a terminal, type a prompt for Claude Code, or leave the Claude.ai interface. The user expresses intent in natural language at the start, reviews the proposed plan, validates the final result. The execution is delegated end to end.
This division of labor is the operational expression of a broader principle: that the user’s role in software engineering with AI assistance should be to decide and to validate, and the AI’s role should be to execute. The Hybrid Method makes this principle implementable in practice, on real projects, at the scale at which serious software is built.
7. Illustration: a multi-release sprint
To make the previous sections concrete, this section describes one specific application of the method. The case is representative rather than exceptional. The continuous use of the method on multiple projects produces similar outcomes; this particular sprint is simply compact enough to summarize in a single section.
The context: a macOS desktop product currently in pre-release, which I will not name here as the product is under embargo until its public launch. The state at the start of the sprint was version 1.0.7.1, shipped some days earlier. An external code audit, itself performed as a Claude Code session in xhigh-effort mode against a clean checkout, had produced a report of thirteen findings: one critical security gap, four high-priority items, the rest medium and low priority. The goal of the sprint was to close as many findings as feasible and ship the resulting work as tagged, changelog-documented releases.
The conversational engine planned three releases. Version 1.0.8 would close the critical security finding and three of the four high-priority items, plus a planned dashboard improvement. Version 1.0.9 would add a set of missing HTTP endpoints. Version 1.0.10 would archive dead code identified by the audit and complete the low-priority cleanups.
The result, measured at the end of the sprint:
- eleven commits pushed to
main, all signed
- eight of the thirteen findings closed, five deferred with documented justification
- test suite extended from 106 to 125 tests, all passing
- three releases tagged: 1.0.8, 1.0.9, 1.0.10
- one
.pkg installer built and verified on the developer’s machine
- no incremental API charges — Claude Code, in this setup, is authenticated through OAuth against my paid Claude subscription (Pro/Max plans, which cover both interactive Claude.ai and Claude Code usage on a single monthly fee); the sprint’s consumption drew from that subscription’s quota, not from a pay-per-token API account
- approximately thirty minutes of human typing time, distributed between planning at the start and review at the end
One operational incident occurred during the sprint and is worth documenting because the response illustrates the supervision pattern. A cleanup operation moved a directory src/wrappers/ to src/legacy/wrappers/. Within the executor’s working scope this was correct: imports were updated, the test suite passed, the commit was clean. Outside the executor’s scope, on the developer’s personal machine, three entries of a local hybrid testing configuration pointed into src/wrappers/ and silently broke when the files moved on disk. The product itself was unaffected (the installed application is self-contained), but the developer’s local environment was. The conversational engine, polling the commit stream, recognized the implication for the local configuration that had been loaded as context earlier, patched the configuration with a one-line sed, backed up the previous version, and noted the incident in the progress file.
From the incident, a new operational rule was derived and added to the project’s CLAUDE.md: the executor produces installable artifacts (.pkg files) and never modifies the developer’s working copy or personal configuration. Future sprints work on dedicated branches or in temporary clones. This rule now applies to every subsequent session.
The illustration is not a remarkable result; it is a representative one. What it demonstrates is that the method produces measured outputs that are competitive in quality with what a small engineering team would produce over a similar duration, with one supervising human engaged for tens of minutes rather than several hours.
8. What the method changes for senior engineers and for users without an engineering background
The Hybrid Method addresses two distinct constraints that have historically limited what an individual can produce with AI assistance, depending on the individual’s level of engineering background.
For senior engineers, the persistent constraint with single-agent AI coding tools is attention rather than capability. The tool can write code faster than the engineer can type, but the engineer still has to hold the plan, supervise every step, review every commit, decide what to do when the tool gets confused. The total work product per unit of engineer-time is bounded by the engineer’s ability to remain present in the execution loop. The Hybrid Method shifts the engineer’s attention to a different lane. The strategic work — architecture, scope, trade-offs, validation — stays with the engineer, but is held in conversation with the conversational engine, which can read the codebase and surface specific facts on demand. The execution work moves to the executor under the conversational engine’s supervision. The line-by-line review work also moves to the conversational engine, which reads the commit stream as it arrives and flags anomalies. The engineer’s residual attention is concentrated on judgment and validation, which is the work that only the engineer can do. A senior engineer using this method can credibly maintain several active sprints in parallel, because none of them requires continuous attention during execution.
For users without a software engineering background — professionals in other fields, technical hobbyists, anyone whose primary expertise is elsewhere — the persistent constraint with single-agent AI coding tools has been prompt-craft expertise. Writing the multi-page structured prompt that Claude Code needs to produce high-quality autonomous output is itself a craft requiring weeks or months of accumulated engineering judgment. Most users without this background do not have it and never will. The Hybrid Method removes the requirement. The conversational engine writes the engineered prompt, drawing on its long conversational context with the user and on the project’s CLAUDE.md. The user expresses intent in natural language, in their own language; the rigorous prompt is produced for them. The user contributes domain knowledge, judgment about what the system should do, validation of outputs in the real-world context the user uniquely understands. The AI agents contribute the engineering rigor. The asymmetry that previously excluded non-engineers from building serious software is reduced.
The two effects are complementary. The same method that frees the senior engineer’s attention for higher-leverage work also opens the practice of software development to users whose previous bar to entry was prompt-craft expertise they did not possess. Neither effect was the explicit design goal; both are properties that emerge from the architectural choice of separating the conversational lane from the execution lane.
9. Why this assembly does not appear documented elsewhere
A review of the public literature on the Claude ecosystem as of May 20, 2026 identified several adjacent patterns. None of them is the same as the Hybrid Method described here.
| Pattern |
Brief description |
How it differs |
| Operator / orchestrator pattern (MindStudio, Anthropic documentation) |
A Claude Code session orchestrates other Claude Code subagents through the native Task tool |
Internal to Claude Code. No conversational supervisor in front. |
| Claude Agent SDK (Anthropic, official) |
A Python wrapper that spawns Claude Code as a subprocess and drives it programmatically |
Programmatic orchestration. No natural-language interface for the human user. |
| Cowork (Anthropic, enterprise product) |
Claude Desktop spawns Claude in a managed sandboxed Linux virtual machine for asynchronous knowledge work |
Cloud-managed runtime. Visible to the user as a distinct product surface. Not a chat that delegates underneath. |
| Slack delegation (Anthropic) |
@Claude in a Slack thread launches a Claude Code session on Anthropic infrastructure |
Cloud-managed. Visible via the explicit mention. Not portable across organizations. |
| Code tab plus git worktrees (Claude Desktop, third-party guides) |
The desktop app exposes a user interface for spawning parallel Claude Code instances in worktrees |
Launched explicitly by the human user through a UI. No supervising agent in front of the executor. |
| AWS AgentCore with A2A protocol (third-party) |
A main agent and a code agent communicate over the A2A protocol on AWS AgentCore |
Cloud-based. Asynchronous over the A2A protocol. Not local; not MCP-based. |
The Hybrid Method is differentiated from these adjacent patterns on four properties simultaneously. First, the supervisor is a conversational chat — not a script, not a piece of code, not a separate user interface — and the user interacts only with that chat. Second, the transport between the supervisor and the executor is standard MCP, not a Python wrapper or a custom protocol; any LLM client supporting MCP tools could play the supervisor role. Third, the executor is invisible to the user; Claude Code is a subcontractor of the chat, never surfaced explicitly. Fourth, the communication between the two engines is asynchronous and runs through the local filesystem and a git repository, which are the same artifacts that human teams already use for distributed software development.
The individual pieces of this assembly all exist publicly and have been documented separately. None of the documented patterns combines all four properties. This combination is what I have not found written down, and what motivates writing it down here.
10. How to implement the method
The Hybrid Method requires four pieces of infrastructure and three operational disciplines. The infrastructure can be assembled in an afternoon. The disciplines develop over weeks of practice.
The infrastructure consists of:
- A Claude.ai subscription with MCP support (Pro or Max). This is the conversational engine.
- A local MCP server that exposes a Bash tool and a few file utilities to the conversational engine. Approximately two hundred lines of Python written against Anthropic’s official MCP Python SDK, or one of the community implementations. No sandboxing is required for personal development on personal hardware. For an agent operating on a non-developer user’s machine, careful sandboxing is non-negotiable.
- Claude Code installed locally (
npm install -g @anthropic-ai/claude-code or via Homebrew on macOS) with a one-time login. This is the executor engine.
- A well-maintained
CLAUDE.md file at the root of the project repository. This is the shared memory. The first version takes about an hour to write. The file is refined over weeks of use.
The disciplines consist of:
- A documented task allocation matrix. The version in section 4 of this article is mine; an implementer’s version may differ in details. What matters is that the matrix is written down, applied consistently, and updated based on measurement.
- A prompt engineering practice for the engineered sprint prompts the conversational engine writes for the executor. Four phases, acceptance criteria per subtask, ten or so strict operational rules, an escalation protocol, status file conventions. This is the operational moat in the method. It is developed over weeks of iteration on real sprints.
- The discipline of two lanes. The user stays in the chat. The conversational engine stays in the supervisor lane. The executor stays in the execution lane. These roles do not blur. Once delegation begins, the user does not open the terminal.
For server deployment, the local MCP server is replaced by an SSH-capable MCP, and the executor runs on the remote server under a dedicated low-privilege Unix user. Everything else is identical.
The first sprint executed with the method will be messier than expected. The third sprint will be smoother. By the tenth sprint, the prompt engineering practice will have stabilized, the allocation matrix will reflect measured patterns rather than guesses, and the CLAUDE.md will encode the operational lessons that previous sprints surfaced. The infrastructure pays back from the first session. The disciplines compound over weeks.
Conclusion
The Hybrid Method is, in the simplest formulation, a way of using two existing Claude products together so that they cover complementary regimes of work: a conversational engine for decisions, context, and supervision; an executor engine for sustained autonomous engineering. The user interacts only with the conversational engine. The executor is a subcontractor whose work is supervised through artifacts the user does not need to read.
The infrastructure is small. Three components — a chat subscription, a local MCP server, Claude Code installed — and a shared memory file at the root of the project. The infrastructure does not require a cloud service, a custom protocol, or specialized engineering work.
What requires craft is the operational discipline that turns the infrastructure into a productive system: an allocation policy that engages the right engine for the right kind of work, a prompt engineering practice that translates conversational intent into structured executor instructions, and the simple but consistent separation of lanes that keeps each engine doing what it does well.
What the method offers, in return, is a meaningful shift in what a single person can produce with AI assistance. For a senior engineer, attention is freed for the work only the engineer can do — judgment, validation, scope, real-world correctness — while execution moves to a supervised executor. For a user without an engineering background, the bar to participation is lowered: the prompt-craft expertise that previously gated access to Claude Code’s autonomous mode is provided by the conversational engine on the user’s behalf, allowing the user to contribute domain knowledge and judgment without first acquiring engineering rigor as a prerequisite.
I have used this method daily since April 21, 2026 on projects in production. After a month of measured use, I consider it the most useful AI-assisted engineering organization I have encountered. The throughput gain over single-agent use is approximately an order of magnitude; the output quality is higher; the cognitive cost of context-switching between strategy and execution drops to near zero because the user never leaves the conversational interface. These claims are made carefully and with measurement behind them, not as marketing.
The deeper observation, beyond the immediate productivity gains, is that the Hybrid Method makes implementable in practice a division of labor that has been theoretically advocated for some time: the human decides and validates, the AI executes. Single-agent AI coding tools have come close to this division but have not quite delivered it, because the human has had to remain present in the execution loop to supervise. By dedicating one Claude to supervision and another to execution, with the human attached only to the supervisor, the Hybrid Method delivers the division in a form that holds up under the duration and complexity of real software projects.
The pieces of this assembly are all public. The combination, as far as my search of the public literature on May 20, 2026 indicates, is not yet documented elsewhere. The choice to write this article down was motivated by that absence and by a sense that the window during which writing it down is the most useful contribution available is narrow: the major AI vendors are visibly moving toward native versions of related capabilities, and a built-in feature in Claude.ai that delegates to Claude Code from the chat is, in my reading, plausible within twelve months. Until that arrives, the user-side configuration described here is available to anyone who wants to assemble it.
If the description above is useful, the most valuable next step for a reader is not further reading but practice. Install the four ingredients, write a first version of the CLAUDE.md, attempt a small sprint under the supervision pattern, measure the outcome, refine the allocation matrix and the prompt format on the basis of what was learned. The first sprint will be uneven. The fifth will not. The framework described here is the scaffolding; the productive use of it is built through iteration on real work.
Feedback, prior art that contradicts the claim of originality, refinements to the allocation matrix, and accounts of other implementations are all welcome. The method is named, but it is not finished. Improvements in any of these dimensions are improvements to the shared practice rather than to any individual implementation, and they are how the method becomes useful beyond the small set of practitioners who have so far converged on something resembling it.
— Driss Amiroune
