How I Learned to Write with AI (By Slowing Down)

I expected AI to make writing faster. Instead, it made it slower - and much better.

When I sat down to write my first blog post about AI orchestration, my instinct was simple: dump my thoughts into Claude, ask it to write an article, iterate until it looked good. The result was readable. It was also... bland. It could have been written by anyone, about anything.

I tried something different. A structured, file-based process that forced me to slow down. And somewhere in that slowness, I found the breakthrough.

The Problem with Chat

AI models are trained on the entire internet. Without guidance, they produce the statistical average of everything they've read. It's like taking the average tone of millions of people - readable, but indifferent. Anthropic calls this "distributional convergence." The output works. It just doesn't say anything.

Most people respond to this in one of two ways. They "prompt and pray" - throw their thoughts at the AI and hope for magic. Or they go back and forth refining in the chat. They change this and tweak that, without a cohesive direction. Neither produces writing that actually says something.

Why Files Change Everything

The breakthrough came when I switched from chat to files.

Files feel permanent. You don't fill a document with half-baked thoughts, the way you might fire off a quick chat message. You pause. You think. You wouldn't negotiate a contract verbally and trust your memory; you write it down, review it, and sign it. The same psychology applies here.

Files can be revisited. I found myself stepping away for hours to mull over my answers. Chat invites rapid-fire responses. Files invite reflection. I'd come back with fresh eyes and add a tangential example I'd thought of, or refine a point that felt weak.

Files enable meta-analysis. They accumulate across sessions. I can ask Claude to study all my past articles and draw out common themes - fodder for future writing.

The Process That Emerged

I developed a seven-phase process:

1. Discovery - A questionnaire to extract what I actually want to say
2. Critique - Stress-test my thinking before drafting
3. Understanding - Claude confirms what it understood
4. Structure - Choose a narrative approach
5. Outline - Detailed section-by-section plan
6. Draft - Write following established principles
7. Assets - Supporting materials (optional)

You can use all seven or adapt to your needs. But three of them are where the real value emerges.

The Critique Phase

This was the most surprising part.

Before drafting, Claude stress-tested my argument. The goal wasn't to defeat my thesis but to identify weak points, missing evidence, and objections I should pre-empt. The challenges were rigorous - sometimes uncomfortably so.

Here's an example from my Orchestration article. I had argued that AI would change how we think about coding. Claude pushed back:

This caught a logical inconsistency that I hadn't noticed. I wasn't arguing that coding disappears. I was arguing that the abstraction layer rises. The final article has a much tighter definition because of this challenge.

But the critique didn't stop there. It also challenged my core claim that "baked-in process is bad":

This forced me to be more nuanced. I wasn't arguing against all process - I was arguing against process that restricts innovation, without providing compensating value. The final article includes a section explicitly distinguishing between process that creates value through standardisation (like Stripe), and process that restricts value by preventing innovation (like my 360 feedback example).

I didn't always agree with the critiques. Sometimes I pushed back and defended my position. Other times I realised that the critique was right and I adjusted. Either way, I emerged with a stronger argument, because I'd been forced to defend it.

The key insight: it's easier to strengthen an argument before you've written 2,000 words defending it. The critique phase catches problems early, when they're cheap to fix.

The Understanding Summary

After the critique, Claude wrote down what it understood. A memorandum of understanding - both parties confirming what we're doing before proceeding.

Something interesting's happened: in both articles I've written this way, the understanding summary has required no corrections.

Two data points isn't proof. But it suggests something. The earlier phases - discovery and critique - front-load the alignment work. By the time you reach the understanding summary, clarity has already been forced. The structured process works.

The Structure Phase

Even narrative structure became a choice.

Claude proposed several approaches for the Orchestration article: lead with stakes (the wake-up call), lead with an example (concrete-first), or lead with contrarianism (everyone believes X, they're wrong). Each had trade-offs. I chose a hybrid - give a concrete example first, and then escalate to stakes.

The same content can land very differently depending on structure. Having explicit options forced me to think about my reader.

Capturing It: Skill Extraction

After the draft was done, I realised something: this process was worth capturing.

A chef perfects a dish by feel, over many attempts. At some point, they'll write it down. The recipe doesn't capture everything - the implicit knowledge, the timing instincts. But it captures enough to reproduce the result, and to teach others. Over time, they refine the recipe based on feedback, adjusting proportions, adding notes about common mistakes.

I did the same. After completing the draft and supporting materials, I asked Claude to extract the process as a reusable agent skill. The key elements: I defined a process but gave it leeway to adapt. I provided context and some constraints. The result was a skill with phases, templates, and writing principles.

This skill is now in my agent skills repo. It contains a main SKILL.md file that references templates for each phase, and for multiple article types. I invoke it simply by mentioning I'm writing an article.

Skills should be single-purpose, for easy composition. The article writing skill handles drafting. A separate skill could handle colleague feedback. A third could handle SEO verification. Small standardised pieces combine into anything - like LEGO, not pre-moulded toys.

This is still early days for agent skills, and there are no established best practices. But the principle is clear: capture what works, so you can do it again.

Getting Started

If you want to try this yourself, you'll need an agentic tool that can read and write files. While not essential, it's best if it supports the Agent Skills standard - Claude Code, GitHub Copilot, and Codex all do, and most tools will shortly. See the Claude Code docs for getting started.

Set your expectations: this is slower than "just ask Claude." The payoff is genuinely better output, plus a reusable process.

Expect to make tweaks. The skill evolves as you use it. One thing I noticed: Claude defaulted to US English when I wanted Australian. That's the sort of improvement that you'll add back into the skill - a simple requirement that persists across sessions. The agent can help with that - ask it to update the skill based on deviations you've made.

Start with something you care about. Don't test this on throwaway content. The process rewards investment.

The breakthrough wasn't a better prompt. It was giving myself permission to slow down.