Gradient Descent for Writers

The same loop that hardens code can tighten prose. An AI editor that reads your draft, makes one improvement, saves its work, and repeats — until the document is done or you tell it to stop.

The Problem

Writing is rewriting. Lawyers red-line contracts seven times. Academics revise papers through dozens of drafts. Grant writers polish proposals until the deadline. Consultants tighten decks the night before the pitch.

The work isn't generating the first draft. It's the fifteen passes after that — cutting filler, sharpening arguments, catching inconsistencies, fixing tone. Each pass makes the document slightly better. Each pass is tedious. Each pass is the same kind of judgment applied to slightly different text.

That's a loop. And loops are what computers are for.

The Tools

toast is composable AI for the terminal. It reads a .persona file that defines its role and a .tools file that controls what commands it can run. Point it at a file with a prompt, and it edits.

v is intent-first version control. Every save is a moment with a why — not "updated draft" but "tightened the methodology section, cut redundant citations." You can undo any change, branch to try a different direction, search your revision history by intent.

jam is a shell with times and while loops. These turn toast from a single-edit tool into an autonomous revision engine.

One Pass

The simplest use. Point toast at a file:

$ toast brief.md "tighten the prose, cut filler"
$ v log "first editing pass"

Toast reads the file, rewrites it, saves the result. You log the moment with v. If you don't like it, v undo and you're back to where you started.

Pipe in context for more targeted edits:

$ cat reviewer-comments.txt | toast paper.md "address these reviewer comments"
$ cat style-guide.txt | toast report.md "conform to this style guide"
$ toast contract.md "identify ambiguous clauses"

The Loop

One pass is useful. Twenty passes is transformative.

🍞 20 times toast draft.md "tighten prose, cut filler"

Each round, toast reads the current state of the file — not a cached version, not the version from three rounds ago, the actual file on disk right now. It finds one thing to improve. Makes the change. Logs it with v. Reads .crumbs so it knows what it already did. Moves on.

After twenty rounds, v history reads like a revision log written by a copy editor:

The AI decided it was done after 14 rounds. Six rounds of budget left, nothing worth changing. Every edit is individually reversible with v undo. You can walk through each change with v changes and keep or discard them one at a time.

Unbounded Revision

If you trust the persona and want the AI to decide when it's done:

🍞 while toast draft.md "kaizen until publication ready"

The loop runs until toast outputs DONE. Cap it for safety:

🍞 50 while toast draft.md "kaizen until publication ready"

Fifty rounds max. For a 5,000-word paper, that's more than enough for the AI to touch every paragraph, tighten every sentence, and run out of things to fix.

Different Personas, Different Jobs

The editing style lives in .persona. Swap the file, swap the editor.

# .persona
You are a contracts attorney. Flag ambiguous terms,
missing definitions, one-sided indemnification, and
unlimited liability. Suggest specific redline language.
One issue per round.

🍞 10 times toast vendor-agreement.md "review and redline"

# .persona
You are an academic editor in the sciences. Enforce
active voice, cut hedging, ensure every claim cites
evidence, flag unsupported conclusions. One fix per round.

$ cat reviewer2.txt | toast paper.md "address this reviewer's concerns"

# .persona
You are a technical writer. Every function must have
a description, parameters, return value, and example.
Flag missing docs. One file per round.

🍞 while toast api-reference.md "complete the documentation"

# .persona
You are a McKinsey-trained editor. Every slide needs
one takeaway. Cut jargon. Make the ask explicit.
Pyramid principle. One slide per round.

🍞 15 times toast deck.md "tighten for the board"

Memory

.crumbs is how toast avoids going in circles. Each round it appends what it learned — "intro is tight now, discussion still flabby" or "all passive voice fixed, check citations next." The next round reads this before touching the file.

v history is the revision trail. Every round is a moment with intent. You can search it (v search "thesis"), branch from any point (v on alternate-framing), or restore an earlier version of a single section (v restore a1b2c3d chapter3.md).

The file itself is the ground truth. Toast reads it fresh every round. No stale state. No drift.

Branching Drafts

Not sure if the argument should lead with data or with narrative? Branch it.

$ v on data-first
$ 10 times toast draft.md "restructure to lead with evidence, data first"

$ v on narrative-first
$ 10 times toast draft.md "restructure to lead with the story, data supports"

$ v compare data-first
# see the diff between both approaches

Two branches, two revision trails, one command to compare them. Keep the one that works. The other stays in v forever — you can always come back to it.

Getting Started

# Install toast
$ curl -sSL linuxtoaster.com/install | sh

# Install v
$ gcc v.c -o v && mv v /usr/local/bin/

# Start a writing project
$ mkdir brief && cd brief && v init

# Write your first draft however you like, then:
$ v log "first draft"
$ 20 times toast draft.md "tighten prose, cut filler"
$ v history

Then read what your editor did and why.

Same tools as Gradient Descent for Code — different persona, different job. linuxtoaster.com