Two Model Passes for Friday’s Release Notes

It is Thursday afternoon, and your team needs release notes before Friday’s deployment. You have a list of merged changes, several ticket descriptions, and a rough outline. An AI model could turn that material into readable copy. But does every attempt need the most capable model you can access?

A useful starting point is to split the work: use a lower-cost model to produce and revise a draft, then ask a stronger model to review the best version. You spend less on exploration while reserving more capability for the decisions that matter before publication.

Drafting and final review are different jobs

The draft stage involves plenty of disposable work: trying three openings, grouping changes by audience, or shortening an awkward paragraph. You need something usable to react to. You do not need every version to be ready for customers.

The final pass has a narrower purpose. It checks whether the chosen draft follows instructions, preserves important details, and says anything the source material cannot support. A more capable model may handle these judgments better, but that is something to test on your tasks, not assume from its price.

This approach works best when the first stage produces a draft you can inspect. If the initial task requires difficult reasoning just to establish the right answer, a cheap first pass may create more correction work than it saves.

Give the first model a bounded drafting task

For release notes, provide the actual change list and define the output. Ask for sections covering new features, fixes, and any action customers must take. Specify the audience and approximate length. Tell the model to flag missing information rather than invent an explanation.

A practical request might read: “Draft 400-word release notes from these approved changes. Write for developers using our API. Preserve endpoint names and version numbers exactly. Do not describe a performance improvement unless the notes include evidence for it.”

Use the lower-cost model for revisions that remain straightforward: remove repetition, regroup related fixes, or produce a shorter opening. Choose one draft before moving forward. Sending every alternative through the stronger model defeats much of the purpose.

Send the reviewer the evidence and the draft

The stronger model needs more than the draft. Give it the original source material, the writing requirements, and a clear review assignment. Otherwise, it can make the text sound convincing without knowing whether it is accurate.

• Compare every factual claim with the approved change list.
• Identify omitted changes that customers need to know about.
• Preserve names, dates, version numbers, and technical identifiers.
• Return a corrected draft and a short list of unresolved questions.

Ask it to distinguish corrections supported by the source from questions requiring a person’s answer. If a ticket never states whether an update is backward compatible, a second model cannot supply that fact reliably. Someone on the team must resolve it.

Measure the cost of the whole workflow

Two passes do not automatically cost less than one. The reviewer reads the instructions, source material, and draft, then generates another response. Long inputs and repeated reviews can consume the savings from cheaper drafting.

Start with a small comparison using similar completed tasks. Record total API spend, time spent correcting the output, and whether the result passes your normal review. Compare the two-pass workflow with using the stronger model from the start. Keep the split only where it produces an acceptable result at a better total cost.

Make switching models a small application choice

Keep separate model settings for drafting and review so you can change either without rewriting the workflow. Store the prompts and source material alongside each result to make failures easier to investigate.

RelayVano is worth considering for this setup: its pay-as-you-go relay lets developers access multiple model providers through an OpenAI-compatible SDK. Sign up and try one bounded task before expanding the workflow.

Keep a human checkpoint before Friday’s publication

For customer-facing release notes, a person should approve the final text and resolve flagged questions. The useful division of labor is simple: inexpensive drafting creates options, focused review improves the chosen version, and the team remains responsible for what ships.