AI-Assisted Commits: What Makes Them Safe to Merge

The tool writes code. I sign for it.

Between May and September 2026, 419 of my commits across a Laravel API, several React and Next.js apps, and a FastAPI backend carry a Co-Authored-By: Claude trailer. They include features like a live lesson whiteboard, billing endpoints, and SAML SSO.

The trailer is honest about who typed. It doesn't move responsibility. Every one of those commits landed in a shared codebase under my name, and a teammate reading it later can't tell from the diff whether I wrote a line or approved it. So the bar can't be "does it look right". It has to be "can a stranger verify it".

This is the standard I hold those commits to, and what the history shows.

1. The commit carries its own evidence

338 of the 419 have a real body, not just a subject line. A good body answers the reviewer's first three questions before they're asked:

• What was wrong, from the user's side ("a note the tutor stretched came back at the default size on every page turn")
• Why, at the level of the mechanism ("validated() returns only keys that carry a rule; meta.color was the only rule under meta")
• What proves the fix ("the regression test asserts the round trip through the response and the row")

AI tools are very good at producing a plausible fix. The body is where I show it's the right fix. If I can't write down the mechanism, I don't understand the change well enough to merge it, whoever typed it.

2. Tests pin the bug, not just the feature

115 of those commits name the tests they add or run. The useful ones are shaped like the bug:

• The whiteboard overlay once drew marks before the PDF had rendered. The regression test holds the page in its unrendered state and asserts nothing is drawn.
• The real-time channel's authorization has a test per case: tutor 200, student 200, outsider 403, soft-deleted enrolment 403, anonymous 401.
• Broadcasting has a test proving that a broken broadcaster never fails the save.

A generated test that only exercises the happy path is decoration. A test that reproduces the exact failure, and would fail if someone reverted the fix, is the one worth keeping.

3. Measure instead of describing

62 commits record a measurement or an explicit verification, not an adjective:

• "The page the tutor actually teaches from was 257×363 px on a 1440×900 laptop: 7.2% of the screen." After the change: 537×760 px, 31.5%.
• "Measured: 78px of the slide cut off, while 234px of clear space sat to its right."
• A duplication cleanup: each extraction "independently verified to produce identical DOM / zero behavior change". Duplication went to 4.97% under jscpd, the threshold was lowered to 5, and the type-check baseline and production build were unchanged.

"Improved layout" can't be reviewed. "4.4× the area" can.

4. Keep the dead ends

Some of the most useful lines in these commits describe what didn't work:

I first tried to remove the selector entirely by running all materials together into one continuous filmstrip. That does not work: page counts only exist once each PDF has loaded...

AI tools make it cheap to try an approach and throw it away. Writing down why it was thrown away stops the next person, or the next session, from proposing it again.

5. Scope stays small

The whiteboard landed as dozens of focused commits across three repos, not one giant diff. Each one does one thing a reviewer can hold in their head: "the controls stop moving when you change material", "a failed save says so in the card it failed in". Small scope is what makes the evidence in points 1 to 3 possible.

What this is not

It isn't autonomy. I pick the problem, set the scope, check the mechanism, run the tests, and decide whether it merges. The model speeds up the typing, the searching, and the first draft. It doesn't take ownership of the result.

Faster is only worth anything if the code still holds up after merge. The commit history is where I prove it does.