Who You Are When "Developer" Stops Meaning What It Meant

The first draft doesn't have to come from you. The verification does.

Generated by Midjourney

Three weeks ago a product manager asked me how the ownership percentages get calculated when a payment goes out on one of our servicing systems. I had a rough idea. After twenty-five years, you gain a feel for legacy systems, even the ones you didn’t create. You sense the logic’s structure, where edge cases may lurk, and what the answer is likely to be. But “likely” isn’t something you hand a PM and call it a day, not when real money is attached to it. So I pulled together a report, used AI to help lay out the calculation logic clearly, and then spent most of my actual time doing what I would’ve called the boring part a few years ago: checking it. Line by line, against the real behavior, against edge cases I already suspected might be wrong. Not copy-pasta of the AI output. Verification.

By the time I sent the answer, I trusted it completely. I’d caught two places where the draft logic didn’t match what the system actually did. I stood behind every line of that report the way I’d stand behind code I wrote myself.

And still, for about half a day, something nagged at me that I couldn’t quite name. It wasn’t that the answer was wrong. It wasn’t. It was that the first draft of knowing hadn’t come from me. All throughout my career, “knowing how a system works” meant something specific: you held it, cold, in your own head, built from your own hours in the code. This time the first draft came from somewhere else, and my part was making sure it was true.

What Was Actually in Your Power

Epictetus starts the Enchiridion by making a key point: some things you can control, and some things you cannot. Your judgment: yes. Your opinion, your choices, what you do with what’s in front of you: yes. He’s blunter about what isn’t: “not in our power are body, property, reputation, command, and, in one word, whatever are not our own actions.”

I used to think “knowing how the system works” belonged entirely to me, the good kind of ownership, the kind you earn. But, memory fades. Systems outlive the people who built them. Nobody holds an entire legacy codebase perfectly in their head, no matter how good they are. You were always reconstructing, always checking notes, always half-remembering and half-verifying, long before AI ever entered the picture. The clean, unaided-recall version of “knowing” I was quietly grieving was never fully real to begin with. What was real, every single time, was the part where I decided whether to trust what I had in front of me before I put my name on it.

That’s the part that was always mine. Not where the first draft of an answer comes from: memory, a hunch, a report generated to help me get there faster.

What’s mine is what I do with it before I’d stake anything on it.

The Old Promise, and the Smaller True One Underneath It

I think this is where a lot of the unease about AI-assisted work actually lives. The old promise of this job was that competence looked like recall. After years, you’d just know it. That instant feeling proved you earned your spot. It’s a good story. It’s also always been a slight exaggeration of how the work actually happened. Every developer I respect checks the docs. They ask the person who wrote the original ticket. They also run the thing twice to be sure. Only then do they speak with confidence.

What’s changed is that the answer can now start from places other than just memory. What’s changed is how clear this has become. It can really shake you if you’ve built your identity on the myth of the solo expert. Instead, focus on the smaller truth: don’t claim something is true until you’ve proven it yourself.

What Was Actually Yours

Nothing about my competence had changed. What changed was when my judgment did its work. The verifying, the catching of the two wrong assumptions, the refusal to send anything I hadn’t checked, all of it moved later in the process than it used to. It used to happen while I typed the code. Now it happens while I read someone else’s draft, or a tool’s draft, before I make it mine. Same discipline. Different position in the sequence.

This is similar to what the Stoics believed. They said virtue is about how you act, not what you own. That’s the only good truly worth having. Not “I know this system cold” as a badge. Not even “I produced this myself” as a badge. Just: did you check it. Did you own the answer, all the way down, regardless of where its first shape came from. That part doesn’t change. It was never located in your memory in the first place. It was located in your willingness to be responsible for what you say is true.

I’m not going to pretend the discomfort of that day was pointless. It wasn’t. It’s important to reflect on how knowing has changed. Don’t rush past it with just a pep talk. There’s a big difference between saying, “the first draft of this answer didn’t come purely from my own head,” and “I am no longer someone who owns what I say.” For half a day, I let the first one quietly act like the second. It doesn’t. One is a fact about process. Character is about who you are. AI can’t touch this part of the job.

---

Have you ever felt shaken when the source of your answer changed? Maybe it was a tool, a document, or someone else’s draft. It felt more unsettling than just a simple knowledge gap.

Share your thoughts in the comments. Somebody else quietly grieving the myth of the solo expert might need to hear it.

---

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

---