@uniswap12: I'm truly impressed by how far Claude Code can be used. Matt Van Horn recently wrote a long article revealing all his tips and workflows for using Claude Code. This article sparked considerable discussion in the developer community because what he showed goes far beyond 'using AI...'

X AI KOLs Timeline News
claude-code ai-coding workflow plan-driven-development voice-input compound-engineering ai-productivity

Summary

Matt Van Horn shares advanced workflows for using Claude Code: first plan in detail via plan.md, then use voice input and multi-window parallel execution, demonstrating how to deeply integrate AI into the development process, greatly improving efficiency.

I'm truly impressed by how far Claude Code can be used. Matt Van Horn recently wrote a long article revealing all his tips and workflows for using Claude Code. This article sparked considerable discussion in the developer community because what he showed goes far beyond 'using AI to help write code.' His core claim is just one sentence: no IDE, only plan.md files and voice. It sounds like bragging, but after seeing his entire setup, you realize he's serious. Everything starts with planning; code is the last thing written. Matt says the most important lesson he learned is: as soon as an idea pops into your head, your first reaction should always be /ce: plan. Whether it's a crazy product idea, a GitHub bug report, or an error message in the terminal, he first takes a screenshot or copies the link, throws it into Claude Code, and asks it to produce a plan. The mechanism behind the /ce: plan command is quite interesting. It simultaneously launches multiple research agents working in parallel: one analyzes your codebase, reads files, finds patterns, checks coding standards; another goes through your past bug-fixing experience documents; if the topic requires it, more agents look up external best practices and framework documentation. All run concurrently and finally aggregate into a structured plan.md, detailing what the problem is, what solution to use, which files to modify, and checkboxes for acceptance criteria. All of this is based on your own codebase and history, not generic advice. Then /ce: work takes that plan and executes it—breaking down tasks, writing code, running tests, and checking off acceptance criteria one by one. If context is lost midway, you can start a new session pointed to that plan and continue. The plan file is a never-lost checkpoint. Traditional development is 80% coding, 20% planning. Matt completely flips this ratio. Thinking happens in the plan; execution is delegated to the machine. This philosophy applies not just to coding but to any complex task: spend more time figuring out what to do and how to do it, then automate execution as much as possible. Many people jump in and figure things out on the fly, often realizing halfway that they're heading in the wrong direction and have to start over. Everyone knows to plan before executing, but Matt uses tools to make it a mandatory workflow—and that's the key. Compound Engineering: The plugin that makes plan-driven development a reality. The setup that truly makes this plan-first workflow work is a plugin called Compound Engineering, from the company Every. The installation command is just one line: /plugin marketplace add EveryInc/compound-engineering-plugin. Matt went from a die-hard fan of this plugin to the third-largest contributor on GitHub, with 21 commits. He now has 70 plan files and has submitted 263 commits in the last 30 days. He sets a hard rule for himself: unless it's literally just a one-line change, he always writes a plan.md first. That number alone is telling. 70 plan files correspond to 263 commits, meaning each plan produces on average nearly 4 commits. The clearer the plan, the higher the execution efficiency, and the lower the rework probability. This echoes the 'upfront investment' emphasized in many project management methodologies, but Matt has applied it to daily development work with tool support. Voice input: When the listener is smart enough, speaking becomes the most efficient input method. Matt says he used to hate voice memos—Apple's built-in dictation made him want to throw his phone. But voice-to-LLM is completely different. Transcription doesn't need to be perfect because Claude Code understands context and guesses what the microphone missed. You can be slurred, go off-topic, restart—it doesn't matter. The tool he uses is called Monologue, also from Every, which inputs your speech directly into the currently focused app. You speak, and it types into Claude Code. He even bought a gooseneck microphone for his desk. More impressively, when writing that article, he dictated a section while driving his kids using Tesla's FSD (Full Self-Driving) mode. The core problem that made voice input historically unusable is transcription accuracy. Every word must be correctly recognized, or errors occur. But when the receiver changes from a rigid word processor to a context-aware AI, that bottleneck disappears. The AI doesn't need every word crystal clear; it can infer your meaning from context. This small change unlocks a new human-computer interaction: you can talk to AI like you talk to a colleague, without meticulously choosing words, worrying about phrasing, or even grammar. Four to six parallel windows: One person operating like a team. Matt's daily work state is running four to six Ghostty terminal windows simultaneously, each with an independent Claude Code session. One is writing a plan, another is building code based on another plan, one is running /last30days for research, and another is fixing a bug he discovered while testing the previous feature. When /ce: plan launches research agents in one window, he switches to another window running /ce: work on a plan already written. While that builds, he pastes a new bug into a third window. By the time he returns to the first window, the plan is ready, quietly sitting in the editor. To make this parallel mode work, he changed three key configurations. First, skip permission confirmation—Claude Code defaults to asking for 'Allow' on every action, but he grants all permissions in the config file, letting each session run fully autonomously. Second, play a sound on completion so he can walk away and return when he hears it. Third, set Zed editor to auto-save every 500 milliseconds so that when Claude Code modifies a file, the editor updates instantly; conversely, when he types in the editor, Claude detects it within a second. The whole experience feels like collaborating on Google Docs, except the collaborator is an AI. The trade-off is obvious: his MacBook runs out of battery in about an hour because six concurrent Claude sessions consume a lot of power. He just ordered a new MacBook Pro. But from another perspective, it's unimaginable for one person to simultaneously advance four to six tasks. In the past, you needed a team to parallelize different workflows. Now, one person plus a set of AI sessions can achieve it. /last30days: Before making any decision, see what the community is talking about. Before doing /ce: plan, Matt often runs a research tool called /last30days, which he open-sourced and has already garnered 4500 stars on GitHub. It searches Reddit, X, YouTube, TikTok, Instagram, Hacker News, Polymarket, and the web in parallel, pulling back all community discussions on a topic in the last 30 days within minutes. He gave an example. He was choosing between Vercel's agent-browser and Playwright. Instead of reading documentation, he ran /last30days. Minutes later, results appeared: 78 Reddit posts, 76 tweets, 22 YouTube videos, 15 Hacker News discussions. The data showed agent-browser uses 82% to 93% fewer context tokens than Playwright—Playwright's tool definition alone consumes 13,700 tokens. He then fed all the output into /ce: plan, which produced a plan based on the current real-world community knowledge, not training data from six months ago. The value of this approach: AI model training data always lags behind, but technical community discussions are real-time. First, capture the latest community consensus with a tool, then let the AI plan based on that information—decision quality improves significantly. This idea applies not just to tech choices but also to product decisions, market research, and competitive analysis: see what real users are talking about rather than working in isolation. Lunch chat becomes product proposal: The compound effect of context. Matt told a particularly interesting story. He had lunch with a potential candidate, chatting for 1.5 hours about a new product idea, food, restaurants, kids—everything. He kept Granola recording throughout. After lunch, he pasted the full meeting transcript into Claude Code and asked it to turn the conversation into a product proposal. The key: Claude Code already knew the company's product code location on GitHub and had access to every strategic plan.md he had written. So when processing the lunch conversation, it didn't just extract product ideas; it cross-referenced them against the actual codebase and all past strategic decisions. The result was an excellent proposal generated in one go, complete with goals, user stories, technical plans, and milestones, automatically ignoring the parts about restaurants and sushi. He sent it to the candidate that evening; the candidate later joined full-time and is now working on that product. The most noteworthy concept in this story is the 'compound effect of context.' Every strategic document you've written, every technical decision you've made, every accumulated experience—if stored in a structured way, they become references for the AI's next decision. The longer it goes, the more you accumulate, and the more accurate the AI's suggestions become. It's like compound interest: in the early stages, the difference is barely noticeable, but over time, the gap widens significantly. Mac Mini becomes 24/7 online AI workstation. Matt has a Mac Mini specifically running OpenClaw, but he also uses it for two clever purposes. First, remote control via Telegram. Claude Code has a Telegram integration. He sends messages to the Mac Mini from his phone. If he thinks of a bug while eating, he types /ce: plan fix the timeout issue into Telegram, and by the time he returns to his desk, the plan is waiting in the editor. Second, using tmux on airplanes. Claude Code handles airplane WiFi poorly—the session dies when the connection drops. But if he first tmuxes into the Mac Mini, the session runs on that machine, and the laptop is just a window. WiFi drops for 20 minutes? Reconnect and the session is still there, still working. He was deploying features throughout his entire flight back from Europe. A Mac Mini costing a few thousand yuan, with a few configurations, becomes a 24/7 remote-schedulable AI workstation. This approach offers extremely high cost-effectiveness and is worth considering for anyone needing to run AI tasks long-term. Cost strategy: Claude handles thinking; Codex handles execution. Such intensive usage naturally raises cost concerns. With four to six Opus sessions running all day in parallel, the $200/month Claude Max plan burns through quickly. Matt's solution: buy another $200/month Codex plan. He contributed a /ce: work --codex feature to Compound Engineering that automatically switches to Codex for execution when Claude's quota runs low. The two plans complement each other: Claude handles planning and orchestration; Codex handles heavy code implementation. Some friends use Codex to review Claude Code's output and vice versa. Others prefer Codex's code quality but use Claude Code for orchestration. This approach of having different AIs specialize in different roles mirrors managing a team: you wouldn't have the same person do both strategic planning and detailed execution. The same goes for AI—let the thinkers think, and let the doers do. He also mentioned a 'goodnight mode' where agents keep working while he sleeps, but he said he'll explain how in another post. Just the concept is exciting enough—it effectively extends your work time from 15–16 hours a day to 24 hours. Disney World: This workflow isn't just for coding. At the end of the article, Matt shares a vivid real-world case completely unrelated to coding. He was at a soccer field watching his kid play, and another parent talked to him about planning a Disney World trip. He pulled out his laptop right there. First, he ran /last30days Disney World. Two minutes later, he had 66 Reddit posts, 34 tweets, 8 YouTube videos of latest information, including price trends, which attractions are under maintenance, and which are reopening soon. Then he used /ce: plan to input his requirements: visit four parks in one day, which rides he wants, budget, kids' ages. Claude's research agents cross-referenced the data and produced a structured guide, including park order, FastPass reservation strategy, alarm reminders to set a week in advance, and even children's height requirements. He also helped that parent create a three-day guide—305 lines—with day-by-day itineraries and a reminder to 'first measure your five-year-old's height while wearing shoes this week.' Then he had Claude deploy the guide as a Vercel webpage for easy mobile viewing. Finally, he sent the plan via Telegram to OpenClaw to set reminders on the calendar and also set up a cron job for double insurance. Voice to research to plan to website to auto-reminders—all done from the soccer field sidelines. The significance of this case: it proves this workflow applies far beyond software development. The cycle of research, planning, execution, deployment, and automation works for any scenario that involves processing complex information and making decisions. Travel planning is just one example; market research, event planning, investment analysis—the logic is the same. Matt closes his article with a summary of his entire setup: One voice app, one plan file plugin, three configuration changes, four to six parallel sessions, one Mac Mini, plus lunch meetings that turn into product proposals. No IDE, no code. Speak, plan, build. At the desk, on the couch, in the car, on the field. Perhaps the greatest value of this article is not the specific tools and configurations, but the new work paradigm it showcases: humans handle thinking and decision-making; AI handles research and execution. When you refine the collaboration flow between them to be smooth enough, what one person can achieve exceeds your wildest imagination. And it all starts with a simple habit: when an idea strikes, write a plan first. #AI #AIAgent @grok
Original Article
View Cached Full Text

