There’s an entire genre of content right now about how to write better prompts.
Courses. YouTube rabbit holes. LinkedIn thought leaders with their numbered frameworks and their “steal this prompt” posts. The whole category rests on a shared assumption: prompt engineering is a writing skill, and you need to get better at it.
I’m two weeks into Anthropic’s “Building with the Claude API” course — 84 lessons, 8+ hours — and I think that assumption is slightly backwards.
Here’s what actually happened.
My first Claude Project
A few weeks ago, I built my first Claude Project. For context: a Claude Project is a persistent workspace where you give Claude a system prompt — a set of standing instructions that shape every conversation in that project. Think of it as the difference between briefing a contractor every single time versus hiring someone full-time who already knows your preferences, your standards, your quirks.
The system prompt is the job description. Get it right and everything downstream gets easier. Get it wrong, and you’re constantly correcting drift.
So I sat down to write mine.
And then I thought: Claude knows what a good prompt looks like better than I do. Why am I writing this myself?
So I didn’t. I described what I wanted the Project to do, asked Claude what a good system prompt would look like for that use case, and Claude wrote it. I read it. Made a few adjustments. Done.
The prompt I ended up with was better structured, more precise, and more complete than anything I would have written from scratch. Because Claude has seen more prompts than I ever will, knows what works, and doesn’t have my blind spots about what I might be forgetting to specify.
The insight sounds simple in retrospect: Claude is also an expert on how to talk to Claude. Of course it is. Why wouldn’t you use that?
Then I asked it what to build
While I was at it, I figured I’d push the experiment further.
I asked Claude what kind of app a software engineer should have in their portfolio right now. Claude told me. Specifically. With reasoning.
I said, “Yeah, sounds good.”
Blinked a few times.
Had a working app.
I’m going to save the full story of what that app actually is for next week — it deserves its own post. But the process is the point right now. I didn’t spend days agonising over scope. I didn’t write a product requirements doc — Claude did. And it was better than anything I would have written myself.
That’s a skill too. Maybe the more important one.
The XML thing nobody warns you about
Here’s a practical discovery from the same week that sounds boring and isn’t.
When you write a long system prompt and paste it into a Claude Project window, all formatting disappears. Headers, bold text, bullet points — gone. Everything flattens into an undifferentiated wall of text.
For a short prompt, no big deal. For a complex one — the kind with multiple sections, different rules for different situations, specific instructions that only apply in certain contexts — that wall of text is a problem. Claude is pattern-matching against a blob instead of a structured document.
The solution the course teaches: XML tags.
<instructions>
<role>You are a job application assistant...</role>
<tone>
<style>Casual and direct</style>
<avoid>Corporate jargon, buzzwords</avoid>
</tone>
<tasks>
<task>Review job postings and identify key requirements</task>
<task>Draft tailored cover letters in the user's voice</task>
</tasks>
</instructions>My first reaction was: this feels like overkill. XML is what you use for enterprise data interchange and RSS feeds. It feels heavy for what’s basically a text document.
And then it clicked.
XML is just headings. It’s the same thing your browser has been parsing your whole life to render H1s and H2s and bold text. Claude reads structure the same way your eye does when scanning a well-formatted document — the tags tell it where one concept ends, and another begins.
Long prompts need structure for the same reason long documents need headings. Not because it’s a rule. Because without it, everything runs together, and the important stuff gets lost.
Design for readability. Turns out that applies to prompts too.
Prompt engineering is a directing skill
Here’s the reframe I keep coming back to.
Every “prompt engineering” tutorial I’ve seen frames it as a writing problem. How do you phrase the request? What words do you use? How specific should you be?
But the skill that actually moved the needle for me wasn’t learning to write better prompts. It was learning to direct — to know clearly what outcome I wanted, communicate that clearly, and then get out of the way and let Claude figure out how to get there.
You’re not the author. You’re the editor. You know what good looks like. Claude knows how to ask itself to produce it.
That’s a different skill than writing. And honestly, for an engineer who spent a decade writing code to tell computers exactly what to do — it’s a harder habit to break than I expected.
The instinct to write the thing myself is deeply ingrained.
Sometimes the move is to just ask.
The Anthropic Academy’s API course covers prompt engineering — including the XML structure patterns and evaluation frameworks — as part of the full developer curriculum. Free, certified, worth your time.
Up next: Extended Thinking — what happens when you tell Claude to actually show its work.