44% of Deezer Is AI. I Ran git blame on My Commits and Found Something Uncomfortable

44% of the songs uploaded to Deezer every day are AI-generated. When I read that I had to go back and read it twice. Not because it seems impossible, but because the number is so concrete and so uncomfortable at the same time.

Then I did something I shouldn't have done if I wanted to sleep well: I ran git blame on my commits from the last month.

AI-Generated Content on Platforms: the Problem Isn't Quality

The debate Deezer's number sparked was predictable. Angry artists, executives with prepared statements, think pieces about the future of music. Everyone pointing at the same target: the quality of AI-generated content.

And that's where I think the framing is wrong.

The problem isn't whether code generated by an agent works. At this point, it mostly does. The problem is something else entirely: what does it mean for something to be yours when you didn't actually think it through?

In music it's easier to see because authorship is cultural, almost romantic. But in software we tend to hide behind pragmatism. "If it passes the tests, it's fine." I've written about that before — agents that pass your tests are exactly the problem, not the solution.

So I went looking for the real number in my own projects.

The git blame I Didn't Want to Run

# Reviewing commits from the last month
# I wanted to know how much "my" code was actually mine

git log --since="1 month ago" --author="Juan Torchia" --pretty=format:"%H %s" | head -50

# Then, for each commit, I checked the diff
git show --stat <hash>

# And finally, the honest question:
# How many lines of this diff did I actually think through?
# How many did I paste from an agent without really reading them?

I don't have a script that automatically detects whether I wrote the code or Claude generated it. I wish. What I did was more artisanal and more uncomfortable: I went through commit by commit and tried to be honest with myself.

Did I design this TypeScript block, or did I ask the agent to generate "a function that validates the schema" and then just renamed a variable?

// This is exactly the kind of code that made me doubt myself
// I recognize it because it's too clean to be mine on a first pass
// And because the function name is exactly what I would have asked an agent for

function validateContractSchema(data: unknown): data is ContractInput {
  if (!data || typeof data !== 'object') return false;
  
  const contract = data as Record<string, unknown>;
  
  // Did I write this validation? Or did I ask for it?
  // Honestly: I asked for it. And I merged it without thinking much harder.
  return (
    typeof contract.id === 'string' &&
    typeof contract.amount === 'number' &&
    contract.amount > 0 &&
    typeof contract.effectiveDate === 'string'
  );
}

The number I landed on: around 38% of the lines merged that month had some degree of agent generation where my real contribution was the prompt, not the design.

Not Deezer's 44%. But close enough that the discomfort is real.

When I Migrated the Monorepo to pnpm I Understood the Difference

In 2024 I migrated a monorepo from npm to pnpm. Install time went from 14 minutes to 90 seconds. The team couldn't believe it. And I understood that change completely — every decision, every trade-off, every reason why pnpm handles hoisting differently. That knowledge is mine.

Now I think about how much of the code I merge today I can defend with that same level of understanding. And the honest answer is: not all of it.

That's not an agent problem. That's a process problem I own.

The distinction that matters isn't "I typed every character" vs "an AI generated it." That's a false debate. The real distinction is:

Can I defend every design decision in a code review? Do I understand the trade-offs? If this code breaks at 3am, do I know where to start looking?

If the answer is no, the problem isn't philosophical authorship. It's operational.

The Mistakes You Make When You Don't Know What You Merged

Here are the real gotchas I found in my review:

1. The agent optimizes for the case you described, not for your system

// The agent generated this when I asked for pagination
// Works perfectly for the description I gave it
// The problem: my DB has 2M rows and OFFSET is devastating at scale

// What the agent generated (correct for the prompt)
const results = await db.query(
  `SELECT * FROM contracts 
   ORDER BY created_at DESC 
   LIMIT $1 OFFSET $2`,
  [pageSize, page * pageSize]
);

// What I actually needed (cursor-based pagination)
// I know this because I know my system — the agent doesn't
const results = await db.query(
  `SELECT * FROM contracts 
   WHERE created_at < $1
   ORDER BY created_at DESC 
   LIMIT $2`,
  [cursor, pageSize]
);

I merged the first version. I found it in production three weeks later when the contracts endpoint started taking 8 seconds on page 50.

2. Generated code has no memory of your previous decisions

This connects to something I analyzed when looking at Claude's system prompt diffs between versions — the models don't have context for why your architecture made certain historical decisions. I noticed that when I was looking at how system prompts evolve between Claude versions: the model knows a lot, but it doesn't know your history.

