Git AI Assess

Overview

Git AI is an open-source Git extension for tracking AI-generated code in repositories. The project describes itself as linking every AI-written line to the agent, model, and transcripts or prompts that generated it, creating a Git-native form of AI code attribution for development, review, and production analysis (GitHub: git-ai-project/git-ai, Git AI documentation).

The technical idea is to avoid retroactive AI-code detection. Git AI's documentation says detecting AI code with heuristics is an anti-pattern; instead, supported agents explicitly mark inserted hunks as AI-generated through checkpoints, and the CLI condenses those checkpoints into authorship logs attached to commits using Git Notes (Git AI documentation). The result is a workflow that can answer provenance questions such as which lines were AI-authored, which agent or model produced them, what prompt or session context was involved, and how much generated code survived review and merge (Git AI homepage).

The reason to classify Git AI as Assess is that AI provenance is becoming important for code review, compliance, incident analysis, and software supply-chain trust, but the ecosystem is still early. Git AI should be evaluated as a lightweight provenance layer for AI-assisted delivery, not as a compliance solution by itself. Teams should test whether it captures the agent workflows they actually use, survives their merge and release process, and produces metadata that reviewers and governance teams will rely on.

Adoption Signals

• The GitHub repository describes Git AI as an open-source Git extension for tracking AI-generated code, with an Apache 2.0 license and a Rust-heavy codebase (GitHub: git-ai-project/git-ai).
• Visible repository metadata shows meaningful early traction, including 1.6k stars, 139 forks, 47 contributors, 141 releases, and a latest release listed as v1.3.1 on April 16, 2026 in the fetched GitHub metadata (GitHub: git-ai-project/git-ai).
• Git AI's docs position it as local-first and offline-capable, with no login required for basic operation and no per-repository setup required for the CLI attribution workflow (Git AI documentation, GitHub: git-ai-project/git-ai).
• The project supports a Git-native data model using Git Notes: checkpoints are stored temporarily in .git/ai, then condensed into immutable authorship logs addressed by commit SHA and attached to commits as notes (Git AI documentation).
• The command surface is directly aligned with review workflows. git ai status shows current checkpoint and working-index authorship, git ai blame overlays AI authorship on top of regular blame output, and git ai stats reports AI-code metrics (Git AI documentation, GitHub: git-ai-project/git-ai).
• The documentation names integrations or examples involving Cursor, Claude Code, GitHub Copilot, Copilot, and hook-compatible agents, while the repository page lists supported editor environments such as VS Code, Cursor, Windsurf, Antigravity, and Emacs Magit (Git AI documentation, GitHub: git-ai-project/git-ai).
• Git AI is expanding beyond local attribution into team observability. The homepage describes cloud and self-hosted team options for tracking AI code across repositories, PRs, merged code, token cost, AI efficacy, shared prompt context, and comparisons across teams, repositories, agents, and task types (Git AI homepage).

Risks

• Agent cooperation is required. Git AI does not guess whether code was AI-generated; supported agents mark the exact hunks they wrote, so attribution quality depends on the agent, hook integration, and whether the team's tools participate consistently (Git AI documentation).
• Coverage may vary by workflow. The documentation states that any hook-compatible agent can work with Git AI, but teams should verify coverage for their actual tools, editor integrations, background agents, terminal agents, and CI or server-side workflows before relying on the data (Git AI documentation).
• Git history operations still need testing. Git AI documents support for many operations, including rebases, merges, squashes, cherry-picks, amends, stashes, resets, worktrees, and conflict resolution, but it also lists git mv as a known limitation where attribution does not move properly (Git AI documentation).
• Generated code can be misclassified. The documentation says checked-in generated code is attributed to human authors unless it is listed in linguist-generated, which means repositories with generated clients, SDKs, build outputs, or vendored assets need explicit classification rules (Git AI documentation).
• Server-side merge flows may need team or CI support. Git AI's docs explain that web UI merge operations happen server-side where Git AI is not running, so authorship logs are not updated automatically unless reconstructed by Git AI for Teams or open-source CI workflows (Git AI documentation).
• Prompt metadata is sensitive. Git AI keeps transcripts out of Git and links to sessions stored locally, in Git AI Cloud, or in a self-hosted prompt store, but teams still need retention, access control, redaction, and incident-response policies for prompts, requirements, and architecture decisions (Git AI homepage, Git AI documentation).
• Metrics can distort incentives. Measuring percent AI code, AI accepted rate, and agent effectiveness can help governance, but teams should avoid turning these metrics into productivity surveillance or simplistic quality proxies. The actionable use is review focus, provenance, learning, and risk management, not replacing engineering judgment.
• Provenance is not assurance. Knowing that a line was AI-authored does not establish that it is secure, licensed, correct, maintainable, or compliant. Git AI should sit alongside human review, tests, static analysis, dependency scanning, secret scanning, license checks, and production observability.

Recommendation

Assess Git AI for engineering organizations that already use coding agents and need more trustworthy provenance than commit messages, PR labels, or manual declarations can provide. Good candidates include regulated software teams, security-sensitive repositories, platform teams measuring agent adoption, and organizations that need to debug or review AI-assisted changes after they have moved through pull requests, rebases, squashes, and release branches.

Run a pilot on one or two repositories with high AI-agent usage. Test the full lifecycle: local coding with Cursor, Claude Code, Copilot, or other hook-compatible agents; commits with authorship notes; PR review using git ai blame; merges through the team's normal GitHub, GitLab, Bitbucket, or Azure Repos path; and post-merge reporting using stats. Include edge cases such as rebases, squash merges, cherry-picks, generated-code directories, file renames, conflict resolution, formatter rewrites, and copied snippets.

Adopt only if the metadata is complete enough to influence real review behavior. Define policy before scaling: which agents are supported, where transcripts are stored, who can access prompt/session details, how long metadata is retained, how generated-code paths are marked, whether team/cloud/self-hosted features are allowed, and how AI provenance appears in PR review and incident analysis. Move from Assess to Trial once the team has repeatable attribution coverage through its normal merge workflow and reviewers find the provenance useful.

Sources

• GitHub: git-ai-project/git-ai
• Git AI documentation
• Git AI homepage