Cached at: 06/08/26, 07:21 AM

Claude Code Used to This Extent — I’m Impressed

Matt Van Horn recently published a long article spilling all his tips and workflows for using Claude Code. It caused quite a stir in the developer community because what he shows goes far beyond “using AI to assist with coding.” His core argument is just one sentence: no IDE, just plan.md files and voice. It sounds like bragging, but after reading his entire setup, you realize he’s serious.

Everything starts with a plan — code is written last

Matt says the most important thing he’s learned is: the moment an idea pops into your head, your first reaction should always be /ce: plan. Whether it’s a crazy product idea, a GitHub bug report, or an error message in the terminal, he always takes a screenshot or copies the link, throws it into Claude Code, and asks for a plan first.

The mechanism behind the /ce: plan command is pretty interesting. It launches several research agents in parallel — one analyzes your codebase, reads files, finds patterns, checks coding conventions; another digs through your past bug-fixing experience docs; if needed, more agents look up external best practices and framework documentation. Everything runs simultaneously and eventually merges into a structured plan.md that clearly states the problem, the proposed solution, which files need to change, acceptance criteria with checkboxes — and all of this is based on your own codebase and history, not generic advice.

Then /ce: work takes that plan and executes it — breaks down tasks, writes code, runs tests, ticks off acceptance criteria one by one. If context is lost mid-session, you can open a new session pointing to that plan and continue. The plan file is a save point that never disappears.

