In March 2026, Matt Van Horn published a long article on the X platform with the straightforward title: "Every Claude Code Tip I Know." The post eventually garnered 913,000 views, and the comments section erupted into a frenzy.

The controversy wasn't sparked by a specific command or configuration parameter, but by his opening statement: "No IDE." In describing his work process, he mentioned that he never opened a graphical editor once; all development took place in the terminal command line and a file called plan.md. Some found this absurd, asking him how he handled code reading, debugging, and refactoring; while a senior engineer commented, "This is exactly the method I've been looking for."

Two months later, Chinese developer Meng Shao compiled and released this methodology, along with related community practices, under the title "A Complete Guide to Practical Tips for Intelligent Agent Engineering." It's not a tool evaluation, but rather a set of operational principles revolving around the "Research → Plan → Work" cycle, underpinned by 22 reproducible or discussable specific techniques.

This article compiles some of the most discussed AI workflow operation guides online, from which we may be able to glean some commonalities.

What do you lose when you close the IDE?

Graphical IDEs offer developers more than just a code editing area. They provide a complete sensory system: syntax highlighting lets you instantly distinguish between variables and keywords, real-time error messages tell you where the problem is while you're typing, breakpoint debugging allows you to observe changes in variable state line by line, and file trees and breadcrumb navigation help you navigate large projects without getting lost. This entire visual feedback mechanism establishes a default assumption: the coder needs to see the state of every single line of code.

The workflow of terminal command line + Markdown files removes this visual protective shell. All you're left with is a blinking cursor and a handwritten plan document. There are no red wavy lines marking errors, no auto-completion pop-ups, and no file tree. Matt Van Horn used the phrase "No IDE" in his tweet, but its true meaning isn't rejecting all graphical tools, but rather transforming the development control logic from "manual confirmation line by line" to "batch delegation execution."

Boris Cherny, the lead developer of Claude Code, shared his approach to using Claude Code through Threads and other channels in late 2025 and early 2026. His approach prioritizes CLI, using plan mode as the starting point for all tasks. This is fundamentally different from the IDE mindset: in traditional IDEs, humans are active code producers, with AI completion merely an aid; in plan-driven terminal workflows, humans are the direction setters and acceptors, while the code generation and implementation paths are autonomously chosen by the agent.

Giving up an IDE means losing the sense of security of "typing every line of code by hand." This may sound like a loss, but for developers who have experienced numerous context switches in large projects, it's also a form of offloading. Because you no longer need to repeatedly jump between reading code, writing code, searching documentation, and switching files. You only need to clearly articulate a requirement and then delegate the execution process to a set of agents operating in parallel.

Meng Shao's framework, as summarized, is "human-led direction, intelligent agent execution." In the IDE era, humans were responsible for both direction and execution details, creating an entanglement between the two roles. The new workflow attempts to separate these two roles, with humans handling only the first half.

plan.md is not a document, but a contract.

The most common filename for this workflow is plan.md. It sounds like a project document, but its actual function is completely different.

The project's README or development documentation is for human readers, used to explain architectural decisions, record interface conventions, and help new members get started. The primary reader of plan.md is not a human, but an agent. Its structure revolves around three things: problem definition, solution description, and a checkbox-style execution list. Meng Shao explained this relationship very clearly in a tweet: the role of plan.md is to "constrain the agent from being lazy."

LLMs have a known problem in long conversations, which the community calls "context corruption." As the conversation history gets longer, the model's attention to earlier goals naturally diminishes. It may forget the initial requirement boundaries midway or skip certain check steps. A project in the community called "Cleanliness.skill" specifically addresses this problem, providing methods to automatically clean up session files and update the persistent memory. Its core premise is that the agent's long-term performance depends not on the quality of a single prompt, but on whether there is a stable external memory mechanism.

The `plan.md` file is this external memory. It is stored on the file system and does not disappear when the session ends. Each new Agent session can reload the context from this file, instead of relying on the decayed chat history from the previous conversation.

Compound Engineering, developed by Kieran Klaassen of Every Inc., is the core open-source plugin supporting this workflow. It provides a set of command-line instructions, where /ce:plan automatically generates a draft `plan.md` file based on the developer's input. After generation, the developer's job is to review and correct it: the agent might have incorrect assumptions about technology choices, underestimate the complexity of a module, or completely misunderstand the business logic. Human intervention at this point is not about fine-tuning the code, but about injecting domain knowledge unknown to the agent into the plan file, and then handing the corrected plan back to the agent for execution.

