Llms

A few weeks ago I wrote about an issue in the book ‘Empire of A.I.’ by Karen Hao. There is now a much more in-depth look into this issue by Andy Masley. It includes a response from the author and Andy’s response to that response is well worth reading even if you don’t read the main (very detailed) post. I think both are writing in good faith here, it must be terrible to work on a book only to find you have published an error, which does seem to materially change a (fairly large) point you are making in your book. I do think Andy is correct though. ...

I’ve been following some of the debate on the water usage of LLMs. A lot of people seem concerned that this is a large issue. I’m not sure either way, but I’m coming round to the view that water usage is not a major concern, in comparison to, for example, the energy usage. On the recommendation of a friend I’m reading “Empire of A.I.” by Karen Hao, in the chapter ‘Plundered Earth’ the author touches on the water issue. I think she makes a pretty big error that should have been caught by an editor, but also investigating this error has caused me to update a little in favour of the water issue actually being an issue, even if just a small consideration as opposed to being a complete non-issue. So first of all I’ll give a couple of links to roughly explain where I think we are in the llm-water-usage issue. ...

A couple of weeks back after the GPT-5 release, I wrote a skeptical post that the fact that the GPT-5 model picker release was botched was something of a bearish sign for llm-assisted programming: Okay, but if OpenAI cannot utilise their own models in coding/dev-ops to avoid a high-profile failure on a very high importance launch, what chance do other companies have? Why hasn’t the A.I. enabled OpenAI to improve their development/deployment strategies to avoid such techincal glitches? ...

For a long time I’ve been sceptical that using the file system to denote modules in a programming language is necessary. There are many good reasons to do this as things currently stand, but most of these reasons can, and arguably should, be solved with better tooling. For example from the post linked to above: why would we equate a file to a form of encapsulation? Why, would we wish to divide any application into a bunch of files in the first place. If you ask this question, you get a bunch of answers, but they mostly fall into two categories: 1. some vague notion about organisation and modularising your code and 2. it is easier to navigate whilst coding. I would argue that the first is nonsense, since no one is arguing against modularising code, only that the file system does not need to come into it. The second is potentially true, but rather speaks to a deficiency in your coding environment (text editor/IDE) rather than to the efficacy of using files to modularise a program’s source code. ...