Skip to content
Clawdemy

Practice: AI-authored commits and PRs

Self-check questions

Section titled “Self-check questions”

Answer each in your own words first, then open the answer to check.

Q1. What’s the difference between git’s “author” and “committer” fields?

Show answer

Author = who created the change (stays with the commit forever, even through cherry-pick or rebase). Committer = who applied the commit to the repo (may differ when a maintainer applies a patch on behalf of a contributor). Both are Name <email> strings recorded on every commit; both can be set independently.

Q2. What’s the standard convention for attributing AI contributions in a commit message?

Show answer

A Co-Authored-By: trailer at the bottom of the commit message body, identifying the AI agent by model name and a non-replying email address. Example: Co-Authored-By: Claude Opus 4.7 <[email protected]>.

Optionally paired with a “Generated with” marker line above the trailer when a specific tool (like Claude Code) was used.

Q3. Give three situations where you SHOULD include the Co-Authored-By trailer for an AI agent.

Show answer
  • The agent typed most of the diff and the human reviewed.
  • The agent drafted the commit message (you may have edited it but the AI contributed substantially).
  • The commit was produced through a primarily-AI workflow.

(Other valid answers: any case where the AI substantially contributed to the work.)

Q4. Give two situations where you should NOT include the trailer.

Show answer
  • The human typed all the code; the AI was only consulted for research questions (“how does pthread work?”). That’s not co-authorship, it’s reference lookup.
  • The AI provided line-level typeahead but the human structured all the work. Judgment call, often no.

Q5. List four specific failure modes to look for when reviewing AI-authored code.

Show answer

(Pick any four of:)

  • Hallucinated APIs (calls functions that don’t exist)
  • Plausible-but-wrong logic (looks reasonable, solves wrong problem)
  • Trivial test assertions (assert result is not None instead of result == expected)
  • Confident-but-wrong docstrings (sounds professional, describes wrong behavior)
  • Style mimicry over correctness (consistent style isn’t evidence of correctness)
  • Missing edge cases (happy path covered; edge cases glossed)

Q6. What’s the accountability principle, in one sentence?

Show answer

The human who merges the work is responsible for it, regardless of who typed the code.

Q7. Should release notes call out AI contributions per-feature?

Show answer

User-facing: typically no. A release-level acknowledgment (“Produced with assistance from Claude Code” or similar) is enough. End users mostly don’t care about per-feature attribution.

Internal: more transparency is appropriate. Track AI involvement at the per-PR or per-commit level for process calibration.

Q8. How would you search commit history for AI-authored commits?

Show answer
Terminal window
git log --grep="Co-Authored-By.*Claude" --oneline

Or for a longer-range query:

Terminal window
git log --since="2026-01-01" --grep="Co-Authored-By.*Claude" --pretty=format:"%h %an %s"

GitHub and GitLab also provide UI search by commit trailer.

Trailer-writing drill

Section titled “Trailer-writing drill”

Write commit messages with appropriate trailers for each scenario:

  1. You used an AI agent to refactor a 200-line function into three smaller functions. You reviewed the refactor carefully and confirmed it’s behaviorally equivalent.
  2. You used an AI agent to write a new database migration. You then hand-modified the migration based on feedback from your DBA.
  3. You wrote a new feature entirely by hand. You asked the AI a clarifying question about a library’s behavior at one point but didn’t use any AI-generated code.
  4. You used Claude Code (the specific tool) to add comprehensive test coverage to an existing module. The agent wrote ~250 lines of tests; you reviewed and added 30 more.

Review-lens drill

Section titled “Review-lens drill”

For each AI-authored code snippet below, identify the failure mode (hallucinated API, plausible-but-wrong logic, trivial test assertion, confident-but-wrong docstring, etc.) and propose a fix:

Snippet 1:

def get_user_by_email(email: str) -> User:
    return User.find_or_create_by_email(email)

(Assume your User model is a SQLAlchemy model with no find_or_create_by_email method.)

Snippet 2:

def test_calculate_tax():
    result = calculate_tax(100, 0.10)
    assert result is not None

Snippet 3:

def normalize_phone(phone: str) -> str:
    """Returns the phone number in E.164 format (+12025551234)."""
    return phone.replace("-", "").replace(" ", "")

(Note: removing dashes and spaces does NOT produce E.164 format.)

Snippet 4:

def get_recent_orders(user_id: int, days: int = 7) -> list:
    cutoff = datetime.now() - timedelta(days=days)
    return Order.query.filter(Order.user_id == user_id).filter(Order.created_at > cutoff).all()

(Looks fine at first glance. What’s missing?)

PR description drill

Section titled “PR description drill”

You used an AI agent to add CSV export to your admin dashboard. The agent typed ~80% of the code (the export logic, the CSV formatter); you typed the rest (the route registration and the integration test). Write the PR description.

Release-notes drill

Section titled “Release-notes drill”

Your team shipped 12 PRs this release. Five involved AI assistance. Write:

  1. The user-facing release notes paragraph (3-5 lines)
  2. The internal changelog paragraph (5-10 lines, more transparent)

Scenario reflections

