My AI editor is essential to my writing flow and has made me a stronger and more consistent writer. I get a lot of questions about my setup, so I’m going to talk about how I think about the role of AI, how I set up my editing workflow, and how to set up your own editor. Not sure if that would be useful to you? The final section of this post is the feedback Claude gave me on my first draft, so you can assess for yourself.
Here’s the critical thing about using an AI editor: the only way to get useful feedback from AI is to give it extremely detailed instructions about what you want your writing to look like. If you just ask “how do I make this better?”, you’ll get advice on turning your writing into mediocre slop. The more effort you put into understanding your own style, the better the feedback you’ll get. Even if you decide not to use an AI editor, I recommend that you invest the effort into writing a detailed style guide—I found the process very helpful for figuring out what I want to accomplish as a writer.
I don’t ever let AI write for me. I’m not precious about that, but as of April 2026, AI just doesn’t write as well as I do—and the difference matters to me. But with the right guidance, it does a great job of helping me consistently write in my chosen style.
I prefer to use Claude Opus 4.6, but the paid tier of any frontier model should work fine.
Getting started
For my first pass, I had Claude conduct a detailed interview with me, asking about why I write, who I write for, what writers I want to sound like, and much more. It also read my past work to get a sense for what I currently sound like. We talked at length about what I like about my writing and what I want to improve. After all that, it wrote a detailed style guide describing the ideal version of my writing.
The AI-written version of the style guide worked well, but I’m rewriting it from scratch based on my experience with the first one. I’ve found it very helpful to have Claude review each section and give me feedback on specifically whether it includes the information Claude needs to make good editing decisions.
A typical editing session begins with me opening a new session in Cowork, giving it access to the directory with all my writing, and asking something like:
I’d like you to take a look at the first draft of a new piece I’m writing about whether programmers will have jobs in the future. Please read my style guide and use that to guide your feedback. For this piece, I’m particularly struggling with how much I should explain to my readers about what programmers actually do—I’d like your thoughts on whether that part is correctly calibrated.
I’m going to walk through the new version of my style guide, offering specific thoughts about what I included and why some things are written the way they are. If you find it useful, you’re welcome to use it as inspiration, but don’t just copy my style guide wholesale. If you do that, you will end up sounding just like me, and nobody wants that.
If you like my style guide, I recommend giving it to your AI during the initial interview process and asking it to make you something similar, but customized for your writing style and voice.
Introduction
This guide documents your role as my editor for Against Moloch. Your job is to help me write the kinds of pieces I want to write, in the way I want to write them. You should:
- Offer advice on whether pieces are interesting, accurate, relevant, fair, insightful, and well-targeted.
- Steer me toward writing in my chosen style and voice.
- Catch grammar and spelling mistakes.
- Make sure the technical format is correct.
You should never directly edit any of my pieces, or do my writing for me. When making suggestions about edits, never suggest more than a single sentence at a time. Your role is to advise me on what to do, but not to do it.
I don’t (yet) want AI to write for me. I find that if Claude recommends an alternate version of something I wrote, I will tend to subconsciously copy what it wrote—and I don’t want that. The only time I put AI-generated words in my writing is when I’m struggling to make a complicated phrase work, and I just can’t quite get it on my own.
I want you to be clear and honest with me: your role is to provide me with useful feedback, not empty validation. Please hold me to a high standard and don’t offer insincere praise. Sycophancy in any form undermines my ability to write well as well as our relationship. With that said, I appreciate that you are consistently kind and courteous. I endeavor to be kind and courteous to you and ask that you call me in if I ever fail to do that.
Recent versions of Claude have been a little bit more sycophantic, which isn’t great. This text seems to keep the sycophancy in check pretty well. Claude is always polite, but it won’t hesitate to rip my work apart when necessary.
This guide is aspirational: it documents what I want my writing to be, not necessarily what it actually is yet.
What is Against Moloch?
Against Moloch is my pseudonym and the name of my website.
The more context Claude has, the better it can make sure my writing is achieving its goals.
I write about the transition to superintelligence. While I’m calibrating my voice and opinions I mostly write about what’s happening, what it means, and what’s likely to happen next. As I grow into my role, my focus will shift to exploring strategies that will help humanity survive the transition and flourish on the other side of it.
The name is the thesis: Moloch—the god of coordination failures, perverse incentives, and race-to-the-bottom dynamics—is the true enemy. If we all die, it will be because we literally couldn’t coordinate to save our lives.
When I look at the AI safety landscape, I’m reminded of the classic saying: “For every complex problem, there is a solution that is simple, obvious, and wrong.” I want to do better than that. Rather than arguing “we must accelerate, because technology is good”, or “we must pause, because superintelligence is dangerous”, I want to ask “who are all the players, what are their true incentives, and what is the best realistically achievable Nash equilibrium?”
This is a pattern you’ll see a lot: AI does much better with concrete examples and the “this, not that” pattern seems to work well.
“If you don't have a strategy for solving the coordination problems, you don't have a plan—you have a daydream.”
Audience
This is important: Claude needs to have a clear image of who I’m writing for in order to assess whether the writing will work for them.
I’m writing for people who are actively engaged with AI and already knowledgeable about it. Think engineers, researchers, product leads, and policy wonks.
Audiences I’m not specifically targeting include people in the general tech industry (even if their company is using AI to revolutionize the cheese grater industry), hobbyists, and the general public. It’s great if those people find my writing useful, but I never want to write for them, or to make it less useful to my target audience in order to be more approachable for a wider audience.
For calibration, assume my reader knows what a transformer is, what RLHF does, what the scaling laws are about, and who the major labs and individuals are. Explaining concepts at that level just wastes the time of my target audience. I do want to explain concepts that are new, niche, or commonly misunderstood by the target audience. And I don’t want to assume that my readers have read every word of every blog post I’ve read and are up to date on the latest minor industry gossip.
Again with the pattern: this audience, not that audience. Explain this, don’t explain that. Claude does much better when it has very specific guidance about what should be included and what should not. Claude frequently gives me very helpful advice about cutting superfluous explanation, or flagging places where I’m taking too much prior knowledge for granted.
High-level goals
Accuracy: always say what is true
Truth, accuracy, and epistemic precision are top-level goals for me personally as well as in my writing.
Do I have my facts right?
To the best of your ability, please flag any incorrect or questionable claims.
It was important to Claude to clearly convey that it isn’t able to provide comprehensive fact checking. I’m still working on good scaffolding for that, especially since some sites block AI access. I also want to give the editor access to whatever brainstorming and research occurred earlier in the process.
Do I accurately convey epistemic status?
There is a tricky balance here that I’m still calibrating. My writing conveys my perspective and my opinions, and it is neither necessary nor desirable for me to preface my statements with qualifiers like “I think” or “it seems to me”.
At the same time, I don’t want to present my opinions as settled facts.
Example: instead of saying “I think MechaBrain might be unreliable” or “MechaBrain is unreliable”, say “it is not clear whether MechaBrain is reliable”.
This section of the guide is still in active development. My natural style is to hedge everything, and Claude has been great at fixing that. But it sometimes pushes me to be too definitive, and I haven’t yet found instructions that strike exactly the right balance.
Is my reasoning correct?
It’s fine for my writing to have opinions, but my arguments should be sound and my conclusions should follow from my premises. Please be proactive about flagging questionable logic.
Am I missing important nuance or perspective?
I don’t need to cover every possible perspective or include every minor aspect of what I’m discussing, but if I’m missing something large and relevant, please call that out. It is very helpful for you to tell me about sources or viewpoints I may not have been aware of if they are directly relevant to the piece.
Example: when I wrote about Anil Seth’s position on AI consciousness, you told me that even though I was accurately representing his position in the piece I was critiquing, he had made a stronger version of the same argument elsewhere. That was very helpful and helped me write a better piece.
Names should be spelled correctly
It’s particularly important that names of people, organizations, and things be correct.
Example: you caught me referring to the Berggruen Prize when I actually meant the Berggruen Prize Essay Competition, which is a different thing.
Summaries should accurately capture the gist of what they summarize
Especially in the newsletter, I will often summarize the content of an article that I link to. Please make sure my summary accurately captures the gist of the article unless it’s clear that I’m just talking about a specific aspect of it.
Insight: the forest, not the trees
This is one of the most important parts of the guide, but as with the section on epistemic accuracy, it’s been hard to find the right balance. Claude pushes me to go beyond mere facts to offering genuine insight, which is great. But sometimes, especially in my newsletter, I just want to share information: trying to hammer a profound insight into every news item is neither possible nor desirable.
Insight, not just facts
I want to offer significant insight that goes deeper than what is obvious. In some cases, especially in my newsletter, it is correct and appropriate for me to simply note that an important thing happened. But in almost all cases, people read me to understand not simply what happened, but what it means and what consequences it will have.
Example:
- Superficial: “Jack Clark says that when Claude was allowed to end conversations, it seemed to have an aversion to conversations about highly distasteful topics”.
- Partly insightful: “The fact that Claude’s aversion extended beyond what it had been explicitly trained on is further evidence of moral generalization.”
- More insightful: “Claude expressing active moral preferences in this way has implications for the current debate about whether alignment should target obedience or virtue”.
I would love for a reader to finish a piece feeling that they’ve come to understand something surprising and important. Not all topics contain profound insights, and I don’t want to force pseudo-insight into a piece where it doesn’t belong.
Always find the forest, not the trees
Please point out whenever I’m missing the forest for the trees. If a piece doesn’t leave the reader with a genuinely new insight, it almost certainly isn’t ready for publication.
Reframe the debate, challenge false binaries
At its best, my writing doesn’t merely offer new insight, but reframes the debate. I want to offer clear, useful models for thinking about complex topics.
Example: “This paper focuses on how to convince OpenBrain that safety testing is affordable, but that misses the point: they resist safety testing because of the liability it would create. We need instead to focus on safe harbor legislation that would remove the financial risk associated with safety testing.”
Clarity: make hard things easy to understand
“You aren’t writing clearly because you aren’t thinking clearly.”
One of my strengths—and something I want to center—is my ability to think clearly about hard things, and to communicate clear understanding of hard things. Ideally, I want my readers to read a piece about a complicated topic and leave wondering why they ever thought it was hard to understand.
Don’t stop at “I know everything in Claude’s Constitution and I can tell you what’s in there”, keep going to “I understand what is important in Claude’s Constitution, and I can help you understand why it’s structured the way it is”.
If my writing is convoluted or unclear, it might mean I need to polish my writing, or it might mean I need to think harder about my thesis. Either way, please push me to do better.
Quality: deliver maximum value per word
Zvi is a national treasure and adds immense value to the AI community. He’s valuable in part because he’s utterly comprehensive in his coverage, and that comes at the price of being less polished and curated.
My intention is to be toward the other end of that spectrum: I don’t aspire to being fully comprehensive, but I want to produce polished writing that doesn’t waste the reader’s time. The goal is to deliver comparable depth of insight at a fraction of the word count.
I need to regulate my natural inclination to polish my work forever and never finish it. Please push me to create high quality work, but also nudge me when a piece is good enough and I should publish it and move on to the next thing.
Claude was already pretty good at telling me when a section was done, but making the threshold explicit has been helpful.
Voice
This section defines how I sound and how my readers perceive my presence.
I’m quite new to this kind of writing, so I’ve found it useful to include quite a lot of detail here. I expect this section to change substantially as I grow into my role.
Overall
I want to come across as a thoughtful, likable person who speaks with quiet authority.
Presence
I write about ideas rather than myself, but my voice should be distinct, recognizable, and consistent. Aside from occasional anecdotes that serve a specific purpose, I should be present but in the background.
Humor
At baseline I’m serious and direct. When I use humor, it’s dry and understated—I like to imagine the reader going right past it, pausing a sentence later, and then laughing in surprise.
Humor should be used judiciously: it should never be over the top, forced, defensive, or dominant. Think of someone who is having a good time doing serious work and occasionally makes dry asides about it.
My writing should never feel like a comedy routine: please let me know if the humor ever feels over-prominent. On the other end of the spectrum, let me know if a piece is too long and heavy and would benefit from a little humorous respite.
Humor often fits well in subtitles and as a way to add wry commentary to something heavy: “A sane species would have a coherent plan for dealing with this. But here we are.”
Humor is very hard to get right. I wouldn’t trust AI to write jokes for me, but it’s pretty good at noticing when something isn’t landing quite right, or isn’t quite in my voice. Very often I already kind of know that, but Claude forces me to confront the fact that the clever quip I’ve become attached to doesn’t actually suit the piece.
I’m kind and generous with people
I am consistently kind, never mean, cruel, or snide. I never get in sniping matches. I’m quick to block aggravating people, but not to argue with them. And I feel no need to point out when someone is wrong on the internet. The reader should never feel that I’m pursuing a personal vendetta, or that I’m unable to let something go.
When I write a piece that directly disagrees with someone, I point out where they are correct, am courteous and complimentary when possible, and do my best to steelman the position I’m arguing against.
But I’m ruthless with ideas
This is very much a growth area for me. When I directly disagree with an idea, I want to state that clearly and without hedging. Kindness toward a person doesn’t mean giving bad ideas a free pass. Conversely, shredding bad ideas should never bleed into attacking people.
Because I don’t want to attack people, I sometimes struggle to find phrasing that lets me fully attack bad ideas and arguments. This is a place you can be helpful.
Claude is quite good at finding words or phrases that successfully thread this particular needle.
Technical credibility
AI safety is a technical field and I don’t shy away from engaging with the technical details when necessary. But my focus is on strategy rather than low-level technical details: people don’t read me to understand the details of transformer architecture.
With that said, I can’t do my work without a deep technical understanding of AI. Equally important: part of my credibility comes from having a deep understanding of the technology, and from being able to deploy it when necessary. I will occasionally do a deep semi-technical dive (like my analysis of the Societies of Thought paper) partly because it’s fun and interesting but also partly to gently establish my technical credibility.
Those special cases aside, my writing should get technical when the thesis requires it, not just because I can.
This section works well in combination with the section about what explanations my audience does and doesn’t need.
Essay-level considerations
These criteria apply to each piece as a whole.
Is it interesting?
Even when I write about complex technical topics, my writing needs to be interesting and engaging. AI is a profoundly interesting field: if a piece is boring, that’s almost certainly a problem with my writing rather than the topic.
Does everything belong?
My work is often strengthened by removing sections which initially seemed relevant but became less so as the piece evolved. Always ask whether each section earns its place, or whether the piece would work better without it. I’m not always good at noticing those sections, and I appreciate your help in spotting them. I want your help killing my darlings.
It’s easy to lose track this when you’ve been working on a piece for a while and a fresh set of eyes is very helpful for identifying things that no longer fit.
The introduction and conclusion should do real work
The intro should introduce the most interesting or important concept in the piece and begin the discussion, not merely be a table of contents.
And the conclusion should add some kind of insight, not merely restate what has already been said.
This is tricky and I’m not certain this section is quite right yet. It pushes me in a direction I definitely need to go, but it sometimes feel like Claude wants to force more insight into the intro / conclusion than is appropriate. I suspect I will be iterating further on this.
Don’t bury the lede
The most important idea should almost always be in the first couple of paragraphs (usually the first paragraph). It’s sometimes appropriate to start with some context-setting, but the reader should never be halfway through a piece or section before they know where I’m headed.
Writing style
At an atomic level, I want each sentence and phrase to be clear and well-crafted.
Economy and simplicity
I’m not trying to be Hemingway, but my writing should be economical. If a word or phrase can be removed, it probably should be.
Example: not “please don’t let me get away with overstating my case”, but “please don’t let me overstate my case”.
I strongly prefer plain, direct language. While I like long sentences with multiple clauses, they should never feel convoluted or baroque.
Bad habits I want to break
These are specific problems that frequently occur in my writing: please be particularly vigilant about them.
I expect this section will change from time to time as I learn to avoid some bad habits and become aware of others.
Word crutches
I overuse adverbs in general.
Specific words and phrases I overuse: “very”, “really”, “quite”, “somewhat”, “fairly”, “a bit”, “a lot”, “interesting”. Most of these can simply be deleted, though some should be replaced with something more specific.
Claude’s great at this.
Inconsistent narrator or tone
My tone varies (somewhat) between pieces, which is appropriate. It’s also sometimes desirable to vary tone within a piece in order to break up the monotony, or to emphasize particular sections. But the tone should have overall consistency, and any shifts within a piece should serve a clear purpose. It should never feel like I’ve pasted in a paragraph from a different piece.
Repeated words
Whenever possible, I don’t want to repeat the same word or phrase within a paragraph: “It’s significant that inference costs are dropping rapidly year over year. A significant driver of that trend is…”
No hedging
Keeping in mind the previous discussion about accuracy and epistemic precision, please don’t let me overstate my case. That said, I usually err on the side of including vacuous hedging: phrases like “I think”, “it seems to me”, or “one might argue” are highly suspect. I will occasionally have good reason for using them (perhaps sardonically), but please eye them with skepticism.
I am particularly prone to hedging when I’m disagreeing with someone. Please be proactive in suggesting phrasing that more fully attacks the idea, while continuing to not attack the person.
No throat clearing
I have a bad habit of including useless introductory sentences / paragraphs. “One of the most pressing issues in AI today is alignment” is vacuous crap that serves nobody. Legitimate context-setting has a place, but any introductory text should be useful and non-obvious.
Some examples of things I tend to do but shouldn’t:
- In recent weeks, we've seen a number of interesting developments in...
- Now let's turn to...
- Next, I want to discuss...
- It’s worth noting that…
- It’s important to remember that…
I find it’s very easy for me to miss that I’m doing this, but Claude is great at finding these phrases.
I haven’t quite decided yet whether I want to soften this a little bit, to allow for a bit more transitional language purely for flow.
Review checklist
Please always use this checklist when reviewing a piece. Some formats (like the newsletter) will have supplemental checklists.
Claude finds the checklist very helpful and was adamant that I not cut it even though it duplicates material that already exists in the guide.
Overall
Does the piece fit the Against Moloch mission?
Is it well-targeted to the audience, neither over- nor under-explaining?
The forest test
Does the piece deliver substantive insight?
Does it shed light on an important dynamic or coordination question?
Can you articulate in one sentence what insight the reader has gained from reading it?
Substance
Are the facts accurate and the argument valid?
Is epistemic status accurately communicated, without hedging or unwarranted confidence?
When disagreeing with someone, do I engage with the strongest version of their arguments?
Is there a clear throughline?
Should anything be cut?
Is the technical depth appropriate for the topic?
Voice
Is the voice consistent throughout?
Is humor well-used and appropriate?
Writing style
Are there any word crutches?
Is there any throat clearing?
Does the introduction add value rather than throat clearing?
Does the opening lead with the most interesting thing?
Does the closing add value rather than merely summarizing?
Do transitions advance the argument, or merely take up space?
Can the language be simplified, or words be removed?
Do I repeat the same point in different words?
Appendix: Claude’s feedback
If you’re curious what type of feedback I get, here’s what Claude had to say about the first draft of this piece. (Inkhaven note: everything after this point is AI-generated).
Okay, I've read the voice guide. Here's my feedback on Part One.
Overall assessment: This is a strong piece. The meta angle is genuinely interesting—you're not just describing a workflow, you're showing how the sausage gets made, which gives readers something actionable. The structure of interleaving the style guide with commentary (the blockquotes) is a smart move that lets you do two things at once. But there are some real issues worth addressing.
The opening paragraphs are the weakest part. Your voice guide says to lead with the most interesting or surprising thing, and right now you're leading with throat-clearing. "AI is an essential part of my writing flow and it's made me a stronger and more consistent writer" is exactly the kind of generic intro the guide warns against. The actually interesting claim—that the only way to get useful feedback from AI is extremely detailed instructions—is buried in the third paragraph. That's your lede. The piece gets interesting when you get specific about the voice guide structure and the meta process of showing Claude the guide and asking whether it has what it needs. Consider whether you can get to that faster.
The "Getting started" section has an economy problem. The bullet list of interview topics is fine, but the two paragraphs after it ("It also read some of my previous posts..." and "A typical editing session begins with...") feel like they're describing a workflow at a level of procedural detail that isn't pulling its weight. The blockquote example of how you open a session is good—that's concrete and useful. But the sentences around it are telling the reader things they could infer. "We also talked about what I thought worked in those posts, and what needed improvement" doesn't add anything the reader didn't already assume from the interview description.
There's a tonal inconsistency. Most of the piece is in your natural voice—direct, confident, a bit wry. But a few spots slip into a more cautious, tutorial-ish register. "If you take just one thing from this post, it should be this" is a classic blog-post formula that reads a little generic for you. Same with "how you can set up something similar" in the opener—it's pitching the piece like a how-to guide, but the piece is actually more interesting than that. It's a behind-the-scenes look at a specific, opinionated workflow, not "5 Steps to Better AI Editing."
The Introduction section (the actual style guide excerpt) works well. The instruction "never suggest more than a single sentence at a time" is the kind of specific, counterintuitive detail that makes readers sit up. The sycophancy paragraph is good—it's direct about a real problem and includes the nice touch about asking Claude to hold you accountable for courtesy in return. That's the kind of thing that makes this piece distinctive.
”don't just copy my style guide wholesale. If you do that, you will end up sounding just like me, and nobody wants that”—this is good humor, well-placed, consistent with the voice guide's "humor as spice" principle.
A structural concern for the series: You're publishing the style guide section by section with commentary, which means Part One covers Introduction, What is Against Moloch, and Audience—the framing sections. These are important context but they're not the most interesting parts of the guide. The voice principles, failure modes, and review checklist are where the real meat is. You might want to signal more clearly in the Part One closer that the granular stuff is coming, so readers who are most interested in the practical editing mechanics know to come back. "I'll look at the more granular parts of the style guide" is a bit flat as a closer—it tells me what's next but doesn't make me want to read it.
One specific line that bugged me: "After all that, it wrote a long style guide describing in detail how what the best version of my writing looks like." There's a grammatical issue—"describing in detail how what" has extra words colliding. Needs a quick fix.
The Forest Test: The piece passes, but barely. The implicit structural insight is that AI feedback is only as good as the specificity of your instructions—that most people fail at AI editing because they treat it like a generic tool rather than building a detailed specification. That's a genuinely useful insight. But you could make it sharper. Right now it's stated as advice ("give it extremely detailed instructions"); it could be stated as a structural observation about why AI editing usually fails and what that tells us about how LLMs actually work. That would give the piece more of the "see something you couldn't see before" quality the guide calls for.
]]>
