Comment by dgellow
17 hours ago
Why would you think this? Giving orders to software is such an ineffective, time consuming, error prone way to interact compared to using the interface yourself. That sounds delusional, and would be such a waste of resource, horrendous engineering and user experience
If you know how to accomplish it using the interface, yes
My grandmother keeps a little notebook with detailed instruction on how to do things such as sending a message on facebook or pay a bill using netbank.
For a lot of things, the choice isn't going to be doing it herself or giving orders to the computer. Its going to be not doing it or giving orders to the computer.
Even if it will look very inefficient to people such as you or me
I didn't think it was that controversial actually. I don't bother navigating man pages or help FAQs anymore, i just ask the agent how do i do X step by step. Opening this up as part of the app to regular non-engineering users seems relatively easy to implement, but since it would have app permissions you would skip the "give me the steps" and just say do it.
It is jobs to be done theory on steroids. If someone wants a drill, give them a hole, this kind of logic. Let users literally click “make a hole” button that would instantly make a hole in the wall, and you’ve just disrupted the whole drills market.
Or like in Harry Porter, where you don’t need cooks - food just appears from thin air and floats straight to the tables.
The problem is, jobs to be done theory is not new, and product teams that build Excel and SAP know this stuff. The reason why nobody has yet made an accounting software that is just one magic button is in the amount of user decisions that are necessary to make a “proper hole”.
This is where analogy breaks, because you are not helping to drill a hole anymore, you are helping to design a hole. And to design something you need visibility into what parameters you control, what has just changed with the latest tweak, where rough patches are that require cleanup and design rework.
In programming it just so happened that your code structure and your IDE were also your design UIs. In other areas, like Accounting, your design UI today is Excel and SAP.
Arguably a chat interface can also be a standalone design tool, just not a very user friendly one, like trying to pilot a plane through popup notifications. It works for areas where we fully give control over design to LLMs themselves, but step up into higher level designer shoes and you need proper UI/UX again, chat becomes suffocating.
But would you not agree that writing less code by hand and even looking less at code at all becomes more practical with each new model? If we extend this trajectory, we should see that the time interacting directly with code becomes less and less.