TL;DR: Writing as Software Development

• AI gets a bad rap, but so did the printing press: Amplifiers boost both signal and noise.
• Context beats prompting: Attach your voice style guide, past posts, and transcripts in one environment. Build consistency into the tool through context management.
• Match models to tasks: Use GPT-5 for research and structure. Use Sonnet 3.5 for voice and prose. Different models have different power curves.
• The Pareto Principle always applies: AI generates the first 80% fast. You must edit the final 20% line by line.

Great authors are great editors. First drafts are brain dumps. Final prose is what you sift from the rubble.

The Slop Machine

Let me address this up front. Social Media users call AI-generated content "slop." The criticism is that AI floods the internet with low-quality content that lacks authentic voice, genuine insight, and human experience.

I understand that concern. The output from millions of AI prompts now pollutes my search results and social media feeds. The problem is real, frustrating, and is hurting creative professionals.

But, AI writing tools are the next evolution in a long progression: quill pen to printing press, typewriter to word processor, desktop publishing to cloud collaborative editing. Each advancement democratized who could get their ideas into the world. Each faced skepticism from the existing establishment.

At their core, all writing tools are Garbage-In-Garbage-Out. AI currently gets its bad rap because it amplifies the volume of material bad actors contribute to the commons, but so did the printing press.

Notably, resistance may be found among monks, scribes, politicians, and booklovers alike, each offering different explanations for their opposition. Within these groups, four overarching reasons may be identified for their opposition to print: the heightened prospects of incorrect or corrupt information being distributed widely, the refusal of copyists to give up their profession, the notion that manuscripts were "superior" to the printed word, and, nostalgia, which sought to keep existing practices in use.

• Kojali: The Survival of Manuscripts in Early Modern Europe

This post is my attempt to teach you how to maintain your voice, provide value, and share genuine experience.

I use AI as a collaborative partner to get my lived experience and hard-won insights out of my head and into the world. I've shared shower thoughts like "USB-A wasted 58,000 man-years because of one design flaw" and tutorials on "How I bring my children's sketches to life with AI". These aren't pieces I would have taken the time to publish traditionally. But they're not slop, they're specific, personal, and grounded in real experience that I wanted to share with others.

Why Google Docs Sucks at AI Assistance

I rebuilt my website in Cursor. The project taught me that modern development tools had evolved far beyond current writing software.

Working in Cursor meant I could prototype, iterate, and ship without context switching. When I went to write a blog posts about that experience, I realized I was already in the right tool.

