How AI Stole My Job

The progress of technology over the course of my life has been stunning and the progress of LLMs is vastly outpacing even those previous decades of exponential progress. It’s wild!

In the past two to three weeks, my entire approach to coding has been completely upended.

To the point that it’s hardly even the same job. AI stole that job right out from under me.

I have transitioned from a job meticulously crafting individual line of code to a new job, meticulously crafting instructions for an AI agent.

Prior to my experience with agents, I was already a big fan of chat-based LLMs and less nervous about the accuracy and quality of their results than the general public; or even my peers, probably. I’ve had good success using ChatGPT as a search engine for random low stakes question, and surprising results using it for interpersonal advice.

But even with a couple of years of experience chatting with GPTs, I have been totally blown away by what comes out of the other end of the AI black box. .

Prompt Engineering

So what is my new job? Am I a prompt engineer now?

Maybe, but my current workflow feels more like I’m managing a remote teammate. That teammate just happens to be Claude Code; and we chat in a TUI rather than Slack.

My workflow

Write a short paragraph describing a high-level task based on business requirements.
Feed this task a GPT that I built which asks me questions like a junior engineer and spits out a fully formed Jira story based on my answers to those questions.

At this point, any human developer including myself would be able to work this ticket however they want.
Copy & Paste the description from step № 2 into Claude Code.

Occasionally, I may need to include additional context about related tickets. I’ll accomplish this by pointing to a git branch for that ticket, copy & pasting in that full ticket, or just summarizing it in a few words.

But usually everything relevant is already in the story.
Wait for Claude to do its thing (usually 5 – 20 minutes).
Review the diff of the code it’s written.

I’ve found that if it makes odd choices or assumptions, these mistakes are often propagated across multiple files. So the easiest way to correct them it with a subsequent prompt. Claude Code is incredibly good at search & replace for entire ideas.
Once it looks good, I have Claude write a commit message and push to github.

Results

With this process, I’m able to complete large, fully functional features — the kind that used to take 2–3 days, maybe even a full week — in 1 day or less.

And since a lot of this time is spent waiting for Claude to generate, it frees me up to plan the next feature, review open pull requests, attend meetings, or whatever.

Sometimes I’ll kick off a task and step away — take a breath of fresh air, go for a quick walk, or grab lunch — and come back to a ready-made diff. That kind of asynchronous collaboration with an AI assistant isn’t just productive, it’s honestly kind of delightful.

All things considered, it feels like a 3-4x productivity gain. Realistically? Probably closer to 2x.

Some Fails

My experience so far have been overwhelmingly positive but for the sake of completeness, I should mention a few of the issues I’ve been running into:

It’s very hard to get it to consistently follow instructions.
- I’ve got in the habit of updating the project’s CLAUDE.md whenever something isn’t quite right. But still it will randomly disregard those instructions.
One time, it wrote a series of “TODO” comments rather than actually doing the work. 😆
It often gets into testing or code-quality loops, constantly refining code and re-running testing tools.
- It doesn’t seem to know how to code that conforms to quality standards. The fact that it does, almost seems to be a coincidence.
- Similarly, it doesn’t seem to know how to write tests that will pass. Sometimes it just does.
- At the end of the process, the results are fine. But the process is quite disconcerting.

That’s about it.

And I fully expect these issues to be resolved in the next 3 – 6 months.

Post.Script.

Code is not art.

…it’s certainly not poetry.

Software development is unlike some of the other professions that are seeing real disruption in 2025.

Unlike visual arts, writing, journalism, etc. my career as a software developer has always been a collaboration between me and the rest of the world.

Web developers are expected not only to draw inspiration from the universe of open source code but also to learn by reuse — by literally copy & pasting, then tweaking and re-configuring. We’re discouraged from reinventing the wheel.

The idea of plagiarism doesn’t really make sense in the context of code. Unlike art, copying someone else’s style is a requirement of the job.

So what separates seasoned developers from a junior, has little do with the raw code. It’s more the ability identify problems and select the appropriate approach, anticipate edge cases; and probably most importantly communicating with non-engineers.

Writing good clean code is only a very small fraction of the job. And I’ll admit, as I’m coming up to my 25th year writing code for money, it’s a part of the job that’s become the least interesting to me.

If I can tell a robot to do the boring parts and focus on the other parts, I’m here for it. Personally.

Broadly though, software engineering is uniquely positioned to be sort of immune to prospect of being replaced by AI.

Job Security

The way that AI is poised to disrupt writing code is more directly similar to productivity improvements of the past centuries. Pick your favourite example: the loom, internal combustion, the spreadsheet, etc.

The same number of people currently writing code will be able to produce 2 or 3 times more; and theoretically this should increase wages.

The Future of Writing Software

I have more thoughts and questions about the future of software development, than I do answers.

Do kids coming up in school right now need to learn how to code?
- Probably not.
The “junior engineer” role as we know it will probably disappear.
- It’s likely possible that a 20-something who has grown up using AI tools will be just as capable of building software to accomplish goals as I am after all these years.
If junior engineers don’t really need to learn how to write code and senior engineers are talking to AI instead of writing code, do we even need programming languages?🤯🤯🤯
- Why not just have AI write assembly directly?
- As long as we’re confident that the AI is telling the truth about what the code does and what it’s doing to it, does it matter if a human can’t read it?
  - We’re not there yet, but I’d bet we will be in a year or less.
- In the human reviews of my own AI-assisted code, I’m strongly encourage my teammates to take a light touch when it comes to style and specific choices.
We might not need teams of engineers anymore.
- In the past week, I’ve produced the same amount of code that would have taken my previous team of the approximately the same amount of time.
  - The main productivity gain in this regard is the fact that Claude is able to work with larger chunks of code at once. Claude’s ability to “find & replace ideas” gives me the confidence to work with massive refactors across many files. With results complete in 5 or 10 minutes.
  - My biggest blocker to productivity at the moment is finding a teammate with time to review my massive PRs.

Conclusion

Interesting times ahead.