Result: the generated code is technically correct and architecturally inconsistent with decisions you made six months ago.

3. Generated technical debt is harder to trace

When I write bad code, I usually know why I wrote it. Time pressure, legacy constraints, a conscious trade-off. When an agent generates suboptimal code that I merged without thinking it through, I don't have that memory. git blame says I'm the author. My brain doesn't remember the decision.

This has direct security implications. If you don't fully understand what you merged, you don't understand your attack surface either. What happened with Vercel in April and the supply chain is a perfect example of how outsourcing without real comprehension creates vectors you never see coming.

4. Trust in the tooling replaces your own judgment

This is the subtle one. When the tool generates the code and the tests pass, there's implicit pressure to merge. CI is green. What more do you want? I wrote about this in the context of trusting environment configuration tools and agents: the question isn't whether the tool works, it's whether you understand what it's doing and why.

What I'd Do Differently (and Am Actually Doing)

I'm not going to say "use less AI" because that's an emotionally satisfying answer that's practically useless. What I actually do:

Self code review before merging, without the context of the agent chat

I close the conversation. I open the diff. I ask myself: can I explain every line? If I can't, I don't merge until I can.

I mentally separate "agent-reviewed" commits from "mine"

Not in the public commit message, but in my own process. Commits where the agent had significant weight I mentally flag for deeper review down the road.

The agent generates drafts, I design the architecture

I changed how I frame my prompts. Instead of "generate me a function that does X," I use "explain the trade-offs between approach A and B for this case" and then write the implementation based on that discussion. Slower. More mine.

The parallel with Deezer isn't that AI-generated content is bad. It's that when you can't distinguish what's yours and what isn't, you lose something important — and in software that something is called understanding the system you're maintaining.

FAQ: AI-Generated Content on Platforms and in Code

Is AI-generated code less reliable than human-written code?

Not necessarily. AI-generated code can be perfectly reliable in functional terms. The problem isn't the reliability of the output — it's the author's comprehension. Code you don't fully understand — regardless of who generated it — is code you can't maintain, debug, or defend during a production incident.

How much of the code in professional projects is AI-generated today?

There's no official, consistent number for software the way there is for music on Deezer. GitHub Copilot reported in 2023 that 46% of code in projects using the tool is AI-generated. My personal experience that specific month was around 38% with some degree of agent generation. The number varies enormously by team, role, and type of task.

What's the difference between using AI to generate code and using Stack Overflow?

It's a legitimate question and the difference is one of degree, not kind. With Stack Overflow you generally understand what you're copying because the context is more limited and you have to adapt it. With an agent the generation is so complete and so tailored to your case that the illusion of understanding is much stronger. The risk isn't copying — it's believing you understand when you don't.

How does this affect code security?

Significantly. If you don't fully understand what you merged, you can't reason about your attack surface. Agents generate code that's correct for the described case but can introduce vulnerabilities in contexts they don't know — your specific data model, your authentication policies, your permissions architecture. Review agent-generated commits with the same rigor you'd apply to code from an external developer who doesn't know your system.

Should I be worried that 44% of what gets uploaded to Deezer is AI?

Depends on what worries you. If it's the technical audio quality, probably not. If it's the creative ecosystem and the economic sustainability of human artists, there are real reasons to think about it. The software analog would be: if 44% of your codebase was generated without the team truly understanding it, you have a maintainability problem and a team that doesn't know its own system — that should worry you.

Is there any way to automatically detect which code in a repo was AI-generated?

Not reliably today. Detectors exist but have high false positive and false negative rates. The more useful question isn't "did an AI generate this?" but "can the author defend every design decision?" No script detects that — code review and production incidents reveal it.

The Discomfort Has a Name

The Deezer 44% is uncomfortable because it makes visible something we'd rather not quantify. When it's music it's easy to point at. When it's our own code, the resistance to running the analysis is much higher.

I ran the git blame. I didn't love everything I found. But now I know where I stand.

What I'd do differently isn't use fewer agents — it's be more honest about the difference between "I merged code that works" and "I understand the system I'm building." The first is execution. The second is engineering.

And if 44% of Deezer is AI, the question I'm sitting with for the year ahead isn't how to reduce that number. It's how to make sure whoever's uploading it actually understands it.

In my case, that starts with not closing the agent session before I close the diff.

Did you run git blame on your last month? What number did you find? Write to me — I genuinely want to know if it's just my project or if we're all in the same place.