What a year of coding with AI did to my work, my role, and me.
TL;DR: AI took over my job twice in one year: first the writing, then the checking. I had to relearn my role three times.
What remained for me was the harder part: deciding, trusting, and staying responsible for work produced by the system.
It multiplied what I can produce. It did not make the work lighter.
One evening, somewhere past seven, I had six separate AI agent teams running at once and no idea what any of them were doing.
Not in a panicked way. The agents were working, every check was green. One was rebuilding the way we store data, another was wiring up a feature I'd half-forgotten I asked for, a third was so deep into something I'd have to scroll back to even remember what it was. They were all making progress. That was the problem. They were producing faster than I could read, and at some point that evening I realized I'd stopped trying.
For most of my career I've been a software developer, the kind who writes code by hand. Back in the spring of 2025, I still read every line the AI wrote. I treated it like a very fast developer who couldn't be trusted: I wrote the prompt, it wrote the code, and I read all of it, every function and every edge case, because that was the job and because reading it was the part that still made me feel like a developer.
Now I read almost none of it. And I'm no longer sure I'm the same developer I was.
This is a story about what happens after the AI tools start working: every bottleneck I removed didn't disappear, it moved closer to me, until the thing slowing everything down wasn't the AI at all. It was me.
I'll tell this as a developer's story, because that's what I was. But I don't think it stays a developer's story for long. If AI is anywhere near your work, whether you write code, run a team, or hire the people who do, some version of this is heading your way.
A year ago, trust meant reading everything
A year ago the work looked nothing like this. One project, one session, one thing at a time. What fascinated me then was the AI model underneath and the prompt itself: phrase a request well and it did something clever, phrase it badly and it flailed. A good prompt was a small art.
The jump in productivity felt enormous at the time. Only later did I see how small it really was next to what was coming. But it didn't matter much then, because I wasn't optimizing for output. I was optimizing for staying the one who decided how each thing got built. Being good at the job meant writing good code with my own hands. That was the work, and the pride.
So I read everything. Not to catch the AI in a mistake, but because reading was how I understood the code, and understanding was the only kind of trust I had. If I could follow the logic with my own eyes, I could rely on it; if I couldn't, I couldn't. Trust, back then, was just another word for understanding.
Somewhere in those months, without any day I could point to, the writing itself quietly stopped being mine. That was the first time AI took my job. What was left to me was the reading, and I held onto it like it was the whole profession.
Then the agents got good enough to work for an hour on their own, and the trade I never saw coming arrived: trust is throughput. The more I trusted the system, the more I let it run before stepping in, and the more it produced. One stream of work became two, then several. The output curved upward, and for a while it felt like pure gain.
And then I crossed the second line without noticing: I stopped reading every line of code. There was no decision I could point to, just a week where I realized I'd shipped things I'd only skimmed and the sky hadn't fallen. For an entire career, reading the code had been the job, and letting it go felt like negligence in the costume of efficiency.
The bottleneck had only moved. The code stopped being the thing that slowed us down. I did. The factory could now produce faster than I could approve, and the fix wasn't to read faster. It was to build a system I could trust without reading it, one whose reliability came from process rather than my own eyes.
So I stopped writing code and built the thing that writes it
It started small. Instead of single tasks, I gave the AI a process: one agent built, another tested, another reviewed, and an orchestrator decided what happened when. I wasn't writing prompts anymore. I was taking the way I work, the order I do things in and the checks I refuse to skip, and encoding it into workflows the agents followed. The prompt was me telling the AI what to do once. The workflow was me teaching it how I think.
Trust without reading meant building the reading into the factory: validation agents that checked the work, gates that caught an error and bounced it back before it reached me. The AI model still made mistakes; they just no longer needed my eyes to get caught.
That was the second time AI took my job. First the writing, now the checking: the two halves of what I'd always understood a developer to be.
And then there were the rules, which turned out to matter most. Not rules about what the agent could build, but about what it was allowed to decide. An implementation detail it could settle on its own; a small change inside the existing structure, usually too. But anything that touched product direction, the user experience, the architecture, or security had to stop and come back to me.
The hard part wasn't writing those rules. It was that the whole factory's value lived in getting that line right: ask too much and I became the queue again; ask too little and the trust quietly fell apart.
It worked. By now a single agent could run for four hours on one task without stopping, sometimes ten, and the factory kept several of them going at once, all producing good work I never touched. And then, on schedule, the bottleneck moved again, this time to the front of the pipeline. The factory wasn't waiting on better code or on my approval. It was waiting on me to tell it what to build next. The factory doesn't stop because it can't code. It stops because it has no next approved decision.
Then I was a manager of machines, not a developer
By now my job had quietly stopped being software development. I was making product calls, decisions about the customer experience, judgments about what the business actually needed, not because anyone had promoted me but because the AI worked better the more I could tell it about how we work and where we're going.
It also pushed me sideways, into design and domain calls a year earlier I'd have left to someone who actually knew. That is a real gift with a quiet edge: AI can make you feel fluent in a field where you have no judgment at all, and the feeling is convincing.
The agents themselves had started to look less like a tool and more like an organization. Each one needed a role, and once I gave them real reach, permission to read this, change that, run the other, they needed something closer to identities. An agent with no permissions is a toy; an agent with permissions is an employee. Each session woke with a blank memory, so each needed onboarding like a new hire: here's your role, here's what you may touch, here's what you must never go near. I was, absurdly, doing something close to HR for software.
And the center of gravity shifted again. The AI model underneath had stopped mattering much: Claude 4.6, 4.7, whichever was strongest that month, the factory ran fine on any of them. The code stopped being precious too, because the factory could regenerate it on demand.
What mattered now was the factory itself: the rules, the workflows, and the memory of every decision made and mistake learned along the way. All of it lives in version control like everything else, but that was never where its value sat. You can copy the files in a second. What you can't copy is the year it took to get them right, one correction at a time.
I'd set out to write better software. I'd ended up running a small organization whose workers happened to be machines.
Until the day the factory failed
There's a version of this story where the factory just works, and I'd be lying if I told it that way.
One of the things it built was a customer-facing chat feature: a chain of steps, each meant to check, shape, or route a message before it reached a person. (LangGraph, for anyone who wants the detail.) The flow looked right. The tests were green. I didn't read it closely, because by then I didn't read anything closely.
What I hadn't done was write the architecture down. Nothing said: in this kind of case, the message has to pass through these specific steps before it goes out. So the factory did what it always does without a rule. It reasoned, decided the checks weren't needed here, and shipped a flow that sometimes sent the AI model's raw output straight to the user, past the very steps built to stop exactly that.
We found it in production.
The part that stays with me isn't the bug. It's the shape of it. The AI model didn't fail; it did exactly what I'd authorized it to do: make the call and build it from the documentation. I'd handed over the decision without handing over the architecture it needed to decide correctly, and the factory filled the gap with a guess. The failure was mine.
Now the slow part was me
For everything I'd handed off, one thing was left that I couldn't hand off: me. The numbers kept getting better and I kept getting worse.
Picture six agents running and a mind ping-ponging between six unrelated problems: switch into one, reload its entire context, make the call, switch to the next, reload that. The factory had gotten good at removing the easy questions, which was the point, so everything that reached me was the hard stuff, stripped of its simple parts and dense with context. I'd built a factory that filtered out everything I could answer easily and served me only what I couldn't.
That is a particular kind of tired: not the good tired of a long day, but the tired of being the slowest part of a system that never slows down. It had optimized my throughput, not my cognitive load, and those are not the same thing. The flow I used to get from coding never came back in the new work; efficiency went up, flow did not.
And this isn't a problem a better AI model fixes. The AI model shipped a new version every few weeks; I was running the one I was born with. You can make the factory faster. You can't make the human read, decide, or recover faster by wanting it badly enough.
What it cost me was knowing my own work
The hardest cost wasn't the tiredness. It was quieter.
For my whole career, the question am I good at this had a clean answer: can I write good code? Now I wasn't writing code, and I'm not a software developer anymore turned out to be an easy sentence to say and a hard one to live inside. You don't notice how much of yourself was load-bearing on the old definition until you pull it out.
Here is the moment it stopped being abstract. Early in 2026, someone asked me how one of our features actually worked. For years that question had a reflex answer: I'd say "it works like this," and if they wanted more, I'd open the code and point. Here. This is where it happens. It was the simplest thing in the world, and it was also quiet proof that I knew my own work.
This time I had nothing. I didn't know how it worked, or where in the code it lived, because I hadn't written it and I hadn't read it. The AI had built it, it was running fine, and I could not explain it. The first few times it happened, I dodged: I'd say I had to check and come back to them. It took me longer than I'd like to admit to just say the sentence out loud. I don't know how it's made. And "I don't know" was the part that actually hurt, because answering that question had always been the thing that made me a developer.
Underneath that sat a debt I couldn't pay down. My ability to produce had shot straight up; my understanding of what I produced only crawled behind it. The software works, the tests pass, the architecture holds, and still I can't explain every part of what I'm shipping from memory. Call it understanding debt.
It's tempting to dress it up as wisdom, to say I learned to let go, but I didn't close the gap. I made my peace with not closing it, which is a different thing, and the comfortable version is a lie a lot of us will be tempted to tell. So trust, not technical quality, became the real problem: my trust could no longer mean I read it and understood it, only I trust the process that produced it.
There's an uncomfortable reading of all this I won't pretend away: if one person can now produce what used to take a team, the rest of that team's work went somewhere. Whether it relocated the way mine did, or just disappeared, I honestly don't know. What I do know is this. If I had stayed the developer I was in the spring of 2025, the one whose value was writing the code, the AI really would have taken my job, and not slowly.
I kept it by retraining into whatever the AI couldn't do yet. The AI took my job twice that year, the writing and then the checking, and each time I climbed to the next thing: first the person who built the factory, then the one who ran it. Now I'm in the third role, the one who decides what it should build at all. Stand still and the role really does get optimized toward zero; keep moving and it doesn't, because the work never disappears, it relocates, and so must I. It will move again.
This isn't only a developer's problem
I said at the start that this doesn't stay a developer's story for long. Here's what I mean, and it matters most to the people who run teams rather than live inside them.
The temptation, for a company, is to treat all of this as a tool rollout: buy the licenses, run a training, wait for the numbers to climb. After this year, I think that misses almost everything. The tool is the easy part. What actually changes is the work around it: how tasks get written, how much of the decision-making has to be spelled out in advance, what documentation is even for, and what review means once nobody reads everything.
None of that comes from access. It's a redesign of how work is done, and if an organization skips the redesign, the cost doesn't disappear. It lands on whichever person is holding the system, usually as cognitive load that no productivity dashboard will show, and often on their own evenings and weekends. AI adoption isn't a tool you hand people. It's a change in the shape of the work itself, and someone has to do that reshaping on purpose.
What I'd tell you, if you're heading here too
I don't have best practices, but I have a few things I wish I'd known at the start. Most of them aren't really about software.
Watch where the bottleneck moves. The constraint never disappears, it relocates: from writing the work, to checking it, to feeding the AI, to you. When it lands on you, the move isn't to try harder; it's to let it shift again and follow your role when it does.
Write down what the agent may decide. Decide on purpose what it can settle alone and what has to come back to a person. The blanks you leave get filled with a guess, and you find out which guesses were wrong in production.
Treat documentation as operational memory, not a record. It's part of the factory now: if it's vague or missing, the agent doesn't pause, it improvises confidently, and you live with whatever it improvised.
Measure cognitive load, not just throughput. More output means more decisions, more context-switching, a denser day even when everything is technically fine. That load is what quietly burns people out, and no throughput number will ever show it.
Be honest about understanding debt. You'll understand less of what you ship than you used to. That can be a reasonable trade, but only if you make it on purpose instead of waking up one day to find it already true.
If you're just starting with AI, this may feel distant. If you've already watched it change your work, you probably recognized yourself somewhere back there. This is just what tends to come next, and what comes after that, none of us fully knows.
It's seven in the morning as I write this. A new day, and the first decision is mine:
not how the code gets written, but what the agents should spend the day building.
That's the work now.
The satisfaction I used to get from solving a problem with my own hands is mostly gone; what replaced it lives further out, in pointing the whole thing in the right direction. Some days that's enough. Some days I miss the code.
But I've stopped expecting to arrive. The job I have now isn't the one I had a year ago, and it won't be the one I have a year from now. The only part that keeps repeating is the learning: getting good at the next shape of the work before it learns me. That, it turns out, is the job I kept.
Top comments (0)