In March 2026, Matt Van Horn published a long article on the X platform titled straightforwardly: "Every Claude Code Trick I Know." Eventually, the post racked up 913,000 views, and the comment section became a chaotic discussion.
The controversy was ignited not by a specific command or configuration parameter but by a statement he wrote at the beginning: No IDE. In describing his working state, he mentioned that he had never opened a graphical editor during the entire process; all development operations occurred in the terminal command line and a document called plan.md. Some found it absurd and asked how he managed code reading, debugging, and refactoring; while some experienced engineers commented below, "This is the method I've always been looking for."
Two months later, Chinese developer meng shao organized and published this set of methods along with community-derived practices, naming it "Complete Guide to Practical Strategies for Agent Engineering." It is not a tool review but a set of operational principles revolving around the cycle of "Research → Plan → Work," behind which are 22 reproducible or discussable specific techniques.
This article organizes some of the most discussed AI workflow operating guides online, from which we might derive some commonalities.
When You Close the IDE, What Do You Really Lose?
A graphical IDE provides developers not only with a code editing area. It is a complete sensory system: syntax highlighting allows you to instantly discern the difference between variables and keywords, real-time error alerts let you know where something went wrong during input, breakpoint debugging allows you to observe variable state changes line by line, and the file tree and breadcrumb navigation help you not get lost in large projects. This entire visual feedback mechanism constitutes a default assumption: the person writing code needs to see the state of every line of code firsthand.
The workflow of terminal command line + Markdown file strips away this layer of visual protection. All you are left with is a blinking cursor and a planning file you wrote yourself. There are no red wavy lines marking errors, no autocomplete pop-ups, no file trees. Matt Van Horn used the term “No IDE” in his tweet; its true meaning is not the rejection of all graphical tools but rather shifting the control logic of development from "manual line-by-line confirmation" to "batch delegation execution."
Boris Cherny, the head of Claude Code, shared his own methods of using Claude Code through Threads and other channels from the end of 2025 to early 2026. His approach is CLI-first, using plan mode as the starting point for all tasks. There is an essential difference in thinking compared to traditional IDEs: traditionally in IDEs, the human is the active code producer, and AI completion is merely an aid; in the planning-driven terminal workflow, the human is the direction setter and acceptor, while the generation and implementation path of the code is autonomously chosen by the Agent.
Abandoning the IDE loses the sense of security that comes from "typing every line of code by hand." This sounds like a loss, but for developers who have already experienced a lot of context switching in large projects, it is also a kind of unloading. Because you no longer need to frequently switch between reading code, writing code, searching documentation, and switching files. You only need to clearly explain a requirement and then delegate the execution process to a group of parallel-running Agents.
The framework proposed by meng shao in the summary is "human leads direction, agent executes," where in the IDE era the human has to lead both direction and execution details, with the two roles intertwined. The new workflow tries to separate these two roles, with humans only doing the first half.
plan.md Is Not a Document; It Is a Contract
The most common file name in this workflow is plan.md. It sounds like project documentation, but its actual function is entirely different.
The project's README or development documents are meant for humans to read, explaining architectural decisions, recording interface agreements, and helping new members get started. The primary reader of plan.md is not a human but an Agent. Its structure revolves around three components: problem definition, solution description, and a checklist of tasks in Checkbox form. meng shao stated this relationship plainly in a tweet: plan.md's role is to "constrain the agent from slacking off."
LLMs have a known issue in long conversations that the community calls "context corruption." As dialogue history gets longer, the model's attention to the initial objectives naturally diminishes. It may forget the initial demand boundaries midway or skip certain confirmation steps. A project named "Neat Freak.skill" in the community specifically addresses this issue, providing methods for automatically organizing conversation files and updating persistent memory. Its core judgment is that the long-term performance of an Agent does not depend on the quality of a single prompt but rather on whether there is a stable external memory mechanism.
plan.md is this external memory. It resides on the file system and does not disappear with the end of a session. Every new Agent session can reload context from this file instead of relying on deteriorating chat logs from the previous conversation.
Compound Engineering is the core open-source plugin that supports this workflow, developed by Kieran Klaassen of Every Inc. It offers a set of command-line instructions, among which /ce:plan can automatically generate a draft of plan.md based on the developer's input. After generation, the developer’s job is to review and correct: Agents may make incorrect assumptions about technical choices, underestimate the complexity of a module, or completely misunderstand business logic. The human's intervention at this time is not to fine-tune the code but to inject domain knowledge that the Agent does not know into the plan file and then hand the corrected plan back to the Agent for execution.
This design is highly consistent with a point emphasized by Boris Cherny in the usage principles of Claude Code: concentrating human expert judgment in the plan review node, rather than dispersing it across every step of execution. In his words, if every step requires human confirmation, then it is not fundamentally different from manually writing code.
An effective plan.md will not be very long. It typically contains clear acceptance criteria, each condition corresponding to a Checkbox. These Checkboxes serve as execution anchor points for the Agent and acceptance standards for the human. After developers complete the Work phase, they do not read the code but check whether each Checkbox is ticked off one by one.
Three Forms of a Requirement: Research → Plan → Work
The essential framework of this workflow consists of a closed loop formed by the three stages: Research, Plan, and Work. It is not complicated, but there is a clear division of roles in tool support and human intervention at each segment.
The goal of the Research stage is to provide the Agent with an information advantage before they start working. A common approach is to use the /ce:brainstorm command or load specific Research skill packages. Matt Van Horn open-sourced a skill called last30days-skill, which had exceeded 10,000 stars on GitHub by the end of March 2026. Its function is to allow the Agent to parallel scrape community content related to a specified topic from Reddit, X platform, Hacker News, etc., over the past 30 days and then output a structured analytical summary. Suppose you are starting a project involving a new tech stack; your Agent can gather the latest community evaluations, known pitfalls, and recommended alternatives regarding that tech stack in minutes instead of making you manually open dozens of browser tabs.
The output after Research is not the final answer; it is information input. This information enters the Plan stage, becoming material for generating plan.md.
The Plan stage uses the /ce:plan command. Based on the discoveries from the Research stage, the developer's initial requirements, and the existing code context of the project, the Agent generates a draft of plan.md. The design philosophy of Compound Engineering is to spend 80% of the time on planning and reviewing, and 20% on execution. This ratio may seem aggressive at first glance; the logic is actually straightforward: a clearly written, well-defined, and specifically stated plan minimizes the cost of rework during the execution phase.
What developers need to do during the Plan stage includes correcting the Agent's erroneous assumptions about technical solutions, supplementing business constraints that the Agent is unaware of, adjusting the granularity of task decomposition and execution order, and including edge cases in the Checkbox that the Agent might easily skip. This reviewing process is also a form of "external memory injection," as the human writes down tacit knowledge that is difficult to naturally emerge during conversations into the planning document.
The Work phase uses the /ce:work command. The Agent reads plan.md, decomposes tasks into subtasks, and delegates them to sub Agents for parallel execution. Boris Cherny once shared a figure: using this plan-driven workflow, he produced 259 PRs in a month. This number reflects not code quality but that when decision-making authority in the execution phase is delegated to the Agent, human bottlenecks no longer lie in typing speed.
There is an easily overlooked key point between the three stages: the Research and Plan stages can loop multiple times. If the Agent uncovers an information gap in the Plan stage, it can switch back to Research mode at any time to supplement it. If issues in the plan are found after the Work stage has begun, it can also return to the Plan stage for corrections. This loop is not a linear waterfall; it is a cycle that allows for backtracking and adjustments.
Six Techniques You Can Try Right Now
Among the publicly available information so far, the following six techniques have clear sources and sufficient detail to support a developer's direct trial. They are not abstract principles but concrete actions related to "what to type in the terminal," "what to write in the file," and "which tool to use."
Technique One: Generate a plan immediately when you have an idea; do not simulate it in your head first.
meng shao placed this one towards the forefront of his original post. His logic is that the human brain is good at reviewing but not capable of constructing a complete tree structure of complex logic from scratch. When developers receive a new requirement, they habitually replay the implementation path in their minds, but this process is inefficient due to the limited capacity of working memory. The right approach is to have the Agent generate a first draft of the plan immediately after the idea comes up, even if it is rough, incorrect, and requires substantial corrections. Reviewing a problematic plan is far easier than starting from scratch to write a perfect one.
Technique Two: Don't read the plan yourself; let the Agent summarize it into a few sentences.
Reading lengthy plan documents incurs its own cost. One of the tips from Boris Cherny is to use natural language commands to ask the Agent for a TLDR or to explain the core points of the plan in the simplest way with "eli5." If you have five minutes to review, spend the first three minutes on the Agent's summary and the last two minutes checking the parts you think are risky. The essence of this technique is to delegate the "reading comprehension," allowing humans to only look at what they must.
Technique Three: Use multiple terminals in parallel.
Matt Van Horn mentioned in his tweets that he would have four or more terminal windows open simultaneously, letting different Agent instances handle different subtasks. One tackles the front-end page, another writes the back-end interface, another runs tests, and another retrieves documentation. This method transforms traditional single-threaded development into multi-threaded scheduling. The cost is that you need to manage the outputs and states of different terminals yourself, without a graphical workstation to monitor everything uniformly. For developers used to overseeing everything within a single IDE window, there might be initial anxiety of "not knowing where the error is."
Technique Four: Use voice instead of keyboard input for complex architectural commands.
meng shao mentioned using voice input tools like monologue. The specific approach is to articulate a lengthy system design idea verbally instead of typing it out word for word. The speech-to-text tool transcribes the content into the terminal or plan file. Matt Van Horn referred to this as "Get Voice-Pilled," believing that speaking is easier to maintain the coherence of complex architectural thinking because the speed of speaking aligns better with the natural rhythm of logical flow. There is currently a lack of sufficient feedback on the practical effect of this technique for Chinese developers, and the Chinese voice support capability of monologue still needs further confirmation.
Technique Five: Use email to trigger asynchronous tasks.
In a tweet from April 2026, Matt Van Horn shared a specific scenario: while getting his child to sleep, he sent an email to his Claude Code instance using the agentmail tool, triggering a remote code building task. By the time the child fell asleep, the build was already completed, waiting for him to accept it in the terminal. Essentially, this liberates the development behavior from the physical constraint of "having to be sitting in front of a computer," allowing the Agent to work continuously in the background. The prerequisite is that you have enough trust in the Agent to allow it to operate autonomously without seeing the screen.
Technique Six: Treat your tool stack as a skill marketplace.
Projects like AgentSkills offer a core idea: developers do not need to build every Agent capability from scratch. Common skills like file management, news monitoring, and web scraping already have community-maintained skill packages that can be loaded. In terminal workflows, loading a new skill is similar in complexity to installing a plugin; you only need to declare the source and parameters of the skill package in the configuration, and the Agent can automatically acquire the corresponding tool invocation capabilities. The Claude Code Video Toolkit serves as an example of community practice, adding video content comprehension capabilities to the CLI environment, though the application scenarios are still quite specific. It illustrates that the capabilities of terminal Agents can continuously expand through skill packages.
When This Process May Backfire on You
There is no shortage of opposing voices regarding this workflow. Based on community discussions, the main issues focus on three directions.
The first issue is the boundary of applicable groups. Boris Cherny's 22 tips inherently imply a premise: users need to possess sufficient architectural decomposition and prompt constraint capabilities. Those who can independently complete system design know where the boundaries of “what to let the Agent do and what not to do” lie. For developers still relying on IDE error prompts, code highlights, and breakpoint debugging to understand code logic, turning off a graphical editor equates to shutting down a familiar information acquisition channel. This is not about ability; it is due to differing perceptual channels dependent on working methods. New developers build their mental models of program execution through line-by-line debugging, which lacks alternatives in the terminal workflow.
The second issue is the concentration of risk. In traditional IDEs, errors gradually reveal themselves during execution: compilation errors, type mismatches, runtime exceptions. Humans have opportunities to discover and correct issues at each stage. In plan-driven workflows, all decision reviews are compressed into just the Plan stage. If the review by humans at this node is not thorough enough, errors may be faithfully and efficiently amplified by the Agent in the Work stage. By the time you realize it, several files may have been tainted by erroneous logic.
The third issue was raised by Matt Van Horn himself; he calls it "AI Psychosis." This term refers not to problems with AI but with humans: constructing an Agent cycle can bring about a strong intellectual pleasure, similar to the positive feedback of continually optimizing strategies in games. Developers may become addicted to refining their Agent workflows, constantly trying new techniques, adding new sub-Agents, and optimizing the structure of the Plan while forgetting a fundamental question: what value are you delivering to the users? The tool becomes the objective, and the demand is placed second.
These three issues point to the same conclusion: the plan.md-driven terminal workflow is an efficiency amplifier designed for those who "clearly know what they want," not a learning tool for those who "are still exploring what they should be doing." Its applicability is not based on the choice of technology stack but on the stage of the user. If you are the one who has already drawn a complete system architecture on paper, this workflow can expedite your execution speed by an order of magnitude. If you are still trying to understand the problem itself by writing code, then the visual feedback system of the IDE is a crutch that you should temporarily not discard.
Currently, the core components of this workflow include the operational environment layer of Claude Code CLI or Codex CLI, the process management layer of the Compound Engineering plugin, and the skill expansion layer of projects like last30days-skill and agentmail. They are all in rapid iteration, and the command formats, file agreements, and plugin systems are subject to change. Developers entering the scene now need to accept a reality: the pitfalls you encounter may not yet have community answers because the entire chain is still in the early stage of practice, far from reaching the standard of a "stable toolchain." But this is also a window of opportunity for the first batch of pioneers to establish cognitive advantages.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
