For most developers, the git log is more than just a record of changes; it’s a narrative. It’s a shorthand for the conversations, the late-night debugging sessions, and the implicit knowledge of the team. But what happens when the protagonist of that narrative isn’t human? The rise of AI agents in the development workflow — think Cursor, Claude Code, Copilot — has fundamentally broken this narrative, transforming the git log into a cryptic cipher.
This isn’t about whether AI can write code; it already does. It’s about accountability. When an AI agent autonomously refactors a module or pushes a new endpoint, how do you know, weeks or months down the line, why that change was made? More importantly, was it a directive from a human, or the agent’s own initiative? The answer, right now, is often lost in the diff.
Here’s the crux of the problem: a standard commit message like feat(auth): add token refresh endpoint tells you what changed, but it’s effectively mute on the intent and the provenance of the action. A human developer infers meaning from context — a Slack conversation, a lingering bug, a team discussion. An AI agent reading that same commit lacks that entire universe of tacit knowledge. It either has to chew through a massive amount of token-heavy context to infer intent, or it invents a plausible, but potentially inaccurate, explanation.
The cost of this ambiguity isn’t just academic. It compounds. Reconstructing the lineage of a feature developed across dozens of AI-generated commits becomes an increasingly expensive and error-prone task. Imagine trying to audit a system built with this level of inscrutability.
The Missing ‘Why’ and ‘Who’
Several attempts have tried to address this growing chasm.
In January 2026, Agentic Commits proposed an extension to Conventional Commits, aiming to add the ‘why’ and ‘next step’ to the subject line: type(scope): what (why) → next. It’s a lightweight approach, requiring no new tooling. But it’s still fundamentally limited. It doesn’t tell you which agent made the commit, nor does it distinguish between an autonomous action and a directed one. Cramming complex justifications into a 72-character subject line often leads to oversimplification, rendering the ‘why’ more of a guess than a definitive answer.
Then came “Lore: Repurposing Git Commit Messages as a Structured Knowledge Protocol for AI Coding Agents.” Published on arXiv in March 2026, Lore accurately diagnoses the ‘Decision Shadow’ — the lost reasoning behind code changes. It proposed using native git trailers for constraints, rejected alternatives, confidence levels, and more. It’s a more detailed approach, designed for deep architectural decisions. However, for projects with frequent, atomic commits, many of Lore’s nine optional trailers would likely remain empty or repetitive. Crucially, it also introduces a dependency on a dedicated CLI, a departure from the standard git toolchain that can hinder adoption.
“The existing tooling does not record this.
git blameshows the author, but most agents commit under the developer’s credentials, making blame indistinguishable between human and agent actions.”
Neither of these solutions, however, grappled with a question that’s becoming less of a detail and more of a mandate: was this change made autonomously by the agent, or under human supervision?
As regulatory bodies like the EU, with its AI Act, begin to formalize AI governance, and as engineering organizations grapple with their own internal audit trails, incident reviews, and compliance workflows, the distinction between autonomous and supervised AI actions in code development isn’t optional. It’s becoming essential information.
Enter QAC
This is where the new QAC (Quality Assurance Commit) specification, published at github.com/hubtheocoelho/qac-spec, steps in. It aims to bring clarity to this crucial divide. QAC introduces two key fields within the commit message itself:
- Agent: Identifies the specific AI agent responsible for the commit.
- Mode: This is the game-changer. It accepts one of two values:
hitl(human-in-the-loop), indicating the user requested or approved the action, orautonomous, signifying the agent made and executed the decision without direct intervention.
This seemingly simple addition of Mode: hitl or Mode: autonomous directly addresses the auditability gap that existing tools fail to bridge. Even if an AI agent uses a developer’s credentials (which is common, making git blame opaque), QAC provides an explicit signal about the nature of the change. It offers a structured way to delineate human oversight from AI independence.
Why This Specification Matters Now
The market for AI-powered developer tools is already substantial and growing at a clip that frankly, is astonishing. Companies are investing heavily, and the integration into daily workflows is accelerating. But this rapid adoption outpaces the development of strong governance and audit mechanisms. QAC, by focusing on a core aspect of traceability within the existing git framework, presents a pragmatic, low-friction solution.
It’s not just about cleaner commit logs for human readability; it’s about building systems that can be reliably audited and managed in an increasingly AI-driven development landscape. For quality assurance engineers, security teams, and compliance officers, this specification offers a much-needed lens into the black box of AI code generation. The ability to filter or query commits based on Mode could dramatically simplify incident response and regulatory checks.
This isn’t merely a spec for a few early adopters; it’s a foundational element for building trust in AI-assisted software development. Without it, we risk creating systems where the very act of coding becomes opaque and unmanageable, a ticking time bomb for any organization prioritizing security and compliance.
How QAC Works
QAC integrates directly into the commit message structure. It’s designed to be human-readable while also being machine-parseable. The Agent and Mode fields are intended to be added as standard git trailers, similar to how Signed-off-by or Co-authored-by are used, but specifically for AI agent actions.
An example commit might look like this:
feat(api): implement user profile endpoint
Adds the necessary routes and controllers for user profile management, including CRUD operations.
Agent: Copilot-Enterprise
Mode: hitl
Or for an autonomous action:
refactor(utils): optimize string formatting
Identified redundant string concatenation and replaced with f-strings for improved performance.
Agent: CodiumAI
Mode: autonomous
The beauty here is its simplicity. It requires no complex tooling changes beyond what’s already standard in most git workflows. Developers or CI/CD pipelines can easily parse these trailers to build reporting tools, enforce policies, or simply gain better visibility into the development process.
The Future of Auditable AI Development
The rapid evolution of AI in software development necessitates corresponding advancements in how we manage and govern that development. Tools and specifications like QAC are not just desirable; they are becoming essential infrastructure.
As AI agents become more sophisticated and autonomous, the ability to trace and understand their contributions to the codebase will be paramount. QAC provides a vital mechanism for this traceability, ensuring that the narrative of our code remains clear, auditable, and trustworthy, even when the authors are algorithms.
**
🧬 Related Insights
- Read more: 3 Silent Revenue Bugs Found in 45 Minutes [SaaS Deep Dive]
- Read more: Bonk.exe: Where a Shiba Inu Delivers Brutal Life Lessons Via Browser Bonks
Frequently Asked Questions**
What does QAC stand for?
QAC stands for Quality Assurance Commit. It’s a specification for structuring git commit messages to denote AI agent involvement and action mode.
Will QAC replace existing commit message conventions like Conventional Commits?
Not necessarily. QAC is designed to be complementary. It can be integrated alongside existing conventions like Conventional Commits, adding an extra layer of information about AI actions without disrupting the established format.
How can I implement QAC in my workflow?
Implementing QAC involves standardizing how you add the Agent and Mode fields to your commit messages, typically as git trailers. This can be integrated into your team’s git commit hooks or CI/CD pipelines for enforcement and consistency.
