The Attribution Problem

There's a moment every engineer working with AI eventually hits.

You're in a meeting. Someone asks how a feature got built. You have the answer — you know it was you, the architecture, the decision to build it this way versus that way — but the person asking isn't asking about that. They're asking about the code. And the code, the actual implementation, you didn't write.

You approved. You guided. You reviewed. You made the calls when the AI got stuck. But the artifact they want to see? That came from a tab.

This is the attribution problem. And it's more corrosive than it sounds.

The Version of You That Shows Up

When you ship a feature the traditional way, the story of who you are as an engineer is legible. The commits tell it. The PRs tell it. The code review comments, the tests you wrote, the edge cases you caught — these are all artifacts of a specific mind at work.

When you ship with heavy AI assistance, those artifacts become ambiguous. The commits show your name. But they also show code you didn't conceive, decisions you didn't evaluate from scratch, implementations you accepted on first read.

Your sense of "I built this" has a gap in it. Not a gap in the work — a gap in the felt experience of the work.

And over time, that gap gets lonely.

Why It's Harder for Senior Engineers

Junior engineers navigating this are dealing with skill development. Senior engineers are dealing with something older: identity.

You've spent years building a professional self around the ability to understand systems deeply. When that understanding gets outsourced — not because you're lazy, but because the tool is right there and the pressure to ship is real — something erodes that isn't about competence.

It's about whether you feel like you.

That's the sentence worth sitting with.

The Quiet Compounding

The attribution problem compounds silently.

You start to feel a slight distance from your own work. You stop talking about features in the first person — "we shipped X" becomes safer than "I built X." You become less confident in your own code judgment, not because your judgment has actually declined, but because you've stopped practicing it out loud.

Eventually, you notice that when someone asks a deep question about the system, you feel a flicker of anxiety. Not because you don't know the answer, but because you're not sure the answer you know is actually yours.

The erosion isn't dramatic. It's gradual. And you don't notice it until you realize you've stopped saying "I built this" altogether.

What Most Advice Gets Wrong

The standard responses to this are all slightly off-target:

"Use AI as a pair programmer, not an author." — This assumes the problem is how much you use AI. But the attribution problem exists at low usage levels too.

"Make sure you understand every line AI generates." — Correct in principle, exhausting in practice. You can understand every line and still not feel authorship.

"Attribution doesn't matter as long as the work gets done." — This is true economically and false psychologically. Engineers are not pure economic actors. The felt experience of making things is part of why most of us chose this work.

What Actually Helps

One Question to Sit With

Before your next AI-assisted review, ask yourself: do I know why this decision was made?

Not "do I agree with it" — you can agree with AI output without understanding why it's right. Ask: do I know the reasoning? If the answer is no, that's not a failure. It's a gap. And gaps can be closed.

The engineers who stay sharp aren't the ones who refuse AI. They're the ones who notice when they've outsourced their understanding — and who have a way back.

See you next week.
— Sunny
clearing-ai.com