> I don't understand why we are so obsessed with cranking out even more... the obvious usecase for LLMs should be to write better software
I honestly think this is ideal. Video games aside, I think one day we'll look back and realize just how insane it was that we built software for millions or even billions of users to use. People can now finally build the software that does exactly what they've wanted their software to do without competing priorities and misaligned revenue models working against them. One could argue this kind of software, by definition, is higher quality.
I don't think this will be true for average consumers. Perhaps for nerds like us, who enjoy a bit of tinkering and can put up with weird behaviors. I mean, are you envisioning that everyone would have their own custom messaging app, for example? Or email? Or banking app? I mean, I think most people's demands for those things are all extremely homogenous. I want messages to arrive, I want emails to get spam filtered a little but not too much, and I want my bank to only allow me to log in and see my balances, etc.
I could see maybe more customization of said software, but not totally fresh. I do agree that people will invent more one-off throwaway software, though.
> Perhaps for nerds like us, who enjoy a bit of tinkering
Tinkering? Even today, people don’t need to understand software. They just need to be able to describe their problems and goals to create an app.
> I mean, are you envisioning that everyone would have their own custom messaging app, for example? Or email?
Well first I think there’s a good chance that most apps as we know them today won’t even exist, and most “apps” will be tool use on APIs. But even then, shopping apps, for example, could be so highly personalized that no two people have the same one.
> I mean, I think most people's demands for those things are all extremely homogenous.
They aren’t, as evidenced by the fact there are many dozens of popular messaging apps with millions of users. Despite the network effects for a messaging app to even be viable.
Also, I’m not talking one-off throwaway apps… these are living, breathing pieces of production-grade software users will mold to fit their needs and evolve with them for years.
There’s a bakery around here that actively works to make their line as long as possible. They might have the best croissants in the city, but they also have one person bagging them up at a snail’s pace and chatty cashier that wants to verify with every customer that yes, indeed, it is a beautiful day outside and the weather this week is supposed to be sunny with maybe some rain on Tuesday and she hopes it doesn’t rain on Tuesday because that’s her day off and she was thinking of going on a hike.
It’s hard to piece together what the actual proposal is around all of the hyperbole, strawmanned arguments, and emotional language. It more or less claims Upload Queues solve all of the problems without explaining any of the how… Then it suddenly shifts to “executing markdown” because LLMs?
Is the idea I’d point my security scanner at preview.registry.npmjs.org/ and npmjs.org would wait 7 days before the package would publish on the main registry?
Yes, but once everything has been deployed through their web UI or the cli command, and fine-tuned over the weeks and months as kinks get ironed out, how do you port it all to your own?
Nothing insurmontable or even complex; just laborious. Friction. That’s all it takes to lock users in.
Still not sure this is the right solution. My problem is if one of your first stages gets rejected in review or requires significant changes, it invalidates so much work that comes after it. I've always when possible preferred to get small stuff merged in to production as it happens rather than build an entire feature and put it up for review.
> it invalidates so much work that comes after it.
No, not necessarily.
I work on a large repo and new features often involve changes to 3 different services: 2 from the backend, and the frontend UI. Sending a single PR with changes to all 3 services is really not ideal: the total diff size in a feature I added recently was maybe 600+ lines, and the reviewers for frontend and backend changes are different people. The changes in the 2 backend services can be thought of as business logic on one side and interactions with external platforms on the other. The business logic can't work without integrating calls to external APIs, and the UI can't work without the business logic.
These days I open 3 separate PRs and the software only works once all 3 are merged and built. It would be great to have all of them as a single package that's still testable and reviewable as 3 distinct parts. The UI reviewer can check out the whole stacked PR and see it running locally with a functional backend, something that's not possible without a lot of manual work when we have 3 PRs.
The LLVM community used this model for years with Phabricator before it was EOL'd and moving to GH and PRs was forced. It's a proven model and works very well in complex code bases, multiple components and dependencies that can have very different reviewer groups. E.g:
1) A foundational change to the IR is the baseline commit
2) Then some tweaks on top to lay the groundwork for uses of that change
3) Some implementation of a new feature that uses the new IR change
4) A final change that flips the feature flag on to enable by default.
Each of these changes are dependent on the last. Without stacked PRs you have o only one PR and reviewing this is huge. Maybe thousands of lines of complex code. Worse, some reviewers only need to see some parts of it and not the rest.
Stacked diffs were a godsend and the LLVM community's number one complaint about moving to GitHub was losing this feature.
I honestly think this is ideal. Video games aside, I think one day we'll look back and realize just how insane it was that we built software for millions or even billions of users to use. People can now finally build the software that does exactly what they've wanted their software to do without competing priorities and misaligned revenue models working against them. One could argue this kind of software, by definition, is higher quality.
reply