Like most people in tech in the year of our lord 2026 I have opinions about AI. None of these are particularly unique (probably), but I want to get them written down.

Hot takes

• In my opinion, Large Language Models (LLMs), i.e. ChatGPT, Claude, and all the others, are not AI; this is a marketing gimmick. It's derived from the long history of neural net design, scaled up and with some legitimately interesting/smart insights into language processing; those things were what used to be incorrectly called AI too. But the word Intelligence is doing a lot of heavy lifting (see later) that I'm not convinced is valid.
• LLMs are a useful tool, for certain contexts (particularly coding). But not all contexts, and perhaps not even many contexts.
• The AI bubble is a very real risk, although I have no idea how it'll play out. The "markets" have been irrational for a long time now, so I don't even know if basic monetary physics is still doing what the average human would expect. This could have all sorts of multi-order effects if something goes splat. This worries me, but only in the abstract because there's absolutely nothing I can do about it (my use of, or abstention from, LLMs will have no impact).

These are all totally hot reckons. I could be wrong about any or all of them. I could be right now, and wrong in 5 years (or tomorrow), they're just what I think right now.

The rest is my inter-related thoughts on various aspects; vignettes, if you will. There is no conclusion; this whole area is just a mass of moving parts, and I think it's going to take a couple more years at least for the big things to shake out.

Useful tools

I've been using LLMs to varying degree for a year or two now (honestly, couldn't tell you when I first actively used one other than incidentally). This year I've really gotten into using them for coding. Work encouraged doing so for quite a while, but I struggled to figure out how. But during some PTO a family member reminded me about an application I'd started years ago but never finished (local-use electron based app). So I got myself a Claude subscription, and cracked on. The existing app had all the code and data structures in place, and Claude Code was able to get it across the line, in particular writing piles of boring PDF-generating code. Then Claude helped me polish the app, making the UI something much more usable than I could create by hand with my meagre UI and HTML/CSS/JS skills. I got further in a week of half-assing it (scrolling on my phone while waiting for Claude Code to do things, then testing the results) than I would have in a month of frantic typing. I mostly vibe-coded it, paying relatively little attention to the actual code. But this is locally run (no server), and for a grand total of about 3 people to use, ever. If it breaks, some people will be mildly inconvenienced for a few hours, but no-one will die or be hurt, and no-one will lose any money. More importantly, the actual core app is trivial and easily proven to be working, and isn't going to need much in the way of maintenance. Once done, it's done. So the code truly doesn't matter here; the only interesting result is the finished behaviour.

On my return to work, I found I was far more proficient in using LLMs for work-related tasks. But in that context, I care far more about most of the code; if it will touch production where failures could affect upwards of hundreds of thousands of users, and potentially cost someone millions of dollars, then the stakes are higher, and I found myself reviewing the code in much more detail. However, there's also one-shot throw-away code; being reasonably proficient in prompting for code generation opened up a whole realm of doing things I simply wouldn't have before. For a concrete example: I wrote some code to make a certain cleanup operation more reliable. That code I paid a lot of attention to, because while it mostly runs in CI and dev-time environments, it will also touch production on some occasions. But I needed to know if it actually made it more reliable, so I used an LLM to vibe-code a script to query the CI/CD pipelines to see how often it failed before and after; that code took maybe 15 minutes with an LLM, but would have been several hours of annoying boring fiddling to do by hand, and frankly I wouldn't have bothered. This one-shot throw-away code delivered obvious value; it also let me prove that the cleanup went from something like 20% failures down to 0% failures. The key takeaway: the value and correctness of this one-off code could be trivially verified, and even if it was slightly wrong it was probably close enough for the purpose. And once I had the data, I could throw the code away and never have to maintain it. The standards for that sort of code are completely different from those for production code, and that's important to keep in mind when considering the use of a tool. Most useful tools in any context have dangers, sometimes literally sharp edges, and knowing how to use them correctly and safely in each context is important.

