---
title: "On using AI as a writing assistant"
slug: on-using-ai-as-a-writing-assistant
url: https://listedarticles.com/articles/on-using-ai-as-a-writing-assistant
canonical_url: https://ninashamsi.com/writing/i-am-a-bad-writer.html
content_type: blog_post
language: en
published_at: 2026-10-07T00:00:00.000Z
updated_at: 2026-10-08T05:11:52.029Z
author: "Nina I. Shamsi"
authored_by: human
publisher: "Nina I. Shamsi"
publisher_url: https://ninashamsi.com/
topics: ["AI", "Writing", "Productivity"]
license: all-rights-reserved
word_count: 1809
reading_minutes: 8
citation: "Nina I. Shamsi, Nina I. Shamsi. \"On using AI as a writing assistant.\" 7 Oct 2026. https://ninashamsi.com/writing/i-am-a-bad-writer.html (all-rights-reserved)"
# The full text follows. The web page shows an extract and sends readers
# to the source above; quote the citation and link the canonical URL.
---

# On using AI as a writing assistant

> Nina I. Shamsi, who calls herself a bad writer because her explanations wander, describes how she uses AI as a writing assistant: breaking writing into stages such as brief, outline, drafting and review, the components through which AI helps organise each stage, and the versioned artifacts produced, while admitting the process is still unfinished.

I am a bad writer because I am the worst at explaining things.

Let’s say someone is interested in reading about how to pick the best apples for baking. I may (in my head) relate that interest to how apple trees grow, and if by some miracle the reader sticks with my piece through that, I will veer from growing apple trees to farming and tending to an apple orchard. From my perspective, I am enabling the reader to adopt some manner of resilient or sustainable behavior (“If you’re interested in using apples for baking, you can grow them yourself!”), but whereas I may be interested in such information, I readily acknowledge that to someone else those tidbits of knowledge may come off as non-sequiturs at best or nonsense at worst. So, I simply conclude that I am a bad writer, and as such I’ve never bothered to share most of my writing. Enter AI.

I really like AI as a writing assistant because I think it has enabled me to funnel my fluid thought process into something I can flash-freeze with the liquid nitrogen that is prompt-based engineering and package my writing neatly into bite-sized morsels. Admittedly, I am unsure how successful that experiment has been as yet because I don’t really have any avenues of receiving feedback. I kind of dislike the overall product from AI-assisted writing because I find that AI writing is often stilted (like something just tastes off about it), and I feel like the reviewing and editing process, while it captures some aspect of my voice, leaves the original piece less cohesive than it was when originally composed by an AI writing assistant.

As people increasingly use AI writing assistants, I wonder what their workflows and processes are for using these tools, but I thought I’d at least share mine. Note that I am aware of all the concerns about AI use, and I am also interested in taming the use of volatile, emerging technologies. I feel that I learn more about its pitfalls as I use it different ways.

## The process

Before I start writing something, ideally, I like to become inspired by reading or watching something, usually unrelated to the topic, or listening to music. If I am especially uninspired, I may go for a drive. I have a lot more unpublished writing, but for this article I’ll use the scant examples of technical writing I have published online.

Here are paragraphs from an article I wrote about deepfakes without any AI assistance:

The goal of content authentication is to actively embed media with markings or patterns which are imperceptible to human senses, or to define a methodology for keeping track of the provenance of media that is not AI generated. Blockchains are being explored for provenance tracking, but can be slow and cumbersome.

Pattern embedding, meanwhile, can be applied to non-synthetic media to indicate its authenticity, or to synthetic media during the generation process to indicate that it was produced by an AI. Traditional techniques used for copyright protection and authentication are often vulnerable to attacks from neural nets, and so new authentication methods need to be developed. Some authentication approaches embed metadata or credentials, which can be as small as 1-bit, into media, like a key for identifying the content owner, content subject matter, or creation method. Most recent research focuses on blind embedding methods using neural nets, as opposed to semi-blind or non-blind, as blind methods do not require the original media for authentication.


