Malleable Software in the Age of LLMs (2023)(geoffreylitt.com)
geoffreylitt.com
Malleable Software in the Age of LLMs (2023)
https://www.geoffreylitt.com/2023/03/25/llm-end-user-programming
38 comments
If you don't have clarity of thought, no intelligence in the world can help you.
I disagree.
Moronic people in positions of power are often in this situation. So far this has worked out well for the moronic powerful people: as long as they can convince intelligent people to work for them, they get to be moronic, powerful, and successful. This strategy has been working for them (as a group) for several millenia.
I think this is why the "LLMs will evolve into God In My Pocket" story gets so much traction. To a moronic person in power this sounds a lot like everyday life, but with computers cleaning up their messes instead of humans. It is totally plausible to them.
I disagree.
Moronic people in positions of power are often in this situation. So far this has worked out well for the moronic powerful people: as long as they can convince intelligent people to work for them, they get to be moronic, powerful, and successful. This strategy has been working for them (as a group) for several millenia.
I think this is why the "LLMs will evolve into God In My Pocket" story gets so much traction. To a moronic person in power this sounds a lot like everyday life, but with computers cleaning up their messes instead of humans. It is totally plausible to them.
Maybe it's getting into semantics but clarity of thought does not necessarily mean accurate understanding of reality (which is usually messy and complex), so moronic people could ironically have more "clarity of thought" than non-moronic people because they tend to have simple beliefs (these X people are good, but those Y people are bad).
That sounds less like helping the person overcome their problem and more like secretly demoting them into a figurehead while the devious Grand Vizier actually steers things.
I don't want my tools to work that way. Especially since the not-so-assistant may be making decisions to favor its parent-corporation.
> Once you were in the hands of a Grand Vizier, you were dead. Grand Viziers were always scheming megalomaniacs. It was probably in the job description: "Are you a devious, plotting, unreliable madman? Ah, good, then you can be my most trusted minister.”
-- Interesting Times by Terry Pratchett
I don't want my tools to work that way. Especially since the not-so-assistant may be making decisions to favor its parent-corporation.
> Once you were in the hands of a Grand Vizier, you were dead. Grand Viziers were always scheming megalomaniacs. It was probably in the job description: "Are you a devious, plotting, unreliable madman? Ah, good, then you can be my most trusted minister.”
-- Interesting Times by Terry Pratchett
Indeed. The issue is that of precision. I think it will never be possible to write nontrivial programs by describing them in anything like a conversational human language. I think this is true even if LLMs achieve some sort of godlike intelligence.
The problem is that human languages aren't intended to communicate that sort of precision. That's one of the largest reasons why very specialized technical professions (medicine, engineering, legal, etc.) heavily employ specialized jargon. It's necessary in order to make up for the deficiencies of natural human languages for these sorts of things.
In order to create a program, very high precision of descriptions are required. Programming languages can be viewed as a variety of such jargon. If you're doing it with (say) English, you'll always have to use it in a way that makes it no longer "conversational English".
The problem is that human languages aren't intended to communicate that sort of precision. That's one of the largest reasons why very specialized technical professions (medicine, engineering, legal, etc.) heavily employ specialized jargon. It's necessary in order to make up for the deficiencies of natural human languages for these sorts of things.
In order to create a program, very high precision of descriptions are required. Programming languages can be viewed as a variety of such jargon. If you're doing it with (say) English, you'll always have to use it in a way that makes it no longer "conversational English".
I think LLMs are already influencing the development of somethin between natural language and a formal language.
Prompt engineering and getting structured data in and out of an LLM naturally lead you to something like precise English with JSON and pseudocode syntax sprinkled in
Prompt engineering and getting structured data in and out of an LLM naturally lead you to something like precise English with JSON and pseudocode syntax sprinkled in
Tell me about it... I work on prompting a lot and you would be surprised how different the model interprets things like "suggestion" vs "recommendation".
> Software has been and always will be fundamentally a problem of communication.
its a problem of communication with a system. that system can be a human, a group of humans, some esoteric knowledge graph, internet or even a single webpage. i believe the author here is focusing on generative UIs from a software developer standpoint. this is just one form of interaction/communication and could be wrong to be generalized across scenarios.
i have been thinking about highly lossless and efficient forms of communication between a human and a system. keep converging to voice agents where if they feel alot human(something similar to the hume demo) then it can be the default mode of how a human interacts with a system. again, this will be a specific setting and sounds more consumer-ish. a clear contrast to what the author intends to write.
its a problem of communication with a system. that system can be a human, a group of humans, some esoteric knowledge graph, internet or even a single webpage. i believe the author here is focusing on generative UIs from a software developer standpoint. this is just one form of interaction/communication and could be wrong to be generalized across scenarios.
i have been thinking about highly lossless and efficient forms of communication between a human and a system. keep converging to voice agents where if they feel alot human(something similar to the hume demo) then it can be the default mode of how a human interacts with a system. again, this will be a specific setting and sounds more consumer-ish. a clear contrast to what the author intends to write.
The same points you made make me wonder if end users even want to modify or write a program.
Even if it's possible, it's still a lot of work. I just don't see that as the typical consumer behavior.
Even if it's possible, it's still a lot of work. I just don't see that as the typical consumer behavior.
Software often doesn't do the thing you want to do.
It almost does it.
Or it can just-just do it with contortions and a lot of repetitive toil on your side.
I think writing little plugins and drivers to do the thing you want with an LLM is something that could be built into a lot of software.
I don't think LLM can architect and build whole systems yet, but this niche is something that can be done.
It almost does it.
Or it can just-just do it with contortions and a lot of repetitive toil on your side.
I think writing little plugins and drivers to do the thing you want with an LLM is something that could be built into a lot of software.
I don't think LLM can architect and build whole systems yet, but this niche is something that can be done.
I am not sure that LLMs change much with regards to malleable software. A lot of software used to be somewhat malleable [1]. But that got removed, because it wasn't A/B testable or it wasn't the most easy implementation thinkable. Those two points are not changed by LLMs. Therefore, I doubt we will see a resurgence of malleable or at least configurable and scriptable software. Although, I would love to see it. Even those small features to adapt the application to your style of working instead of the other way around was extremely useful, imho.
[1] There was a time, when it was considered a standard feature of a UI that you could change keyboard shortcuts and toolbars. MacOS and Mac OS X even had an API that end users could use to script across multiple applications. Amiga OS had something similar based on the language Rexx.
[1] There was a time, when it was considered a standard feature of a UI that you could change keyboard shortcuts and toolbars. MacOS and Mac OS X even had an API that end users could use to script across multiple applications. Amiga OS had something similar based on the language Rexx.
> I think writing little plugins and drivers to do the thing you want with an LLM is something that could be built into a lot of software.
Containing the craziness within low level drivers sounds like the perfect way to do several great things: fuzz the OS for vulnerabilities, finally relieve embedded engineers of what they clearly hate so much, save good tech from the scrap heap. So many wins!
Containing the craziness within low level drivers sounds like the perfect way to do several great things: fuzz the OS for vulnerabilities, finally relieve embedded engineers of what they clearly hate so much, save good tech from the scrap heap. So many wins!
I've heard rumors of people that don't know how to code using LLMs to make blender addons in python, so this has already started I think.
I have yet to meet a non-dev who wants to write or modify software themselves. Quite a few people still don't know that it's the software that makes appliances and devices do things and that it is written. They just don't know what software is so how would they know where to begin writing or modifying code?
Start with macro recorders [0] that let users record and replay sequences of operations. This already exists in certain household appliances, or when making a music playlist. Give them the ability to view and modify the macro code. Add loops and variables etc., and some portion of people will create more complex macros, even if they are no software developers and have no interest in being one. It’s like writing a cooking recipe, people understand that. Apple iOS Shortcuts are also a form of that.
[0] https://en.wikipedia.org/wiki/Macro_recorder
[0] https://en.wikipedia.org/wiki/Macro_recorder
Yet I'm sure many of those non-devs have used Excel / LibreOffice / Lotus 1-2-3 to build something that is more-than-a-list-or-grid (anytime you put `=` into a cell, you are programming).
You've never met a non-dev who complains about the UX of Outlook, wants to adjust the contents of their Twitter/Facebook feed, or wishes to tweak the styles of their blog?
Funny that you mention Outlook.
A lot of Microsoft Office and adjacent programs have customizable UIs almost to the point of absurdity for decades yet it's uncommon to see anyone actually change the default layouts, adjust panes, or view modes.
Maybe it's because everyone hates toolbars and ribbons, but why? Perhaps it's that the number of options is overwhelming. I am fairly certain most humans have seen code and their naive impression is that it's "cluttered"/"noisy". That impression is not because it's text or a ton of buttons staring back, but the cognitive overhead of actually understanding what you're looking at. LLMs can create or suggest things, but the user still has to comprehend something to continue interacting. That's where the interaction falls apart.
What I can see is LLMs taking natural language input and curating catalogs of software or plugins. As it stands searching for software by feature is a terrible experience even for devs.
A lot of Microsoft Office and adjacent programs have customizable UIs almost to the point of absurdity for decades yet it's uncommon to see anyone actually change the default layouts, adjust panes, or view modes.
Maybe it's because everyone hates toolbars and ribbons, but why? Perhaps it's that the number of options is overwhelming. I am fairly certain most humans have seen code and their naive impression is that it's "cluttered"/"noisy". That impression is not because it's text or a ton of buttons staring back, but the cognitive overhead of actually understanding what you're looking at. LLMs can create or suggest things, but the user still has to comprehend something to continue interacting. That's where the interaction falls apart.
What I can see is LLMs taking natural language input and curating catalogs of software or plugins. As it stands searching for software by feature is a terrible experience even for devs.
I completely agree that the UX for toolbar customization currently sucks, but that's exactly what LLMs are being proposed as a replacement for.
When the UX is not a barrier, people love customizing their devices! My collogues of all abilities use different Outlook themes, and everybody's mother and their dog have changed their backgrounds and ringtones.
When the UX is not a barrier, people love customizing their devices! My collogues of all abilities use different Outlook themes, and everybody's mother and their dog have changed their backgrounds and ringtones.
Yeah, but do they create folders and rules for their inbox?
Backgrounds and ringtones don't require any meaningful comprehension. It makes a lot of sense to assume the user would get an itch to stop looking at the same pictures and hearing the same ringtones all the time. That's as far as their desire for customization would go. It's similar to why cars have stereos and paint colors. Anyone can pay money for more customization, but few do.
Inbox rules are just about the simplest actually useful thing someone might do, but probably doesn't. That's a pretty clear signal to me they don't care. That end user cognition is the actual barrier.
In so many words, the user is dumb and complacent. Computers aren't going to think for them no matter how advanced the AI. They also don't want the computer thinking for them.
They want to get things done with stability. Computers are not their focus in life. Imagine an office full of people constantly changing how they work and forcing and politicking their bullshit onto other people (like devs do all the time). That's a normal person's nightmare.
Backgrounds and ringtones don't require any meaningful comprehension. It makes a lot of sense to assume the user would get an itch to stop looking at the same pictures and hearing the same ringtones all the time. That's as far as their desire for customization would go. It's similar to why cars have stereos and paint colors. Anyone can pay money for more customization, but few do.
Inbox rules are just about the simplest actually useful thing someone might do, but probably doesn't. That's a pretty clear signal to me they don't care. That end user cognition is the actual barrier.
In so many words, the user is dumb and complacent. Computers aren't going to think for them no matter how advanced the AI. They also don't want the computer thinking for them.
They want to get things done with stability. Computers are not their focus in life. Imagine an office full of people constantly changing how they work and forcing and politicking their bullshit onto other people (like devs do all the time). That's a normal person's nightmare.
Outside of our IT bubble? No. People will complain that something doesn't work, but they have no desire to change it themselves.
Desire or ability?
Currently if I desire to make the "new mail" button always available, some technical individual would have to devote hours of their time to figuring out the required changes.
Replace a technical individual with an LLM and the story becomes completely different. People love complaining! If that's all that's required to make changes then I bet we'd see a lot more of it.
Currently if I desire to make the "new mail" button always available, some technical individual would have to devote hours of their time to figuring out the required changes.
Replace a technical individual with an LLM and the story becomes completely different. People love complaining! If that's all that's required to make changes then I bet we'd see a lot more of it.
Complaining to, praying to, or bullying an AI god is not going to solve anything. I expect this god to bring upon apocalypse. In the world of software, by its very definition, the righteous ones can only be the developers.
Pleasing everyone was never a people problem or a logic puzzle. It's fundamentally intractable and trivial to see how quickly contradictions would arise in any meaningful set of rules.
Pleasing everyone was never a people problem or a logic puzzle. It's fundamentally intractable and trivial to see how quickly contradictions would arise in any meaningful set of rules.
The typical consumer isn't empowered to modify or write a program, so why would they entertain the idea?
Imagine if practically all the writing you encountered was in printed books and magazines. Talk about "personal writing", how it might change things, how to get there, would get back puzzled looks and "Even if it's possible, it's still a lot of work. I just don't see that as the typical consumer behavior." It is a lot of work to produce a book.
Some relevant background: Bonnie Nardi, A Small Matter of Programming.
Some relevant background: Bonnie Nardi, A Small Matter of Programming.
I wish I could remember where I saw this quote - maybe a random comment on Slashdot back in its heyday? Paraphrasing:
"When we finally get a tool that will allow people to write code in plain English, it will be discovered that most people cannot speak plain English."
"When we finally get a tool that will allow people to write code in plain English, it will be discovered that most people cannot speak plain English."
Agree. Even though I only have twelve years of experience writing software professionally I started to use LLMs more and more in the past few months to write my code for me given a specification of the task. The top commercial LLMS usually do a good job but often fail catastrophically, especially on esoteric projects. I feel like I am slowly developing into a lawyer because of how thoroughly I have to spec out the problem at hand to give enough context to get exactly what I want.
> because of how thoroughly I have to spec out the problem at hand to give enough context to get exactly what I want
This is why LLMs in their current iterations are not the danger to our jobs that some fear them to be: end users and other sake holders lack the precision to properly spec what they want (and often don't even accurately know what they want) a tool/service to do, and they don't have the time (or if they do, don't have the patience) to go back and forth iterating over the wording of the spec to get things adequately defined.
I'm currently an LLM refusenik⁰ so might be missing some context, but from my outside view I get the impression that they do a good job a simple boiler-plate-y stuff but don't save time/effort/thinking on anything much more complex. I'm sure most devs beyond the beginner are happy to have those boilerplate tasks taken off them so they can do the fun stuff, but equally end users aren't going to spend the time working with the tools to get anything more interesting than very simple programming/automation tasks done.
--
[0] I'm on the “is that really morally right?” side of the fence on how the training materials are sourced, particularly with regard to code covered by licences like the GPL family¹, and I'm anal enough to not use something I have that sort of question about even if it makes my life a little harder.
[1] If the assurances that chunks of code can't be regurgitated and that makes it all fine both morally and legally, why are none of the publicly useable LLMs such as MS's copilot trained using, say, Microsoft's Office/Windows/other code as well as public repositories? Surely they should be assured that isn't a problem as much as they want everyone else to be assured it isn't a problem?
This is why LLMs in their current iterations are not the danger to our jobs that some fear them to be: end users and other sake holders lack the precision to properly spec what they want (and often don't even accurately know what they want) a tool/service to do, and they don't have the time (or if they do, don't have the patience) to go back and forth iterating over the wording of the spec to get things adequately defined.
I'm currently an LLM refusenik⁰ so might be missing some context, but from my outside view I get the impression that they do a good job a simple boiler-plate-y stuff but don't save time/effort/thinking on anything much more complex. I'm sure most devs beyond the beginner are happy to have those boilerplate tasks taken off them so they can do the fun stuff, but equally end users aren't going to spend the time working with the tools to get anything more interesting than very simple programming/automation tasks done.
--
[0] I'm on the “is that really morally right?” side of the fence on how the training materials are sourced, particularly with regard to code covered by licences like the GPL family¹, and I'm anal enough to not use something I have that sort of question about even if it makes my life a little harder.
[1] If the assurances that chunks of code can't be regurgitated and that makes it all fine both morally and legally, why are none of the publicly useable LLMs such as MS's copilot trained using, say, Microsoft's Office/Windows/other code as well as public repositories? Surely they should be assured that isn't a problem as much as they want everyone else to be assured it isn't a problem?
Projects of mine that LLMs assisted on:
A web framework for C using clang blocks with request-bases memory arenas for easy memory management.
A CNN trained on video stills of playing various chords on guitar hosted using PyTorch in a SwiftUI iOS app
A DSL using Python Lex Yacc for piping CSV data into a runtime that spits out matplotlib graphs in PNG bytes ready for imgcat.
Right now I’m working on language server in written F# using Fparsec with an intermediary AST for capturing multiple parser errors.
I’d say these are relatively advanced endeavors and that there’s a lot more than boilerplate going on.
And yes, I can explain how these things work as LLMs require quite a bit of guidance.
A web framework for C using clang blocks with request-bases memory arenas for easy memory management.
A CNN trained on video stills of playing various chords on guitar hosted using PyTorch in a SwiftUI iOS app
A DSL using Python Lex Yacc for piping CSV data into a runtime that spits out matplotlib graphs in PNG bytes ready for imgcat.
Right now I’m working on language server in written F# using Fparsec with an intermediary AST for capturing multiple parser errors.
I’d say these are relatively advanced endeavors and that there’s a lot more than boilerplate going on.
And yes, I can explain how these things work as LLMs require quite a bit of guidance.
> I feel like I am slowly developing into a lawyer
Law is what you get when you're silly enough to attempt to spec a formal system in an informal language.
Law is what you get when you're silly enough to attempt to spec a formal system in an informal language.
I also see that communication and a clear understanding of what you want is always the biggest hurdle in software development, not the technical issues or understanding the underlying infrastructure. Most of the time, users realize only after a long struggle that what they want is impossible or in strong conflict with other requirements. Only a human expert with experience and knowledge can advise in such matters. No generative AI will be able to point this out, not even its next generation.
So the process of creating software with the help of AI for a consumer will result in a highly stressful process with many trials and errors. Without the ability to understand the generated code, and relying only on guesswork from both sides, I highly doubt that any consumer will ever want to undertake such ventures. Even for the sake of novelty and fun.
So the process of creating software with the help of AI for a consumer will result in a highly stressful process with many trials and errors. Without the ability to understand the generated code, and relying only on guesswork from both sides, I highly doubt that any consumer will ever want to undertake such ventures. Even for the sake of novelty and fun.
> Any tool, software language, or AI coder will still be limited by the clarity and completeness of the specs presented.
> Nothing will ever turn your fuzzy intent into your clear best interest.
I've seen a lot of SWEs saying this, and while it's true to an extent, it misses a lot. Good engineers don't simply turn a given spec into code, indeed there are somewhat deprecating terms for these types of positions, like 'code monkey'.
A good engineer does not require the spec they receive to be absolutely precise. They will recognize the intent, and make good judgements about what the requester most probably wants. They will ask clarifying questions when there is important information missing, or a decision that needs to be made where it isn't clear what the requester wants.
LLMs can't do this very well right now, but it doesn't seem like a stretch to say that they will be able to. Will they be able to turn half-baked, very underspecified requests into exactly what the requestor is looking for with a press of a button? No. But I think they could get, and often already are, quite good at filling in the blanks. Seems like current LLMs have a way to go before they can recognize deficiencies in a prompt and ask for more info, but it's somewhere in the future.
> Nothing will ever turn your fuzzy intent into your clear best interest.
I've seen a lot of SWEs saying this, and while it's true to an extent, it misses a lot. Good engineers don't simply turn a given spec into code, indeed there are somewhat deprecating terms for these types of positions, like 'code monkey'.
A good engineer does not require the spec they receive to be absolutely precise. They will recognize the intent, and make good judgements about what the requester most probably wants. They will ask clarifying questions when there is important information missing, or a decision that needs to be made where it isn't clear what the requester wants.
LLMs can't do this very well right now, but it doesn't seem like a stretch to say that they will be able to. Will they be able to turn half-baked, very underspecified requests into exactly what the requestor is looking for with a press of a button? No. But I think they could get, and often already are, quite good at filling in the blanks. Seems like current LLMs have a way to go before they can recognize deficiencies in a prompt and ask for more info, but it's somewhere in the future.
Not only this but the author lacks enough empathy and imagination to understand how most people are wildly different than him and would not want any of this complexity in the slightest.
> If you don't have clarity of thought, no intelligence in the world can help you.
This is clearly not true, just look at the tech industry. We have product managers, who in the most literal sense, do not know what they mean when they ask for something. They are paired up with people much smarter then them, who try to figure out what they mean, and then deliver that.
While this is far from ideal, it's proof that if you don't have clarity of thought, external (human level) intelligence can help you.
This is clearly not true, just look at the tech industry. We have product managers, who in the most literal sense, do not know what they mean when they ask for something. They are paired up with people much smarter then them, who try to figure out what they mean, and then deliver that.
While this is far from ideal, it's proof that if you don't have clarity of thought, external (human level) intelligence can help you.
I’m quite sure I don’t want a different bespoke UI for everything. And given the non-deterministic nature of these models it’s going to be different even for the same task. Now instead of hunting for the right buttons after a software “update” with some genius redesign: I’ll be hunting every time I use it? Sounds like a nightmare.
I do agree with the author though as to the deficiencies with a purely chat based interface especially for power users or technical interfaces. It’s simply a non-starter for me. That said LLMs will complement power user interfaces nicely by helping the new user learn them.
I do agree with the author though as to the deficiencies with a purely chat based interface especially for power users or technical interfaces. It’s simply a non-starter for me. That said LLMs will complement power user interfaces nicely by helping the new user learn them.
Non-deterministic nature of these models is definitely a concern. Interesting to see how companies implementing generative interface circumvent this. Maybe they create a set of fixed generic UI elements or write a system prompt describing general design guidelines. Still wouldn't fix it 100%.
Wasn't this the initial promise of Smalltalk, to give end users the ability to easily modify and create their own software to fit their needs for personal computing?
`As with Simula leading to OOP, this encounter finally hit me with what the destiny of personal computing really was going to be. Not a personal dynamic vehicle, as in Engelbart's metaphor opposed to the IBM "railroads", but something much more profound: a personal dynamic medium. With a vehicle one could wait until high school and give "drivers ed", but if it was a medium, it had to extend into the world of childhood.`
"The Early History Of Smalltalk"
https://worrydream.com/EarlyHistoryOfSmalltalk/#p12
"The Early History Of Smalltalk"
https://worrydream.com/EarlyHistoryOfSmalltalk/#p12
Software has been and always will be fundamentally a problem of communication. What many don't realize is that the true challenge of communication is not one of transmission, but clarity of thought and understanding. Any tool, software language, or AI coder will still be limited by the clarity and completeness of the specs presented. What is software after all but complete and precise specs? Nothing will ever turn your fuzzy intent into your clear best interest. If you don't have clarity of thought, no intelligence in the world can help you.
That's not to say I disagree with the author, I agree that more complex creative power will be accessible to a greater number of people, but I think the intrinsic efficiency limit of communication will always be more difficult than people think.