People sometimes ask if I’m worried that AI will put me out of a job. My honest answer is no, not really.
In fact, I’ve been here before.
The first time the machine out-coded me. #
When I graduated in the 90s, assembly language was still a respectable skill. I wrote most of my code in C, but there was always that one tight loop or fiddly routine where a bit of hand-tuned assembler felt like wizardry. I was working in embedded systems, targeting a single CPU and we wanted every cycle to count.
And then compilers got good. Really good. I’d write a neat little C function, run it through the compiler, and the generated assembly would do things I’d never have thought of. Loop unrolling, instruction scheduling, register allocation that felt like black magic.
That was the first time I realized a truth that keeps resurfacing in this industry.
The machine will always get better at the mechanical part of the job.
Moving off-shore. #
In the early-to-mid 2000s, I consciously walked away from embedded systems. I still enjoyed it but I could see the ground shifting under my feet. The kind of work I was doing was moving to India and China, but more than that, embedded systems themselves were no longer a distinctive skill.
Say a company has some code that’s just a little too large for the memory on their board.
Option A: Hire this Bill fella who will spend days shaving bytes off a ROM image, hand-optimizing code paths and packing structures like a Victorian watchmaker.
Option B: Put a slightly larger ROM on the board. (The increased cost of the slightly bigger chip would be a rounding error on the bill of materials.)
I was never going to win that battle.
So I moved up the stack. I learned C# and SQL and moved into systems, services, distributed computing and architecture. The work changed but the underlying thinking didn’t.
And that’s why AI doesn’t scare me. I’ve already reinvented myself before when the ground moved.
Telling sand to do mathematics #
As programming environments improved, other once-valuable skills quietly evaporated too.
I haven’t written my own collection classes in decades. Why would I? The standard library versions are faster, safer and better tested than anything I’d produce on a Tuesday afternoon.
Another old friend is drifting toward the same fate, SQL. These days, I let ORMs write queries for me. SQL isn’t disappearing. It’s just becoming ambient, just as assembly did. So what’s left when programming itself becomes automated?
This is the part people get wrong. They assume that my job is writing code, but that’s never been true. No one ever paid me to write assembly language. No one pays me to write C# or SQL. They pay me to be a software engineer.
New-Bill. #
I’ve joked with my team lead that if he ever thinks an AI could do a better job than me, he should absolutely make me redundant and spin up a new instance of Copilot or Claude called “New-Bill”.
But here’s the catch. New-Bill wouldn’t know what problem to solve. New-Bill wouldn’t know the constraints, the politics, the history, the scars. New-Bill wouldn’t know why the system is shaped the way it is, or which decisions were deliberate and which were accidents we’ve learned to live with.
New-Bill could generate code, but can’t generate judgment.
The things that matter survive every wave of automation. Understanding requirements, including the ones stakeholders don’t know they have. Designing systems that survive contact with reality. Making trade-offs under uncertainty. Debugging real-world failures.
These are not tasks you can outsource to a machine.
Programming itself is becoming the new assembly language. Something the machine can do better than we can. But that’s fine. The job isn’t going away but moving up a level.
If a machine can write my C# for me, good. If it writes 80% of my code, fantastic! That frees me to focus on the 20% that actually requires engineering judgment. The job was never to “write code”, but to make stuff that works. AI handles the typing.
Credits
📸 “Hugs, One Dollar” by me.
📸 “Toucan” by Bernard Dupont. (Creative Commons)