How my job as a developer has changed
I write less code than I used to and read a lot more of it. What AI has actually changed in my working day, and what it hasn't touched.
Three years ago, if someone had described my current working day to me, I would only half have believed them.
On the surface not much has changed. I still open the editor first thing in the morning. I still answer client emails. I still lose an afternoon now and then to a bug that turns out to be one wrong character. What has changed is where the hours go, and I think that’s worth writing down honestly, without the hype and without the gloom.
I read more code than I write
For most of my career, the bulk of the work was typing: functions, tests, queries, UI components. These days an assistant drafts a large share of that, and my job is to read it.
That sounds like a small shift. It isn’t. Reading other people’s code used to be the thing you gave the new hire on day one (“have a look around the codebase”). Now it’s most of what I do, and the questions are always the same. Is this actually right? Does it hold up when the input is odd? Does it fit the rest of the system, or does it just look like it does?
Developers who were already good readers have a head start. Those who wrote great code but found other people’s hard going have some catching up to do.
Asking well is half the job
An assistant always gives you an answer. That’s the useful part and the dangerous part. Ask something vague and you’ll get something plausible and wrong, delivered with exactly the same confidence as a correct answer.
So more of my time now goes into the bit before any code exists: working out what is really needed, splitting the problem into pieces that make sense, being clear about the constraints. That was always the core of the job. It used to be buried under the typing. Now it’s out in the open, because a sloppy request shows up in the result straight away.
The time I save doesn’t disappear
I expected the time saved to turn into shorter days. It didn’t. It moved somewhere else.
I spend more time with the people who will use the software. I write more tests, because they’re cheap now. I finally tidy up the part of the project I’d been putting off for months. I reread things calmly before a release instead of rushing.
The result is that projects don’t just go faster. The repetitive parts go faster, and the parts that matter get more attention. That’s when it’s used well, anyway.
What hasn’t changed at all
Plenty of things AI hasn’t touched. The client who needs someone to explain, in plain words, what they’re paying for. The bug that only appears in production on a Friday afternoon. The meeting where you discover the real process is nothing like the one you were told about. And the responsibility, when something breaks, to understand what happened and put it right.
That was the job before, and it’s the job now. If I’m honest, it’s also the part I find most interesting.
Moving up a level
If I had to put it in one line: the work is shifting up a level. Less time on individual lines, more on the system, the people and the decisions.
We’ve been here before. High-level languages, frameworks, open source libraries, Stack Overflow: each time, someone announced that programming was about to become trivial. Each time, the job changed and we ended up needing more good people, not fewer.
I can’t tell you what it will look like in five years. I can tell you I still enjoy it, maybe more than I did before.
Thinking about bringing AI into your development team’s work, or into software you already use? Let’s talk in a 20-minute call. Book the call.