Most conversations about AI in software development circle around output – more code, faster releases, shorter sprints. What gets less attention is what happens to the person writing that code, and how the job itself shifts underneath them while nobody’s looking.

I’ve been living that shift for the past year and a half, across several projects where AI agents went from a helper in the chat window to a full participant in the codebase. During this time both the tools and my role kept changing.

At this point, one thing is clear. The job I have now isn’t the one I started with. The transformation started slowly but progressed fast.

I didn’t set out to become someone who mostly reviews an agent’s code instead of writing my own. It happened project by project, tool by tool. Looking back, I’d pin down these thoughts for anyone who wants to explore the same path or just needs a perspective from another human.​

#1 One leap at a time

The first stage barely counted as agentic. I was mostly using chat AI to speed up the smaller, more mechanical parts of the job: dropping in snippets to investigate an issue while I focused on the bigger problem, asking for a helper function or a small algorithm, or simply handing off bits of code that weren’t worth writing from scratch. Security constraints made even that awkward on some projects, so examples sometimes had to be stripped of context or changed enough to make the real code less recognizable. It was useful and it saved time, but only in small doses. Everything still had to travel through the chat window and back into the codebase by hand, which put a pretty hard ceiling on how far that way of working could scale.

The next step was the first generation of agentic coding tools, such as Cursor. The AI moved into the editor, gained access to the surrounding code, and could propose or make changes directly instead of relying on me to shuttle snippets back and forth. At the time, that felt like a significant leap.

Then came the current generation of agentic tools, with Claude being a good example: connected not just to the codebase, but to the ticketing system and source control as well. That’s when the work stopped being about writing code most days and started being about deciding what should get built and checking that it got built right.

#2 Output is not the point anymore

For most of my career, the thing I produced was code. Lines written, features shipped, bugs fixed. Now the thing I produce is closer to steering direction: what the outcome should look like, what the constraints are, when something’s good enough to ship and when it isn’t.

That’s a different skill than the one I trained for. Writing good code and judging whether code someone (or something) else wrote actually solves the right problem – aren’t the same muscle. I’m still building the second one.

#3 The lines between roles are blurring

I’ve watched this spread past engineering. A designer on one of our projects started making small code changes directly, because the agent could handle the implementation, once she described what she wanted. A project manager writes tickets that already include a rough technical breakdown, because she can ask the agent to sanity-check the approach before it ever reaches an engineer.

None of that was possible without a developer in the loop for even the smallest changes. I don’t think it means those roles are dissolving into each other. It means the bottleneck moved: technical execution got cheaper, and judgment about what’s worth building got more valuable for everyone on the team, not just engineers.

#4 What I’ve traded away

I want to be honest – there’s a part of this that isn’t a clean win. I know this codebase less intimately than I used to know the ones I wrote by hand. If something breaks at two in the morning on a system I’ve mostly reviewed rather than written, I don’t have the same instinct for where to look first that I’d have on code I typed myself, line by line.

That’s a real cost. The tradeoff only makes sense if what replaces that instinct – tests, rules, documentation that stays current – is actually reliable enough to catch what my gut used to catch. Most days it is. I don’t know if it always will be.

#5 What remains unchanged

No matter how good the tooling gets, someone still has to lay the foundation by hand. That part hasn’t changed, and I don’t think it will.

My most agentic project so far was greenfield, which sounds like the easy case: no legacy code, no old patterns to fight. In practice, the first two or three weeks were the opposite of smooth. The agent had no existing codebase to learn from, no patterns to follow, so early architectural decisions needed a lot more manual correction than I expected going in.

Once that foundation was in place, the agent had something to reason from, and the pace changed completely. I don’t think that early friction was a failure of the approach. It’s the actual shape of doing things well, no matter the framework: slower at the start, faster once the groundwork is solid. The tools changed. The need for someone to lay that first foundation carefully didn’t.

#6 What adaptability actually looks like

If there’s one thing I’d tell an engineer starting this shift, it’s that the discomfort in the first few weeks isn’t a sign you’re doing it wrong. Trading a skill you’re confident in for one you’re still building is supposed to feel worse before it feels better. The tools changed faster than any previous shift I’ve been through in this job. What didn’t change is that someone still has to decide what’s worth building and be willing to say “not yet” when the agent is confident but wrong.

#7 A question for my future self

Do I still think of myself as a programmer? Yes, for as long as I believe I could still go back to writing code, line by line. But there are days when what I actually typed wouldn’t prove it. Maybe that’s the real shift: the job used to be measured by what I wrote, and now it’s measured by what I’m willing to stand behind. Is it a fair trade? Ask me again in six months.