Eight months ago I wrote everything by hand. Today the AI writes most of it. I am still not sure which version of me is the better engineer.
Eight months ago I was grinding through a government project solo. Every function, every migration, every middleware. Typed out by hand, reasoned through line by line. It was slow. Some days it was frustrating. But I knew every decision I made because I made every decision.
Then I started letting the AI in. A little at first. Autocomplete here, a generated test there. Then whole controller methods. Then entire service classes from a single prompt. Now I look at my own repositories and roughly 90% of what is committed was written by a model, not by me. I set the base, I write the instruction, I review the output. The AI does the rest.
The question I keep sitting with is: does that make me a better engineer, or am I slowly becoming someone who used to know how to do this?
The Numbers Confirm I Am Not Alone
I did not arrive here by accident and neither did everyone else. GitHub Copilot was writing 27% of code at launch in 2022. By 2025 that number had climbed to 46% across all active users, with Java developers hitting 61%. Gartner projects that 90% of enterprise software engineers will be using AI coding tools by 2028, up from less than 14% in early 2024.
The industry moved fast and most developers moved with it. The productivity numbers are real. Developers complete tasks 55% faster. Pull request time dropped from 9.6 days to 2.4 days in some teams. These are not vendor marketing claims. The 55% figure comes from a controlled study across 4,800 developers.
So the tools work. The speed gains are measurable. The question is what you trade for them.
What the Productivity Reports Leave Out
GitClear analysed 211 million changed lines of code from 2020 to 2024, pulling from repositories at Google, Microsoft, Meta and large enterprises. What they found does not show up in the Copilot press releases.
Refactoring as a percentage of changed code dropped from 25% in 2021 to less than 10% in 2024. Code classified as copy-pasted went from 8.3% to 12.3% in the same window. For the first time in the history of their dataset, developers were pasting code more often than they were moving or reusing existing code.
That is not a productivity story. That is a maintenance story that has not happened yet.
When you generate a function from a prompt rather than extracting it from existing logic, you are not practising the skill of recognising duplication. When you accept a suggested block rather than writing the conditional yourself, you are not building the habit of reasoning about edge cases before you commit them. The code ships faster. The code also carries patterns that a senior developer five years ago would have caught before they ever reached a pull request.
The Real Risk Is Not That You Write Less Code
The concern I keep seeing framed as “AI will replace developers” is the wrong frame. The actual risk is subtler.
When I wrote everything by hand, I was constantly building and maintaining a mental model of my own system. Every file I touched reinforced what I knew about the shape of the thing. I knew where the data flowed. I knew which service was responsible for what. I knew the rough cost of every query because I had written the query.
When the AI writes 90% of it, I am still making architectural decisions. I am still reviewing output. But I am reviewing it as a reader, not as the author. And reading code is a different cognitive activity than writing it. Readers miss things that authors would never do in the first place.
The developers I worry about are not the ones using AI tools. They are the ones using AI tools without having first spent meaningful time without them. There is a difference between a senior developer who delegates routine implementation to an AI and a junior developer who has never learned what routine implementation teaches you about a system.
The Stanford labour study I referenced in an earlier piece found that developers aged 22 to 25 have seen roughly a 20% decline in employment from the 2022 peak. Whether that is AI adoption, the post-pandemic correction or both is contested. But the timing is not coincidental.
The Skill Has Not Disappeared. It Has Shifted.
Here is what I actually do now that I did not do a year ago.
I spend more time thinking about the shape of a feature before I touch a keyboard. Because a vague prompt produces wrong output, and reviewing wrong output is slower than writing the right thing from scratch. Prompt quality is a direct function of how clearly you have thought through the problem. That is not a new skill. It is design and decomposition, which was always the valuable part of the job.
I review generated code differently than I used to review human-written code. I am looking for code that does more than I asked. Functions that quietly picked up extra responsibilities, assumptions about data that the model made without me specifying, edge cases that were handled in a way that looks correct but carries an implicit constraint I did not intend. That kind of review is harder than reviewing code written by someone who sat in the same sprint meeting as you.
I also catch myself going back to first principles more often when something the AI generates does not feel right but I cannot immediately say why. That instinct, the one that says something is off before you can name it, is built from years of writing things yourself and watching them break. It is not the kind of thing you develop by reviewing AI output from day one.
The Honest Answer
Am I a better engineer now than I was eight months ago? In terms of output volume, yes, clearly. In terms of how much I am exercising the raw mechanics of writing code, no.
The 90% figure does not worry me for myself the way it would worry me if I had not spent years writing the other 90% first. The context is already there. I am drawing on it every time I review a generated function and know which questions to ask.
What I think is actually changing is what “engineering” means. The job used to be: understand the problem, design the solution, implement the implementation. The implementation part was where you learned the most about whether your design was correct, because the moment you tried to write something you discovered the five things you had not thought through.
Now the implementation is faster and the feedback on your design quality comes through review rather than through writing. That is a real change. Whether it makes the discipline stronger or weaker over the next decade depends entirely on whether developers stay curious about what is happening inside the code they accept, or whether they stop asking.
I have not stopped asking. I am just aware that the temptation to stop is much more available than it used to be.
Then I Asked Myself an Uncomfortable Question
What happens if the subscription lapses?
Card declined. Company policy change. The provider shuts down the tier I rely on. Claude Code hits a rate limit at 11pm the night before a deployment. Whatever the reason, the tools are gone and I am staring at a blank file.
My gut answer was immediate: I would struggle.
Not because I have forgotten syntax. I can still write a Laravel service class from scratch. I still know what a query scope does and why you would use one. The foundational knowledge has not evaporated. But the speed, the confidence, the willingness to just start typing without knowing exactly where the function is going. That muscle has softened. I have been letting the AI do the first draft for long enough that sitting down to be my own first draft feels heavier than it used to.
That is not a theoretical problem. That is a real one.
I have worked through enough production incidents to know that the moments when the tools fail and the pressure is highest are exactly when your raw ability matters most. A server is down. The client is calling. You cannot wait for a model to generate a fix because the model is suggesting something plausible but wrong and you do not have twenty minutes to iterate toward correct. You need to read the stack trace, know what it means and write the fix. That is still a human job.
The dependency is not just psychological either. AI tools are billed monthly. They have rate limits. They go down. The model runs out of room at the worst possible moment. Any tool you cannot afford to lose should not be the thing your entire output depends on. Not in a client engagement. Not in production support. Not in a one-person practice where there is no one to cover for you.
I am not saying stop using the tools. I am saying: test yourself without them occasionally, on purpose, before the test becomes involuntary. Write a non-trivial feature by hand once in a while just to find out where your thinking still holds and where it has gaps. The answer will be informative in a way that no amount of AI-assisted output can substitute for.
My gut says I would struggle. My gut is probably right. The question is whether I am going to do something about that before I find out the hard way.
If you are using AI tools heavily and you cannot explain why a generated function works, not at the level of “it passed the tests” but at the level of what it is actually doing and why, that is worth paying attention to. The tools are not the problem. Accepting output without understanding it is.
