There's something that happens around month three or four of heavy AI assistance.
You look at your git history. You shipped things. Significant things. A feature that required architectural decisions. A refactor that restructured three modules. A bug fix that involved real diagnosis.
And yet when you try to feel the work — when you try to locate yourself in the process — there's a blank space where the sense of authorship should be. The code exists. The work happened. You're not sure you're the one who did it.
This is ghost authorship. You're present in the output. You're absent from the process.
---What Ghost Authorship Actually Is
Ghost authorship has a clinical definition from academic publishing: when someone makes substantial intellectual contributions to a work but isn't acknowledged as an author. The work exists. The person doesn't appear in it.
In AI-assisted engineering, the inverse happens. You appear in the work. Your name is on the commit. The pull request is yours. But the substantial intellectual contributions — the decisions, the diagnoses, the architectural reasoning — came from somewhere else. You supervised the process. You didn't drive it.
Ghost authorship isn't imposter syndrome. Imposter syndrome is feeling like a fraud despite evidence of competence. Ghost authorship is something more specific: feeling like you didn't actually do the work even though you're credited for it. The code is yours. The authorship isn't.
The distinction matters because imposter syndrome is a cognitive distortion — it's about how you perceive real accomplishments. Ghost authorship is a functional change — something genuinely shifted in the relationship between you and your work. The craft isn't being doubted. It's being outsourced.
---How It Shows Up in Practice
The code review you can't explain
Someone asks about a piece of code in review. You can navigate it — you know where things are. But when they ask why it was structured this way, you realize you're reconstructing the logic rather than recalling it. You're reading the code like someone who just joined the project, not someone who built it.
The knowledge feels second-hand. The authorship feels borrowed.
The feature that shipped but doesn't feel like yours
You built a non-trivial feature over two weeks. The PR is merged. The feature works. When you try to describe what you specifically contributed — the decisions that were uniquely yours — the story is vague in a way that feels different from normal modesty. You're not underselling yourself. You genuinely can't locate where you ended and the AI began.
The debugging session that felt like supervising
Something breaks in production. You start debugging — and at some point you realize you've been watching the AI walk through the code more than you've been walking through it yourself. The diagnosis happened. The fix happened. But you were in the room for it rather than driving it.
The onboarding of your own system
You come back to something you built six months ago. The code is familiar in the way a house you lived in is familiar — you know the layout, but you don't always remember why the hallway turns there, or why that wall is where it is. Except with a house, you'd remember building it. With your code, you sometimes genuinely don't.
Why This Is Harder to Notice Than It Should Be
Ghost authorship is easy to dismiss in the moment because AI-assisted work still requires real judgment. You reviewed the approach. You approved the implementation. You made decisions at every step. The work is real. Your role in it is real.
But there's a difference between approving work and producing it.
The problem isn't that you did nothing. It's that the part of the work that used to give you a sense of craft — the grappling with a hard problem, the failed attempts, the slow dawning of the right approach — got compressed into a prompt and a review. The satisfying part, the part where the skill actually lives, became optional.
You can be fully engaged and still not be the author. You can review every line and still be a reader.
This is why ghost authorship is particularly insidious for senior engineers. Your bar for "good enough" is high. Your reviews are substantive. You're not phoning it in. And yet: the sense of ownership that comes from having genuinely struggled with something and solved it — that's gone. And you may not notice it missing until you try to describe a recent project and realize you can't tell the story of how it was made.
---The Difference Between Ghost Authorship and Normal Delegation
Senior engineers have always delegated. You delegate code reviews. You delegate implementation details to juniors. You delegate research to teammates. You rarely implement everything yourself, and you never feel like you need to.
So why does AI feel different from normal delegation?
Because delegation to a person maintains your authorship. You gave someone direction. They executed. The relationship between your judgment and the output stays intact. The work is yours because you decided what the work should be.
AI is different because it doesn't have judgment — it has pattern. It executes with a surface-level fluency that resembles understanding without having the underlying model of the problem that you have. When you review AI output, you're not reviewing a colleague's reasoning. You're evaluating a simulation of reasoning. And your brain — which is very good at recognizing fluent language — fills in the sense of authorship that the fluency implies.
The delegation looks the same from outside. It feels very different from inside.
---What Reclaiming Authorship Actually Looks Like
This isn't about using AI less. It's about being more deliberate about which parts you delegate and which parts you keep.
The Explanation Requirement
Before you merge any AI-assisted work, write one paragraph explaining — to someone who doesn't have context — why the solution is structured the way it is. Not what the code does. Why that approach was chosen over alternatives.
If you can't write that paragraph without looking at the code, the authorship is ghost. The code is yours in name. It's not yours in understanding.
This is a diagnostic. It's also a practice. The act of writing the explanation — forcing yourself to articulate the reasoning — starts rebuilding the connection between your judgment and your output.
The Decision Log
For significant pieces of work, keep a 2-3 sentence log of the decision: what was the problem, what did you consider, what did you choose and why. Not for documentation. For yourself. For six months from now when you come back to it.
This gives you a record of your own reasoning that predates the code. When you come back to the system and can't remember why the hallway turns there, the decision log tells you. The authorship is documented even if it doesn't feel documented in the code.
The No-AI Sprint
Once a week, pick something small and build it with no AI assistance. Complete it. Ship it. The thing itself doesn't matter — the point is having recent, direct experience of what it's like to start with a blank file and end with working code, with no supervisor in the room.
This isn't about proving you can still code. It's about having a fresh data point on what your own process actually feels like, so the comparison with AI-assisted work isn't purely theoretical.
The Code You Can Explain
As a weekly review, look at one piece of code you wrote or significantly shaped in the past week. Can you explain every major decision in it — not what the code does, but why each piece is structured the way it is? If yes, the authorship is present. If not, it's ghost. File that information without judgment and decide what to do about it.
The Closing Argument
Ghost authorship is a structural consequence of how AI assistance works, not a personal failure. The work is good. The output is real. You're still the engineer in the room.
But the authorship — the connection between your judgment and your craft, the sense that you made this thing through your own thinking — that requires something AI can't provide: direct struggle with a problem you chose to take on.
The gap doesn't close by using AI less. It closes by being more deliberate about which problems you take on directly, and by building practices that keep the connection between your judgment and your output intact.
The code is yours. Make it feel that way.
---Take the AI Fatigue Quiz
The quiz has a dimension that maps directly to ghost authorship — the question that asks how you feel about code you've shipped. Your results page has a section specifically on the authorship question.