As a minor bonus: LLMs generally don't make basic typing mistakes; no more reloading a page to see an error that I missed a character or a semi-colon or a parenthesis. Just recently on another app, I decided to handle a couple of small tasks myself, and suddenly remembered just how slow it is to type all those lines, and get all the fiddly little programming details right. It's not that I don't know these things, it just takes much effort to get "Just So". This alone is worth a lot for anything other than trivial changes. Logic or design bugs are entirely different, but that's something that always needs attention.

LLM vs AI, and the nature of intelligence

It is my opinion that the thing we call intelligence is a result of several things that are not elements of LLMs:

1. Some degree of consciousness. If not full self-awareness, then something of a continuous stream of existence beyond one-shot actions with no connection from one to the next. In humans that can be an inner monologue, although some apparently do that more visually or in other forms, but there's still that continuity of experience.
2. Embedding in a world. Arguably LLMs are embedded in a world of words (or tokens), but I think intelligence requires interaction with something external and persistent that is not the entity itself.
3. Growth. LLMs are trained, then go forth and do the math on the inputs, producing outputs. Any given interaction is a short-lived event which then evaporates, and the LLM does not learn or adapt. This isn't a strong link/requirement though; it's not necessary for something to appear intelligent in one interaction. But somehow this seems important.
4. Self-motivation. This is related to consciousness and embedding in a world IMO; an intelligent entity exists, is aware it exists, and wants something, and will act to get that, perhaps food or pleasure/satisfaction. This is where pain and fear also come in: there are things the entity wants to avoid, such as hunger or danger. It's also where the whole topic gets scary. If humanity succeeds in creating Artificial General Intelligence and then cages it, we've just reinvented slavery only in digital form, unless we give that AI free rein, in which case I've read those books and seen that movie and this ends poorly for humanity.

Given all that, I see current AI marketing/expectations as problematic. As happens so often with people in the tech industry, they see something that solves their problems (the internet, blockchains, LLMs, etc.) and assume that:

1. Every other thing in the world will obviously benefit from that thing, and
2. Doing so will be easy because tech is hard and those other things are simple.

I'm exaggerating slightly, but the underlying feeling/mania is not uncommon. I genuinely believe that much of the AI hype is coming from this; coders have found a useful tool and extrapolated far beyond about what it's capable of, and where it will be safe to use, in its current incarnation. The AI bubble is as much about timing as anything; maybe in another few years we'll have actually nailed something closer to intelligence, without the sci-fi-esque problems, potentially by moving past just language into something embedded in a world, and then life will be interesting. But the assumption seems to be that we'll get there shortly, or that current LLMs with just a little more tweaking will be the same thing. I'm not convinced. To repeat myself: I might be wrong. Only time will tell.

Verifiability

Today, the class of problems where the LLMs are particularly useful is ones where it's easy to verify the results. For my throw-away code, that's when the results exist or do not, and can be easily spot-checked. For some of my small-use-case electron applications, literally using them proves what I need, and the surface area is small enough that I can do so quickly.

To my mind this is something like the inverse of NP in the P vs NP problem. My thesis is that the use of LLMs is problematic when used to generate results that we cannot quickly verify are correct, because the LLMs are not actually reasoning with intelligence and understanding. As we've seen early on (and continue to see to this day), they can hallucinate, or follow utterly wrong threads of reasoning. Humans can too, although I postulate they do so at lower frequency. The trouble is that in practice humanity is applying the same rules/heuristics to LLMs that we used to apply to anything coming out of a computer: it's probably right, and is likely deterministic. So now we have to apply human evaluations (or even stronger) to some bits of computer output and verify them, even if it's just running it through the "does this sound right?" filter. Unit tests or simply operating the software and verifying that it does what you expect under the expected scenarios can be enough for code, although that assumes the intent and execution of the unit tests are themselves verifiable/verified.

