Claude Feels Exhausting Because You Are Using It Like Chat, Not Infrastructure

Last week, I used Claude Code to produce several pieces of content across very different topics: Claude Code engineering setup, AI search visibility, and a multi-app iOS development workflow.

The surprising part was not that the writing became faster.

The surprising part was that I stopped repeating myself.

Before this, writing with Claude often had the same failure pattern. Halfway through a draft, I would have to explain the background again. The same formatting issue would come back. The same audience assumptions would need to be restated. The same style corrections would be made over and over.

This week, that mostly disappeared.

The difference was not a better prompt.

The difference was treating Claude Code as an engineering system instead of a chat tool.

Most People Use Claude Like a Chat App

That is the core problem.

A chat app assumes a simple loop:

I describe what I want. The AI gives me an answer. The conversation ends. Next time, we start again.

That is fine for one-off questions. It breaks down for recurring creative work.

Writing is not a one-off action. You have fixed style rules, fixed publishing platforms, fixed audience assumptions, fixed formatting conventions, and fixed quality standards. If you explain all of that every time, you are using human labor to maintain context that should already exist in the system.

That is why many people feel more tired the more they use AI.

They are not reducing work. They are manually rebuilding the same working environment inside every prompt.

The Shift: From Prompting to Context Engineering

The real improvement came from three layers.

1. CLAUDE.md as the Project Specification

Every writing repository should have a project-level instruction file.

For me, that file defines:

• writing style
• banned phrases
• platform formatting rules
• closing format
• image conventions
• reader profile
• publishing workflow

The important part is not that CLAUDE.md is long. It does not need to be.

The important part is that Claude does not enter the project blind. When I open Claude Code inside that directory, the system already knows the local rules.

I no longer need to write a mini operating manual inside every prompt.

2. Skills as Reusable Workflows

Some tasks happen again and again:

• write a WeChat article
• create an English version
• turn an article into a Twitter/X thread
• prepare a weekly review
• publish to a platform

If I explain these workflows from scratch every time, I am the bottleneck.

So I turn them into Skills.

A Skill does not need to be fancy. Even a written workflow is better than an improvised prompt. The point is to make the recurring process explicit and reusable.

Once a workflow becomes a Skill, I stop asking Claude to guess the process. I ask it to execute the process.

3. A Material Folder for Each Article

Every article has its own working directory.

Inside that directory, I keep a materials folder with notes, references, links, drafts, and source files.

That changes the collaboration.

Instead of explaining the background verbally, I can let Claude read the files. The model works from actual context, not from whatever summary I happen to type that day.

These three layers are simple:

• project rules
• reusable workflows
• article-specific materials

Together, they change the nature of the work.

Claude stops behaving like a clever answer machine and starts acting like part of a production environment.

How the Workflow Actually Ran This Week

The first layer was input.

I maintain an AI_Clippings folder in my writing repository. When I find a useful article, I save it as Markdown with Obsidian Web Clipper.

This week, I saved around 20 pieces: Anthropic feature announcements, a Shopify Claude Code setup write-up, Codex team notes, and various Claude usage patterns.

Most of these clippings did not become articles immediately.

That is the point.

They create a searchable local memory. When I sit down to choose topics, I am not starting from an empty screen. I have material with density.

The second layer was production.

For one article, the process looked like this:

1. Create a directory for the article.
2. Put the source material into the materials folder.
3. Open Claude Code in that directory.
4. Let it load the project context.
5. Invoke the writing workflow.
6. Review the draft section by section.
7. Push the final version through the publishing workflow.

My job was not to type every sentence.

My job was to judge: what matters, what is too soft, what sounds like documentation, what should be cut, what should be sharper.

Claude’s job was to organize language, structure the argument, format the output, and handle the mechanical parts.

That division of labor matters.

If you ask AI to decide what is important while you manually polish sentences, you have reversed the leverage.

English Adaptation Is Not Translation

After finishing a Chinese article, I usually create several English versions.

Not translations. Adaptations.

Medium, Substack, and Twitter/X are not the same container.

Medium can support a complete argument with a slower build. Substack works better when the point is denser and more personal. Twitter/X needs each post to carry one standalone idea.

So the workflow is not:

Chinese article in, English article out.

It is:

Chinese argument in, platform-specific version out.

Claude is useful here because it already has the original article, the platform rules, and the project style.

I do not need to say:

“Please remember my tone, avoid generic AI writing, keep the argument sharp, do not over-explain, and turn this into a Twitter thread.”

Those constraints should live in the system.

What You Can Copy

If you want to build a similar setup, start with three things.

First, write a CLAUDE.md

Keep it short.

Define:

• who you write for
• what your voice should sound like
• which phrases you do not want
• how each platform should be formatted
• how images should be handled
• what a finished draft should include

This file is not decoration. It is the base layer of the working environment.

Second, turn recurring tasks into Skills

If you do something more than twice, write down the workflow.

Do not wait until it is perfect.

A rough workflow is still better than reconstructing the same process from memory every time.

Third, build a material capture habit

Use Markdown folders, Notion, Bear, Obsidian, or whatever you already use.

The tool matters less than the habit.

When you see something useful, save it in a form that can be searched and reused. Do not rely on “I vaguely remember seeing something about this.”

That sentence is where good ideas go to die.

The Real Bottleneck Is Not the Model

The lesson from this week is simple:

Writing faster with AI is not mainly about the model being smarter.

It is about the context being clearer.

When context is structured, output becomes more stable. Revision gets smaller. The workflow gets faster.

When context is improvised inside every prompt, you are not really using AI to build leverage.

You are using AI to manually repeat work that should have been systematized.

That is the part that took me a while to understand.

The upgrade is not a magic prompt.

The upgrade is turning your writing process into infrastructure.