Traditional development is 80% coding, 20% planning. Matt has completely flipped that ratio. Thinking happens in the plan, execution is handed to the machine. This idea doesn’t just apply to writing code — for any complex task, spending more time figuring out what to do and how to do it, then automating execution as much as possible, yields much higher efficiency. Many people jump in and start doing things, thinking as they go, only to find halfway through that they’re heading in the wrong direction and have to start over. Everyone knows the principle of planning first, then executing — but Matt turned it into a mandatory workflow using tools. That’s the key.

Compound Engineering: the plugin that makes plan-driven development real

The workflow that makes this plan-first approach actually work is a plugin called Compound Engineering from Every Inc. The install command is just one line: /plugin marketplace add EveryInc/compound-engineering-plugin.

Matt went from being a loyal fan of this plugin to its third-largest contributor on GitHub, with 21 commits. He now has 70 plan files and has made 263 commits in the last 30 days. He’s set himself a hard rule: unless it’s literally a one-line change, always write a plan.md first.

That number speaks volumes. 70 plan files correspond to 263 commits, meaning each plan yields nearly 4 commits on average. The clearer the plan, the higher the execution efficiency, the lower the rework rate. This is the same principle emphasized in many project management methodologies — “front-loading” — except Matt has applied it to his daily development work, with tools to enforce it.