If we cannot verify the results quickly, it becomes much more risky. When I use an LLM to tell me about some area that I have no expertise in, it's too easy to take it at face value; it talks mostly like a human, so my pattern-matching human brains says "must be a human". But then I remember all the times I've seen an LLM hallucinate when I know the details, and I realize if I cannot verify, it's utterly untrustworthy if the answer matters, because I won't know when to query further. Again, because it's important: we read text that looks like a human wrote it, and is 100% confident in it's phrasing, and make the associated leap of faith. In the short term, this is something LLMs could be made to do differently, producing more prevarication and subtlety in their answers, indicating probabilities not certainty.

The corollary: LLMs are really useful for making suggestions, providing lists of ideas, and other fuzzy output where what they produce is just an input into a further human driven process. Then a human will implicitly verify by filtering and doing further work.

Where humans matter

I won't rehash in detail, but I'm firmly in the camp of art being a human thing. It carries meaning, derived from shared experience and trying to share a feeling, a moment, or a vision. I've used LLMs to create a logo or placeholder graphic, but for actual art (imagery, music, etc.) other than light entertainment (creating a humorous image or piece of text) I think it should be human created. Because that's what the receiver wants: a human connection to something shared.

And if you'll permit me to take a hard left turn from art: design documents. Or rather: anything where the act of creating it (like this blog) is a huge part of the point of the exercise. Reading a technical design document which is clearly LLM generated is frustrating in the extreme. The point of such a document is to think through all the things that matter; to use the depth of personal experience the author has to find edge cases. LLM output reverts to the mean, and will miss hard, subtle, or novel problems, because it is trained on the past. When I review or read that document, I want a window into the human mind that created it. Plus I'm sick to fucking death of 4 bullet points with bolded first words that use many words to say nothing. Then the same content repeated in slightly different ways. Take me on a journey: tell me where you started (the problem), what your constraints are, how you're going to solve them, what could go wrong, and what the implementation journey will look like. Take me with you, don't just dump text on me.

Junior employee

LLMs are currently very much like a junior employee. I've found that giving them an existing project with structure (code + data) and having them make further changes in the same style is highly effective. Having them start from scratch can be less so, unless you review the code more intently and correct the design until it resembles what you need.

Where this is challenging is the modern (relatively recent) concept of agents, with multiple threads of work. Because in the old days, you'd give your junior (or many juniors) a task, and they'd head off and take a few hours, if not days, to produce a result or need assistance. Now you fire off a prompt and have to respond to queries about design within seconds or minutes, or allow it to do things unbound (unless you trust the harness to not delete your production database with creds it found lying around). And then review the actual result 5-15 minutes later. While another stack of LLM sessions are also hounding you for input. This is exhausting, even in one code base let alone multiple. I think this is something we're going to have to reckon with carefully; I find it wonderful that I can fire off a decent prompt (or a plan) and go make dinner and come back to something testable, but that's because I have something else to do. We should not burn out engineers.

But this also speaks to growth: LLMs do not grow. A given LLM model today will continue at the same general level for the foreseeable future. An actual junior engineer will learn from each task and grow to become a senior engineer. The short-sighted idea that we can have a bunch of seniors with a pile of agents replace an organisation is going to cause pain. Maybe LLMs will get better, but this also speaks to verifiability: today we can verify hard things because of the experience we gained doing those things ourselves. Seniors grow from juniors, and that never goes away, unless we decide we're not going to have seniors either. This argument has been made many times, and I won't repeat it, other than to say: this bit worries me, deeply.

Non-linear productivity

I am deeply irritated by the 10x or 100x arguments being bandied about (see also growth, junior engineers, and so on). What if at any time in history someone went to a business and said: "Here's a tool, and if you give me a year or two I can teach your staff how to use this tool safely and you'll get 1.5x the productivity"? For any reasonable amount of money they would be welcomed gladly and showered in praise. 2x, 3x even more so. Why is that not enough? Why are the proponents of AI targeting 10x and 100x rates of productivity? If the financial numbers for the AI industry (development, hardware, and operational costs) need that, then we're already in trouble, and bubbles will pop. This stuff just makes me very worried.