Fine-Tuning an AI on Your Writing vs Measuring It

By Jack Stovell X · Instagram · LinkedIn · 2026-09-14 · Updated 2026-11-05 · Research

Fine-tuning produces an opaque artefact you cannot read. Measurement produces an explicit, editable, portable profile. An honest comparison for the technical DIYer.

You don't need to fine-tune a model to sound like yourself. Most people think you do. That's the whole industry pitch, isn't it: feed the machine enough of your prose and it becomes you. Except it doesn't, not quite, and even when it half-works you can't tell why.

So let's actually compare the two approaches properly, because you're a technical person and you deserve better than marketing copy.

What fine-tuning actually costs you

Fine-tuning means taking a base model and further training it on your own writing samples until its weights shift toward your patterns. In principle, elegant. In practice, expensive in three currencies: data, money, and time.

You need volume. Not a blog post and a couple of emails, real volume, enough that the gradient updates have something to converge on. Then you need compute, or you pay someone else's compute bill via an API-based fine-tuning service. Then you wait. Training runs aren't instant, and neither is the evaluation loop after, where you generate samples, read them, decide the tone's off, and go again.

And here's the part that should bother a technical reader more than the cost: you can't inspect what it learned. The model's a few billion parameters shifted by a small amount, and there's no clean readout that says "sentence length variance: increased" or "contraction rate: 0.52." It's opaque by construction. You get outputs. You don't get a spec.

That opacity compounds over time, too. Base models get updated, deprecated, replaced. Your fine-tune was built on top of a specific checkpoint, and when the provider retires it or nudges its behaviour, your carefully tuned artefact can drift or break outright, and you often won't know until the outputs start feeling wrong. Debugging that means retraining and hoping. Not exactly an engineer's idea of a good time.

What measurement does instead

Measurement takes a different bet entirely: don't touch the model, describe the style.

ScriptGrain's approach (and this is the category, not just one product) pulls 45 distinct attributes out of your writing: sentence length and its variance, contraction rate, comma density, how often you hedge versus state things plainly, your preferred discourse markers, paragraph opener habits, the lot. Every one of those is a number or a labelled pattern you can actually read. Not a black box. A spec sheet.

That matters for three reasons, and they stack.

  1. It's editable. If the profile says your contraction rate is lower than it should be, or your rare_word_rate has crept up because you've been reading too many papers lately, you correct the number. Try doing that to a fine-tuned model's weights.
  2. It's portable. The profile isn't locked to one base model. Feed it into GPT-family models, Claude, whatever comes out next year, the constraint travels with you. Fine-tunes don't; they're welded to their base.
  3. It's cheap to start. You need a handful of samples, not a corpus. ScriptGrain's free tier gives you a profile and one analysis, no card required, and there's a free browser tool at scriptgrain.com/tools/writing-style-analysis if you just want to poke at your own writing before committing to anything.

None of that is hand-waving. It's the difference between an inspectable artefact and an inference you're hoping holds.

Where fine-tuning actually wins

To be fair, and I want to be fair here, there's a real case for fine-tuning, and it's not small: deep domain style at scale.

If you're generating enormous volumes of output in a narrow, technical register, legal drafting, medical documentation, a codebase's internal style guide made prose, fine-tuning can bake in domain-specific patterns that a general-purpose model plus a style profile might still miss on the edges. It's also better suited when the "voice" you want isn't really personal at all; it's institutional, collective, built from thousands of documents rather than one person's habits. A measured profile describes an individual's stylometric fingerprint. It's not designed to encode a hundred years of case law formatting.

So if you've got the data pipeline, the budget, and a narrow enough domain that drift and opacity are acceptable trade-offs, fine-tuning earns its keep. That's a genuine concession, not a hedge.

The practical split

For most people considering this, though, the calculus is simpler than it looks. You want your writing to sound like you across tools, across models, without an ongoing training bill and without a black box you have to re-earn trust in every time the base model changes. That's a measurement problem, not a training problem.

And the honest test is this: can you read what the system learned about your voice, check it against a paragraph you know is authentically yours, and fix it if it's wrong? With a profile, yes, every time. With a fine-tune, you're reading tea leaves in generated text and guessing at the mechanism underneath.

Fair enough if you still want to fine-tune. Some jobs call for it. But if what you actually want is your voice, portable, inspectable, and correctable, start with the thing you can read. ScriptGrain's plans start from £12 a month if you want the full pipeline, but the free analysis will tell you more about your own writing in five minutes than most people ever bother to learn. That's not a bad place to start, whichever way you go after.

Questions

What is the difference between fine-tuning an AI on your writing and measuring it?

Fine-tuning takes a base model and trains it further on your samples until its weights shift toward your patterns. Measurement leaves the model alone and describes the style instead. ScriptGrain's approach, which is really the category rather than one product, pulls 45 attributes out of your writing: sentence length and its variance, contraction rate, comma density, how often you hedge, your discourse markers. Each one is a number or a labelled pattern you can read. Fine-tuning gives you no such readout.

How much does it cost to fine-tune a model on your own writing?

It costs you in three currencies: data, money and time. You need real volume, far more than a blog post and a couple of emails, so the gradient updates have something to converge on. Then you need compute, or you pay someone else's compute bill through an API-based fine-tuning service. And there's a fourth cost that sneaks up later: when the base model is retired or changed, your fine-tune can drift or break.

Can you see what a fine-tuned model has learned about your voice?

No. The model is a few billion parameters shifted by a small amount, and there's no clean readout that says "sentence length variance: increased" or "contraction rate: 0.52." That opacity is the part that should bother a technical reader most. You end up reading tea leaves in generated text and guessing at what's going on underneath.

Can you correct a voice profile if it gets your style wrong?

Yes, because every attribute in it is readable and editable. If the profile says your contraction rate is lower than it should be, or your rare_word_rate has crept up because you've been reading too many papers, you correct the number. The honest test is simple: read what the system learned, check it against a paragraph you know is authentically yours, and fix it if it's wrong. A profile passes that test every time.

When is fine-tuning the better choice?

Fine-tuning wins on deep domain style at scale. If you're generating huge volumes in a narrow, technical register, such as legal drafting or medical documentation, it can bake in patterns a general model plus a profile might miss on the edges. It also suits voices that are institutional rather than personal, built from thousands of documents. If you've got the data pipeline, the budget and a narrow enough domain that drift and opacity are acceptable, fine-tuning earns its keep.

More from the Journal

More from the ScriptGrain Journal