Table of Contents

• Introduction
• Why AI Attribution Matters
• Current AI Attribution Landscape
  • The Transparency Stack
  • What’s Missing From Current Systems
  • The Gap
• AI_ATTRIBUTION.md
  • The Core Concept: Six Levels of Creative Control
  • How It Works in Practice
  • What This Solves
  • Room for Improvement
• Conclusion

Introduction

Every developer using AI faces the same question: who actually built this?

If you have been actively programming something while using AI tools like Anthropic’s Claude Code or OpenAI’s Codex you might have wondered is this specific code, idea, or direction human-made or did AI make this?

Typically, our first instinct is to think in terms of git blame history. That is, we think in terms of raw lines of code and characters added. Did the AI tool or an actual person write this line of code?

Programming software is just so much more than the actual typed characters in a file. When we write software we might consider things like:

• What are we building and how should it be structured?
• Who chose this approach over alternatives?
• Understanding field-specific requirements (security, performance, regulatory compliance)
• Evaluating whether the solution is actually good/maintainable
• Designing for change and growth beyond the immediate need

An AI tool might draft the implementation, but you define the problem, choose the approach, and vouch for the result. So how do we capture who/what actually had creative control? What contribution came from the developer and what was generated by AI?

Professional accountability has always required documentation. A surgeon documents each procedure, a lawyer bills by the hour with detailed timesheets, and architects maintain design decision logs. When something goes wrong, these records answer “who did what and why?” Like any principal-agent relationship, software development with AI needs the same accountability infrastructure, but such systems are fragmented and inconsistent.

In this article, I’m going to attempt to outline this core problem of AI attribution, why it matters, and what’s currently being done about it. Then I will give you my proposed practical solution to this problem.

Why AI Attribution Matters

Attribution generally solves four problems you will hit whether you track contributions or not.

Debugging When Things Break - A bug surfaces six months after deployment. Was this AI-generated boilerplate you adapted, or code you wrote from scratch? Each scenario changes your debugging approach. Without attribution records, you’re reverse-engineering your own thought process instead of fixing the bug.

Documenting Invisible Work - Git commits show lines added, not creative vision. They don’t capture the AI suggestions you rejected, the hours hand-tuning constants, or the architectural decisions that made everything possible. Design decisions, problem framing, rejecting bad approaches—this is the work that actually matters, and none of it shows up in your codebase. An attribution log documents it.

Building Credible Portfolios - Vague ambiguity about AI involvement hurts you. People assume the worst. But specific attribution (“AI scaffolded the configuration; I designed the architecture and wrote the core algorithm”) demonstrates what you’re capable of. Research shows people assign less credit to AI-assisted work even when you controlled all decisions. The fix isn’t hiding AI involvement—it’s being precise about creative control.

Accounting for Memory Decay - Six months from now, you won’t remember which parts were AI-assisted. Your brain merges the collaboration into “I built this.” Then someone asks for details during a code review, and you realize you don’t know. This isn’t a personal failing—it’s how human memory works in collaborative contexts. Attribution logs remember what you’ll forget.

Before diving into my solution, let’s examine what already exists and why it falls short.

Current AI Attribution Landscape

AI transparency systems already exist, but they’re solving different problems than the one developers face daily.

The Transparency Stack

Think of AI transparency as layers, each answering a different question:

Layer 1: Binary Disclosure - “Was AI used?” Academic publishers like Nature and SAGE require this, but the rules vary wildly. Some accept undisclosed AI for copy editing, others require statements for any use. The International Committee of Medical Journal Editors states AI can’t be an author but offers no standard format for documenting human responsibility.

Layer 2: Provenance & Integrity - “Can we verify this file’s history?” C2PA and IPTC Digital Source Type answer this with cryptographic signatures. They tell you an image came from Photoshop and was AI-edited, but not who controlled the creative decisions.

Layer 3: Supply Chain (AI-BOM) - “What models and datasets were involved?” Standards like CycloneDX ML-BOM and SPDX 3.x document ML components, similar to software bill of materials. They inventory dependencies, not collaboration.

Layer 4: Attribution Statements - “How should we describe AI involvement?” IBM’s AI Attribution Toolkit generates human-readable statements about proportion, type, and review level—but only for finished artifacts, not ongoing workflows.

Layer 5: Collaboration Semantics - “Who exercised creative control during the work?” This is where AI_ATTRIBUTION.md operates.

What’s Missing From Current Systems

Here’s what existing approaches don’t capture:

Open source communities are improvising their own solutions. The Linux kernel requires Assisted-by: commit tags with tool and model version. Gentoo banned AI contributions entirely. Fedora requires disclosure but no standard format. Everyone knows they need something—nobody agrees on what.

The Gap

Research on AI attribution in HCI contexts shows people struggle to consistently judge credit for AI-assisted work. They also can’t reliably remember which ideas came from AI after time passes.

The EU AI Act requires transparency labels, and China mandates labeling for AI-generated content, but neither specifies how to document internal creative control.

None of these systems track creative control at the task level, chronologically, as work happens. That’s the operational question developers actually need answered for debugging, code review, and taking responsibility for their work.

That’s what AI_ATTRIBUTION.md provides.

AI_ATTRIBUTION.md

