How do you use AI to write technical docs, changelogs, and commit messages?

Question

Accepted Answer

The key is to **give AI the raw material** — the actual diff or code — and ask for a specific, conventional format. AI is good at turning a change into clear prose, but only if it can see what changed.

## A good workflow

- **Feed it the diff**, not a vague description: `git diff --staged | <your AI tool>`.
- **Ask for a known convention** — Conventional Commits (`feat:`, `fix:`, `docs:`), or your changelog style.
- **Keep it accurate and concise** — a subject line under ~50 chars, a body explaining *why*.
- **Verify it matches the diff.** AI can invent changes that aren't there; you must check.

## Before / after

A lazy commit message:

```text
fixed stuff
```

After feeding the diff and asking for Conventional Commit style:

```text
fix(auth): reject expired tokens in session middleware

The middleware only checked token signature, not expiry, so expired
sessions stayed valid. Added an `exp` claim check that returns 401.
```

The second version tells a reviewer *what* changed and *why* — far more useful in `git log` six months later.

## What AI is good at here

- **Docstrings and READMEs** — summarize a module's purpose and usage.
- **Changelogs** — group commits into Added / Fixed / Changed sections.
- **Commit messages** — turn a diff into a clean, conventional message.

Always **read the result against the actual change**. AI doesn't know your intent — only the code it was shown — so it can mislabel a `fix` as a `feat` or claim a side effect that isn't real.

## Why it matters

Good commit messages and docs are how your future self and teammates understand *why* code exists. AI removes the friction of writing them well, but accuracy is on you: a confidently wrong changelog is worse than none. Feed it real input, demand a real convention, and verify before you commit.