How to write X posts with AI without losing your voice

Give the assistant something only you can supply

The most recognizable part of your voice is often your judgment: what you noticed, what you found difficult, and why a decision mattered. An instruction such as “write in a casual founder voice” cannot supply that. It produces a style approximation without the observation that would make the post yours.

Start with rough notes. What happened? What did you expect? What changed your mind? What can you show? These questions give an assistant concrete material to organize. You can speak the notes, paste a short work log, or describe a screenshot. The input does not need to be polished; it needs to be true.

For example, “I removed three steps because customers kept abandoning setup” includes a customer claim that needs evidence. If all you know is that the flow felt cumbersome in your own review, say that. The assistant should help you express the stronger supported observation, not quietly upgrade it into a more marketable story.

Create a voice reference from posts you would actually publish

Select a small set of your own posts that still feel representative. Include more than one type: an explanation, a progress update, a question, and a product invitation. Tell the assistant what you like about each. Perhaps you lead with the concrete problem, keep uncertainty visible, or use one short example instead of broad advice.

Add negative examples when they are useful. Show a draft you rejected and identify why: exaggerated success, invented emotion, a hook that promises more than the post delivers, or a CTA that sounds unlike you. Specific feedback is easier to apply than “make it more authentic.”

A voice reference should guide editing, not trap you in an imitation of old posts. Your writing can change with the subject. A technical note may need more detail than a visual demo caption. Preserve the underlying habits of thought while letting the format serve the material.

• Lead with the concrete event or problem when it is the main point.
• Use words you would say in conversation with this audience.
• Keep uncertainty when the evidence is incomplete.
• Avoid invented emotions, customer quotes, and success claims.
• Use a CTA only when the next step helps the reader.

Separate the fact, the interpretation, and the invitation

A useful draft often has three components. The fact is what happened or what the artifact shows. The interpretation is what you think it means. The invitation is what the reader can do next. Keeping them distinct makes the post easier to review and prevents your opinion from appearing as a measurement.

Suppose you redesigned a settings page. Fact: the primary action now appears beside the relevant setting. Interpretation: you think this makes the workflow easier to follow. Invitation: people can view the prototype and comment on the interaction. You cannot replace the interpretation with “conversion increased” unless you have that evidence.

Not every post needs all three components. An explanation can be useful without an invitation. A screenshot may carry the fact while the caption carries the interpretation. Ask the assistant which component is doing the work and whether any part repeats what the reader can already see.

Generate genuinely different drafts

Ask for a few distinct approaches rather than superficial hook variations. One draft can lead with the problem. Another can lead with the decision. A third can lead with the artifact. Compare which approach makes the reader benefit clearest without distorting the source material.

Here is an invented source note: “The report used to rank one viral post above every recurring topic. Added median comparisons so repeated performance is easier to inspect.” A problem-led draft might begin, “One viral post made the rest of my report look worse than it was.” A decision-led draft might begin, “I added medians to the report so one exceptional post does not set the whole baseline.” Both preserve the same evidence.

Reject an option like “This one analytics trick guarantees better posts.” It may be attention-grabbing, but it invents a promise. A good hook makes the useful part easier to notice; it should not create a debt the rest of the post cannot repay.

Use my source notes and voice examples to write three distinct drafts: problem-led, decision-led, and artifact-led. Preserve all facts and limitations. Do not invent feelings, results, quotes, or urgency. Keep the reader benefit concrete. Add a CTA only if there is a useful available next step. After each draft, explain which source fact supports the opening.

Edit for specificity before editing for brevity

First check whether the nouns and verbs point to real things. “Improved the experience” could mean almost anything. “Moved export into the report header” is inspectable. “Learned a lot” is a reaction without content. “The empty state needed one next action” communicates a lesson.

Then remove sentences that repeat the opening, decorate an obvious point, or explain your enthusiasm instead of the reader’s benefit. Shorter is not always better: a missing detail can make a concise post vague. Keep the detail that helps someone understand or use the idea, and cut the sentence that only sounds polished.

Read the result aloud. Notice where the rhythm sounds like a prepared announcement rather than your normal writing. Replace stock transitions and inflated adjectives. You can keep a memorable line if it earns its place through the actual observation; you do not need to sand every post into neutral documentation.

Match the CTA to the actual stage of the work

A CTA is a practical next step. If the product is in early access, invite readers to join early access. If the post teaches a method, link to the fuller guide when it adds detail. If the artifact is a prototype, ask for feedback on a specific choice. Do not promise immediate access to something that is only a waitlist.

Give the reader a reason to act that follows from the post. “Join my waitlist” is clear, but “Join early access if you want to compare these patterns in your own history” connects the invitation with the demonstrated value. Keep the language proportionate; a small interface improvement does not need a dramatic sales pitch.

When there is no useful next step, let the post stand. Requiring an engagement question at the end of every draft can make genuine observations feel formulaic. An assistant should be allowed to recommend no CTA when the idea is already complete.

Learn from performance without letting it dictate your personality

Save the published version alongside the draft and note what you changed. Over time, this can show which instructions consistently help: clearer first sentences, stronger artifact descriptions, or fewer unsupported claims. The point is a better writing process, not an assistant that maximizes a single metric regardless of your goals.

Compare similar topics and intentions when reviewing performance. A product announcement and a reflective technical note have different jobs. If a provocative draft gets more reach but attracts the wrong audience, that is not automatically the direction to repeat. Read the responses and consider what the post made you recognizable for.

X-tra’s approach to patterns can help you inspect which topics and formats work in your own history. Use that evidence to decide what deserves another attempt while keeping authorship with you. An agent can organize your material and tighten a sentence; your observation and judgment remain the source.