Lesson: AI-authored commits and PRs

The lesson where “who wrote this commit” gets a more honest answer

Here’s a moment that’s becoming routine in 2026 engineering. An engineer (call her Amal) is reviewing a PR. The code is clean. The tests pass. The commit messages are clear. She’s about to click approve. Then she notices the commit message ends with:

Co-Authored-By: Claude Opus 4.7 <[email protected]>

She pauses. Not because there’s anything wrong, but because that line tells her something specific: this PR was AI-assisted. The diff was typed by an agent, with the PR author providing direction and review. Amal’s review needs to be a little different.

Different how? She still checks correctness. She still runs the code. She still thinks about edge cases. But she also looks specifically for:

API calls that LOOK right but reference things that don’t exist (hallucinated APIs)
Patterns that match the style but solve the wrong problem (plausible-but-wrong logic)
Test assertions that pass by checking trivial conditions instead of meaningful ones
Documentation strings that sound confident but describe wrong behavior

These are the failure modes specific to AI-authored code. They’re not unknown in human code (juniors make some of them too), but they’re more common and have a particular flavor when an AI is typing.

L15 is about this shift. The git workflow itself doesn’t change much. Commits are still commits, PRs are still PRs. What changes is the conventions for attribution, the focus of review, and the way teams talk about AI contributions in changelogs and release notes.

This is the lesson where the engineering profession’s relationship with AI authorship gets explicit. Honestly attributing it. Reviewing it specifically. Acknowledging it in release artifacts. Treating it neither as something to hide nor as something to celebrate disproportionately.

The author and committer concepts in git

Quick foundation. In git, every commit has two fields:

Author is who created the change. Typically the person whose code is being committed. Stays with the commit forever (even when the commit gets cherry-picked or rebased onto another branch).

Committer is who applied the commit to the repository. Usually the same as the author, but can be different (e.g. when a maintainer applies a patch on behalf of a contributor).

Both are recorded as name-and-email strings (a display name followed by an email address in angle brackets). Neither is verified by git itself. You can put anything in either field.

Most workflows ignore the distinction. Author and committer are both you, both your work email. You don’t think about it. But the FIELDS are there in every commit, and they form the basis for everything else this lesson discusses.

When an AI tool produces code, the “author” question gets interesting. Should the author field be the AI? The human directing the AI? Both? In practice, the dominant convention as of 2026 is:

Author field = the human who is responsible for the commit (who reviewed, who pushes).
Committer field = the human who runs the commit command.
AI’s contribution is acknowledged in the commit message body via a Co-Authored-By trailer.

This convention puts the human firmly in the accountability seat (the person whose name appears in git log) while still creating a trail of which commits had AI involvement.

The Co-Authored-By trailer, git’s native attribution mechanism

Git has a long-standing convention for acknowledging multiple contributors to a single commit: the Co-Authored-By trailer in the commit message.

A trailer is a line at the bottom of a commit message of the form key-then-colon-then-value. Trailers are parsed by various tools (GitHub renders them specially, some CI tools read them). The most common ones, each written as the key followed by a name and email:

Signed-off-by is the developer asserting they have the right to contribute (used in Linux kernel and many other projects)
Co-Authored-By credits an additional contributor to this commit
Reviewed-by credits a reviewer
Reported-by credits whoever reported the issue this commit addresses

Co-Authored-By is the standard for AI attribution. The line goes at the very bottom of the commit message, in this format:

Co-Authored-By: Claude Opus 4.7 <[email protected]>

The name should be specific (the model name, not just “Claude” or “AI”). The email should be a non-replying address that signals “this is an AI, not a person.”

GitHub renders these as additional contributor avatars on the commit page, and they’re searchable. Other platforms handle them similarly.

A complete commit message with this pattern:

Add weekly digest email feature

Implements the digest job that runs every Monday at 9am UTC,
collects user activity from the last 7 days, formats it into
HTML, and sends via the email service.

Tested against the staging email service. Verified the
digest renders correctly on mobile and desktop.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

The human is the author. The AI is acknowledged. The accountability is clear.

The “Generated with Claude Code” marker, a richer convention

For commits where the AI did most of the typing, a richer convention is emerging: a multi-line trailer block that includes both the co-authorship and a higher-level “this PR was produced with AI assistance” marker.

The pattern used by Claude Code and a number of other tools as of 2026:

