Cool idea, but isn't this kind of old school? I mean, with all the new AI stuff that can learn and guess what we need to do, isn't the whole record and replay thing a bit behind the times? Wouldn't generative AI solve that?
We've run some experiments, and the answer is "sort of...sometimes...for some things".
One of our customers, for instance, records macros that upload new users from their Plato tables into their Hubspot CRM, and doing that field mapping is a lot easier in a formal system like a macro than in English.
It seems use cases that can tolerate more ambiguity are more amenable to LLMs, since that's what English is best at.
I see your point, but consider this - generative AI has shown excellent performance in mapping tasks. I've seen examples where it flawlessly extracts data from markdown format to JSON, so mapping fields should be as nearly as the same? I bet something like GPT-4 can even figure out mapping by itself.
Definitely, though the semantics of field mappings often only exist in a user's head, so will need to be explicitly defined.
English prompts will no doubt be a big part of Plato, though. We're still figuring out exactly where the line is between English and traditional UIs. Have you read any good analysis on the subject? Here's one that explores the limits of LLMs: https://magrawala.substack.com/p/unpredictable-black-boxes-a...
We're not looking for partnerships right now, but message me and I'm happy to chat about visual programming. Max/MSP is the OG (though we of course are bullish on macros vs. flowcharts).
Yeah, I'm not sure if "partnerships" is what my project would be looking for either. I'm honestly curious on the purely conceptual level of how you think the corporate world might approach the concept of "very stateful" clients. FWIW, most of my interest is in enabling DIY/hobbyist and academic research use cases that would in fact want as much client-side statefulness as possible.
I guess I don't really understand the idea of macros extremely well. In your system, is it basically a function that's dynamically generated from the interface that is bound to a context-sensitive keyboard shortcut?
Mostly, yea. It's generated from the sequence of actions the user takes in the UI, with a little bit of inference so we can detect, for example, that a user actually is trying to update the first row in a filtered table, rather than a specific row with a specific ID.
And they can be triggered in lots of different ways (buttons, forms, events), not just keyboard shortcuts.
9 comments
[ 4.0 ms ] story [ 35.0 ms ] threadOne of our customers, for instance, records macros that upload new users from their Plato tables into their Hubspot CRM, and doing that field mapping is a lot easier in a formal system like a macro than in English.
It seems use cases that can tolerate more ambiguity are more amenable to LLMs, since that's what English is best at.
English prompts will no doubt be a big part of Plato, though. We're still figuring out exactly where the line is between English and traditional UIs. Have you read any good analysis on the subject? Here's one that explores the limits of LLMs: https://magrawala.substack.com/p/unpredictable-black-boxes-a...
I guess I don't really understand the idea of macros extremely well. In your system, is it basically a function that's dynamically generated from the interface that is bound to a context-sensitive keyboard shortcut?
And they can be triggered in lots of different ways (buttons, forms, events), not just keyboard shortcuts.