Section titled “Scenario reflections”

Scenario A: A new hire asks: “Why do we add Co-Authored-By trailers for AI? The AI isn’t a person.” Walk through your answer.

Show answer

Three reasons:

  1. Honesty. Engineering history should reflect what actually happened. Hiding AI involvement creates a misleading record. Future engineers reading the commit log should know which code was AI-assisted; that context matters for debugging and process learning.
  2. Process calibration. We can only improve our AI workflows if we can measure them. Trailers make AI involvement searchable. We can ask “what fraction of bugs originated in AI-authored commits?” Without trailers, that question has no answer.
  3. Cultural norm. Trailers signal that AI contributions are an honest, attributable part of the work. They normalize transparency. Teams that don’t use trailers often end up in awkward conversations later about who wrote what.

Scenario B: You’re reviewing an AI-authored PR. The diff looks reasonable. Tests pass. You don’t have time for a deep review and the PR author is asking for sign-off so they can ship before end-of-day. What do you do?

Show answer

Don’t rubber-stamp. The accountability principle: if you sign off, you’re responsible. If you’re not confident, either:

  • Ask for more time to review properly
  • Ask the PR author to walk you through the diff and answer your specific questions (if it’s small, this might be quick)
  • Decline to be the reviewer and ask someone else to do it

The discomfort of pushing back is much smaller than the discomfort of being on the hook for a bug you didn’t actually check.

Scenario C: Your team has been using AI tools for 6 months. Time for a process retrospective. What metrics or signals would you look at?

Show answer

Metrics to look at:

  • Adoption. What fraction of commits use trailers when they should? Does the convention have buy-in?
  • Productivity. PRs per week before vs after AI tools. Lines of code per PR. Time from PR open to merge.
  • Quality. Defect rate in AI-assisted vs human-authored commits (using trailers to slice). Time to incident detection. Any incidents traceable to AI-specific failure modes (hallucinated APIs, etc.)?
  • Review burden. Average review time per PR. Reviewer satisfaction. Are reviewers spotting the AI-specific failure modes?
  • Team morale. Do engineers feel AI tools have improved their work? Made it worse? Are there areas of friction?

Adjust process based on findings. The review checklist should evolve. The trailer convention should be enforced if drift appears.

Scenario D: A senior engineer pushes back: “All this attribution stuff is busywork. The code is fine; what matters is that it works.” How do you respond?

Show answer

Acknowledge the concern (busywork IS bad) but push back on the conclusion. The trailer convention is roughly 20 seconds of work per AI-assisted commit. The value:

  • Auditability when an incident happens
  • Honesty in the engineering record
  • Searchable metrics for process improvement
  • Cultural norm that says “we’re transparent about how work gets done”

The cost-benefit favors keeping it. If the senior engineer’s pushback is really about something else (e.g. they feel review takes too long), address that separately. Don’t drop the trailer convention because someone wants less paperwork.

Flashcards

Section titled “Flashcards”
Q. Git author field
A.

Who created the change. Stays with the commit forever (across cherry-pick, rebase). Recorded as Name <email>.

Q. Git committer field
A.

Who applied the commit to the repo. Often same as author. Recorded as Name <email>.

Q. Standard AI attribution mechanism
A.

Co-Authored-By: <Agent Name> <noreply-email> trailer at bottom of commit message

Q. Trailer format
A.

Key: Value at the bottom of the commit message body. Examples: Co-Authored-By, Signed-off-by, Reviewed-by.

Q. Generated with marker
A.

Optional richer convention: Generated with [Claude Code](https://claude.com/claude-code) line before the Co-Authored-By trailer

Q. Include trailer when...
A.

AI agent typed the diff and human reviewed; commit was primarily-AI workflow; AI substantially contributed to commit message

Q. Don't include trailer when...
A.

Human typed everything; AI was only consulted for research; AI provided typeahead but human structured the work

Q. Hallucinated API
A.

AI calls a function that doesn’t exist but sounds plausible. Catch by: verifying APIs against docs, integration tests against real services.

Q. Plausible-but-wrong logic
A.

Code looks like it solves the problem but actually solves an adjacent or wrong problem. Catch by: walking through concrete inputs.

Q. Trivial test assertion
A.

Test passes but asserts something meaningless (assert result is not None instead of result == expected). Catch by: reading assertions critically.

Q. Confident-but-wrong docstring
A.

Sounds professional, describes wrong behavior. Catch by: reading docstrings against code, not just for plausibility.

Q. Style mimicry over correctness
A.

Agent applies team style consistently but style is not the same as correctness. Catch by: not trusting ‘looks right.’

Q. Missing edge cases
A.

Agent produces the happy path; edge cases (empty inputs, null arguments, error returns) get glossed over. Catch by: enumerating edge cases explicitly during review and verifying each is handled.

Q. Accountability principle
A.

The human who merges the work is responsible, regardless of who typed it.

Q. Release notes treatment
A.

User-facing: light acknowledgment at release level. Internal: more transparency for process calibration.

Q. Audit search
A.

git log --grep='Co-Authored-By.*Claude' finds AI-co-authored commits