Add weekly digest email feature

Implements the digest job that runs every Monday at 9am UTC...

Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.7 <[email protected]>

The “Generated with” line is purely informational. It tells human readers (and downstream tools) that this commit went through the Claude Code tool specifically. The Co-Authored-By line is the formal git attribution.

Variations across tools:

“Generated with GitHub Copilot” is used when Copilot did substantial work
“Authored by [Tool name]” is an alternative wording, same intent
“AI-assisted” is a generic flag without a specific tool name

The convention isn’t fully standardized as of mid-2026. Teams pick a convention that fits their tooling and apply it consistently within their repository.

When to include the trailer (and when not to)

A common new-to-AI question: which commits get the trailer?

Always include when:

An AI agent typed the diff and a human reviewed it
The commit was produced through a primarily-AI workflow (the human’s role was direction and review)
The commit message itself was largely AI-generated

Optional / judgment call when:

The AI suggested a single function and the human typed the rest
The AI was used for typeahead/autocomplete (line-level help) but the human structured the work
The AI was used only to format/lint a human-written diff

Don’t include when:

The human typed everything themselves and only consulted the AI for unrelated questions (“how does pthread work?”). That’s research, not co-authorship
Pair-programming-with-AI where the AI was a sounding board but didn’t produce the code

The principle: be HONEST about the level of AI involvement. Including the trailer for commits where the AI substantially contributed is honest. Including it for every commit (when the AI barely helped) dilutes the signal. Omitting it when the AI substantially contributed is dishonest.

Most teams develop rough internal heuristics: “include if AI typed more than 50% of the lines,” or “include if the agent produced the structure, exclude if the human did.” Pick a convention and apply it consistently.

What human review specifically looks for in AI-authored code

This is the heart of L15. Reviewing AI-authored code is the same job as reviewing human-authored code, with some specific patterns to weight more heavily.

Hallucinated APIs. The agent calls a function that doesn’t exist. The call looks plausible. It has the right shape for the library, the parameter names sound reasonable, it would be a sensible function to provide. But the library doesn’t actually have it. Tests catch this if they exercise the path; reviewers should also pattern-match for “is this an API I recognize?”

This pattern is especially common in less-well-documented libraries and in fast-moving APIs where the agent’s training data is months out of date.

Plausible-but-wrong logic. The diff looks like what code FOR THIS PROBLEM should look like. Variables named appropriately. Standard structure. Standard idioms. But the logic doesn’t quite solve the actual problem. Maybe it solves an adjacent problem the agent misunderstood. Maybe it solves the right problem incorrectly (subtle bug). The output passes superficial inspection.

Review move: don’t just check “does this code look reasonable?” Check “does this code actually do the thing the spec asked for?” Walk through a few concrete inputs.

Test assertions that pass by checking trivial conditions. The agent wrote tests. The tests pass. But on inspection, the tests assert something like “result is not none” instead of “result equals the expected value.” Or “the item count is greater than zero” instead of “the item list equals a specific expected list.” The tests are technically green but aren’t actually checking the intended behavior.

Review move: read the test assertions critically. Are they checking the meaningful properties? Or are they checking conditions that would pass even if the function returned garbage?

Confident documentation strings that describe wrong behavior. The agent wrote a docstring. The docstring sounds professional and confident. But on careful reading, it describes what the function “would” do if everything was correct, not what it actually does. Or it describes a slightly different function than the one above it.

Review move: read docstrings against the code, not just for plausibility.

Style mimicry over correctness. The agent has picked up the team’s style (snake_case, three-space indent, specific naming patterns) and applies it consistently. But style mimicry doesn’t imply correctness. A solution that LOOKS like it belongs in this codebase can still be wrong.

Review move: don’t trust the diff because it “looks right.” Trust it because you’ve verified what it does.

Missing edge cases the human would have spotted. The agent often produces the “happy path” version. Edge cases (empty inputs, null arguments, error returns) sometimes get glossed over. The human sees fewer edge-case branches than they would have written.

Review move: enumerate the edge cases yourself. Are they all handled? Are they tested?

The accountability principle

Here’s the unchanging rule across all AI-assisted workflows:

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

If an agent typed a bug and a human merged it, the bug is on the human. Not on the agent. Not on the tool. On the merger.

