Can Rules Improve AI Writing? — Turning a Professional Editor into a TypeScript Workflow

When AI prose feels mediocre, the obvious reaction is: “Use a smarter model.”

There is another option: put an absurdly persistent editor next to the model.

That editor checks the headline, compares it with the article’s actual promise, scans the headings, catches unexplained jargon, notices repeated caveats, verifies all 12 locales, and sends only the failed parts back for revision.

TypeScript does not write prose. But it can build an editorial desk that refuses to ship weak prose.

1. Five-second answer: do not code writing talent; code the editorial process

Yes, shared rules can improve AI writing. The bigger gain, however, comes from turning those rules into a workflow: generate → check → judge meaning → revise failures → check again.

OpenAI describes evaluation as a loop of specifying what good looks like, measuring outputs, and improving the system as new failure modes appear.[1]

For writing, that means a bad article should not merely be fixed once. The failure should become a reusable quality check for the next hundred articles.

2. TypeScript is not the writer; it is the production line

Code is excellent at deterministic checks:

• Is there more than one H1?
• Do title and og:title disagree?
• Are all required locales present?
• Are headings duplicated?
• Are dates and URLs malformed?
• Did the score fall below a release threshold?

But code alone is weak at questions such as:

• Is this opening actually engaging?
• Is the metaphor worth keeping?
• Does this heading make sense without context?
• Does the title express the reader’s real question?
• Has the research section swallowed the original insight?

The useful split is simple: TypeScript handles reliable mechanical checks; an AI editor handles meaning-based judgment.

3. “Professional editor” becomes practical when split into roles

“Edit this like a professional” is too vague for a production system. Break it down.

Structural editor

Checks reader need, order, pacing, and whether the answer arrives soon enough.

Copy editor

Improves headlines, openings, repetition, wording, and rhythm.

Fact editor

Checks numbers, dates, quotations, confidence, and source alignment.

Search-entry editor

Checks whether the beginning of the headline tells readers what the page is about.

Google Search Central says title links help users quickly understand a result and why it is relevant. It recommends descriptive, concise, distinct titles and warns against keyword stuffing.[2]

NN/g’s usability research likewise shows that people often scan web pages and that the first words of links and headlines carry disproportionate information value.[4][5]

This is not “put magic SEO keywords on the left.” It is make the article recognizable before the reader spends attention on it.

4. Before and after: move the joke; do not kill it

Suppose the title is:

Before

The Surname Is Innocent; the Dictionary Crashed — Manko, Wang and Chin as “Dangerous Names in Other Languages”

The joke is strong, but the actual subject arrives late.

After

Names That Sound Awkward in Another Language — Manko, Wang, Chin and Cross-Language Name Collisions

Then open the article with:

The surname is innocent. The dictionary crashed.

The joke survives. It may work better because readers already know what the joke is about.

Google’s people-first guidance also asks whether a page title gives a helpful, descriptive summary instead of being written mainly to chase search traffic.[3]

5. Good shared rules prevent repeated accidents; they do not clone every article

Rules become harmful when they force every article into the same skeleton: always three sentences, always a question heading, always two examples, always the same “In conclusion” opening.

Better rules describe failures to avoid:

• Do not bury the main question behind a slogan.
• Do not promise something the body never answers.
• Do not repeat the same caveat three times.
• Do not drop jargon without explanation.
• Make headings understandable on their own.
• Let research support the original insight instead of replacing it.
• Do not translate Japanese word order mechanically into 11 other languages.

Keep creative freedom; block defects.

6. P0 / P1 / P2 keeps the system from becoming a rule prison

P0: must not fail

Facts, numbers, dates, quotations, headline-body consistency, privacy, locale completeness, and unsupported claims.

P1: strongly preferred

Fast answers, one main idea per paragraph, plain-language explanations before jargon, meaningful headings, and less repetition.

P2: voice

Jokes, metaphors, conversational rhythm, unusual phrasing, and memorable hooks.

P0 does not require killing P2. Otherwise quality control produces prose that reads like a government warning label.

7. The real asset is a failure-driven evaluation loop

A strong system does this:

1. Generate a draft.
2. Run deterministic checks.
3. Let a semantic editor read for meaning.
4. Return structured failure reasons.
5. Revise only the failed parts.
6. Check again.
7. If the failure is new and generalizable, add it to the permanent rubric.

OpenAI’s eval framework emphasizes this continuous improvement loop: real failures become new evaluation cases and clearer expectations.[1]

The important detail is targeted revision. If only the headline failed, do not regenerate 2,000 good words and introduce five new problems.

8. A TypeScript implementation can stay simple

const draft = await writeArticle(input);

const hardCheck = runDeterministicChecks(draft);
const editorial = await semanticEditor.review(draft, rubric);

if (!hardCheck.ok || editorial.hasCriticalIssue) {
  const revised = await reviseOnlyFailures(draft, {
    hardCheck,
    editorial,
  });

  return verifyAgain(revised);
}

return draft;

The point is not fancy code. Put certain checks in runDeterministicChecks, meaning-dependent decisions in semanticEditor.review, and transform failure reasons into precise revision instructions.

That is easier to maintain than a giant prompt containing two hundred vaguely interacting commandments.

9. Automation still has weaknesses: the AI editor can be wrong

A model can label a good joke “redundant,” flatten minority styles, destroy culturally specific humor during localization, rate its own prose too generously, or confuse plausible wording with factual verification.

So semantic scores are signals, not truth.

Facts still go back to primary or official sources. High-risk publication cases can be escalated to human review. Each locale should be judged as writing in that language, not as a shadow of Japanese.

“AI said OK” is not a quality system.

10. At 100 or 1,000 articles, the compounding improvement matters most

One article reveals that the slogan pushed the real question too far back. Add a check.

Another reveals that four “however” paragraphs dissolved the conclusion. Add a check.

Another reveals that the German version is technically correct but obviously translated. Add a locale-specific check.

A failure no longer fixes one article. It becomes editorial infrastructure.

That is the compounding advantage.

11. Conclusion: build a sleepless editorial desk, not a mountain of writing rules

The goal is not to transplant literary talent into TypeScript.

The goal is to reproduce the useful judgments of a strong editor:

• “Readers cannot tell what this is about.”
• “That headline promises something the article never answers.”
• “Do not delete the joke; move it.”
• “This fact needs a source.”
• “This translation sounds translated.”

Turn those judgments into repeatable checks, semantic review, targeted revision, and re-evaluation.

Then the same model can produce a meaningfully better final article because the system around the model learned how to edit.

---