I've been writing software professionally for about ten years — the last eight of them in healthcare technology, and the most recent stretch leading the engineering, DevOps, and AI teams behind a claims platform.
That's not a long career by industry standards. It is long enough to have watched one complete cycle of a tool arriving, being declared the end of the profession, and settling into being a tool. So when people ask whether AI has made software engineering obsolete, I have a specific, unromantic answer.
The Part That Got Faster
I want to be honest about this first, because there's a genre of essay that defends craftsmanship by pretending the new thing doesn't work. It works.
The mechanical parts of my job have got dramatically faster. Boilerplate. Test scaffolding. Translating a well-understood pattern into a language I use less often. Reading an unfamiliar codebase and getting an orientation in minutes instead of an afternoon. The first draft of almost anything.
I build things now I wouldn't have started before, because the cost of finding out whether an idea works has dropped enough to change what's worth trying. That's not a small change and I'm not interested in downplaying it.
The Part That Didn't
What hasn't changed is the part of the job that was always the hard part.
Knowing what to build. Deciding which of three reasonable designs will still be reasonable in two years. Recognising that a requirement as stated will produce something technically correct and operationally useless. Understanding why a piece of code is strange — and whether the strangeness is a bug or a business rule nobody documented.
In claims processing that last one comes up constantly. Code that looks wrong frequently encodes something real: a payer that behaves differently, a regulation that changed, an edge case discovered expensively. A model reading that code sees an oddity to clean up. Knowing which oddities are load-bearing is not available in the diff.
None of that got easier. If anything it got more important, because the cost of producing code fell and the cost of producing the wrong code fell exactly as fast.
The New Failure Mode
The thing I actually watch for in my teams isn't people being replaced. It's confidence outrunning understanding.
Generated code is plausible. Plausible is a dangerous property — it passes a glance, reads idiomatically, and is occasionally wrong in ways that don't look like mistakes. In a domain where an error means a denied claim or a delayed payment to a provider, "looked right" is not a standard.
So the discipline I care about is the same one that always mattered, applied harder: can you explain why this works? Not "does it pass" — why. If nobody on the team can answer that for a piece of code in production, you have a liability regardless of who or what wrote it.
This is why I've been more interested in tests, static analysis, and progressive delivery over the last year than in any model. The volume of code a team can produce went up. The team's ability to verify it has to go up with it, or the two diverge and you find out from a customer.
What I Tell Engineers
Learn the fundamentals anyway. Not out of nostalgia — because they're what lets you evaluate a suggestion. An engineer who understands transactions, indexing, memory, and concurrency can look at generated code and tell whether it's right. One who doesn't is copying with extra steps, and the gap between those two people is widening, not closing.
Get good at judgement. The scarce skill was never typing. It's deciding what deserves to exist, what to simplify, what to refuse. That skill has appreciated.
And stay curious about the tools. The engineers doing the most interesting work right now are not the ones refusing to use this, and they're not the ones using it uncritically either. They're the ones who treat it as a capable colleague whose work still gets reviewed.
Where I've Landed
The craft isn't dead. The proportion of it spent producing code has shrunk, and the proportion spent on judgement, verification, and deciding what's worth building has grown.
That's a better job, honestly. The tedious parts are more tedious in retrospect than they felt at the time, and I don't miss them. What's left is the part I liked anyway.
Ten years in, the tools look almost nothing like they did when I started, and the hard parts look exactly the same.