This isn’t a moral judgment about AI tools. It’s a workflow principle. AI tools don’t have legal standing, can’t be held accountable in incident reviews, can’t get fired, can’t be promoted. The accountability has to land somewhere, and it lands on the human in the loop.

What this means practically:

Take review seriously. The human is the last filter.
Don’t merge AI-authored code you don’t understand, on the assumption that “the agent is probably right.” If you don’t understand it, you can’t be accountable for it.
The convention “AI typed this, so it’s the AI’s fault if it’s wrong” doesn’t exist. The merger is on the hook.
Time savings from AI authorship come from the AI handling the typing, NOT from the human skipping the review.

This is the social contract of AI-assisted engineering as of 2026. Teams that internalize it stay healthy. Teams that drift toward “rubber-stamp the AI’s work” ship bugs they later have to explain.

PR descriptions in an AI-assisted workflow

PRs have descriptions, not just commit messages. The description is where the team conversation happens. What the PR is for, how to test it, who reviewed it.

Conventions for AI involvement in PR descriptions:

State the AI involvement clearly at the top. Something like:

“This PR was produced with Claude Code. Sections marked AI-authored were typed by the agent and reviewed by [your name]. The human-authored sections [list them] were typed by hand.”

This is the most honest form. Many teams converge on a lighter version:

“AI-assisted with Claude Code.”

(Sometimes added as a label on the PR rather than in the description.)

Test plans should be human-written. Even when the rest of the description is AI-generated, the “how to test this” section should be human-written. The reviewer trusts the test plan to know what behavior to verify. An AI-generated test plan might describe what the AI THINKS the PR does, which may not match what it actually does.

Don’t paste the AI’s chain-of-thought as the description. Some workflows let the agent produce a long explanation of its reasoning. That can be useful as a personal note but doesn’t belong in a PR description. The description should explain the change to a reviewer, not narrate the agent’s thinking.

Be honest about uncertainty. If you (the human) aren’t sure why a particular line is what it is, say so in the description. “I’m not 100% sure why the agent chose [X] instead of [Y]; reviewer please sanity-check.” This is much better than pretending you wrote it confidently.

Release notes and changelogs

How do AI contributions appear in release notes?

The dominant 2026 convention: don’t call them out specifically. Release notes focus on what the release does for users, not who typed which line. The “this feature was AI-assisted” detail is interesting at the engineering level but not at the user-facing release-notes level.

Light variants:

A “Contributors” section that lists humans (and possibly tools used during the release period in aggregate, e.g. “This release was produced with assistance from Claude Code”)
A separate “engineering notes” or “behind the scenes” section that’s transparent about AI involvement but lives below the user-facing changes

Heavier variants (less common in 2026 but exist):

Per-feature attribution (“Feature X was AI-assisted”)
Open-source projects making clear which contributions were AI-assisted

The principle: be honest at whatever level of detail your audience cares about. End users mostly don’t care; engineering management often does; the AI-engineering community at large is interested for cultural reasons.

For internal changelogs (the kind your team reads, not the kind that ships to customers): more transparency is usually right. Trace AI involvement so you can measure it, calibrate your tools, and refine your processes.

Audit and traceability

A practical concern: how do you find AI-authored commits later when you need to (e.g. during an incident review, a security audit, or process calibration)?

Because Co-Authored-By trailers are searchable, you can:

git log --grep="Co-Authored-By.*Claude" --oneline

This finds all commits with Claude as co-author. Substitute the agent name you use.

For longer-range queries:

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

Lists all Claude-co-authored commits in 2026 by hash, human author, and summary.

GitHub and GitLab provide UI search by trailer too (varies by platform version).

The traceability matters for:

Incident reviews. “This bug was introduced in commit X. Was it AI-authored? Were similar AI-authored patterns introduced around the same time?”
Process calibration. “What fraction of our commits are AI-authored? How does that compare to last quarter?”
Tooling decisions. “We had 3 incidents in the last month traceable to AI-authored code with this specific pattern. Time to update our review checklist.”

Teams that don’t tag their AI involvement lose this capability. The trailer is cheap to add and valuable to have.

Legal and licensing notes (light touch)

A common question: are there licensing concerns with using AI-generated code?

As of 2026, the legal landscape is still settling. The dominant positions:

