Lab notes: Writing a Novel the Developer Way
Systems for Storytellers / 02
Introduction
The tools you use shape how you work. Painters choose between oils and acrylics. Musicians select instruments that match their style. Writers, too, make choices about their workspace—and those choices matter more than most realize.
Most authors default to familiar options: Microsoft Word, Google Docs, or dedicated writing software like Scrivener. These tools work well and have served writers for decades. But there’s another category of software—one designed for an entirely different profession—that offers surprising advantages for creative writers willing to look beyond the obvious choices.
I’m talking about the software that developers use every day: Integrated Development Environments, or IDEs. Before you dismiss this as irrelevant technical nonsense, consider what you actually do when you write. You type letters and symbols into a file. You organize those files into folders. You revise, rewrite, and track changes over time. Developers do exactly the same thing—just with code instead of prose. The tools they’ve built to manage their work translate remarkably well to managing yours.
What Exactly Is an IDE?
An IDE—Integrated Development Environment—is software designed to help developers write, edit, and manage code. Think of it as a text editor with superpowers. Popular options include Visual Studio Code (free, from Microsoft), Cursor (built specifically around AI assistance), and Sublime Text.
“But I’m not a developer,” you might say. “Why would I use their tools?”
Here’s the thing: an IDE doesn’t care what you’re writing. It sees text. Whether that text forms a Python script or a fantasy novel, the IDE handles it the same way. You’re not learning to code by using these tools—you’re simply accessing features that word processors don’t offer.
The real question isn’t whether you can use developer tools for writing. It’s whether doing so provides benefits that traditional writing software can’t match. The answer, for many authors, is yes.
Version Control: Your Manuscript’s Safety Net
The most compelling reason to adopt developer tools is version control—specifically, a system called Git and its most popular hosting platform, GitHub.
Think of version control as a time machine for your manuscript. Every time you save a meaningful change, you create a snapshot. Days, weeks, or months later, you can return to any of those snapshots instantly. Unlike Word’s version history or Google Docs’ revision timeline, Git preserves everything—not just recent changes, and not subject to arbitrary time limits.
But version control offers more than just backup. Imagine you’re halfway through your novel when a wild idea strikes: what if the protagonist’s mentor was actually the antagonist all along? In traditional writing software, exploring this idea means either making irreversible changes or manually saving a copy of your entire project. With Git, you create what’s called a “branch”—a parallel version of your manuscript where you can experiment freely without affecting your main work.
If the experiment succeeds, you merge the branch back into your main manuscript. If it fails, you simply delete the branch. No harm done. Your original work remains untouched throughout.
Consider the practical applications:
Alternate storylines: Branch your novel to explore different plot directions without losing your original path.
Risky revisions: Test major structural changes in isolation before committing to them.
Beta reader feedback: Create separate branches for each reader’s suggested changes, then selectively merge what works.
Collaboration: Multiple authors can work on the same manuscript simultaneously, with Git intelligently merging everyone’s contributions.
GitHub adds another layer of value. Your manuscript lives in the cloud, accessible from any computer, automatically backed up, and protected against local hardware failures. You can make your repository private (for unpublished work) or public (for open-source projects or community collaboration).
The learning curve for Git basics is modest—a few hours of tutorials will teach you everything a writer needs. The payoff is a level of manuscript control that traditional writing software simply cannot match.
AI Integration: More Than Autocomplete
Modern IDEs have embraced artificial intelligence in ways that benefit writers as much as developers.
The most visible feature is inline completion. As you type, AI predicts what might come next and offers suggestions. For developers, this means auto-completing function names and code structures. For writers, it means sentence suggestions, dialogue continuations, and phrasing alternatives.
Is this always helpful? No. Sometimes you know exactly what you want to write, and AI suggestions become distracting noise. But when you’re stuck—when the next sentence won’t come, when dialogue feels stilted, when a transition eludes you—having AI offer possibilities can break the logjam. You’re not obligated to accept any suggestion. Think of it as a brainstorming partner who occasionally has good ideas.
More powerful than inline completion is the integrated AI chat feature that most modern IDEs now include. Tools like Cursor and Visual Studio Code with extensions allow you to have conversations with AI assistants—Claude, GPT, or others—directly within your writing environment. Critically, these conversations can include your manuscript files as context.
This changes how you interact with AI assistance. Instead of copying text into a separate chat window, you can ask questions like:
“Does my protagonist’s motivation stay consistent throughout chapters 3 through 7?”
“Suggest ways to foreshadow the reveal in chapter 12 based on what I’ve written so far.”
“Review this dialogue for voice consistency with my character descriptions.”
The AI sees your actual files—your notes, your outline, your draft—and provides responses grounded in your specific project. This integration creates a more seamless workflow than constantly switching between your writing software and a separate AI tool.
File Formats and Flexibility
Traditional word processors excel at formatted documents—bold text, headers, page layouts, and the visual presentation of your work. IDEs, by contrast, work primarily with plain text.
This sounds like a limitation, and in some ways it is. You won’t be adjusting margins or selecting fonts inside an IDE. But plain text formats offer advantages that formatted documents can’t match.
The most relevant format for writers is Markdown—a simple way to indicate structure (headers, bold, italic, lists) using plain text characters. A header is just a line starting with #. Bold text is wrapped in **asterisks**. The syntax is intuitive and takes minutes to learn.
Why does this matter? Markdown files work everywhere. They open in any text editor on any operating system. They convert easily to HTML for blogs, to formatted documents for print, to ebooks for digital distribution. They’re small, fast, and future-proof—you’ll never face a situation where a file format becomes obsolete or incompatible.
For authors focused on self-publishing or digital-first distribution, Markdown offers particular advantages. Blog platforms, static site generators, and many ebook creation tools accept Markdown directly. Your manuscript becomes more portable and more flexible.
A word of caution: if you’re submitting to traditional publishers or literary agents, they typically expect .doc or .docx files formatted to specific guidelines. Markdown works well for drafting and certain publishing paths, but you may need conversion tools like Pandoc for traditional submission. This is a workflow consideration, not a dealbreaker—but it’s worth understanding before you commit.
Limitations and Learning Curve
Adopting developer tools isn’t without friction. Honesty requires acknowledging the downsides.
The learning curve is real. IDEs are designed for developers, and while writers don’t need most features, the interface can initially feel overwhelming. Menus reference concepts you don’t need to understand. Features you do need aren’t always obvious. Expect a few hours of orientation before things feel comfortable.
Formatting is limited. If you need real-time visual formatting—WYSIWYG editing with visible fonts, margins, and layouts—IDEs aren’t the right choice. They’re built for content creation, not document design. Final formatting typically happens elsewhere, in a tool specifically designed for layout.
Collaboration requires buy-in. Git’s collaboration features only work when everyone uses Git. If your co-author or editor prefers Word’s Track Changes, you’ll need to accommodate that workflow rather than forcing developer tools on resistant collaborators.
Not all AI features are free. While many IDEs offer free tiers, advanced AI capabilities often require subscriptions. Cursor, for instance, offers powerful AI integration but at a monthly cost. Evaluate whether the benefits justify the expense for your specific workflow.
These limitations aren’t trivial, but neither are they insurmountable. Many writers find that the benefits—particularly robust version control and seamless AI integration—outweigh the learning investment and workflow adjustments.
Getting Started: A Practical Path
If you’re intrigued but unsure where to begin, here’s a straightforward approach.
Step 1: Download Visual Studio Code. It’s free, widely supported, and strikes a good balance between power and approachability. Install it from code.visualstudio.com.
Step 2: Create a project folder. Make a folder on your computer for your manuscript. Inside, create a file called manuscript.md (or whatever name you prefer). The .md extension indicates a Markdown file.
Step 3: Write something. Open VS Code, open your project folder, and start writing. Ignore the unfamiliar menus and features for now. Just write.
Step 4: Learn basic Markdown. Spend fifteen minutes with a Markdown tutorial. Learn headers (#), emphasis (*italic*, **bold**), and basic structure. That’s enough to start.
Step 5: Add Git when ready. Once you’re comfortable with the editor, initialize a Git repository. VS Code has built-in Git support—the Source Control panel (left sidebar) guides you through making commits. Create a free GitHub account and push your repository to the cloud.
Step 6: Explore AI features. If AI assistance interests you, install an extension like GitHub Copilot or try Cursor as your IDE. Experiment with inline suggestions and integrated chat.
Don’t try to master everything at once. Start with the basics—just using the editor as a text editor—and add capabilities incrementally as you grow comfortable.
Conclusion
Writing with developer tools isn’t about becoming technical or abandoning creative instincts for cold efficiency. It’s about recognizing that writers and developers share fundamental needs: managing text, tracking changes, exploring alternatives, and leveraging AI to work smarter.
The tools developers have built to address these needs are sophisticated, powerful, and—increasingly—accessible to non-programmers willing to learn something new. Version control protects your work while enabling fearless experimentation. AI integration meets you where you write rather than requiring constant context-switching. Plain text formats ensure your manuscripts remain portable and future-proof.
This approach won’t suit every writer. Those who need rich visual formatting, who prefer familiar word processors, or who work primarily with collaborators wedded to traditional tools may find the tradeoffs unfavorable. That’s a legitimate choice.
But for writers who value robust backup systems, who want seamless AI assistance, who publish digitally or maintain complex projects with multiple branches and versions—developer tools offer something traditional writing software can’t match.
The software doesn’t care that you’re writing a novel instead of a program. It just sees text—and helps you manage that text more effectively than you ever could before.
Perhaps it’s time to write your novel the developer way.