| ▲ | gaigalas 10 hours ago | |
One thing I mentioned before is that the representation of artifacts produced by AI being inspectable has notable value. I miss this in some existing agentic interfaces. I'm not typing into the text editor, I'm inspecting the work it does. Not exactly "reading every line", but definitely inspecting. I understand not all kinds of works can be like this, and having to understand how "a bunch of text files" become something else (a program, or a page, or etc) is really taxing on cognition (that's why GUIs exist), but also really beneficial for verification (you can see the guts of the thing). So, it's not prose text. I'm talking about the artifact produced by the agent having a plain text representation. Lacking that produces back-and-forth interactions that feel exhausting. I can make Claude design a spreasheet for me, and it will present it beautifully for me, with export to Google Sheets and so on. But then, changes to it don't let me dig up into it interactively. I need to open the spreadsheet externally, then translate my attempt at debugging the issue to the chat back, which is super slow. Designing one inspectable interface for each kind of produced artifact/outcome sounds like a lot of work. And plain text solves this beautifully (it is an interface) by introducing formats (like Markdown for documents). I'm not suggesting every single AI user will eventually migrate to IDEs with sidebars, but I think something closer to it will be prominent for a foreseeable future in major important work done with AI assistance (the kinds of things that really matter, big work). Some of your demos are not opening, so I don't know what is the MarbleOS solution for things like spreadsheets or more elaborate artifacts that, today, in tools like Claude, produce this exhausting back-and-forth I mentioned. Also, I must say the exhausting part is really only exhausting for power users (the guy that does a lot of spreadsheets needs the speed, not the ease of use). For beginners, a more guided approach might be best. For something that carries the OS terminology, I would expect both approaches to be present at some capacity (other harnesses fail at this too, so don't worry). | ||