Author here. Yes, I think the original GitHub Copilot autocomplete UI is (ironically) a good example of a HUD! Tab autocomplete just becomes part of your mental flow.
Recent coding interfaces are all trending towards chat agents though.
It’s interesting to consider what a “tab autocomplete” UI for coding might look like at a higher level of abstraction, letting you mold code in a direct-feeling way without being bogged down in details.
If that's what you think a HUD is, then a HUD is definitely way, way worse. Rather than a copilot sitting next to you, that's someone grabbing your hands and doing things with them while you're at the controls.
But if I invoke the death of the author and pretend HUD meant HUD, then it's a good point: tools are things you can form a cybernetic system with, classic examples being things like hand tools or cars, and you can't form a cybernetic system with something trying to be an "agent". To be in a cybernetic system with something you need predictable control and fast feedback, roughly.
I take "HUD" here to just mean "in your line of vision" or "in the context of your actual task" or minimizing any context switch to another interaction (chat window).
Rather I think most implementations of HUD AI interactions so far have been quite poor because the interaction model itself is perhaps immature and no one has quite hit the sweet spot yet (that I know of). Tab autocompletion is a simple gesture, but trades off too much control for more complex scenarios and is too easy to accidentally activate. Inline chat is still a context switch and also not quite right.
Neat —- Scrappy looks like a lovely prototype! As the creators say in their writeup, it fits nicely into the lineage of HyperCard-style “media with optional scripting” editors, which provide a gentle slope into programming.
In the section on dynamic documents towards the end of our essay, we show several of our lab’s own takes on this category of tool, including an example of integrating AI as an optional layer over a live programmable document.
Actually, Patchwork has surprisingly few features! Think of it more like an OS than a product. The goal is a small set of composable primitives that let you build many things - documents, tools, branching/diffs, plugins…
To answer your question: although we use Patchwork every day, it’s currently very rough around the edges. The SDK for building stuff needs refinement (and SDKs are hard to change later…) Reliability and performance need improvement, in coordination with work on Automerge. We also plan to have more alpha users outside our lab before a broader release, to work through some of these issues.
In short, we feel that it’s promising and headed in a good direction, but it’s not there yet.
> I agree, I feel like the authors are underestimating the effect the new AI is already having on the concept of local software crafting
Coauthor here -- did you catch our section on AI? [1]
We emphatically agree with you that AI is already enabling new kinds of local software crafting. That's one reason we are excited about doing this work now!
At the same time, AI code generation doesn't solve the structural problems -- our whole software world was built assuming people can't code! We think things will really take off once we reorient the OS around personal tools, not prefabricated apps. That's what the rest of the essay is about.
Yes, but I think we have a somewhat different idea about the market forces. My impression from your essay is that you believe app developers will add APIs that enable personal tools, and only then will local software crafting take off.
My belief is that it is happening already: local software crafting is happening now, before the tools are ready. People aren't going to wait for good APIs to exist; people will MacGyver things together. They'll scrape screens (sometimes with OCR), run emulated devices in the cloud, and call APIs incorrectly and abusively until they get what they need. They won't ask for permission.
A lot of software developers may transition from building to cleaning up knots.
Yes, I think atproto is a great example of the “shared data” pattern for composable tools! Especially since it handles public social scale, which is not addressed by the other systems we mention.
AFAIK, atproto is primarily designed to support multiple distinct clients over shared data, but I also wonder if it could help with composing more granular views within a client. I previously worked on a browser extension for Twitter, and data scraping was a major challenge - which seems easier building on an open protocol like atproto.
Sorry we didn’t mention — it is on our radar but we ran out of space and had to omit lots of good prior art..
I should also mention btw that Bluesky user-configurable feeds is a perfect example of a gentle slope from user to creator!
You make a fair point! Ease of use matters. We all want premade experiences some of the time. The problem is that even in those (perhaps rare!) cases where we want to tweak something, even a tiny thing, we’re out of luck.
An analogy: we all want to order a pizza sometime. But at the same time, a world with only food courts and no kitchens wouldn’t be ideal. That’s how software feels today—-the “kitchen” is missing.
Also, you may be right in the short term. But in the long run, our tools also shape our culture. If software makes people feel more empowered, I believe that’ll eventually change people’s preferences.
Well, if I may continue my pessimistic outlook, I would simply say that anyone can cook, but not everyone can cook. Programmers are chefs - we take ingredients called SDKs and serve them up into meals called custom software. Anyone who isn't a chef, might need to buy the packaged cake mix at Walmart.
For something as complex as software, it's sad, but it's almost... okay? Every industry has gone through this; there was a time when cars were experimental and hand-assembled. Imagine if Henry Ford in the 1920s had focused on democratizing car parts so anyone can build their own car with thousands of potential combinations; I don't think it would have worked out. It is still true that you can, technically speaking, build your own car; but nobody pretends that we can turn everyone into personalized car builders if we just try hard enough.
I gotta say I don’t understand your point about cooking — billions of people who aren’t professional chefs cook meals every day! These meals may not live up to restaurant standards but they have different virtues — like making it taste just the way you like it, or carrying on a family tradition.
On that note, Robin Sloan has a beautiful post about software as a home cooked meal…
That said, I think talking about cars may be stronger ground for the argument you’re making. Mass production is incredible at making cheap uniform goods. This applies even more in software, where marginal costs are so low.
The point of our essay, though, is that the uniformity of mass produced goods can hinder people when there’s no ability to tweak or customize at all. I’m not a car guy, but it seems like cars have reasonably modular parts you can replace (like the tires) and I believe some people do deeper aftermarket mods as well. In software, too often you can’t even make the tiniest change. It’s as if everyone had to agree on the same tires, and you needed to ask the original manufacturer to change the tires for you!
First thanks for the original article and it is great to know a team is going deep on this.
I am a bit fed up with software less because of malleablity but because of the cloud walled gardens. I can't open my Google doc in something else like I can a pdf in different programs. Not without exporting it.
This for me interested and I found remotestorage.io which looks very promising. I like the idea that I buy my 100gb of could storage from wherever then compose the apps I want to use around it.
I hadn't thought of malleable software... that's a whole other dimension! Thanks for introducing this as a concept worth talking about. Of course I have heard of elisp and used excel but haven't thought of it front and centre.
In terms of cooking ... I feel like cooking is easier potentially as for the most part (some exceptions) if I know the food hygiene and how to cook stuff then it is an additive process. Chicken plus curry plus rice. Software is like this too until it isn't. The excel docs do a great simple budget but not a full accounting suite. With the latter you get bogged down in fixing bugs in the sheet as you try to use it.
I think it is good you are researching as these could be solvable problems probably for many cases.
Something I have always thought about is sometimes it matter less if the software is open source than if the file format is. Then people can extend by building more around the file format. A tool might work on part of the format where an app works on all of it. I use free tools to sign PDFs for example.
Also adding that software only being inflexible due to being mass-produced is the state of the pre-Enshittification era that we already left behind.
Since the last decade or so at the latest, software is often designed as an explicit means of power over users and applications are made deliberately inflexible to, e.g. corece users to watch ads, purchase goods or services or simply stay at the screen for longer than intended.
(Even that was already the case in niches, especially "shareware". But in a sense, all commercial software is shareware now)
> But in the long run, our tools also shape our culture. If software makes people feel more empowered, I believe that’ll eventually change people’s preferences.
I'm really curious to see how the overlap with BABLR plays out. In many ways we're doing the same experiments in parallel: we're both working on systems that have a natural tendency to become their own version control, and which try to say what the data is without prejudice as to how it might be presented.
In particular BABLR thinks it can narrow and close the ease-of-use gap between "wire up blocks" style programming and "write syntax out left to right" style programming by making a programming environment that lets you wire up syntax tree nodes as blocks.
It's still quite rough, but we have a demo that shows off how we can simplify the code editing UX down to the point where you can do it on a phone screen:
Try tapping a syntax node in the example code to select that node. Then you can tap-drag the selected (blue) node and drop it into any gap (gray square). The intent is to ensure that you can construct incomplete structures, but never outright invalid ones.
> That’s how software feels today—-the “kitchen” is missing.
I believe you'll want to read this essay which appeared in the Spring 1990 issue of Market Process, a publication of the Center for the Study of Market Processes at George Mason University ...
"An Inquiry into the Nature and Causes of the Wealth of Kitchens"
by Phil Salin
Having worked for him, I'd say his wikipedia entry doesn't do him justice, but is a good start if you're curious--like your Ink & Switch group he spent many years trying to create a world changing software/platform [AMIX , sister co. to Xanadu, both funded in the 1990s by Autodesk].
Look at HyperCard (more or less dead, regrettably) or Excel and you'll see many useful "applications" created by non-programmers over the years.
People want to create, but need tools to make this easier / more abstract than regular programming. Most companies want to get them into their walled gardens instead, especially web-based companies today.
We're happy to share the Embark prototype with anyone who wants to try it out - just email me at [email protected] and I can share a link with you.
A couple reasons we've decided not to share the demo widely: 1) it's research software, not developed to the quality standards of a commercial product, so we don't want people to get confused or disappointed by that, 2) the prototype heavily uses the paid Google Maps API.
We've also publicly released demos of some related work, like Potluck, an interactive medium built on text notes:
reply