100% AI-Generated Code? What My Job Looks Like Now

AI writes 100% of my code. The work did not disappear, it was relocated. Read about what a developer actually does now, what improved and what was given up for it.

AI writes all of my code. Not most of it, not the boring parts. All of it. This is how that happened and how it changed the job. Some of it got better than I could ever expect. Some of it I am still not comfortable with.

How it all started

Before AI was in the picture, I had an idea about how to get better at this job. I had to be faster.

So, in my first year as a junior developer, I practised typing. Actual typing tests, where they show you a paragraph and count your words per minute. I watched that number go up and felt like I was investing in my career. I memorised editor shortcuts, found quicker ways to move around the codebase, cut every small movement between the thought and the file.

What I missed back then seems obvious to me now.

The things that actually cost me days had nothing to do with my typing speed. A user story so imprecise that nobody could tell me what “done” meant. A module three developers old that everybody avoided. A task where I simply could not see the solution yet. The only real way forward was to sit with it or to discuss it with somebody out loud.

No typing speed in the world comes close to any of that. However, speed was the part I could measure, so speed was the part I kept working on.

I used to think typing faster would make me a better developer. Today, I barely type code at all.

The ChatGPT era

The first thing AI replaced was not writing code, it was Stack Overflow.

Trying to get unstuck used to result in a routine. You typed your problem into a search box and opened six tabs. You read other people’s questions, hoping one of them was similar enough to yours. The answer I had found was always for a slightly different version from mine, a slightly different setup or a subtly different problem. Then came the work of applying it to your case.

By using ChatGPT I could describe my problem at hand instead. My code, my error, my constraints. The loop was simple. Paste the code, explain what was wrong, get a suggestion, copy it back, test it. If it did not work, say so and ask again.

I was still the developer. I wrote the code, I decided what went into the project, I kept the whole thing in my head. AI was something I turned to when I got stuck. Then I went back to work. Nothing about that felt like a threat to my job. It felt like a better search engine.

That is how it started for me. Not with AI taking over the code, but with me closing the Stack Overflow tab.

When AI moved into my editor

Then I stopped moving between windows. To ask a question, I no longer had to leave my editor, open a browser nor paste my code into a chat.

With Cursor, AI was no longer somewhere else. It could see the project, read the files and change them. I stopped describing my code to it, because it could already access the same files I was looking at. The copy-paste step disappeared. No more adapting a generic answer to my file names or my structure. A suggestion arrived in the right place, in the right shape. I either kept the solution or disregarded it.

That sounds like a small convenience, but it changed the whole rhythm of the work. This is where AI stopped being something I consulted and became part of the job.

I was still writing code, just not all of it.

When I stopped writing code

Then I stopped writing it at all.

With Claude Code, even the last step disappeared. I no longer open the editor to implement a feature. I describe what needs to happen and AI makes the changes. I read what comes back.

Part of me resisted this. Programming was the first thing I have ever really enjoyed. I could picture myself doing it for the rest of my life. I did not want to give that up.

Then one day it hit me. This is real. AI is writing all of my code. A few years ago that sentence would have sounded ridiculous.

What I do instead is read. Not every line with the same attention. Most of it is not where the risk is. A component that renders a list either works or it does not. The tests will tell me that.

Migrations get most of that attention. A migration runs once against real data. If something goes wrong, there is often no way back. Configuration and dependency versions get read just as closely, but for a different reason. A wrong value usually announces itself. The deploy fails. The service does not start. I know long before it can do any damage.

So, my job changed. I went from writing code to reviewing decisions made by someone or something else.

So what does a developer actually do now?

That is the question I get when I say AI writes my code. If it writes everything, what is left for you?

I am busier than I used to be. The work just moved.

When I used to write code by hand, most of my decisions happened quietly while I typed: where does this logic belong, which layer owns it, how far to generalise it, what this class is allowed to know. I never had to put any of it into words. It was part of the typing.

Now those decisions have to be made out loud.

The same goes for context. AI reads the repository, the repository does not explain itself. It cannot tell you why those two services were split or which client is still on the old subscription plan. I carry that. If I do not pass it on, the code comes back wrong in a way that looks right.

Then there is the question of what the term correct means for this feature. Not whether it runs. Whether it does the thing we actually wanted, including the cases nobody thinks about until production. I define that. Then I review everything against it.

So the work did not disappear. It lost the part that used to fill my day and kept the part that was always harder.

I produce far less code than I used to, but I make more decisions than I ever did.

The hardest part is knowing what to ask for

