LLM Inevitabilism

In the 90s a friend told me about the internet. And that he knows someone who is in a university and has access to it and can show us. An hour later, we were sitting in front of a computer in that university and watched his friend surfing the web. Clicking on links, receiving pages of text. Faster than one could read. In a nice layout. Even with images. And links to other pages. We were shocked. No printing, no shipping, no waiting. This was the future. It was inevitable.

Yesterday I wanted to rewrite a program to use a large library that would have required me to dive deep down into the documentation or read its code to tackle my use case. As a first try, I just copy+pasted the whole library and my whole program into GPT 4.1 and told it to rewrite it using the library. It succeeded at the first attempt. The rewrite itself was small enough that I could read all code changes in 15 minutes and make a few stylistic changes. Done. Hours of time saved. This is the future. It is inevitable.

PS: Most replies seem to compare my experience to experiences that the responders have with agentic coding, where the developer is iteratively changing the code by chatting with an LLM. I am not doing that. I use a "One prompt one file. No code edits." approach, which I describe here:

https://www.gibney.org/prompt_coding

The problem with LLM is when they're used for creativity or for thinking.

Just because LLMs are indeed useful in some (even many!) context, including coding, esp. to either get something started, or, like in your example, to transcode an existing code base to another platform, doesn't mean they will change everything.

It doesn't mean “AI is the new electricity.” (actual quote from Andrew Ng in the post).

More like AI is the new VBA. Same promise: everyone can code! Comparable excitement -- although the hype machine is orders of magnitude more efficient today than it was then.

I don't know about VBA, but spreadsheets actually delivered (to a large extent) on the promise that 'everyone can write simple programs'. So much so that people don't see creating a spreadsheet as coding.

Before spreadsheets you had to beg for months for the IT department to pick your request, and then you'd have to wait a quarter or two for them to implement a buggy version of your idea. After spreadsheets, you can hack together a buggy version of your idea yourself over a weekend.

Right. Spreadsheeds already delivered on their promise (and then some) decades ago, and the irony is, many people - especially software engineers - still don't see it.

> Before spreadsheets you had to beg for months for the IT department to pick your request, and then you'd have to wait a quarter or two for them to implement a buggy version of your idea. After spreadsheets, you can hack together a buggy version of your idea yourself over a weekend.

That is still the refrain of corporate IT. I see plenty of comments both here and on wider social media, showing that many in our field still just don't get why people resort to building Excel sheets instead of learning to code / asking your software department to make a tool for you.

I guess those who do get it end up working on SaaS products targeting the "shadow IT" market :).

Software engineers definitely do understand that spreadsheets are widely used and useful. It's just that we also see the awful downsides of them - like no version control, being proprietary, and having to type obscure incantations into tiny cells - and realise that actual coding is just better.

To bring this back on topic, software engineers see AI being a better search tool or a code suggestion tool on the one hand, but also having downsides (hallucinating, used by people to generate large amounts of slop that humans then have to sift through).

> It's just that we also see the awful downsides of them - like no version control, being proprietary, and having to type obscure incantations into tiny cells

Right. But this also tends to make us forget sometimes that those things aren't always a big deal. It's the distinction between solving an immediate problem vs. building a proper solution.

(That such one-off solution tends to become a permanent fixture in an organization - or household - is unfortunately an unsolved problem of human coordination.)

> and realise that actual coding is just better.

It is, if you already know how to do it. But then we overcompensate in the opposite direction, and suddenly 90% of the "actual coding" turns into dealing with build tools and platform bullshit, at which point some of us (like myself) look back at spreadsheets in envy, or start using LLMs to solve sub-problems directly.

It's actually unfortunate, IMO, that LLMs are so over-trained on React and all kinds of modern webshit - this makes them almost unable to give you simple solutions for anything involving web, unless you specifically prompt them to go full vanilla and KISS.

I'm constantly surprised that no one has mainstreamed version control. I see so many cases where it could be applied: document creation and editing, web site updates, spreadsheets ... even the way that laws are amended in Parliament [1]

[1] https://www.gov.uk/guidance/legislative-process-taking-a-bil... https://www.gov.uk/government/publications/amending-bills-st...