It’s Saturday afternoon. As I write this post, Claude is working on making my new web application mobile-ready.
This is not a post about vibe-coding. It’s not an apocalyptic post, nor is it a euphoric one. It’s about harnessing the power of AI tools like Claude to make us more creative. More accurately, it’s about co-creating with them.
If, like most people online, you are aware of (and annoyed by) all the slop content that floods the web these days, co-creation with AI might sound idealistic and detached. Maybe. But in this post, I would like to talk about the alternative to this flood. No, the alternative is not going back to a time, not that long ago, when nobody knew what an LLM is. The alternative to delegating our creativity to AI is to collaborate with it and use it as a flywheel.
The following is not a recipe, not a method, and not a collection of tips. It’s just the story of what I built this week. The moral of the story is not “imagine something and AI will build it for you.” It’s “Find a good reason to build something and find a partner to build it with.”
But let’s start at the beginning.
I’m writing quite a lot. At least a lot for someone who isn’t a full-time writer. I’m working on a book (and a half… but that’s for another post), and I try to write weekly content for my newsletter. And while I refuse to let AI write for me, I’ve been using AI-based tools to help me write better long before ChatGPT was introduced.
I don’t take writing lightly. I treat it as a craft — a skill one should always strive to improve. The fact that I write in a language I don’t natively speak makes the challenge even greater. And while ongoing practice is a sure way to improve, getting frequent feedback and working with someone to guide you is even better.
When I started writing in the early 2000s, the only things I could rely on were the built-in spellchecker in my word processor and the patience of my native English-speaking friend. Grammar-checking tools, if there were any, were scarce, and their sensitivity to nuances like desired tone was nonexistent. Not to blame the technology, but you can imagine my writing was barely passable.
Then came tools like Grammarly, which opened a wider window for better writing. They were based on machine learning and seemed more context-driven. And while Grammarly often pleasantly surprised me, in many cases, the revisions it proposed were repetitive and didn’t capture how I wanted to sound. When I intentionally use terms like “mind pantry” and the tools I work with keep offering the same alternatives that I keep rejecting, those tools become less and less helpful.
Then came Claude, and suddenly I had someone to talk with about my writing. I didn’t want it to write for me; I wanted it to help me become a better writer. I asked it to identify not only errors but also opportunities for style improvements. If a sentence was too long, it would tell me. If a sentence was fragmented, it would highlight that. But Claude also understood that sometimes I made deliberate choices; that writing, like many other crafts, is built on rules — and knowing when to bend them.
Your Daily Dose of Creativity
Download the CreativityMEDS iPhone App
Claude became a kind of coeditor. It could find a grammar error in a single sentence as well as review an entire chapter. It learned my tone and the special terms I use. It could tell me that something was fine given my preferences, or that I had to change something despite them. It understood what I wrote, not just how I wrote.
Still, I felt something was missing. I felt we could do even better. As effective as my discussions with Claude were, they were not consistent. Sometimes it focused on my tone and voice, and at other times it highlighted the lack of a counterpoint or dove into a specific analogy buried in a long-forgotten paragraph. It felt like having an editor with a different attention span and a different vocabulary every day.
No less important, it was hard to follow a review of a 2000-word text and then discuss a few specific points. The chat interface is not really built for managing several threads of discussion on the same artifact and keeping them in context.
And then came Claude Code.
Before I was an aspiring writer, I was a software developer. I know how to program, but more importantly, I know how software works. I understand what makes a software design good, and I have the language to articulate it. I loved developing software, but I loved conceptualizing it more than I liked the mechanics of actually writing code. I enjoyed designing stuff. The repetitive work of translating ideas into a programming language? Not so much. Twenty years ago, I pivoted into adjacent areas and no longer called myself a software developer.
When Claude Code became publicly available, I immediately saw a personal opportunity. I had no idea if it was any good. I didn’t (and still don’t) know what impact it might have on the economy or the profession I once loved. But I did know this: I could at least try to go back to creating useful stuff without having to write code for hours, days, and weeks. Worst case, it would fail. But if it didn’t, I was going to have fun creating my own, perfectly customized toolset.
I started with an idea: to have a more grounded, consistent conversation about the qualities of a text, we need a common language. I love building frameworks — taking abstract or complex concepts and defining a vocabulary for them. I had a sense that this was something someone had already done for analyzing text. So I asked Claude what Domain-Specific Languages (DSLs) are used to analyze prose.
I should be honest: I am not a researcher, and this was not academic research. In a different context, it might not be something I’d ask AI to do. But for this project, Claude was the perfect research partner. Sure enough, my co-creator came back with an answer that would have taken me days if not weeks to compile.
It soon became clear that while there are quite a few taxonomies for analyzing text, each typically focuses on one aspect: rhetorical devices, voice, progression, etc. Other aspects are common in editorial work but weren’t formalized. But the most important realization was that there was no single system — one formal language — that combined all of these aspects in a way both machines and humans could understand.
So, we created one.
The result was a DSL spec spanning more than 3000 lines, covering multiple aspects and listing hundreds of terms — each with definitions, tests for telling them apart, and examples. And that was just the first version.
Reading it isn’t easy. Understanding it is challenging. For a human to analyze a text with it is impractical. But for Claude, who can read it in seconds, make sense of it, and then use it as a vocabulary, the DSL is priceless. It adds structure and consistency to how Claude sees and makes sense of the text. At least that was the theory.
To test that theory, I asked Claude to create a blueprint of one of my articles using the language we’ve just defined. Naturally, the result was as long and as tedious to read as the language specification. When I first saw it, I was overwhelmed. I almost decided to backtrack and declare this a dead end.
But then I discovered the unique quality of what Claude had generated. Something that had been missing before: the ability to engage in a conversation based on a shared, well-defined language. When Claude tagged a statement as a hinge, we both knew what it meant. When it identified a well-established pattern, I could look it up. And when it said the voice I use oscillates, it could demonstrate that with accurate examples. If I didn’t understand something, there was a reference we could both align on.
Having a shared language did more than sharpen the analysis. It gave us the infrastructure to go beyond the text itself — to define a vision of what we were really building.
Next, I asked Claude to compile a list of insights into what works and what doesn’t in the text. This is what I’d wanted ever since I started editing my work with Claude, but now we had the blueprint of the text as a solid foundation for this analysis. The result was a thoughtful evaluation of the text, with clear, structural explanations that revealed its DNA.
That was what I was looking for. Now, it was time to turn this workflow into a tool.
Over the next few days (well, mostly nights), we iteratively designed and implemented a tool that executes this workflow and presents the analysis results with direct reference to the text. It explains the insights and their impact and allows me to chat with Claude on each one in context.
Not everything went smoothly. No development project ever does. For some aspects I found important, the DSL didn’t work and needed refinement. Some text samples were misclassified, leading to strange recommendations. We had to continually revise the analysis workflow. But what made this work possible was the shared, well-defined language that we now had to discuss all these issues.
Many of the insights the tool now generates are spot on. Quite a few are debatable, but in a good sense. I wasn’t looking for clear-cut answers. I was looking for a thoughtful conversation. Just like one you’d have with an editor.
It seemed adequate to call my new app CO.EDITOR.
As someone who loves modeling stuff, I got a bonus. When I come across a good piece of writing, I can now ask CO.EDITOR to analyze it and reveal its internal workings. Good writing must have a soul, but a solid skeleton is equally important. CO.EDITOR allows me to see and make sense of that skeleton.
It was one of the most productive and rewarding weeks I’ve experienced. True, I didn’t write a single line of code. I also didn’t spend days and weeks reading academic papers. I defined a vision, I navigated, I made decisions, I made mistakes, and I created something I needed that wasn’t there a week ago. Co-created.
If you ask AI tools to work instead of you, you won’t get far. That auto-generated blog post, that video that looks like a thousand others, or the presentation that might be fairly accurate — AI can do all that, and it will likely get better with time. But that’s like applying an automatic filter to a poor photo you took: the outcome might be good, but it is purely mechanical. The real value lies in a deliberate creative collaboration.
The alternative is not simple to implement, but it radically increased the value of my work with Claude: You have to know what you need. You must have the language — any language — to articulate your vision. You should be able to communicate your ideas and defend them, but also have the means to absorb new ideas and reshape your understanding. You have to be willing to be changed by the process.
We think of AI as a powerful tool, and it certainly is. But language matters. When we think of Claude as a tool, we default to just using it. That’s a missed opportunity. We don’t need to fully understand or agree on what Claude is. We just need to change the way we interact with it.
Instead of thinking of it as a tool, think of it as a collaborator. Instead of framing the interaction as offloading work, consider it a partnership. Instead of engineering prompts, have a conversation. Sometimes, you’ll need to define a language to do that. Like we did.
That’s co-creation.
CO.EDITOR (Beta) is available for free. Using it requires your own Claude API key, for which you will be billed by Anthropic per usage.
If you just want to get an impression of what it can do, you can explore the built-in examples without an API key.