When I used to write code myself, I was allowed to start vague. I could begin with a rough idea. Write the first version. Watch it fail. Let the details fall into place as I go. The code asked me the questions one at a time. I answered them as they came up.

Delegating does not work like that.

AI does not stop to ask what I meant. It takes whatever I give it and returns something complete, with confidence and finished. If my prompt was flawed, it wouldn’t be obvious that the outcome is broken. It is inconspicuously not what I wanted, but I notice that while reviewing, not while building.

So everything needs to be planned three steps ahead. Before anything gets built, I have to know what I want and to put it into words somebody else could follow.

That turned out to be harder than writing the code ever was.

It is also why a loose chat with AI stopped being enough. A more structured way of working became necessary. Tools like Spec Kit exist for exactly this problem. A colleague of mine wrote about that shift in more detail. The read is worth your time.

The better AI gets at writing code, the more it matters what I ask for.

The good, the bad and the AI

AI did not make me a better developer, nor a worse one. It made me better at some things and worse at others. I am still not sure the trade is even.

Some things I can feel getting better. I read code more critically than I used to. Nothing gets into the project unless I decide it should. I think about a feature as a whole before it exists. That is not optional, because the description comes first.

Other things moved in the opposite direction. I could still write a feature from an empty file, it would just take me longer. Things I once typed without even thinking would take me a moment to process now. My projects still make sense to me, but I no longer carry every detail in my head.

So here is the question.

If AI does something for you and you stop practising it, do you fall behind?

I think you do. A skill you stop using does not stay sharp.

A simple  answer would be that I traded mechanical skill for sharper judgement. It is probably true. It was a good trade. I know exactly what I gave up for it.

The things AI made dramatically better

Not all of it was a trade.

Every project carries a pile of work that matters and never gets to the top of the list. The tests we promised ourselves after the feature shipped. The README that stopped being true two sprints ago. The document explaining why we built it this way, for whoever inherits the project next year.

That work lost every argument against a deadline. It was tedious. It was invisible. There was always something more urgent.

Now it costs me almost nothing.

Tests are the clearest case. Everything has them now. Coverage used to be whatever there was time for. Then there was the refactor. Thirty tests go red. Putting them back in line is a mechanical afternoon nobody wants. That now happens in the same step as the change.

Documentation went the same way. Handover notes, an explanation of how the pieces fit together, a diagram of what calls what, a record of why we chose this and not that. All of it written while the reasoning is still fresh, not reconstructed a year later by somebody guessing from the code.

Even naming things stopped being my job. That sounds like the smallest possible win, until you remember who the names are for. They were never for the machine. A good name is the shortest message you can leave for whoever opens the file next. I used to weigh them one at a time. Not always well.

None of that work waits for a quieter week now.

The next person who opens one of my projects will find the tests, the diagram and the reasons behind them. I used to leave them nothing but the code.

What I don’t like about it

Now the part that makes me uncomfortable.

The code that goes out under my name is not code I wrote. I read it. I send it back when it is wrong. But I did not write it. I can tell.

I used to recognise my own code. Partly by its shape, mostly by its names. Now I open a file I shipped last month. It reads like somebody else wrote it. It is good code, just not mine the way it used to be.

So, how much of this code is actually mine?

All of it, in the way that counts. If the code breaks on a Sunday night, nobody is going to ask who typed it. Nobody should. I chose it, I approved it, I shipped it. That is ownership in every sense that matters. To a client, to a team, to me at 2AM. It is simply not authorship. I used to have both and never had to tell the two apart before.

The second thing is harder to say out loud. I cannot really picture a few days of work without Claude or a similar tool. It’s not impossible, but everything around the job now assumes AI is there. What I promise, how long I think something will take, how much fits into a sprint. None of those numbers would have been the same two years ago.

I have never been this productive. And never this dependent on something I do not own. Every estimate I make now is an estimate for two: AI and me.

Would I ever go back?

No. That one did not take long to answer.

Not because AI writes better code than I do. Some days it does, some days it does not.

The job I would be going back to does not exist any more. How I plan a feature, what I ask before a single line exists. All of it grew around the way I work now. Working without AI would not make me independent. It would only make me slower.

The old way was not the better way, it was only more mine.

Years ago, as a junior developer, I watched my words per minute soar and felt like I was building a career. I was not wrong that speed mattered, but I was wrong about which speed. The most productive developer is not the one who writes code the fastest. It is the one who knows exactly what needs to happen and can explain it clearly enough that it gets built.

Those typing tests still exist online. I would probably score well, but that number just stopped being relevant.