Release notes sit at the intersection of engineering and product communication. Engineers know what changed but write in technical jargon. Product managers know how to communicate to users but may not fully understand every change. The result is release notes that are either too technical, too vague, or simply missing.

The AI Approach

An LLM reads the technical change log - PRs, commit messages, issue descriptions - and translates it into user-facing language. It understands that “refactored the authentication middleware to support OIDC” means “you can now sign in with your company’s single sign-on.”

Three-Step Build

  1. Collect changes - Gather PRs merged since the last release, their descriptions, and linked issues. Include any product requirement documents or feature specs referenced in the issues.
  2. Translate - Prompt the LLM to rewrite each change from the user’s perspective. What can they do now that they could not before? What problem is fixed? What should they be aware of?
  3. Structure - Group changes into user-facing categories (new features, improvements, bug fixes) and format for your release channel (email, blog, in-app notification).

Where It Breaks

Internal refactors and infrastructure changes have no user-facing impact and should be excluded, but the AI may try to describe them anyway. Changes that span multiple PRs may be described multiple times. Human curation of the final output is essential.

The Production Path

Trigger on release tag creation. Generate a draft that a product manager reviews before publishing. Over time, fine-tune the output based on which AI-generated descriptions the product manager keeps versus rewrites. Maintain a glossary of how your team’s technical terms map to user-facing language.