Reviewing changes & PRs

A "diff" is just a fancy word for "what's different." Sparkle puts the before and after right next to each other. Removed lines show up in red, new lines in green, so you can skim what the agent actually did in seconds without reading a single file end to end.

You've got four moves, and not one of them can hurt your project:

• Looks right? Keep it (that's a merge, see below).
• Unsure about one part? Ask for a follow-up change in plain English.
• Curious? Click through the changed files one at a time and look around.
• Hate it? Discard it, and your project snaps right back to how it was.

Reviewing first is always safe, because until you keep the work, your real project hasn't moved an inch. So poke around. Take your time. Get nosy. New to the whole idea? Here's a friendly explainer on pull requests and proposing changes.

You already know the failure mode: the AI confidently rewrites three files, two of them great and one of them quietly, beautifully wrong. The diff is how you catch the wrong one before it ships.

Review fast, but review for real. A killer 60-second pass: scan the file list first (did it touch things it had no business touching?), read the red removals before the green additions (deletions are where the silent breakage hides), and eyeball any new dependency or config change. Something smells off? Request a follow-up edit instead of accepting now and firefighting later. And if the whole branch is a mess, don't wrestle it. Discard and re-prompt. Way cheaper than untangling.

It's a standard diff against the branch's base: per-file, red removed, green added. Read it, request edits, or discard the branch outright if it isn't worth salvaging. Nothing exotic here. This is the part you already trust.

The point worth making: because each agent works in its own worktree on its own branch, the diff is clean and isolated. So review is a real gate, not a polite formality you click through on autopilot.

Given enough eyeballs, all bugs are shallow.

Bringing the changes in is called a merge. The instant you merge, those changes become an official part of your app. Until then, your main project sits there completely untouched, which is exactly why reviewing first can never get you into trouble.

Sparkle handles all the fiddly git mechanics behind the scenes. Your only job is the fun part: deciding when the work is good enough to keep.

Merging integrates the agent's branch into your main line. Sparkle commits and merges for you, so the git incantations aren't your problem. Your job is the one thing software can't do for you: the judgment call on when.

merge fast-forwards or merges the agent's branch into your main line; Sparkle handles the commit/merge plumbing. Until then main is untouched, so a bad branch costs you nothing but the tokens you already spent. Cheap mistakes are good mistakes.

A pull request is a polite, formal "please review and accept these changes" that goes through GitHub. It's the right move when other people, or automated checks, should sign off before the work becomes part of the project.

Flying solo? You usually don't need one: merging directly is completely fine, so don't overthink it. Working with a team? A PR is how everyone stays on the same page. Gentle background reading: about pull requests.

Got CI or a teammate in the loop? Skip the direct merge and have Sparkle open a GitHub pull request from the branch instead. Same review habit, now routed through the checks that catch what your 60-second skim didn't. Solo with no CI? Merge directly and keep moving.

Sparkle opens a GitHub PR from the branch in one step, so changes run through your existing review and CI before merging. No local push dance required. Reference, if you want the canonical model: about pull request reviews.

Programs must be written for people to read, and only incidentally for machines to execute.

A diff exists for a human to read. That stays true when the author is an agent.