Reviewing AI rewrites without losing technical meaning

zhenyu xu — Fri, 23 Oct 2026 16:34:18 +0000

A smoother sentence can still be a less accurate sentence. When editing a README, release note, support response, or incident summary with AI, review the meaning before accepting the style.

Disclosure: I work on AI Humanize, a web tool for comparing and refining AI-written drafts. The examples below are written illustrations of a review method, not measured model results.

1. Identify what must survive the edit

Before requesting a rewrite, mark facts and constraints that cannot change: version numbers, commands, dates, units, conditions, exceptions, and the strength of each claim.

For example:

The migration may reduce query time for accounts with more than 10,000 records. It does not change the retention policy.

A rewrite that says "The migration makes queries faster" has lost both uncertainty and scope. A more useful edit would be:

For accounts with more than 10,000 records, the migration may speed up queries. The retention policy stays the same.

The second version is shorter without turning a conditional observation into a promise.

2. Treat code and identifiers as protected text

Ask the editor to leave code blocks, command flags, environment variable names, API paths, and quoted error messages unchanged. Then compare them yourself. A writing model can produce a plausible-looking identifier that your application does not recognize.

A focused instruction is easier to review:

Shorten the prose. Keep code blocks, version numbers, URLs, and error messages exactly as written. Preserve every condition and limitation.

This is an instruction, not a guarantee. Verify the result against the source.

3. Compare before you replace

Keep the original visible next to the revision. Check these questions in order:

Are names, numbers, units, dates, and identifiers unchanged?
Did "may" become "will", or "some" become "all"?
Did the rewrite remove a prerequisite or exception?
Did it invent a cause, result, benchmark, or recommendation?
Does the shorter version still tell the reader what to do?

Only after those checks should you decide whether the new wording sounds better.

4. Give one follow-up instruction at a time

If the revision drops an important limitation, ask for that specific repair. For example: "Restore the limitation to accounts with more than 10,000 records. Keep the rest concise."

Small, explicit follow-ups make it easier to inspect what changed. Avoid repeatedly asking for a vague improvement when the actual problem is a missing fact.

5. Keep the final decision with the writer

In AI Humanize, the workflow is to compare the original and revised text, edit manually, and optionally request a follow-up revision. It also supports writing history and TXT/Markdown import and export. Manual edits do not use generation credits.

The same review method works in a text editor or version-control diff. The useful habit is preserving a source of truth and checking each change against it. A rewrite should improve how a technical statement reads without changing what it claims.

What detail do you most often find missing when reviewing an AI rewrite: a condition, a caveat, or an exact identifier?

A callback-first recovery pattern for AI video jobs on Vercel

zhenyu xu — Thu, 01 Oct 2026 12:15:42 +0000

An AI video job should keep running when the user closes the tab. That makes the browser a useful progress display, but a poor owner of the job lifecycle.

In H3 Max, the video tool I operate, we use a callback-first flow with a delayed recovery check. This is a short implementation note about that design, not a benchmark or a claim that it eliminates background costs.

Separate completion from recovery

The normal path lets the model provider's callback save the result. The callback does not create a Workflow just to save a completed video. If a recovery Workflow already exists, the callback can wake it.

When a job is created, a delayed queue message is also registered with a 60-second delay. That message carries a job ID. When delivered, the consumer reads the current database row rather than assuming the original work still needs attention.

The consumer returns immediately if the job has been deleted or has reached a terminal state. If the next check is not due, or another worker still holds a lease, it defers the check. Only unresolved, eligible work is handed to a recovery Workflow.

What the delay does — and does not — mean

Sixty seconds is an initial recovery checkpoint, not a promise that every model call finishes within a minute. The consumer may defer again based on the job's current state. The queue still incurs work even when the callback succeeds first; what it avoids is starting a recovery Workflow for every successful job.

This also makes failure handling explicit. A failed Workflow handoff throws so the queue can redeliver the message. A duplicate delivery must check the current state again. Provider completion, database persistence and UI progress are separate concerns.

Checks worth keeping

A callback completes the job before the delayed message arrives.
The callback never arrives, so recovery must take over.
A message is delivered more than once.
A job is deleted while background work is pending.
The Workflow handoff fails temporarily.

This pattern trades constant polling for an event-driven normal path plus a durable recovery path. Its cost depends on callback reliability, job duration and retry behavior, so I would measure those before choosing a delay for a different application.

Disclosure: I operate H3 Max. This article was prepared with AI assistance using the project's current implementation.

DEV Community: zhenyu xu