Voice Input: when the listener is smart enough, speaking becomes the most efficient input method

Matt says he used to hate voice memos — Apple’s built-in dictation feature made him want to throw his phone. But voice-to-LLM is completely different. Transcription doesn’t need to be perfect because Claude Code understands context and can guess what the microphone missed. You can mumble, go off-topic halfway, restart — none of that matters.

The tool he uses is called Monologue, also from Every Inc. It takes what you say and inputs it directly into the currently focused application. You speak, it types into Claude Code. He even bought a gooseneck microphone for his desk. What’s more, he wrote part of that article while driving his kids around on Tesla FSD, dictating with his voice.

The reason voice input has always been terrible is the core problem of transcription accuracy. Every word you say must be recognized perfectly, or errors occur. But when the receiver changes from a rigid word processor to a context-aware AI, that bottleneck disappears. The AI doesn’t need every word crystal clear — it can infer your meaning from context. This change seems small, but it actually unlocks a whole new mode of human-computer interaction: you can talk to the AI the way you talk to a colleague, without weighing every word, worrying about phrasing, or even grammar.

Four to six windows running in parallel: one person, one team

Matt’s daily work mode is to have four to six Ghostty terminal windows open simultaneously, each running an independent Claude Code session. One is writing a plan, another is building code based on a different plan, another is running /last30days for research, and yet another is fixing a bug he found while testing the previous feature.

