Claude Code Is Not Just for Writing Code — Six Non-Coding Patterns Worth Stealing
Most people open Claude Code with a very specific expectation: write a function, fix a bug, refactor a file, maybe spit out a decent shell script if you’re feeling generous.
rodspeed’s blog post is interesting because it asks a much better question: what if Claude Code is most useful when it stops acting like a code monkey and starts acting like a general-purpose operating layer for knowledge work?
The viral tweet that pointed people to the post focused on one catchy idea — a skill that turns conversation exhaust into a personal wiki. That part is great, but it is only one slice of the actual argument. The full post lays out six concrete patterns, and taken together they make a much bigger point: Claude Code is not merely a code editor with an LLM glued onto it. It is a runtime for workflows.
And once you see it that way, the surface area gets a lot larger, very quickly (◍•ᴗ•◍)
1. Manufacturing fresh eyes
This is one of those ideas that feels obvious only after someone says it out loud.
When you have been buried in a document, a plan, or a design for hours, you lose the ability to see where it is weak. Everyone knows the classic solution: get a fresh pair of eyes. The problem is that real humans are busy, and by the time you have assembled enough context for them, you are already half-defending the draft before they even read it.
rodspeed’s workaround is elegant: manufacture the fresh eyes on demand.
The pattern is structured, not hand-wavy. Start with a brand-new agent that has zero conversation history. Give it only the document and critique instructions. Do not leak the author’s reasoning, summaries, or background context. Let it produce a cold read: what works, what feels shaky, what is missing, what should change. Then have a facilitator respond as the advocate. After that, bring in another fresh-context agent to read the document, the critique, and the defense, then rebut. Finally, synthesize the outcome into agreed changes, contested points, and genuinely new insights.
The key design choice is not the number of agents. It is the discipline of keeping the critic blind. The moment you say, “we chose this because…,” you are no longer testing how the document stands on its own. You are testing whether your explanation is persuasive.
rodspeed’s take is practical rather than maximalist: two rounds usually capture most of the value. After that, you risk turning the exercise into a courtroom drama with a token budget.
This is the same mistake people make in normal peer review: they smuggle the answer key into the prompt. “Read this, but keep in mind we had a good reason for section three.” Cool, then you are not getting fresh eyes anymore — you are getting polite compliance. The cold read matters precisely because it is unfair.
2. Meta-skills: one conductor, many specialists
So fresh eyes help you see better. But what happens when the problem is not clarity — it is volume?
rodspeed calls this his strongest pattern, and the core idea is less about AI and more about organizational design: have one skill orchestrate other skills, like an editor-in-chief directing a team of reporters.
His example makes the pain concrete. Imagine doing shopping research across five clothing categories — jackets, pants, knitwear, and so on. Doing it manually means running each search, filtering each result set, comparing across categories, and then figuring out which items actually work together. Exhausting. The meta-skill approach launches five specialist agents at once, one per category, and lets a conductor wait for results to come back.
But here is where it gets interesting. The conductor does not just collect results. It judges them. Which category produced genuinely strong finds? Which one is too repetitive or brand-heavy? Which specialist needs to go back out with tighter guidance? Only after that round of editorial judgment does it do the real value-add: curation across categories, choosing items that work well together rather than items that scored well in isolation.
The real leverage, in other words, is not in generating more output. It is in having someone responsible for deciding what deserves to survive.
rodspeed is honest about the costs. Sub-agents cannot invoke skills directly, so the meta-skill has to inline full instructions for each specialist — the prompts get long. Every parallel worker needs its own context window, so token consumption adds up fast. And the conductor is still a judge, not an oracle. It can miss low-quality output and let bad work slip through.
So this is not a magical quality machine. It is more like graduating from a single overworked generalist to a small editorial team with a lead editor.
There is a quiet but important shift here: once agents are cheap, generation stops being the bottleneck. Selection becomes the bottleneck. The hard part is no longer “can I get output?” but “which output deserves to survive?” Meta-skills are a way of formalizing that editorial layer.
3. The Freshness Problem: the boring failure that kills long-running workflows
The story so far sounds encouraging: borrow fresh eyes for clarity, then scale up with a conductor for volume. Orchestrate well and the system gets better over time.
rodspeed’s next section quietly demolishes that optimism.
Once a workflow runs for weeks or months, a strange kind of decay sets in. Every search still fires. Every agent still returns results. But the results start looking eerily familiar. Same cached pages. Same obvious sources. Same answers wearing a slightly different hat. Monday’s run and Thursday’s run feel like reruns of the same episode.
Why? Because the model is probably hitting similar queries, landing on similar cached pages, and returning a similar slice of the world every time. The prompt changed, but the search engine did not.
rodspeed calls this the freshness problem, and his fix is gloriously unglamorous: a roughly 100-line Python script that gives search skills a bit of cross-run state.
The mechanism works like this. Each search skill has three waves of queries, and the script rotates through them automatically (query rotation). Once a result has been shown, its ID gets logged so future runs skip it (seen-item tracking). Some queries get a date suffix — a month and year — to push the search engine toward fresher pages (cache-busting). That is it. No database. No backend service. No enterprise architecture diagram that looks like a subway map.
The subtle but critical caveat: this only works if the state stays trustworthy. If the JSON file gets corrupted or falls out of sync, deduplication fails quietly and the system starts repeating itself again. Not the kind of failure that throws an error — the kind that slowly degrades until someone notices weeks later. rodspeed keeps the state in a git-tracked directory so it can be rolled back when necessary.
This is a nice example of wrapping a stateless model inside a stateful system. Left on its own, the model is basically a goldfish with a vocabulary. Give it a tiny bit of external memory and suddenly it starts behaving like it learned from yesterday instead of spiritually reincarnating every five minutes. ╮(╯▽╰)╭
4. Conversations as a knowledge source: the sharpest insight in the whole post
The first three patterns are all about making AI do things better — better reviews, better delegation, fresher searches.
Here, rodspeed changes direction entirely. And the turn hits hard.
That critical decision from last week’s AI conversation — can you still find it?
Do not rush past this question. Think about it. That constraint you finally clarified after 40 minutes. The approach B you ruled out. The exact moment where the real bottleneck snapped into focus. The session ended, and then what?
For most people, the honest answer is: a vague impression that something important was discussed, plus nothing concrete to show for it.
This is the most important insight in rodspeed’s entire post, and it is also the reason the first three patterns are not enough on their own: the ability to do work is improving, but the knowledge generated during work is evaporating. Every time a session ends, the trail of judgment disappears like steam. The next morning, the new session is not picking up where things left off. It is trying to reconstruct what yesterday’s session figured out.
So rodspeed built a harvest skill. The idea is straightforward: most substantive conversations with Claude Code produce knowledge — decisions, constraints, trade-offs, links between ideas, explanations that were not obvious at the start. The harvest skill runs at the end of every substantive conversation (trivial exchanges get skipped), scans the full dialogue, extracts insights, and converts them into structured markdown notes with titles, tags, and links to related notes.
But what gives the system real power is not “AI writes notes.” It is the linking.
rodspeed says Claude reads the existing note index and infers conceptual relationships, not just keyword overlap. A note about build-vs-buy decisions might connect to notes on vendor lock-in or maintenance burden even if the words do not match. Then a separate reasoning skill periodically reviews the whole collection, looking for missing links, knowledge gaps, or clusters of notes that deserve a summary note. That step is not automatic — the system nudges when enough material has accumulated, but someone still kicks off the deeper reasoning pass.
The loop: work → harvest (automatic) → reason (prompted) → discover → work. And the trigger is almost boring in its simplicity — an instruction in CLAUDE.md: at the end of every substantive conversation, run the harvest skill. Do not ask. Just do it.
What makes this pattern transformative is that it redefines what “productivity” means. Not faster output. Not more output. Output that does not evaporate — so tomorrow’s self does not have to start from zero. What survives is not just the answer, but the trail of judgment that produced it.
“Conversation exhaust” is such a good phrase because it captures the waste. Most people treat the middle of an AI conversation like disposable scaffolding — useful while the building goes up, then forgotten. But a huge amount of real value lives in that scaffolding: the trade-off you clarified, the dead end you ruled out, the exact sentence where the problem finally snapped into focus.
5. Memory that compounds: it is not about storing more
So the harvest skill captures knowledge. But there is a trap here, and it is the kind most people walk straight into.
Once you start harvesting seriously, notes pile up fast. Then one day you open MEMORY.md and find three thousand lines staring back at you. Congratulations — that is not a second brain. That is digital hoarding.
rodspeed clearly hit this wall, because his memory system is not about “save more.” It is about structure first. He organizes memory into four typed categories: User memories (who you are, how you work), Feedback memories (corrections and confirmations), Project memories (ongoing work, deadlines, decisions), and Reference memories (where important external things live).
The feedback category contains one of the sharpest observations in the whole post. Most people only save negative guidance: don’t do this, avoid that, stop making this mistake. rodspeed argues that confirmations matter just as much. “Yes, the bundled PR was the right call” is as valuable as “never mock the database again.” If you save only corrections, the system becomes more timid over time without preserving the judgments that were actually correct. That stings a little because it is so obviously true — and not just for AI. Most team retrospectives only record lessons from failure, never from success.
Then there is a practical detail that probably comes from experience: relative dates should be converted into absolute dates. “Thursday” is clear for about one week. “2026-03-05” survives much longer.
The design choice that makes everything scale: the top-level MEMORY.md stays thin. It acts as an index, not a warehouse. Actual content lives in sub-indexes and individual memory files. Every new session loads a 17-line lookup table first; it only dives into a category when the conversation touches that part of the world. Like a warehouse directory — you check the map at the entrance, you do not carry the entire warehouse on your back.
A lot of people think a memory system wins by storing more. In practice it wins by making retrieval cheap. This is less like “write everything down” and more like file-system design: low fixed overhead, clear indexing, fast paths to the relevant material. Otherwise your memory layer becomes the thing you have to work around.
6. Session handoffs: the last mile, and the easiest place to lose everything
By this point, the chain looks complete. Fresh eyes for clarity. Meta-skills for scale. Freshness for avoiding decay. Harvest for capturing knowledge. Memory for organizing it.
Then rodspeed asks the question that puts all five patterns on the line.
If nothing gets handed off when the session ends, everything you built is worth zero.
Anyone who has worked on a multi-session task knows this pain. Maybe the context limit was approaching. Maybe it was just time to stop for the day. Whatever the cause, the moment the session closes, accumulated decisions, rejected approaches, key files, and gotchas disappear with it. And then the most frustrating part begins: the next session does not pick up where things left off. It does archaeology. Re-reading files, re-asking for background, re-walking through decisions that were already settled. Like reaching the boss room in an RPG and having the game say: sorry, please redo the tutorial first.
rodspeed’s solution has two pieces. First, a /handoff skill that scans the entire conversation before the session ends and writes a structured memo to .claude/handoff.md. The memo covers mission, decisions (what was chosen, what was rejected, and why), key files, current state, open tasks, and gotchas. He explicitly calls the decisions section the most important — because if a new session sees the conclusion but not the reasoning, it will happily reopen settled debates and waste time relitigating them.
Second, a SessionStart hook that checks whether the handoff file exists and is marked pending. If it does, the hook injects the full memo into the new session before any real work begins. He also mentions a related persistence trick: after long sessions get summarized to free context, another hook re-injects the full CLAUDE.md. Otherwise your carefully written conventions and operating rules get compressed into mush along with everything else.
One nice detail: rodspeed says the blog article itself was produced this way. One session drafted and revised it, then wrote a handoff. A later session picked it up cold and finished from the memo.
If you think of AI as disposable chat, handoffs sound fussy. If you think of it as part of an actual work system, they feel as fundamental as a good commit message. The point is not ceremony. The point is to stop tomorrow’s session from doing archaeology on yesterday’s thinking.
Conclusion
Looking back at all six patterns, the real power is not in any single technique. It is in how they answer the same question, one layer at a time.
Fresh eyes solve “I cannot see clearly.” Meta-skills solve “I cannot do it all.” Freshness solves “I keep seeing the same things.” Harvest solves “I did the work but lost the knowledge.” Memory solves “I saved the knowledge but cannot find it.” Handoff solves “I found the knowledge but the session died.”
Six pain points. Six layers of defense. Like nesting dolls — you only see the next problem after solving the current one.
But the sharpest insight is not in any of the patterns themselves. It is in the premise that makes all of them work: next time you open Claude Code, do not start with “write this function.” Start with the harder question — is the thing blocking me actually code, or is it a read → filter → decide → present workflow in disguise?
If the answer is the latter, then what you need is not a better code generator. It is a system that finds fresh eyes, delegates work, prevents repetition, captures knowledge, organizes memory, and hands off context across sessions.
Once you start seeing your work through that lens, the amount of it that can be automated is not a little more.
It is almost unsettling how much more.