Before this workflow, I'd publish one post per month for a few months, then stop for years. Each post took 4-6 hours scattered across multiple tools. Now I ship weekly in the same time and the posts are longer and more informative. That's an increase in velocity, quality, and consistency (Editor's note: Feel free to mock me when I stop publishing again in a month.)

Here's why Google Docs sucks at AI-assisted writing:

No Context Access

AI needs to understand your voice, reference your past work, and maintain consistency across everything you've written. Traditional tools isolate each document. In most other tools, you can't easily give an AI access to your style guide, previous articles, and the current draft simultaneously.

No Real Version Control

Track Changes and Suggesting Mode capture surface-level edits, but the're not as powerful as having git. The ability to review different versions of a document, branch, merge, and publish all within one tool is high leverage.

Bolt-On AI, Not Built-In

Google Docs added AI features after the fact. The writing environment wasn't designed for AI collaboration from the ground up. Cursor was. Every shortcut, every interface element, every workflow assumes you're working with AI, not fighting against tool limitations.

Traditional tools were built for humans writing alone. AI-native tools were built for humans and AI collaborating together.

Cursor as an AI-Native Writing Environment

My writing environment is a git-backed markdown repository. Every blog post, style guide, and transcript lives in version control.

This setup gives me three critical advantages:

Full Context Availability: When I open Chat (⌘L on Mac, Ctrl+L on Windows), I can attach my style guides, past posts, and interview transcripts through the @Files & Folders feature and it send them as context to the LLM. The AI sees everything that matters for maintaining voice consistency.

Version Control as Creative Safety Net: I commit frequently. If I don't like a direction, I can revert. If an AI edit loses the plot, I can see exactly what changed since the last commit. That safety net makes me bolder about experimenting with structure and angles. I've respun entire drafts with a different angle/lens that I've discovered during the editorial process.

Iterative Improvement by Design: Each post is a commit. Each commit documents the evolution of my writing voice. Over time, I can see patterns in what works and what doesn't. The repository becomes a canonical reference that an LLM can use for pattern recognition.

After publishing each article, I have the AI analyze the differences between the final version and the initial draft. It compares these changes against my style guide (writing-style.xml). I then update the style guide with successful patterns and improvements. This iterative process helps align the AI's output more closely with my natural writing style over time.

Next week I'll publish a detailed guide on how to build your own writing style guide in XML, including a template you can customize for your voice.

My Writing Workflow in Cursor

Here's how I go from idea to published post:

Phase 1: The Interview

First, I work with ChatGPT to research and plan interview questions around my topic. Then I switch to voice mode and have it ask me those questions one at a time. The process feels like a natural conversation, similar to brainstorming with a colleague over coffee. The voice interview captures my authentic phrasing.

GPT-5 Interview Prompt:

As a world-class interviewer, your task is to help write a blog post about {{subject}}. Begin with a concise checklist (3-5 bullets) of sub-tasks you will perform before drafting the questions. Research and generate a well-organized list of questions on this topic. For each significant source or insight, state briefly why it is relevant. Focus on creating questions that will allow me to share personal anecdotes and insights, highlighting the wisdom gained from my experiences. After assembling the question list, review to ensure that the questions are varied, engaging, and aligned with the blog post’s intended tone. After the questions are generated, ask me to switch to voice mode and ask me one question at a time as an interviewer.

Download Prompts

Phase 2: Refine the Outline

Once I have the transcript, I work with GPT-5 to create an outline. To do this efficiently, I store my writing-style.xml, resume, and examples of previous posts in the Project (ChatGPT Feature) that I use for my blog creation. Since those files are accessible to the Retrieval Augmented Generation (RAG) tooling and the conversation has the raw transcript from the interview, GPT-5 has access to everything it needs to structure the outline.

I prefer the way GPT-5 handles research, organization, and structure when compared to Sonnet 3.5. It's a newer thinking model with more parameters and agentic tools. The outlines it creates have better flow and information hierarchy than the older models.

Together, we iterate on the outline until it captures the narrative arc I want. Usually takes two to three revision passes. Some dramatic, some more incremental in nature.

GPT-5 Outline to XML Prompt:

You are an SEO expert and blogger tasked with drafting and structuring a blog post based on the given interview and project files.

Before Starting

• Begin with a concise checklist (3-7 bullets) outlining the main sub-tasks you will perform for this task, keeping items conceptual.

Instructions

• Review the completed interview and all files in the project.
• Generate a suggested outline for the blog post using the provided interview content.
• Discuss and revise the outline collaboratively until it is finalized.
• After finalizing the outline, create an XML document that includes:

1. A verbatim transcript of the interview, wrapping each question and answer within <question> and <answer> tags as <qa> elements, inside a <transcript> section.
2. The finalized blog outline, using nested <heading> tags with a level attribute (e.g., <heading level="1"> for H1, <heading level="2"> for H2, etc.) within an <outline> section. ...

See Full Prompts

Phase 3: Draft the Post

Then I switch to Sonnet 3.5 as my preferred Ghost Writer.

I attach all the source materials into Cursor's context:

• My XML writing style guide (Stored in the Repo)
• The Markdown file for the blog entry, where I paste the XML data that ChatGPT curated in the last prompt

Once the XML is pasted in the blog, I commit this "draft" version to the repository. This approach preserves all the original source material in one place, making it easy to reference later if needed (Cursor has tool calls that can reference previous commits).

I'll then prompt the model to draft 1,200-1,600 words based on the outline in my tone and rhythm.

The first draft comes back surprisingly close to publishable. The AI references my patterns and follows the outline structure: short punchy paragraphs, one idea per sentence, specific details over generalizations, active voice, minimal hedging.

Sonnet 3.5 Blog Draft Prompt:

Based on my {{Style Guide}} review the XML documentation of the interview and suggested outline for my blog post on {{subject}}. After a deep review, ask clarifying questions and then provide a draft blog post that uses lightly edited quotes from the transcript directly in the body text wherever possible.

Insert your content above the XML document so we can reference it during the revision process.

See Full Prompts

Phase 4: Review and Refine With Diffs

But you can't short the Pareto Principle. The first 80% of the post is done in 20% of the time with AI, but the last 20% requires the requires 80% of your effort. This is where you must work line by line to make sure the document meets your personal standards.

Luckily, this is where Cursor shines.

I can highlight a paragraph and open the Inline Edit feature (⌘K). Then I prompt: "Tighten by 15%, active verbs, one idea per sentence, no em dashes."

The AI proposes a new version. I see exactly what's different. Accept, manually edit, or outright reject its proposal.

Unlike Word or Google Docs with their red strike-throughs and green mid-sentence markup, Cursor's in-line diff shows the complete previous prose in red and the suggested edit directly below it in green. This makes it easy to compare complete sentences and choose the best version.

Accept Changes?

Phase 5: Ship and Iterate

Before I publish a new post, I also implement one feature or bug fix on my website. That way each post makes the site slightly better. The goal is slow, compound progress, toward an unattainable perfection.

When I'm ready, I change the frontmatter YAML for status from draft to published. A git push triggers deployment. The new post goes live with proper metadata, hero images, and SEO optimization baked in.

Keyboard Shortcuts That Accelerate Flow

Cursor is built on VSCode, so all the standard code editor shortcuts apply. Here are the ones that matter most for writing:

When I need to generate an outline or discuss structural changes, I attach my style guide and past posts for full context.

Open Chat (⌘L): Attach context and collaborate with AI on structure and content

When I make broader changes using the Chat function, I review each delta carefully. The inline diff shows additions in green and deletions in red, making it easy to see exactly what changed.

Accept (⌘+Shift+Y)/Reject Inline Changes (⌘+N): A floating review bar appears at the bottom with Accept and Reject buttons—I can approve good changes and dismiss ones that drift from my voice

If a paragraph feels wordy or drifts from my voice, I highlight it and prompt directly without opening a separate panel.

Inline Edit (⌘K): Select text and prompt for targeted revisions without leaving the editor

When I want to consistently internally link a phrase on my site to a new blog post, I search first to see where that phrase appears.

Find in Files (⌘⇧F): Search across all posts to find opportunities for internal linking

The workflow becomes muscle memory. You stop thinking about the tool and focus on the ideas.

Why Model Selection Matters

Different models excel at different tasks. I've learned to match the model to the work:

GPT-5 for Outlines and Structure: Better at research, organizing information hierarchically, identifying narrative arcs, and suggesting logical flow. When I need to understand the overall shape of a piece, I use GPT-5.

Sonnet 3.5 for Voice and Prose: Better at capturing my specific phrasing patterns, sentence rhythm, and tonal consistency. When I need words that sound like me, I use Sonnet 3.5.

Choose the right model for the job.

Most people stick with one model for everything. That's like using a hammer for every construction task. Different models have different power curves and biases. Cursor allows you to query different models by simply clicking on a dropdown.

Continuous Improvement as Writing Practice

Every post is an experiment.

My goal is to ship one blog post per week for a year. That's roughly 50 posts and 50,000 words. Eventually, I'll use AI tools and human editing to help me turn that corpus into a book.

This weekly cadence is a micro-contract with myself. This simple rule bypasses decision-making and creates consistent output.

But shipping volume isn't enough. I test one workflow improvement or site feature with each post.

Recent experiments include:

• Switching from JSON to XML for the style guide based on OpenAI's prompt engineering recommendations
• Adding author metadata and headshots to the blog layout
• Implementing a Substack subscription form for email distribution
• Refining typography choices based on reader feedback about mobile readability
• Testing different hero image styles and aspect ratios for social sharing

Each change is small. These small changes compound over time creating outsized impact.

This is the same approach I take to product development: ship frequently, measure what matters, iterate based on data and feedback.

The Real Output: A Learning System

The posts I publish are the visible output. The more valuable output to me is the system itself.

Every week, I get better at:

• Articulating my thoughts clearly
• Structuring narratives that hook readers and deliver value
• Collaborating with AI while maintaining authentic voice
• Shipping consistently despite competing priorities
• Improving my web presence incrementally

Those impacts provide me more benefit than any individual post's reach.

The site I have today looks nothing like where I started a few months ago. Systems and rituals outlast motivation and sometimes the process is the product.

Lessons From the Workflow

Treat Writing Like Software Development: When I radically restructured a post one evening, then realized the original flow was stronger, two clicks in git restored it. That safety net changed everything. Version control, iterative improvement, automated testing (editorial notes and voice checks), and continuous deployment all apply to writing.

Build Your Context Library: Early drafts felt too similar until I documented successful post formats in my style guide. Now each post references 3-4 previous posts that captured my voice well, plus proven structural frameworks. The more high-quality reference material you give the AI, the better it performs. Invest in documenting your voice and organizing past posts for easy reference.

Don't polish the hammer, strike the nail.: My first AI-assisted post took weeks to ship while I second-guessed my workflow. The sixth post took four hours and resulted in better engagement. Publishing weekly forces you to make decisions and move forward. As Donald Knuth warned, premature optimization is the root of all evil.

Automate What You Can, Own What Matters: AI-written posts without my input were slop. Now I inject wisdom through voice interviews and share details only I know. AI handles structural organization and first drafts. Let it handle generation, structural suggestions, and consistency checks. You own the personal experience, specific insights, and final editorial judgment. Great authors are great editors. Even when I wrote with pencil, I always sifted final prose from verbose brain dumps.

Measure What Matters: I stopped tracking social media likes and started tracking meaningful conversations. One post with 50 views sparked deep dialogue with an old friend. Another with 500 views generated zero substantive engagement. Track reading time and your publishing velocity. Ignore vanity metrics. Focus on whether readers find value and if you're improving.

Try Writing with Cursor

Writing in Cursor has fundamentally changed how I think about written content creation.

I don't wait for inspiration. I don't get paralyzed by the blank page.

I've built a system that captures my thoughts, structures them clearly, and ships them consistently.

This approach isn't for everyone. If you love Google Docs and your current workflow serves you well, keep using it. Tools should fit your process, not the other way around.

But if you're a product manager or software builder who writes regularly, this workflow might unlock something for you. The same iterative, version-controlled, context-rich approach that works for building software works for documenting ideas.