The output of AI tools is generally treated as the work of the human user (the AI tool isn’t a separately-licensed contributor in the legal sense).
License-aware AI tools (like Claude Code in many setups) avoid producing code that’s verbatim from copyleft sources or in a problematic license overlap.
Companies using AI tools typically have their own internal policies covering what’s allowed and what’s discouraged.

This lesson doesn’t go deeper because legal positions vary by jurisdiction, company, and tool. If your company has an AI-tool policy, follow it. If you’re working on open-source or contributing to projects you don’t own, check the project’s CONTRIBUTING guide for AI-tool stances.

For most working developers in 2026, the practical guidance is: use AI tools in line with your company’s policy, attribute honestly via the conventions above, and don’t try to hide AI involvement.

Worked example 1, a typical AI-assisted commit

You’re using an AI agent to add a “remember me” checkbox to your login form. The agent typed the diff in a few minutes. You reviewed the diff carefully, ran the tests, then committed.

git add forms/login.html services/auth.py tests/test_auth.py
git commit -m "$(cat <<'EOF'
Add 'remember me' checkbox to login form

Persists session for 30 days when checked. Default is the
existing 24-hour session. Tested with valid/invalid credentials,
expired tokens, and concurrent sessions.

Co-Authored-By: Claude Opus 4.7 <[email protected]>
EOF
)"

The HEREDOC form shown above is one way to write multi-line commit messages from the command line. Most editors handle this naturally too (when you run git commit with no message flag, your editor opens for the message).

Commit history now shows:

abc1234 Add 'remember me' checkbox to login form (you, Claude Opus 4.7)

GitHub renders both contributors on the commit page.

Worked example 2, reviewing an AI-authored PR

You receive a PR from a teammate. The description says:

“AI-assisted with Claude Code. Adds rate limiting to the public API endpoints.”

You open the diff. Three files changed:

the rate-limit middleware file (new file, ~120 lines)
the API router file (5 lines added)
the rate-limit test file (new file, ~80 lines)

Your review:

The rate-limit middleware: Looks reasonable at a glance. Uses Redis. Has a leaky-bucket implementation. Configuration via env vars.

Looking deeper:

It calls a set-with-ttl method on the Redis client, passing a key, a value, and a time-to-live. Wait, does Redis-py have that method? You check the Redis-py docs. The actual method is the plain set method, with the expiry passed as a keyword argument. The set-with-ttl form doesn’t exist.

This is a HALLUCINATED API. The agent confidently called a function that sounds plausible but doesn’t exist. Tests caught it? Let’s see.

The rate-limit test file: Tests look comprehensive. But on inspection:

The tests use a mock Redis. The mock doesn’t validate that the actual Redis API is being called correctly. It just records calls.
The test asserts that the mock’s set-with-ttl method was called. The mock dutifully has a set-with-ttl attribute (because Python’s MagicMock creates any attribute on access). The assertion is meaningless.

The tests pass because they’re testing the mock, not real Redis behavior. Run against real Redis, you get an attribute error.

You leave a comment: “The Redis API call set-with-ttl doesn’t exist. Should be the plain set method with the expiry passed as a keyword argument. Also recommend at least one integration test against real Redis to catch this class of issue.”

The PR author updates. Review continues. This is the value of the lens “look specifically for hallucinated APIs in AI-authored code.” A reviewer who didn’t apply this lens would have missed it.

Worked example 3, release notes for a sprint that included AI contributions

You’re writing release notes for v2.5.0. The release contains 35 PRs over 4 weeks. About 60% involved AI assistance to varying degrees.

User-facing release notes:

## v2.5.0, Released 2026-06-15

### New features
- Rate limiting on public API endpoints (configurable per-route)
- Weekly digest email for users (opt-in)
- Improved error messages on the checkout page

### Bug fixes
- Fixed timeout on slow networks during payment processing
- Resolved an issue where user avatars sometimes failed to load

### Performance
- 30% faster initial page load on the dashboard
- Reduced database query count on the search page

### Contributors
Engineering team: [list of humans]. This release was produced
with assistance from Claude Code. Thanks to all contributors.

The user-facing notes don’t itemize per-feature AI involvement. The acknowledgment is at the release level. Honest, light-touch.

Internal changelog (for the engineering team):

## v2.5.0, engineering notes (internal)

### AI involvement summary
35 PRs total; 21 (60%) included AI-assisted commits per Co-Authored-By trailers.

