AI code vs human code distinction in VCS

AI code vs. human code distinction in version control means that the repository's history explicitly tags which lines, commits, or files were generated by AI systems versus written by humans. It goes beyond the MVAT's PR-level metadata to create line-level or commit-level attribution that makes AI authorship queryable across the entire codebase. The question "what percentage of the payment processing module was AI-generated?" has a concrete, computable answer.

This distinction matters at L4 (Optimized) because the scale of AI code generation has crossed a threshold where aggregate statistics become operationally relevant. When 30-50% of new code is AI-generated, the questions change: which parts of the codebase have the highest AI-code concentration? Are AI-dense areas of the codebase correlated with higher defect rates? Do changes to AI-generated code by human developers introduce more bugs than changes to human-written code, or vice versa? These questions require line-level attribution, not just PR-level flags.

The technical approach to AI/human distinction in VCS combines several mechanisms. Git trailers on commits flag AI-generated commits, as established in L3. But at L4, this is extended to a git blame-compatible attribution: each line in the codebase has an authorship record that includes whether the committing AI session generated it or the human wrote it. This is implemented as a custom git attribute (.gitattributes) combined with a wrapper around git blame that reads the commit-level AI flags and presents them alongside normal blame information.

There's a philosophical question embedded in the AI/human distinction: what does it mean for code to be "AI-generated"? A line that an AI suggested, a human modified slightly, and then committed - is that AI-generated or human-written? The pragmatic answer at L4 is: code that originated in an AI session is AI-attributed unless a human substantially modified it before commit (where "substantially" means more than whitespace, variable renaming, or formatting changes). Organizations that try to achieve perfect categorization end up in a definitional swamp. A practical threshold, consistently applied, is better than a theoretically pure definition that cannot be implemented.

• Enables codebase-level AI attribution analytics - without line-level attribution, you can only ask "was AI used in this PR?" With line-level attribution, you can ask "what percentage of the authentication module is AI-generated, and what is its defect density compared to the human-written portions?"
• Satisfies EU AI Act documentation requirements for high-risk systems - for organizations building high-risk AI systems (under EU AI Act Annex III), documentation of how AI was used in developing the system is required; VCS-level attribution is the most credible form of this documentation
• Enables license risk assessment - AI-generated code may carry different license obligations depending on the model and the training data. Knowing which code is AI-generated enables targeted legal review of AI-attributed code sections
• Supports differential review policies - organizations can implement a policy where AI-generated code requires stricter review (a second reviewer, mandatory security scan, specific reviewer qualification) by detecting AI attribution at the line or file level
• Feeds the model performance analysis - correlating AI attribution with downstream defect rates, performance issues, and security vulnerabilities gives the most granular signal available about which AI-generated patterns are problematic

1. Establish the attribution standard - write a one-page specification that defines: what constitutes AI-generated code (generated in an AI session with less than N% human modification), what the VCS attribution format is (a commit-level tag that applies to all lines in that commit), and what the attribution exception process is (how to mark a commit as "AI-generated but substantially human-modified"). This specification is the normative reference for the implementation.
2. Implement commit-level AI attribution tags - extend the MVAT git trailers with an AI-Coverage: [none|partial|substantial|full] field. "Full" means the commit content was generated by AI with minimal human modification. "Partial" means a mix of AI-generated and human-written code in the same commit. "Substantial" means AI was used in ideation or context but the code was written by the human. "None" means no AI involvement.
3. Build the AI-attribution git blame wrapper - write a script (ai-blame) that runs standard git blame and overlays AI attribution data from commit trailers. The output shows, for each line, the standard blame information (commit hash, author, date) plus the AI-Coverage value from that commit. This makes AI attribution as accessible as standard blame information.
4. Build the repository attribution dashboard - aggregate AI-Coverage data across all commits in a repository to produce: percentage of current code that is AI-generated (by file, by directory, by module), trend over time (how has AI coverage changed month by month), and concentration map (which areas have the highest AI-code density). Update this dashboard weekly.
5. Integrate with code review tools - configure your code review tool to display AI attribution alongside diff lines. When a reviewer sees a diff, they should be able to see whether each hunk of the change is AI-generated or human-written. This context informs the depth of review appropriate for each section.
6. Define differential review policies - decide whether AI-attributed code in high-risk repositories requires additional review steps. Candidate policies: "full AI-generated commits in SOC2-scope repositories require two human reviewers," "AI-generated code in security-sensitive modules requires a security team member as a reviewer." Implement these as compliance gate rules that evaluate the AI-Coverage field.

Trying to track attribution at the line level rather than the commit level. Line-level attribution is theoretically more accurate but practically untenable: it requires tracking which specific lines within a commit were AI-generated, which changes as developers modify AI output, which changes again as the codebase evolves and lines are moved and modified. Commit-level attribution with a coverage classification (full/partial/none) is accurate enough for all practical purposes and infinitely more maintainable.

Creating a two-tier codebase culture. If AI-generated code is visibly flagged in review tools, developers may start treating AI-generated code as "lower quality by default" even when it isn't. The attribution data should be used to calibrate review intensity based on empirical risk data, not to create blanket quality judgments. The message should be: "we apply stricter review to AI-generated code because we're still building empirical confidence in it, not because it's inherently worse."

Ignoring the classification of human modifications. When a human developer modifies AI-generated code, the modified version remains "AI-generated" by the attribution standard. But that may become increasingly misleading over time as the code evolves. Consider implementing an attribution decay policy: after a file has been 50%+ modified by human developers since its AI-generated commit, it gets reclassified as "human-modified AI original" rather than "AI-generated." This keeps attribution data meaningful as the codebase ages.

Not addressing generated test code separately. AI-generated tests and AI-generated production code are different attribution categories with different risk profiles. A function that was AI-generated has one risk profile; a test that was AI-generated to test that function has a different (and potentially correlated) risk profile. The attribution system should distinguish these categories.

Attribution data that nobody uses. An AI attribution system that generates data but has no consumers is expensive governance theater. The attribution data needs at least two active use cases to justify its maintenance: a compliance use case (EU AI Act documentation, SOC2 evidence) and an operational use case (model performance analysis, differential review routing). If neither use case is active, descope the implementation until the use cases exist.