Most engineering teams have two data sets that live in separate systems and never meet: AI spend data in a billing dashboard, and code activity in a git repository. A third data set lives in Jira, Linear, or GitHub Issues: tasks completed.

AI ROI measurement requires all three. Spend without output is just a cost report. Output without task context is just a code report. Connecting commits to tasks is what turns both into a productivity story.

Why the connection matters

Consider two commits that look identical in a git history: both add roughly 200 lines, both touch similar files, both are authored on the same day. In isolation you cannot tell them apart.

One closes a critical bug fix that had been blocking the release for two days. The other implements a low-priority cleanup that was on the backlog for six months. The AI cost attached to each commit is identical. The value delivered is not.

Commit-to-task mapping is what makes the distinction possible. Without it, every line of committed code is treated as equivalent — and no ROI calculation is meaningful.

How the mapping works in practice

Modern engineering teams already have most of the infrastructure for this. The convention is almost universal: branch names and commit messages reference issue IDs. fix/PROJ-142-webhook-handler or a commit message ending in closes #891 creates a linkable trail from code to task.

The steps are:

1. Extract issue references from commit metadata. Parse branch names, commit messages, and PR descriptions for issue IDs matching your tracker's format (Jira's PROJ-123, Linear's ENG-456, GitHub's #789). Most teams have 80–90% of commits linkable this way without any additional discipline.

2. Pull task data from the issue tracker. For each referenced issue, retrieve the task status, type, estimated vs. actual time, and completion date. This is available via API for Jira, Linear, and GitHub Issues.

3. Associate AI sessions with the commits. This requires knowing which AI sessions produced which code. The linkage runs through the developer, the timestamp, and the repository. A session from developer X at 2 PM that touches the same files as a commit from developer X at 3:30 PM is a reasonable attribution.

4. Calculate cost per task. Total AI session cost attributable to commits that closed a given task, divided by one, gives you AI cost per task. Aggregate across a time period to get average cost per task type, per project, or per developer.

What you learn from the mapping

Once commits and tasks are connected, the useful patterns emerge quickly.

Task type × AI cost. Some task types have dramatically different AI cost profiles. Bug fixes often show lower cost-per-task than new feature development, because debugging benefits heavily from AI assistance with clear context. Open-ended feature work may show higher spend-per-task because the problem definition is less structured.

Time estimates vs. AI-assisted actuals. If your issue tracker has time estimates, you can compare estimated developer hours against AI-assisted completion time. This is the most direct way to measure time saved, and it produces numbers your project managers already understand.

High-value vs. low-value task distribution. Not all closed tasks are equal. Connecting AI spend to task priority, story points, or business impact lets you see whether AI effort is concentrated on high-value work or spread uniformly.

Commit quality signals. Tasks that required many commits to close (lots of back-and-forth, revisions) may indicate less efficient AI usage than tasks that closed cleanly. This is a rough signal, not a judgment — some tasks are genuinely iterative — but it is a useful pattern to watch.

The 20% of commits that do not map

In most codebases, a fraction of commits will not have task references. Infrastructure changes, dependency updates, merge commits, and quick fixes often skip the reference convention.

This does not break the analysis. Unmapped commits still appear in total commit volume and total AI spend. They simply do not contribute to per-task metrics. For most reporting purposes, attributing spend to mapped tasks and acknowledging that unmapped commits exist is sufficient.

If you want higher mapping coverage, the fix is process, not tooling: make issue references a merge requirement, not a convention. Most teams that enforce this at the PR level get to 95%+ coverage within a month.

Why this is harder without dedicated tooling

Connecting these three data sources manually is a weekend project that becomes a maintenance burden. Git logs, Jira APIs, and AI billing exports all have different schemas, update cadences, and authentication patterns. Keeping the pipeline running as team size, repositories, and AI tools change requires ongoing maintenance that most engineering teams do not have spare capacity for.

The alternative is a purpose-built layer that does the joining and keeps it current — which is what Tazmin is built to do.

Tazmin connects AI spend, git commits, and issue tracker data so the commit-to-task mapping happens automatically. Join the waitlist to get early access.