This design aligns closely with a key principle emphasized by Boris Cherny in his Claude Code principles: concentrating human expert judgment at the planning and review stage, rather than distributing it across every step of execution. In his words, if every step requires human oversight and confirmation, it's essentially no different from manually writing code.

An effective plan.md file won't be very long. It typically contains clear acceptance criteria, each corresponding to a checkbox. These checkboxes serve as execution anchors for the Agent and acceptance standards for the user. After completing the Work phase, developers don't read the code; instead, they check if these checkboxes are checked one by one.

Three forms of a requirement: Research → Plan → Work

The core framework of this workflow is a closed loop consisting of three phases: Research, Plan, and Work. It is not complex, but each phase has a clear division of labor in terms of tool support and human involvement.

The goal of the Research phase is to give the agent an informational advantage before it takes action. Common methods include using the /ce:brainstorm command or loading specific Research skill packages. Matt Van Horn open-sourced a skill called `last30days-skill`, which had over 10,000 stars on GitHub by the end of March 2026. Its function is to allow the agent to crawl content related to a specified topic from communities like Reddit, X platform, and Hacker News in parallel over the past 30 days, and then output a structured analytical summary. Suppose you're starting a project involving a new technology stack; your agent can pull up the latest community reviews, known pitfalls, and recommended alternatives about that technology stack within minutes, instead of making you manually open a dozen browser tabs.

The output after the research is completed is not the final answer, but information input. This information enters the Planning phase and becomes the material for generating plan.md.

The Planning phase uses the /ce:plan directive. Based on findings from the Research phase, initial requirements from developers, and the project's existing code context, the Agent generates a draft `plan.md`. Compound Engineering's design philosophy is to spend 80% of time on planning and review, and 20% on execution. This ratio may seem aggressive at first glance, but the logic is straightforward: a clearly written plan with well-defined boundaries and specific acceptance criteria minimizes rework costs during the execution phase.

During the Plan phase, developers need to: correct incorrect assumptions about the technical solution made by the agent, add business constraints unknown to the agent, adjust the granularity of task breakdown and execution order, and add edge cases that the agent might easily skip in the checkboxes. This review process itself is also a form of "external memory injection," because people at this stage write implicit knowledge that is difficult to emerge naturally in conversation into the plan document.

The Work phase uses the /ce:work command. The Agent reads `plan.md`, breaks down the task into subtasks, and dispatches them to sub-Agents for parallel execution. Boris Cherny once shared a statistic: using this plan-driven workflow, he produced 259 pull requests in one month. This number doesn't illustrate code quality, but rather that when decision-making power in the execution phase is delegated to the Agent, the human bottleneck is no longer typing speed.

There's a crucial, often overlooked, point between the three phases: the Research and Plan phases can be cycled multiple times. If the agent exposes information gaps during the Plan phase, it can switch back to Research mode at any time to fill them. Similarly, if errors are found in the plan after the Work phase begins, it can return to the Plan phase to correct them. This cycle is not a linear waterfall flow, but a loop that allows for rollback and adjustments.

Six tips you can try right away.

Of the currently available information, the following six tips all have clear sources and sufficient detail to support a developer's direct attempt. They are not abstract principles, but specific operations such as "what to type in the terminal," "what to write to the file," and "which tool to use."

Tip 1: Generate a plan as soon as you have an idea; don't just mentally simulate it first.

Meng Shao placed this point very early in his original post. His logic is that the human brain excels at reviewing but not at constructing complex logical tree structures out of thin air. When developers receive a new requirement, they habitually mentally rehearse the implementation path, but this process is extremely inefficient because working memory has limited capacity. The correct approach is to have the agent generate a first draft plan immediately after an idea emerges, even if it's rough, contains errors, and requires extensive revisions. Reviewing a problematic plan is much easier than writing a perfect plan from scratch.

Tip 2: Don't read the plan yourself; have the agent summarize it into a few sentences.

Reading lengthy planning documents is itself a cost. One of Boris Cherny's 22 tips is to use natural language commands to have the agent provide a TLDR (Translation Time Reference), or use "eli5" to have it explain the core points of the plan in the clearest terms. If you have 5 minutes to review, give the first 3 minutes to the agent for a summary, and the last 2 minutes only to check the parts you think are risky. The essence of this technique is to delegate "reading comprehension" as well; people only read what they need to see.

Tip 3: Multi-terminal parallel operation.

In his tweet, Matt Van Horn mentioned that he opens more than four terminal windows simultaneously, allowing different Agent instances to handle different subtasks. One is working on the front-end page, one is writing back-end APIs, one is running tests, and one is fetching documentation. This approach transforms traditional single-threaded development into multi-threaded scheduling. The trade-off is that you need to manage the output and status of different terminals yourself, without a graphical workbench to provide unified monitoring. For developers accustomed to having a comprehensive view in a single IDE window, there will initially be an anxiety of "not knowing where things went wrong."