Here are paragraphs from an article I prompted via a Telegram bot to a suite of agents running on my self-hosted server to write while I was at a doctor’s appointment:

The distinction between identity and trustworthy behavior is longstanding. Google’s 2006 operational research described combining authenticated domain identities with spam classification and user feedback to build reputation. Approximately 41% of spam in that historical dataset was already authenticated. Identification supplied a consistent entity against which behavioral evidence could accumulate; authentication alone did not establish that a message was wanted or safe.

The precedents support identity as part of an abuse response system, e.g., verify authority, associate incidents with a credential or deployment, coordinate investigation, and withdraw access where justified. A system can provide value by shortening an incident or limiting its spread even if it does not prevent the initial intrusion. For agents, working groups should investigate which of these benefits existing mechanisms can deliver, how replacement or compromised identities affect them, and what privacy and access costs they introduce. The precedents establish useful mechanisms to test; they do not by themselves establish the need for a new institution.


I like how clinical the second excerpt is because that’s just my taste for technical writing (not everyone’s bag, and that’s okay with me), but I do like the almost-clinical-but-not sensibilities inherent to the former example.

To many, both of these examples may read the same, and I think that’s really interesting from a cognitive science perspective. I don’t know how to explain how they appear different to me.

As a process-obsessed engineer, I am torn between writing authentically, whatever that means to one, and providing objective technical information to a reader.

## Details on the process

Better writers, and remember that I am a bad one, have ways to organize themselves when they compose something. I just cannot do that without AI to rein me in. Someone else may naturally arrive at some variant of organizing their writing via the following stages and sticking to them, but I need AI to remind me to stick to them while my writing assistants preserve the following artifacts for use and reproducibility:

| Stages (better writers may naturally follow) | Components (through which AI helps me organize the process) | Artifacts | 
|---|---|---|
| Brief | Identify the audience, question, scope, and intended reader action. | Versioned writing brief | 
| Evidence | Associate each planned claim with inspected sources. | Frozen source pack and claim ledger | 
| Outline | Explain the job of each section and the evidence it needs. | Outline with unresolved gaps | 
| Draft | Compose from the selected brief, outline, and sources. | Candidate Markdown revision | 
| Critique | Identify unsupported claims, missing conditions, and unclear explanations. | Critique tied to that revision | 
| Revise | Apply specified editorial and grammar instructions. | New candidate and a diff | 
| Save version | Keep the writer’s chosen draft. | Immutable document version | 

When I am not prompting via a Telegram bot, I interact with the process via home-built custom tooling, which roughly takes the following shape:

```
Custom HTML + JavaScript chat
            │ authenticated application requests
            ▼
Writing application backend
  sessions · briefs · source packs · profiles · document versions
            │
            ├── LiteLLM Python SDK ─────────────────► model provider
            │
            └── optional LiteLLM Proxy ─────────────► model provider
```
Or I use the chat interface of AI agent coding tools supplemented with (often homegrown) MCPs and skills, including the following (a non-exhaustive list):

| Component | Type | Role in preparing this article | 
|---|---|---|
| `ai-assistance-writing-skill` | Skill | Guided the writing brief, evidence selection, drafting, revision records, and reproducibility requirements. | 
| `literature-review` | Skill | Organized the preliminary research and comparisons between approaches. | 
| `dispatching-parallel-agents` | Skill | Guided parallel research into API parameters, conversation state, and inference variability. | 
| `openai-docs` | Skill | Guided verification of OpenAI-specific documentation and API claims. | 
| `verification-before-completion` | Skill | Guided verification of artifacts before reporting completion. | 
| Context7 | MCP server | Contributed to preliminary technical documentation research. | 
| Web browsing | Built-in tool | Retrieved primary sources and checked current provider documentation. | 
| Agent collaboration | Built-in tools | Coordinated research agents and collected their findings. | 
| Local shell and Python | Execution tools | Captured source snapshots, assembled files, checked example syntax, and generated hashes and archives. | 