### Patterns observed
- Rate-limiting PR initially had a hallucinated Redis API; caught in review.
- Digest email PR was largely AI-typed; human added 2 edge-case handlers in review.
- Several CSS-only PRs were typed by AI in seconds; review was correspondingly fast.

### Process notes
Continue with the current review-checklist focus on hallucinated APIs
(caught 2 instances this release). Consider adding integration tests
against real services for areas relying on external APIs.

The internal version is more transparent. It supports process calibration without burdening end users with detail they don’t care about.

Worked example 4, building a personal review checklist

You decide to make your AI-code-review focus explicit. You write a checklist that you mentally run through (or paste into PR comment templates) when reviewing AI-assisted PRs:

## AI-assisted PR review checklist

- [ ] API calls verified to exist (especially in newer or less-documented libraries)
- [ ] Logic walked through with concrete sample inputs (not just "looks right")
- [ ] Test assertions check meaningful properties (not just truthiness)
- [ ] Docstrings match the actual code behavior
- [ ] Edge cases enumerated and handled
- [ ] Style consistency NOT used as a proxy for correctness
- [ ] Any unfamiliar idioms verified against documentation

Variations of this list circulate in many engineering teams. The shared theme: don’t trust the diff because it LOOKS like good code; trust it because you’ve verified it.

Over time, the checklist evolves. Items get added when you (or teammates) catch a new failure pattern. Items get removed when they stop being an issue. The checklist is a living document.

A note for experienced developers

If you’ve been programming since before AI tools were routine, the L15 patterns probably feel familiar in shape:

Co-Authored-By trailers have been around for years for human collaboration (pair programming, suggesting code in a PR comment that gets incorporated, etc.). Using them for AI is a natural extension.
Reviewing for hallucinations is a specific case of “review what the code DOES, not what it LOOKS like.” Junior developers also produce plausible-but-wrong code; the AI case is a higher-volume version of the same pattern.
The accountability principle is the standard “the merger owns the bugs” rule applied to AI authorship. Nothing morally new; just a new flavor of the same rule.

What’s genuinely new:

Volume. AI tools enable much higher PR throughput, so the patterns that mattered occasionally with junior contributors now matter daily.
Consistency mimicry. AI tools pick up your team’s style faster than humans do, which makes style-as-correctness-proxy a more misleading signal than it used to be.
Confident-but-wrong tone. Hallucinations come with confidence. Junior developers usually express uncertainty when they’re guessing; AI agents often don’t. The signal “this engineer is unsure” is harder to read.

The adjustments are real but not radical. Engineering review skills mostly transfer. Sharpen the specific lenses above; don’t overhaul your whole review philosophy.

A useful frame for managers and technical product managers

For managers introducing AI tools to engineering teams:

Pick a co-authorship convention and document it. The shared convention is part of the team’s culture; pick one and enforce it via review (PRs without the trailer when AI was used get a comment, PRs with the trailer get accepted normally).
Train reviewers on the AI-specific failure modes. A 15-minute internal talk plus a written checklist goes a long way. Reviewers who haven’t been told to look for hallucinated APIs miss them; reviewers who have been told catch them quickly.
Measure AI involvement. Track what percentage of commits have Co-Authored-By trailers. Track which kinds of work benefit most from AI assistance (some teams find CSS and tests get high AI value; complex business logic gets lower value). Tune accordingly.
Don’t shortcut review. The biggest failure mode is “we have AI tools, so review can be faster/lighter.” It cannot. Review takes about the same time per LOC reviewed; the savings come from how much CODE the team produces, not from skipping review.
Be transparent in user-facing communication. Acknowledge AI assistance at the release level. Don’t overstate it (“our AI built this!”) or hide it (“all human work!”). Honesty serves the team’s long-term credibility.

For TPMs specifically: when scoping features that will be AI-assisted, the timeline estimate should include normal review time (not just the agent’s typing time). A PR that took 20 minutes to type still needs 30-60 minutes of careful review. Plan accordingly.

A foreshadowing note for L16

L16 closes the track with a speculative-but-grounded look at where git might evolve in an AI-collaborative world. What new primitives might emerge. Where the conventions might shift. How to stay calm as the tooling changes.

L13 (worktrees), L14 (integration patterns), L15 (commits and PRs) covered the workflow as it exists today. L16 looks forward without making promises.