While one window’s /ce: plan is spinning up research agents, he switches to another window running /ce: work to execute an already-written plan. While that one is building, a third window gets a new bug pasted in. By the time he switches back to the first window, the plan is already done, waiting quietly in the editor.

To make this parallel work mode feasible, he changed three key configurations. First, skip permission confirmations — by default Claude Code asks for “allow” on every action, he opened up all permissions in the config file so each session runs autonomously. Second, play a sound upon completion — so he can walk away and come back when he hears the chime. Third, set Zed editor to auto-save every 500 milliseconds — so when Claude Code changes a file, the editor updates instantly; conversely, when he types in the editor, Claude perceives it within a second. The whole experience feels like collaborating on Google Docs, except the collaborator is an AI.

The cost of this workflow is obvious: his MacBook dies in about an hour — six Claude sessions running in parallel drain the battery hard. He just ordered a new MacBook Pro. But think about it: one person pushing four to six tasks forward simultaneously was previously unimaginable. You used to need a whole team to parallelize different workflows. Now one person plus a set of AI sessions can do it.

/last30days: before making any decision, see what the community is talking about

Before doing /ce: plan, Matt often runs a research tool called /last30days. He open-sourced it himself — it already has 4,500 stars on GitHub. It searches Reddit, X, YouTube, TikTok, Instagram, Hacker News, Polymarket, and the web in parallel, pulling back all community discussions on a topic from the past 30 days in minutes.

He gave an example. When he was choosing between Vercel’s agent-browser and Playwright, instead of reading docs, he ran /last30days. Minutes later, results came back: 78 Reddit posts, 76 tweets, 22 YouTube videos, 15 Hacker News discussions. The data showed agent-browser uses 82%–93% fewer context tokens than Playwright — Playwright’s tool definition alone eats 13,700 tokens.

He then fed all that output into /ce: plan, and the resulting plan was based on the real-time understanding of the community, not six-month-old training data.

The value of this approach: AI models’ training data is always lagging, but tech community discussions are real-time. First, use a tool to grab the latest community consensus, then let the AI plan based on that — decision quality improves dramatically. This idea isn’t limited to tech choices; for product decisions, market research, or competitive analysis, seeing what real users are talking about is far more reliable than brainstorming in a vacuum.

Lunch chat turns into product proposal: the compounding effect of context

Matt told a particularly interesting story. He had lunch with a potential candidate, talking for an hour and a half — covering a new product idea, food, restaurants, kids, everything. He kept Granola recording the entire time.

After lunch, he pasted the full meeting transcript into Claude Code and asked it to turn the conversation into a product proposal. The key: Claude Code already knew where their product code lived on GitHub and had access to every strategic plan.md he’d written before. So when processing the lunch conversation, it didn’t just extract the product idea — it cross-referenced it against the actual codebase and all past strategic decisions.

The result came out great in one shot — goals, user stories, technical approach, milestones — automatically ignoring the parts about restaurants and sushi. He sent it to the candidate that evening. That person later joined them full-time and is now working on that product.

The most notable concept in this story is “the compounding effect of context.” Every strategic document you’ve written, every technical decision you’ve made, every piece of experience you’ve accumulated — if saved in a structured way, becomes reference material for the AI’s next decision. Over time, the more you accumulate, the more accurate the AI’s suggestions become. It’s like compound interest: early on, the difference is negligible, but as time goes on, the gap widens dramatically.

Mac Mini becomes a 24/7 AI workstation

Matt has a Mac Mini dedicated to running OpenClaw, but he also uses it for two clever things.

First, remote control via Telegram. Claude Code has Telegram integration — he just sends messages from his phone to the Mac Mini. Think of a bug during dinner? Type /ce: plan fix the timeout issue into Telegram, and by the time you get back to your computer, the plan is already waiting in the editor.

