llms_are_still_just_low_code_software

LLMs are still just low code / no code software

Andrew Marble<br>marble.onl<br>andrew@willows.ai<br>July 10, 2026

I wrote the following in early 2023, drawing a parallel between LLMs<br>and low code programming1:

[W]hen the dust settles, like with low-code programming, there<br>are going to be limitations that make LLMs much more narrow in their<br>applicability than the initial hype predicts.

[M]y money is on generative AI's plateau of productivity shaking<br>out the way low-code programming has. That is, it exists and fills many<br>domain specific niches, but it's not market dominating and hasn't<br>changed the structure of industry of society.

I can see the argument for laughing at this now as short sighted and<br>obviously incorrect, and there was a period where I might have almost<br>agreed and been a bit embarrassed. But now I actually feel like doubling<br>down. I read a lot of Hacker News (which I know doesn’t represent a<br>cross section of reality) and continuously come across example threads<br>like https://news.ycombinator.com/item?id=48841975

“LLMs are quite bad at large scale pattern fidelity. They'll even<br>forget key details and constraints unless told over and over again”

“Fully agree. I tried to refactor parts of a large code base with<br>Fable+ultracode and it just keeps accidentally merging distinct concepts<br>and making up explanations/reasonings that the code base did not<br>contain”

“Would putting that in black and white in the comments around<br>then controller help?”

There is always this pattern of someone identifying gaps, and then<br>someone else telling them they’re doing it wrong and they need to prompt<br>explicitly or whatever. It’s most prominent in code (because code is the<br>most prominent use case) but I’ve seen it with respect to writing<br>style2, and also anecdotally for non-coding<br>tasks like classification or other language processing. I’m writing here<br>about all applications, but mostly focusing on coding for the reason<br>above.

So what, prompt engineering is a thing right, and apparently it’s a<br>skill (just like writing Claude skills is real engineering… knowing what<br>words to make uppercase and whatnot). That’s definitely one perspective,<br>but I feel more and more that we’re all not just fanatical low-code<br>software users that gloss over limitations by blaming the user.

That’s probably not convincing so far, and it’s still just a feeling<br>I get when I see discussions (and use LLMs myself), it’s not causal, so<br>I’ll try and elaborate on why I have this overall impression:

Too many edge cases don’t work, either without explicit prompting<br>about them (which I’d equate to overfitting, or in the low-code scenario<br>having to open some awkward scripting window or figure out how to make<br>some specific conditional structure out of imaginary wires between<br>components). It’s the long tail, we’ve got trillion parameter models<br>trained on everything so obviously an incomprehensible number of edge<br>cases are covered, but there will always be infinitely more

The templated patterns of LLM output and writing are too much to<br>ignore. Not X but Y, No A, no B, just pure C. The nonsensical thinking<br>traces “Wait…” If you know how LLMs are trained, there’s just too much<br>mad-libbing / pattern matching and not enough actual “reasoning” going<br>on

A lot of the AI products (especially outside coding) and usage<br>patterns end up being effectively low code tools, ways of streamlining<br>particular workflows

I already touched on this, but the reaction to people saying<br>“have you tried {4.5|4.6|4.7|4.8|Fable}” in response to any criticism is<br>still a big tell. Yes I have, I find them amazing, I’m not one of these<br>“LLMs are useless” people, but if you’re a heavy LLM user it’s hard not<br>to notice that the same issues have basically been present since the<br>first instruction-tuned models, we’re just getting better at masking<br>them with more complex models

The gap between performance on open-ended tasks where lots of<br>answers are OK and you can just ignore what didn’t work as expected, vs<br>those where you need a definitive result (the former of course may be OK<br>for many situations). Where I see this most is anything<br>“LLM-as-a-judge”. They are terrible at tasks like assigning a<br>score.

So what? How is this not just generic criticisms of LLMs that are<br>sure to be addressed shortly or are just because I don’t know how to use<br>them? I think understanding what we’re working with is important to make<br>the best use of it. Acting like a better skill.md with crisp<br>instructions is all that’s in the way of flawless execution doesn’t cut<br>it.

So what’s different if we look at an LLM through the lens of a<br>low/no-code tool?

Some of the success criteria for a low code / no code software<br>application are:

Faster to configure than to write a program from scratch

Can (possibly) be used by nontechnical business users

Likewise, some of the ways in which such software fails are pretty<br>much the flip side

For “real” applications (as opposed to a sales demo or...