I have a habit of asking people when they discovered AI. Not ChatGPT specifically. I mean the moment when this whole thing stopped being another technology story and actually entered their work.
I ask it on calls. I ask it over coffee. I ask potential colleagues and people whose work I find interesting.
The answers are surprisingly revealing. And developers deserve their own category.
Their journey has often been longer, more painful and considerably funnier than everyone else’s.
I recently read Brett Terpstra’s post I’m done using AI, which is perhaps the purest specimen I’ve found of this progression. He has been programming for 20 years and describes going from dismissing Copilot as useless, to having Claude Code build a non-trivial project from Linear tickets without him editing a single line, to wondering whether he should become an electrician.
His conclusion is considerably more anti-AI than mine. He ultimately stopped using it entirely because he felt it was making him a worse programmer, distancing him from his work and damaging his mental health. But the journey itself is almost archetypal.
After enough conversations with developers, I think it has roughly five stages.
Stage One: This Thing Is Shit
Our developer first encounters GitHub Copilot in Visual Studio Code. It’s autocomplete on steroids.
You type: function sortNames and suddenly a ghost appears suggesting the rest. Interesting. He tests it. The suggestion contains a bug.
He strokes his beard, says something unprintable about JavaScript programmers and disables the extension. Case closed. Computers remain stupid.
Brett describes almost exactly this first encounter: Copilot felt distracting and basically useless. Around the same time, somebody at work discovers ChatGPT. They ask it to fix a relatively straightforward software problem. ChatGPT confidently recommends a version of a library.
Small complication: that version doesn’t exist.
It cannot be installed. It cannot fix anything. Excellent.
Our developer now has empirical evidence for his original position.
AI is autocomplete for people who don’t know what they’re doing.
Stage Two: The Virus Spreads
Then management hires someone who is really into AI. Usually product. This person begins submitting code changes generated by LLM tools while having only a partial understanding of what those changes do to the broader system.
Every meeting suddenly contains the phrase:
“How can we add AI to this?”
Nobody knows why the customer needs AI in the expense-reporting dashboard, but this is apparently beside the point.
Our developer watches the infection spread through the organization. Meanwhile, he continues doing actual work. Writing tests. Building features. Debugging things. Understanding the system. Enjoying programming.
Brett literally describes watching AI “spread like a virus” through his organization while he continued coding as he had for decades. Then other engineers start using Cursor. Tab. Tab. Tab.
Sometimes they ask the model to change something directly inside a file. Our hero watches. Fine. It’s neat. Almost magical. But it works mostly at file scale, and nothing is going to separate this man from Neovim and tmux.
He already types quickly. Why exactly does he need this?
Stage Three: Fine, I’ll Try the Damn Thing
Early 2025.
Management asks:
“What do you think about this AI coding stuff?”
Our developer gives the technically correct answer:
“It’s often wrong, gets in my way and doesn’t make me code faster, so I don’t use it.”
Management then attends a conference. This is an important step in every corporate technological revolution. They return having learned that AI will transform everything we know about knowledge work.
Shortly afterward comes the message:
Use AI or get left behind.
Our developer is not delighted. But he isn’t stupid either. So he tries Cursor. Doesn’t like it. It runs terribly on Linux.
Then Zed. Something clicks. There’s a chat window on the side. You explain what you want. The model edits the code. It builds the software.
You ask questions about the repository. It answers. And suddenly the stupid autocomplete has become something else.
Brett describes this moment simply: it “honestly felt magical.”
This is usually the dangerous stage. Because now the skeptic has seen it work.
Stage Four: Wait, Why Am I Writing Code?
By mid-2025, autocomplete is already becoming the boring part.
The interesting thing is agentic coding. Models get better. Harnesses get better. Context gets larger. Agents navigate repositories, run tests, inspect errors, use terminals and iterate.
The unit of delegation changes.
First: complete this line.
Then: write this function.
Then: change these five files.
Then: fix this bug.
Then: here’s the ticket.
And somewhere during 2026 our composite developer connects the task tracker directly to Claude Code.
Claude takes a non-trivial project. Works through it. Builds the thing. Tests it. Finishes. Our developer doesn’t edit a line. And, annoyingly, it finishes faster than he would have.
Brett reached almost exactly this point. He connected Linear to Claude Code and watched it build a non-trivial project from beginning to end. He barely had to think.
This is the moment when the original argument collapses.
The question is no longer: Can AI write good code?
Clearly, under the right conditions, yes.
The new question is much worse. What exactly am I here for?
Stage Five: Should I Become an Electrician?
And then comes the existential crisis.
Our developer realizes his workflow increasingly looks like this: Linear ticket enters. Agent works. Code comes out. Another agent reviews it. Tests run. Human checks a few things. Ticket closes. Repeat.
At first this feels extraordinary. Look at the productivity!
Then one afternoon he notices that he has become an unusually expensive biological router between Jira and a command line.
Brett puts the problem very clearly. He found himself increasingly reduced to code review and QA for enormous quantities of AI-generated code, while feeling less connected to the software itself. Eventually he wondered whether software engineering would exist in a few years and whether he should “go become an electrician or something else entirely.”
There it is. The electrician stage.
The final stage of AI grief. Denial. Anger. Bargaining. Agentic coding. Electrical certification.
Where I Disagree
Brett’s response was to stop. He concluded that AI was making him lazy, making him care less about the software, preventing him from learning and ultimately making him a worse programmer. Going back to programming games by hand reminded him why he had loved coding in the first place.
I think this is a legitimate response. But I don’t think it’s a scalable answer for the profession.
The uncomfortable part is that both things can be true simultaneously:
AI can make software development dramatically faster. And AI can remove many of the activities that made software development satisfying. That’s not a contradiction.
Industrial technology has been doing this to crafts for several centuries. The problem is that software developers assumed they were operating the machines. It turns out they were also artisans.
Programming and Software Engineering May Be Separating
I think we’re beginning to confuse two different things.
Programming is an activity.
You understand a problem, construct an implementation, wrestle with constraints, debug it, improve it and gradually build a mental model of the system. That can be deeply satisfying.
Software engineering is an economic function.
The company needs reliable software that solves a problem at an acceptable cost. These goals overlapped beautifully for decades because humans were required to write the code.
AI is beginning to separate them. A person may still love programming in exactly the same way someone loves woodworking. That doesn’t guarantee companies will continue paying large teams to manually type every implementation. And companies may produce much more software while individual engineers write considerably less code.
That’s the part I think many developers are actually mourning. Not employment yet.
The craft.
The Skill Is Moving Up the Stack
I don’t think the answer is to become a faster typist than Claude. That competition has an obvious ending.
The more interesting engineering skills increasingly become: choosing architectures, understanding systems, specifying behavior, designing constraints, building evals, debugging failures, orchestrating agents, reviewing outcomes, and deciding what should exist in the first place.
Ironically, this requires understanding software more, not less.
If you don’t understand the system, you can’t tell when twenty autonomous agents have collectively produced a beautifully tested catastrophe.
The dangerous developer isn’t the person who doesn’t use AI. It may increasingly be the person who uses AI extensively but has never developed enough engineering judgement to know when it’s wrong.
So I Keep Asking the Question
When I ask developers: “When did you start using AI?”
I’m not really interested in whether the answer is November 2022 or March 2025.
I’m trying to locate them on the curve.
Still laughing at hallucinations? Using autocomplete? Using agents occasionally? Delegating entire tickets? Running multiple agents? Building systems where agents review other agents? Or staring quietly at Claude Code while reconsidering several decades of career decisions? Because almost everyone seems to travel through some version of the same journey.
They just started at different times. And increasingly, when an experienced developer tells me they’ve been using coding agents seriously for a while, there’s one question I really want to ask:
Have you thought about becoming an electrician yet?