Maybe the future of application development is there will be no apps
I’ve been thinking more and more about the ergonomics of software developers workflows lately.
As one does.
In the olden days, software used to be written in a text editor. In the slightly less olden days, that text editor accumulated a few useful bits and pieces and became an IDE, an Integrated Development Environment, that in addition to letting you write code could let you run your unit tests, or talk to your source control system, or etc.
Now that we are in the beginning phases of the not olden at all days, that IDE has gradually acquired an artificial intelligence.
First it would just make inline suggestions while you wrote your code.
Later on it would write the code for you and let you review it line by line.
Over time, that amount of time spent in the chat window where you tell the AI what to do has gotten bigger, and the text window where it happens has gotten smaller.
This has happened really incrementally. In VS Code for example, you used to automatically get a diff view after every change the LLM made, with a prominent “Keep / Discard” control. Now you can click to a git diff if you choose to, but there’s no obvious way to revert the latest change; it’s just assumed that you’re going to accept the changes.
Now it’s to the point where there are now apps that dispense with the text window altogether. The IDE is just an interface to the AI, where you tell it what problems to solve or what features to add to your app, and it does it for you. Then it runs your test suite, pops open a browser window and takes a screenshot to check its own work visually, updates the docs, and makes you a cup of coffee while you wait.
This takes a certain amount of trust that the AI is going to build what you wanted built in a reasonably efficent way. And I think it’s indicative of how much these AIs have improved, and how rapidly, that there are already these apps that simply do away with the ability to directly view the AI’s work. I’m writing this at a Moment In Time, of course. A year ago I think it would have seemed reckless to suggest an AI should open a PR before any direct human review happens, but now it’s a built in default.
It’s an easy next step to imagine this sort of tool no longer being used by a “software developer” but instead being used by a “product manager”. If all I’m doing is telling the AI what to build and then confirming that it built what I wanted it to, better to have that done by someone who has the product knowledge and the customer knowledge.
(And some companies are already doing this; there are “engineering” roles being listed that are really a combined engineering / product management / customer relations position, with the assumption being that the day to day engineering is going to be done by the machine, with the human modifying and correcting its output.)
And it’s easy to imagine this becoming more common as LLM capabilities continue to improve and solidify, to the point where product software engineering gets absorbed fully into the product team, and the role of “software developer” just... goes away. Or evolves into something completely different than what it means now. Just QA, observability, and infrastructure, maybe.
But the next step beyond that is really interesting, because it’s the realization that why do we need software products in the first place? If the process for software development becomes as simple as telling the AI what to build, then instead of having the customer expert doing that, why shouldn’t the customer themselves be able to do it?
It wouldn’t be a huge technological leap to make Copilot Desktop be a consumer-facing application instead of a developer-facing one. All you’d really need to add is a built-in dev server for preview while you’re using it, then a “publish this as a website” / “publish this as an app” workflow to utilize the results. Build in a skill that tells the AI how to route those requests into your handy subscription-based hosting service to share the user’s work, and you might even have a business plan!
Would consumers create well-architected, bug-free applications? No. Will it matter? Arguably also no. If it’s acting broken they’ll fiddle with it until it works well enough for them. Anyway, maintainability is less of a concern when it’s easy enough to just start over and build a new app that does whatever you need.
I guess what I’m saying is that I think we might be nearing the end of SaaS as a viable business model.
Is that provocative enough for a Monday morning lmk