Second, using tmux on airplanes. Claude Code handles airplane WiFi poorly — a dropped connection kills the session. But if he tmuxes into the Mac Mini, the session runs on that machine, and his laptop is just a window. WiFi drops for 20 minutes? No problem — reconnect, session is still there, still working. He shipped features the entire flight from Europe back home.

A few-thousand-dollar Mac Mini, plus some configuration, becomes a 24/7 AI workstation that can be dispatched remotely anytime. The cost-effectiveness of this approach is extremely high — for anyone who needs to run AI tasks for long periods, it’s worth considering.

Cost strategy: Claude handles thinking, Codex handles grunt work

Such intensive usage naturally comes with cost implications. Four to six Opus sessions running all day will burn through the $200/month Claude Max plan quickly.

Matt’s solution is to add another $200/month Codex plan. He submitted a /ce: work --codex feature to Compound Engineering — when Claude’s quota runs out, it automatically switches to Codex for execution. The two plans complement each other: Claude handles planning and orchestration, Codex handles heavy code implementation.

Some friends use Codex to review code written by Claude Code, and vice versa. Others prefer Codex’s code output quality but use Claude Code for orchestration. This “let different AIs do what they’re best at” approach is like managing a team: you wouldn’t have the same person doing both strategic planning and hands-on execution. Same for AI — let the thinkers think, let the doers do.

He also mentioned a “good night mode” that lets agents keep working while he sleeps, but he’ll explain how later. Just the concept is exciting enough — it means your work hours go from a dozen or so per day to 24 hours.

Disney World: this workflow isn’t just for code

At the end of the article, Matt tells a vivid story completely unrelated to code. Watching his kids at a soccer game, a parent next to him talked about planning a Disney World trip. He pulled out his laptop on the spot and demonstrated.

First, run /last30days Disney World. Two minutes later, he had 66 Reddit posts, 34 tweets, and 8 YouTube videos with up-to-date info — price trends, which rides are under maintenance, which are reopening soon. Then with /ce: plan, he input his requirements: four parks in one day, rides they want to do, budget, kids’ ages. Claude’s research agents cross-referenced the data and wrote a structured guide, including park order, FastPass booking strategy, alarm reminders to set a week in advance, and even kids’ height requirements.

He also made a three-day itinerary for the other parent — 305 lines, with daily schedules and a note saying “make sure your five-year-old wears shoes when you measure their height this week.” Then he told Claude to deploy the guide as a Vercel webpage so it’s easy to view on a phone. Finally, he sent the plan to OpenClaw via Telegram, which set reminders on the calendar and set up cron jobs as a backup.

Voice → research → plan → website → automated reminders — all done from the soccer sidelines.

The significance: this workflow applies far beyond software development. Research, plan, execute, deploy, automate — this loop works for any scenario that requires processing complex information and making decisions. Travel planning is just one example; replace it with market research, event planning, or investment analysis — the logic is the same.

Matt concludes his article with his full setup:

A voice app, a plan file plugin, three configuration changes, four to six parallel sessions, a Mac Mini, and lunch meetings that turn into product proposals. No IDE, no code. Speak, plan, build. At the desk, on the couch, in the car, at the soccer field.

The greatest value of this article might not be the specific tools and configurations, but the new work paradigm it demonstrates: humans think and decide, AI researches and executes. When you polish the collaboration between the two to be smooth enough, what one person can achieve goes far beyond imagination.

And it all starts with one simple habit: when you have an idea, first write a plan.

#AI #AIAgent @grok

Similar Articles

@yaohui12138: I've finished reading it. Here are some key takeaways I've compiled for everyone: In this session, he primarily broke down a core mechanism overlooked by 90% of users: the CLAUDE.md context injection system. This system is divided into three levels: Enterprise-level: Organization-wide mandatory rules that cannot be overridden by individual settings. Project-level: Team-shared code standards and workflows. Loc...

X AI KOLs Timeline

The article shares key insights from a workshop by Boris on using CLAUDE.md for context injection in Claude, highlighting three usage levels, specific commands like /loop, and plan mode to improve developer workflows.