Concrete scenarios across team scales

Solo developer using AI for personal projects:

Conventions are loose. The developer often doesn’t add Co-Authored-By trailers (no one else will look at the commits) but does pause to review the agent’s output before committing. Personal accountability is informal but real. Bugs they ship are their bugs.

When the project goes public or onboards collaborators, the conventions get tighter. Trailers appear. Review processes formalize.

Startup, 3-person team, regular AI usage:

Team adopts a shared convention (probably the Co-Authored-By: Claude Opus 4.7 form or similar). Trailers appear on most non-trivial AI-assisted commits. Review checklist circulates informally.

Founder or tech lead often models the convention: their commits set the example. New hires pick it up quickly.

Mid-size company, 50-person engineering team:

Formal AI-tool policy. Co-authorship convention documented in the engineering handbook. Some teams have a “AI involvement label” on PRs. Review training mentions AI-specific failure modes during onboarding.

Internal changelog tracks AI involvement at the release level. User-facing changelog mentions tooling at the release level (acknowledgment but not per-feature attribution).

Open-source project receiving AI-assisted contributions:

Project has a CONTRIBUTING.md section on AI-assisted contributions. Contributors are expected to use the standard trailer convention. Maintainers review AI-authored PRs with the same standards as human-authored, applying the specific lenses (hallucinated APIs, plausible-but-wrong logic).

Some projects opt to label AI-assisted PRs explicitly (with a tag or label) for tracking purposes. Others treat them no differently in review (the trailer is the only marker).

Multi-agent team in production:

All commits get trailers. The convention is enforced by tooling (commit hooks reject commits without proper trailers when AI was involved). Trailers are searchable for incident analysis and process calibration.

Release notes acknowledge AI contributions at the release level but typically not per-feature. Internal engineering notes are more granular.

The team has refined the review checklist over many sprints. New AI failure modes get added; resolved ones get removed. The checklist is part of onboarding.

The stay-calm psychology for AI authorship

Two things to internalize.

One: this is just a new flavor of an old workflow. Co-Authored-By trailers existed for human collaboration before AI. Reviewing for “plausible but wrong” code existed before AI (you’ve reviewed junior developer work, right?). The accountability principle “the merger owns the bugs” existed before AI. None of this is fundamentally new. The volume is new. The confidence-but-wrong tone is new. The patterns themselves are familiar.

Two: the convention bar is “be honest about who typed what.” That’s the whole rule. Honest about AI involvement in commit messages. Honest about AI involvement in PR descriptions. Honest about AI involvement in release notes (at the appropriate level of detail for the audience). Honest with yourself about what you did and didn’t review carefully.

Teams that internalize these two things adapt to AI-assisted workflows in weeks, not months. Teams that drift toward “let the AI handle it” (skipping the trailers, skipping the careful review, claiming credit for AI work) eventually run into incidents that make the disconnect visible. The honesty-based approach is the more comfortable position for the long term.

What you can do now

You can:

Add Co-Authored-By trailers to commits where an AI agent substantially contributed
Use the “Generated with Claude Code” marker (or equivalent for your tool) when the agent did most of the typing
Decide which commits warrant the trailer (substantial AI contribution) and which don’t (research consultation, line-level help)
Review AI-authored diffs with specific lenses (hallucinated APIs, plausible-but-wrong logic, trivial test assertions, confident-but-wrong docstrings, missing edge cases)
Write PR descriptions that honestly state the level of AI involvement
Decide how AI involvement appears in release notes (user-facing vs internal)
Search commit history for AI involvement using trailer-based grep
Apply the accountability principle (the human merger is responsible regardless of who typed it)

What’s next in the track

L16 closes the track. We’ll look at where git might evolve as AI authorship becomes routine. What new primitives might emerge, where conventions might shift, how to stay calm as the tooling changes. L16 is the only lesson in T7 that’s explicitly forward-looking, but it’s grounded in patterns visible today, not pure speculation.

Voice anchor (carried from L1-L14)

Git stores snapshots. Every other command is just navigating those snapshots.

The author of a snapshot is just a field in the snapshot’s metadata. The Co-Authored-By trailer is just additional metadata. Whether the human or the AI typed the actual code, git stores the snapshot the same way and serves it the same way. The conventions around attribution are social, not technical. The git plumbing handles either case identically.