I’m of a similar, maybe slightly older, vintage as you having started in the mid 1980s on a VIC-20, then the C-64 (though I had access to Atari 400/800 and Apple ][+). And I loved programming back then… BBS software and admittedly simple games. Writing programs was liberating and taught me some ways to think about how things piece together that I’m not sure I would have learned as early or as well otherwise. I founded local a computer club, did a little hacking (ok, maybe a lot), found peers locally and across the country all before “the internet” was readily available to retail consumers.
I like that today I don’t write as much code and more that I can get certain tasks done that I simply would have avoided in the past because they were beyond my skill or domain knowledge. But when you look back at that history you need to recognize that what programmers did and even what a programmer is hasn’t been static until LLMs showed up. Back in the C-64 days, I could understand the entire machine: the manual that was included in the box not only told you how to turn it on, but also had a programming guide with addressable system functions and even a schematic diagram of the computer. Back then my programming didn’t have anything to do with what I would have considered “boilerplate”… hell, there wasn’t room for it. And for awhile new computers simply meant more powerful versions of that same model… you could get more done, faster, while keeping that whole-machine model inside your head.
At some point though programming became increasingly about layering abstractions on top of ever deeper abstractions. Sure, back in the old days we had BASIC which was an abstraction, and even Assembly wasn’t pure machine code, but it only strayed so far from what the electronics could do: it was very different. Today which abstractions are chosen (language, libraries, frameworks) and how to use them “correctly” injects a level of “fashion sense”, disconnected from the colder, logical world of the original home computers. The social interactions evolved, too, from mostly sharing tips on how I solved a certain challenge in -my- program with others writing different programs to now having to collaborate with others with competing visions in how to write the same program. Programming evolved to become about accessing other’s abstractions much more than engaging with my own abstract thinking over the machine.
Hell, even MIT doesn’t teach SICP anymore because the nature of what a programmer does, and even who a programmer is, changed. And all of this before LLMs arrived on the scene.
So there are certain programming tasks today that I very much enjoy. But so much of it is just trying to coax a library or framework into doing what I want… and having that go many layers deep, that it can be more frustrating than enjoyable. So I completely understand the desire to have the LLMs, which, machine qua machine, are better equipped to deal with the degree of library-trivia we need to know than we humans are, do much of this dealing with programming tasks today.
I think this is on the right track overall, but I think overemphasizing “the stochastic parrot” aspect undersells what capabilities actually exist in misleading ways. For example, it use to be that LLMs would use that token generation process to answer calculated answers and not do very well: now they’ll typically write a program in python which calculate the answers. In the end I find that the most recent results can be much better than mediocre. Not all the time, not without good guidance… but consistently enough that I absolutely include LLMs in my toolkit and I pay much attention how best to use them.
Just over a week ago, I had a 4 hour training session I had to conduct for 25 supply chain professionals concerning automated inventory replenishment tools and my slide deck needed work still the morning of the presentation. So early that morning I jump into the self-driving taxi that’s taking me to the airport, fire up the laptop and my mobile hot spot… the car already knew to stream my work-music playlist… and finish it up. Finishing it up meant having my coding LLM (Claude) verify certain facts and assertions that I was making in the presentation, or facts I hadn’t yet added to the presentation, and giving me back plain English descriptions/verifications/or corrections. I would then hand that off to CoPilot which could manipulate the power point directly while keeping good style and such. The LLMs did this work very well, with guidance, but very well. Of course the car wasn’t an LLM, but it got me to the airport on time, without distraction and provided a smooth ride to boot. It felt like “living in the future”, and it felt good with new opportunities waiting.
I found the video below to be a really compelling and fair take, along the lines you’re taking, on understanding the bigger picture of LLMs which (interview with Gary Marcus, cognitive scientist/professor emeritus NYU/founder of machine learning company Geometric Intelligence):
In the end I guess I’d say that I do pay attention to how LLMs are changing my role and I don’t look at that change as either good or bad: just unavoidable. The kind of programming I loved, and the people I was social with in that endeavor, became something very different (for the most part) long before LLMs, so I don’t get depressed over that loss, I find some trepidation over feeling that I haven’t yet figured out my correct role, but I can see some new, compelling paths forward, paths that might not have been open to me without LLMs, so there’s some hope, too.
But I’m definitely still figuring it all out. The key is not fear it… that’s not a winning strategy… not try to stop it… I’m pretty convinced that battle is already lost… it’s recognize what it is, what it isn’t, and how it’s evolving and respond appropriately.
