All of those, for many or most users, would be best used as tool calls to ChatGPT. That takes care of all the hold those companies have over users, which they use to extract money. As for stealing the useful parts:
- Adobe Photoshop, Canva, Figma, Replit, Lovable - are all kinds of Computer Aided creation tools, and once converted into tool calls, can be gradually reproduced and replaced feature by feature.
- The rest, they're just fancy (and user disempowering) wrappers around proprietary databases and/or API calls to humans. Those cannot be trivially reproduced, because code is neither their secret sauce, nor their source of value. But they can still be pressured into becoming tool calls along with competition, and subsequently commoditized.
It may not seem like it now, but that's because a big chunk of software industry is making money on introducing friction, and preventing automation, because the user interface that sits between a person and some outcome they desire, makes for a perfect marketing channel.
It kind of isn't? If I read your comment and rather than taking the time to think about what you said and respond to you I simply prompted one of the many tools to "write a comment that disagrees with TeMPOraL" something would be lost.
And the point of the computer is not to replace me everywhere it can. Also, automating something is one thing. It requires deliberate actions. Outsourcing is another thing.
The problem is that "enterprise-grade intelligence", by its very nature, doesn't want to be trapped in a pipe feeding apps - it subsumes apps, reducing them to mere background tool calls.
The perfect "killer app" for AI would kill most software products and SaaS as we know them. The code doing the useful part would still be there, but stripped off branding, customer funnels and other traps, upsell channels, etc. As a user, I'd be more than happy to see it (at least as long as the AI frontend part was well-developed for power users); obviously, product owners hate this.
(Good) Apps take the context of the user and their use-case from their head and make it into something the user can see and interact with. An app might or might not be the 'product'. Unfortunately it seems there is always going to be some 'product' so dark patterns might be here to stay.
Right. Problem is, the user interface is also the perfect marketing channel, because it stands between the user and some outcome they want.
Due to technical and social limitations, most apps are also limited in what they can do, this naturally shapes and bounds them and their UIs, forming user-facing software products.
Intelligence of the kind supplied by SOTA LLMs, is able to both subsume the UI, by taking much broader context of the user and the use case into account, distilling it down to minimal interaction patterns for a specific user and situation, and also blur the boundaries of products, by connecting and chaining them on the fly. This kills the marketing channel (UI) and trims the organizational structure itself (product), by turning a large SaaS into a bunch of API endpoints for AI runtime to call.
Of course, this is the ideal. I doubt it'll materialize, or if it does, that it'll survive for long, because there's half a software industry's worth of middlemen under risk of being cut out, and thus with a reason to fight it.
> Distribution has always been monetized. What margin did a retailer take for putting your boxed software on the shelf? How about that magazine ad? Google search? And so on. Get over the idea that a platform should give you their distribution for free.
As 'amelius said below, there used to be more platforms. This matters, because it made for a different balance of power. Especially with retailers - the producers typically had leverage over distributors, not the other way around.
> This matters, because it made for a different balance of power.
In actual practice, it just means that users get fucked from every side: You have 100 different "launchers", just like the 1000 toolbars in the internet's early days. You have to keep track of 100 different emails, accounts, recurring bills and all sorts of shit.
You'd have to be naive as heck to believe corporations fighting against a platform's monopoly are benefactors who want distribution of power and access for the benefit of users, instead of mobsters wanting a cut of each user's pie.
Which is exactly what the OP was saying - these are the kind of questions that are often needed, but that seniors won't ask because it'll make them lose face. Juniors are the ones allowed to "not get it".
There are kinds of questions that you can ask to signal your seniority and matureness. There are other kinds of questions that, should you ask them, will leave people wondering what the hell have you been doing for the past N years and why they're paying you senior-level salary.
A lot of early signs of problems, such as critical information becoming tribal knowledge instead of being documented, are revealed when asking the second kind of questions.
In other words, circling back to Brad Cox's Software ICs, we're all using devboards and Arduinos instead, because those look simple to newbies and save a little glue work here and there.
In hardware world, it's fine to use devboards and Arduinos to prototype things, but then you're supposed to stop being a newbie, stop using breadboards, and actually design circuits using relevant ICs directly, with minimal amount of glue in between. Unfortunately, in software, manufacturing costs are too cheap to meter, so we're fine with using bench-top prototypes in production, because we're not the ones paying the costs for the waste anyway, our users are.
(Our users, and hardware developers too, as they get the blame for "low battery life" of products running garbage software.)
> Unfortunately, in software, manufacturing costs are too cheap to meter, so we're fine with using bench-top prototypes in production, because we're not the ones paying the costs for the waste anyway, our users are.
I’m not sure what you’re trying to say - UTF-8 is the standard text encoding by a mile. It’s not a prototype.
UTF-8 here is like having a devboard with an USB controller chip, complete with power circuitry and USB port. It could all be high-quality components, it's super useful to have it on the board for prototyping, but in the actual product, you aren't going to ship three devboards wired by SPI, but each carrying some combination of USB, Ethernet, Wi-Fi, Bluetooth controllers and other stuff, all of it disabled/unused, all because you need three ICs and found it easier to order devboards. You're just going to use the ICs you care about, supply the USB controller and port and necessary wiring yourself, and otherwise use minimum amount of extra components necessary.
So, in context of Mikhail_Edoshin's example, I'm saying that this "text shaping library" they mention is basically a devboard - full of components not necessary for its core functions. Most software libraries are like that, so applications using them are basically like a device built from wiring up a bunch of devboards.
Because typing on mobile is slow, app switching is slow, text selection and copy-paste are torture. Pretty much the only interaction of the ones OP listed is scrolling.
Plus, if the above worked, the higher level interactions could trivially work too. "Go to event details", "add that to my calendar".
FWIW, I'm starting to embrace using Gemini as general-purpose UI for some scenarios just because it's faster. Most common one, "<paste whatever> add to my calendar please."
Keeping a basic air purifier (i.e. fan strapped to HEPA filter) at low power but constantly on would also help with the dust problem, I believe. There's not going to be much dust on things if it gets sucked out of the air before landing on things.
- Adobe Photoshop, Canva, Figma, Replit, Lovable - are all kinds of Computer Aided creation tools, and once converted into tool calls, can be gradually reproduced and replaced feature by feature.
- The rest, they're just fancy (and user disempowering) wrappers around proprietary databases and/or API calls to humans. Those cannot be trivially reproduced, because code is neither their secret sauce, nor their source of value. But they can still be pressured into becoming tool calls along with competition, and subsequently commoditized.