I don’t remember much fear that spreadsheets were going to replace programmers. What I remember more was a kind of simmering contempt for them, though time may be sanding the edges off that memory.
From the IT side, spreadsheets and later spreadmarts were a completely understandable headache.
The business needed solutions, and IT often couldn’t deliver fast enough. A lot of that was structural: IT was usually treated as a cost center, underfunded, and forced through layers of process and overengineering. So even small things could take too long, cost too much, and come wrapped in too much ceremony.
So the business used spreadsheets because they were powerful, flexible, and already there.
The real problem came later. Business process, business data, and domain knowledge ended up trapped inside undocumented spreadsheets living on someone’s PC. Out of sight, out of mind, and effectively unmaintained.
Then Joe retired, quit, or got laid off, and suddenly some weird but critical business function stopped working because Joe always did it and it lived on Joe’s machine.
That was the nightmare. The same IT group that didn’t have the time or resources to meet the need in the first place now had to reverse engineer a giant kludgy spreadsheet and somehow turn it into something supportable.
Which is part of why the current AI moment feels familiar to me. Not because AI is the same thing as a spreadsheet, but because the adoption pressure comes from the same places: businesses want to save money, people need to get their work done, and they will reach for whatever is powerful, available, and fast enough.
And just like with spreadsheets, some of what gets built this way will be genuinely useful, some of it will become invisible infrastructure, and some of it will turn into a future headache for whoever has to untangle it later.
I don’t think the lesson from spreadsheets was that end-user tools replaced professional software. It was that when the official path is too slow, too expensive, or too disconnected from the real need, people route around it. AI looks to me like the same pattern on a much larger scale. The hype says panacea. Reality will probably be messier.
I’m building a blackjack simulator/research tool called Blackjack Wonk. It started as a hobby project and turned into a deeper engineering rabbit hole than I expected. The goal is to make the simulations reproducible and trustworthy enough to test the kinds of blackjack questions that usually get answered with rules of thumb, anecdotes, or forum arguments. So a lot of the work is around deterministic runs, validation, configuration, and chasing down small discrepancies until I understand them. Very niche, but a fun mix of math, software, and curiosity.
I never even thought about that post being anything but legit, why? Because I agree with it, and no matter WHAT my wife and kids might occasionally say, I am no AI :)
I haven’t thought about it, but I just feel that the topic of ai might hit someone my age differently than someone who is building their career rather than coming to the close of it. To someone who is genuinely threatened by the advent of ai (and I don’t say they are wrong) anyone like me who is enjoying the experience of learning how to use it may be mystifying. But at least in my view it’s understandable,
In most respects I consider myself a Luddite, or maybe a neo-Luddite. I think a lot of that comes from the constant business push for “new” and “faster” for no reason other than that they’re new and faster.
But I’ve used both Claude and Codex for more than a year now, and while they can still be amazingly frustrating, they also keep getting better. Since the projects I work on now are my own, I like being able to work with these tools almost the way I’d work with a smart but inexperienced junior programmer—useful, capable, sometimes surprising, and still needing guidance.
To me, it still takes skill, domain knowledge, and programming knowledge to get meaningful results. What it can remove is not the need to think, but a lot of the hours spent pounding out code.
I understand the sense of loss some people feel when they talk about the art of programming. But no one is stopping them from opening their IDE and doing it the old way. For my part, I enjoy seeing my ideas come to life with less sweat. I’ve done plenty of sweating alrea
I don't know where you are in your career, me I am on the backend. But all the time I was working the constant churn of new tools/languages/frameworks and so on, the race to keep up with the vendors just wore me out. And despite all that, building software honestly never changed much.
I have been working with both Codex and Claude, and you are right, you can't trust them. My best practice I have found is constantly play one off against the other. Doing that I seem to get decent, albeit often frustrating results.
Yes, the actual building of the code is either over, or soon to be over. The part that I always considered the "art." I often found code to be beautiful, and enjoyed reading, and writing, elegant code all the time I was working with it.
But the point of code is to produce a result. And it's the result that people pay for. As you mentioned with the evolution of development in your original post, the process and tools might have changed, but the craftsmanship in operation with those using them did not.
You make a fair point that this abstraction is different — prior layers were engineered and traceable, and an LLM output isn't. But I'd argue that makes the human in the loop more important, not less. When the abstraction was deterministic, you could eventually lean on it fully. When it isn't, you can never fully step away. That actually protects the craft.
Until AI becomes a "first mover" god forbid, where there is no human in the chain from inception to product, there will always be a person like you who knows where the traps are, knows what to look out for, and knows how to break a problem down to figure out how to solve it. After all, as I have always said, that is all programming really is, the rest is just syntax.
From the IT side, spreadsheets and later spreadmarts were a completely understandable headache.
The business needed solutions, and IT often couldn’t deliver fast enough. A lot of that was structural: IT was usually treated as a cost center, underfunded, and forced through layers of process and overengineering. So even small things could take too long, cost too much, and come wrapped in too much ceremony.
So the business used spreadsheets because they were powerful, flexible, and already there.
The real problem came later. Business process, business data, and domain knowledge ended up trapped inside undocumented spreadsheets living on someone’s PC. Out of sight, out of mind, and effectively unmaintained.
Then Joe retired, quit, or got laid off, and suddenly some weird but critical business function stopped working because Joe always did it and it lived on Joe’s machine.
That was the nightmare. The same IT group that didn’t have the time or resources to meet the need in the first place now had to reverse engineer a giant kludgy spreadsheet and somehow turn it into something supportable.
Which is part of why the current AI moment feels familiar to me. Not because AI is the same thing as a spreadsheet, but because the adoption pressure comes from the same places: businesses want to save money, people need to get their work done, and they will reach for whatever is powerful, available, and fast enough.
And just like with spreadsheets, some of what gets built this way will be genuinely useful, some of it will become invisible infrastructure, and some of it will turn into a future headache for whoever has to untangle it later.
I don’t think the lesson from spreadsheets was that end-user tools replaced professional software. It was that when the official path is too slow, too expensive, or too disconnected from the real need, people route around it. AI looks to me like the same pattern on a much larger scale. The hype says panacea. Reality will probably be messier.