AI_ATTRIBUTION.md is a single markdown file that lives in your project repository. It is a structured log that tracks who had creative control over specific work, you or the AI tool. It can be edited and maintained by AI (preferably) or manually by you.

The Core Concept: Six Levels of Creative Control

Instead of simply asking if AI was used or not, or just measuring “what percentage was AI,” the framework uses six involvement levels that capture who made the decisions:

The key insight: these aren’t about line counts. They’re about who controlled the creative decisions. For example, you can reject a dozen AI suggestions and write 10 lines yourself, that’s GUIDED or INFORMED, not GENERATED.

How It Works in Practice

Each entry in your log captures:

• What was built - Scope tags like code, design, docs, tests.
• Involvement level - One of the six levels listed above.
• Which tool - The AI model name and version.
• Optional context - What you decided, what you rejected, why you chose this approach.

Here are a few real examples from one of my game development projects (Click to expand.)

### [2026-02-22] — Burst-then-coast bullet dynamic [🟡 `GUIDED` — design, code]

**Human:** Asked about interesting bullet movement dynamics for 2D games.
Chose burst-then-coast from four options AI presented. Implemented
`BurstSpeed` and `CruiseSpeed` components and the lerp-based deceleration
independently after AI explained the concept.

**AI (Claude):** Presented four bullet dynamic options (acceleration,
burst-then-coast, sine wave, deceleration) with descriptions. Explained
lerp-based deceleration in detail: how `f32::lerp()` works, why multiplying
by `delta_secs()` makes it frame-rate independent, what `.clamp(0.0, 1.0)`
guards against, and the relationship between the three config values
(`BULLET_BURST_SPEED`, `BULLET_CRUISE_SPEED`, `BULLET_SPEED_DECAY`).
Wrote implementation plan.

**Commits:** `["e0ee2cf"]`

**Notes:** Human chose the dynamic and did the implementation. AI's primary
contribution was explaining the lerp math and the burst/cruise/decay
parameter relationships.

### [2026-02-22] — Codebase review for easy wins [🔵 `INFORMED` — code]

**Human:** Asked for optimization and clarity improvements across the
project.

**AI (Claude):** Reviewed all source files and identified 10 issues: a bug
(`return` vs `continue` in bullet loop), unnecessary `Resource` derive on
`WallHit`, duplicated `MovingDirection`/`Size` types across modules,
duplicated wall collision logic, stale test system (`test_flicker_on_keypress`),
copy-paste comment errors, missing inspector registrations. Prioritized
the bug fix and deduplication as highest value.

**Commits:** `["50e2d34"]`

**Notes:** Human asked the question, AI identified issues. Implementation
of fixes is ongoing.

### [2026-02-17] — Centralized config module [🟠 `ASSISTED` — config, code]

**Human:** Decided to centralize all global constants into `src/config.rs`.
Chose the file location. Explicitly rejected local re-export convenience
aliases -- wanted `config::` prefix used directly at every call site.

**AI (Claude):** Created `src/config.rs` with all constants (window, camera,
level, player, logging). Updated `level.rs`, `camera.rs`, `main.rs`, and
`player.rs` to reference `config::` prefixed constants. Configured
`bevy::log::LogPlugin` with `config::LOG_LEVEL`.

**Commits:** uncommitted

**Notes:** Human made the architectural decision and style preference
(no re-exports). AI executed the extraction and migration across files.

What This Solves

Remember those four problems from earlier? This file addresses each:

• Debugging - When the pathfinding algorithm bugs out, I know immediately that the core algorithm came from AI but I modified obstacle avoidance. I know where to look.

• Invisible work - The log captures that I designed the movement architecture and rejected approaches. That’s nowhere in the git commits.

• Credibility - I can point to specific entries showing “I designed the state machine; AI implemented physics based on my specs.”

• Memory - Six months later, I don’t need to reconstruct who decided what. It’s written down.

Room for Improvement

This framework is a starting point, not a finished product. Here are three key challenges that need solutions:

• Model-Dependent Attribution Evaluation - Different AI models evaluate the same work differently due to their non-deterministic nature—one might call work ASSISTED, another GUIDED. Specialized tooling could provide a dedicated attribution model, but the goal is to remain tool-agnostic.

• Workflow Integration - The biggest barrier is remembering to log. Automatic hooks like git commit or pre-commit checks could remind the model to log at natural breakpoints, but this conflicts with the framework’s lightweight design.

• Multi-AI Workflow Synchronization - Using multiple AI tools simultaneously (chat interface, IDE agent, CLI agent) creates fragmented attribution records with no automatic way to synchronize entries. A centralized service could coordinate tools, but that introduces infrastructure complexity the framework avoids.

Conclusion

The AI attribution problem isn’t going away. As AI tools become more capable, the question of “who did what” becomes harder to answer and more important to document.

Binary disclosure doesn’t cut it. Percentage metrics miss the point. Memory fails us all.

AI_ATTRIBUTION.md offers a third way: structured logging that captures creative control as work happens. It’s lightweight, meaningful, and standardized enough to support tooling.

Imagine code review tools that automatically highlight AI-assisted sections, portfolio sites that generate contribution breakdowns, and hiring managers who can see not just what you built, but how you exercised creative control. That future requires a standard.

Try it on your next project. Even a week of logging will teach you about how you collaborate with AI.

We’re building the tools that define human-AI collaboration. Let’s capture it honestly.