Tip 4: Use voice input instead of keyboard input for complex architectural commands.

Meng Shao mentioned using voice tools like Monologue for input. The specific approach is to express a lengthy system design concept verbatim instead of typing it out, then let a speech-to-text tool import the content into a terminal or project file. Matt Van Horn calls this "Get Voice-Pilled," believing that voice is better at maintaining the coherence of complex architectural thinking than typing because the speaking speed matches the natural flow of logic more effectively. However, the actual effectiveness of this technique for Chinese developers currently lacks sufficient feedback, and Monologue's Chinese voice support capabilities require further confirmation.

Tip 5: Trigger asynchronous tasks via email.

In a tweet in April 2026, Matt Van Horn shared a specific scenario: while putting his child to bed, he sent an email to his Claude Code instance using the agentmail tool, triggering a remote code build task. After the child fell asleep, the build had completed, and the result awaited his acceptance in the terminal. Essentially, this liberates development from the physical constraint of "having to sit in front of a computer," allowing the agent to work continuously in the background. The prerequisite is that you have a high enough level of trust in the agent and are willing to let it execute autonomously without seeing the screen.

Tip 6: Treat your tool stack like a skills marketplace.

Projects like AgentSkills offer a core concept: developers don't need to build every agent capability from scratch. Common capabilities like file management, news monitoring, and web scraping already have community-maintained skill packages that can be loaded. In a terminal workflow, loading a new skill is roughly equivalent to installing a plugin; you only need to declare the skill package's source and parameters in the configuration, and the agent can automatically obtain the corresponding tool's capabilities. The Claude Code Video Toolkit, as an example of community practice, adds video content understanding capabilities to the CLI environment. Although its application scenarios are still relatively vertical, it demonstrates that the capabilities of terminal agents can be continuously expanded through skill packages.

When will this process backfire on you?

There is considerable opposition to this workflow. Based on community discussions, the problems mainly focus on three areas.

The first issue is the boundary of the applicable user group. Boris Cherny's 22 Tips inherently presuppose that users need sufficient architectural deconstruction capabilities and prompt constraint abilities. Those who can independently complete system design know the boundaries of "what the agent should do and what it shouldn't do." For developers who still rely on IDE error messages, code highlighting, and breakpoint debugging to understand code logic, turning off the graphical editor is equivalent to shutting down their familiar information acquisition channel. This isn't a matter of ability, but rather a difference in the perceptual channels relied upon by their work methods. Novice developers build a mental model of the program's execution process through line-by-line debugging, and this learning process lacks an alternative in terminal workflows.

The second issue is the concentration of risk. In traditional IDEs, errors are gradually revealed during execution: compilation errors, type mismatches, runtime exceptions. Humans have the opportunity to discover and correct problems at each stage. In a plan-driven workflow, all decision-making reviews are compressed into a single node at the Plan stage. If human review at this node is insufficient, errors will be faithfully and efficiently amplified by the Agent in the Work stage. By the time you discover them, multiple files may already be contaminated with erroneous logic.

The third problem, which Matt Van Horn himself called "AI Psychosis," doesn't refer to AI itself being flawed, but rather to human error: the very act of building the agent loop can generate intense intellectual pleasure, similar to the positive feedback loop of continuous optimization in strategy games. Developers may become engrossed in refining the agent workflow itself, constantly trying new techniques, adding new sub-agents, and optimizing the plan's structure, forgetting a fundamental question: what value are you actually delivering to the user? The tool becomes the end, and the user's needs are relegated to a secondary position.

These three questions all 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 designed for those who "are still figuring out what to do." Its applicability is not limited by the choice of technology stack, but by the user's stage. If you're someone who has already drawn up a complete system architecture on paper, this workflow can increase your execution speed by an order of magnitude. If you're still understanding the problem by writing code, then the visual feedback system of an IDE is a crutch you shouldn't discard for now.

Currently, the core components of this workflow include the Claude Code CLI or Codex CLI at the runtime environment layer, the Compound Engineering plugin at the process management layer, and projects such as last30days-skill and agentmail at the skill extension layer. These are all undergoing rapid iteration, and command formats, file conventions, and the plugin system are subject to change. Developers entering the field now need to accept the fact that the pitfalls they encounter may not yet have community solutions, as the entire chain is still in its early stages of implementation and far from meeting the standards of a "stable toolchain." However, this is precisely the window of opportunity for the first wave of pioneers to establish a cognitive advantage.