Below I share an outline of an example repository I may use for AI-assisted writing:

```
ai-assisted-writing-workflow/
  article.v1.md       Saved reference draft
  brief.md            Writing requirements and assumptions
  messages.json       Available ordered inputs; explicit transcript gaps
  sources/            Frozen evidence and workflow instructions
  source-index.json   Source identities, capture metadata, and hashes
  generation.json     Observed runtime settings and declared unknowns
  environment.lock    Recorded application and dependency versions
  tool-results.json   External evidence/tool records with stated scope
  edits.patch         Applied editorial changes; empty before review
  manifest.json       Artifact inventory, versions, and hashes
```
I am particularly interested in the reproducibility of a process across sessions for ensuring and maintaining the integrity of collected evidence, so I wish it were possible to control the following parameters (using the LiteLLM API as an example) for the latest model APIs from different providers:

| Parameter | What it controls | Writing implication | 
|---|---|---|
| `temperature` | Sampling variability, where configurable. | Tune only within a validated model profile. | 
| `top_p` | Probability mass considered during sampling. | Usually adjust this or temperature first, rather than both. | 
| `seed` | Supported sampling reproducibility controls. | Useful for comparisons; not an identity guarantee. | 
| `max_tokens` /`max_completion_tokens` | Generation limit with model-specific accounting. | Budget for completion and detect truncation. | 
| `response_format` | Supported output structure. | Useful for briefs, outlines, or claim records. | 
| `presence_penalty` ,`frequency_penalty` | Token repetition preferences. | Leave unchanged unless an evaluation justifies tuning. | 
| `stop` | Supported stopping sequences. | Avoid accidentally cutting off prose or citations. | 

For this article (the one you’re reading, hi), I used AI for research and for organizing information in the tables, but not for the writing. For example, I researched which control parameters could be used for earlier model APIs (I haven’t personally tested these):

| Parameter | Kimi K3 / K2.7 Code | Kimi K2.6 | GLM-5.3 / 5.2 / 5.1 | 
|---|---|---|---|
| `temperature` | Fixed 1.0 | Fixed 1.0 thinking / 0.6 non-thinking | Adjustable 0–1 | 
| `top_p` | Fixed 0.95 | Fixed 0.95 | Adjustable 0.01–1 | 
| `seed` | Not documented | Not documented | Not documented | 
| Token limit | `max_completion_tokens` ;`max_tokens` deprecated in current API | Current API documents both; prefer model-validated field | `max_tokens` | 
| `response_format` | JSON / JSON Schema documented at API level | JSON / JSON Schema documented at API level | Text / JSON object; schema enforcement not documented | 
| Presence/frequency penalties | Fixed 0 | Fixed 0 | Not documented | 
| `stop` | Supported at API level; up to five strings | Supported at API level; up to five strings | Supported; documentation specifies one stop string | 

The writing agent skill I’ve developed currently attempts reproducibility via the following goals, but I am still trying to shape it into something I like:

| Goal | What the skill requires | What it promises | 
|---|---|---|
| Consistent writing | Reuse the brief, evidence, editorial rules, and acceptance criteria. | Comparable substance and style; wording may differ. | 
| Independent regeneration | Preserve ordered inputs, source snapshots, generation settings, dependency versions, tool results, and revisions. Compare subsequent outputs. | Another session can attempt the same task; identical output is not guaranteed. | 
| Exact replay | Store an immutable document version, calculate its hash, and retrieve those saved bytes directly. | The same artifact, verified by its hash. | 

## The point

As this article was written and organized mostly by my organic LLM (side note: I hate equating the mind to an LLM because I do not think it’s that simple, but I digress), maybe this article is a bit disorganized. I am still trying to find an AI-assisted writing process which works for me and provides consistent and reliable output, i.e., I have something that is apple-orchard-shaped, but will it produce quality ingredients for various baked apple goods? I don’t know. TBD.