I think this is a dated mindset with AI in the mix. Not only is AI making it easier to do big-bang rewrites which wouldnt have been done before, it is making working on brownfield codebases more feasible. It is lowering the barrier to entry for non-devs to contribute to codebases. Most software did not stagnate because there wasnt a need to grow it more, it stagnated because the friction and/or cost of change hit a critical mass.

I think we are much too early into the "new era" of software to understand what it looks like tomorrow, especially in terms of what we assume to be true today.

The historic embargo system is likely not sustainable and we need a shift in both approach and security posture (ie fully trustless architectures by default). Not only that, but because of the insanely amplified frequency and risk of the 0-days, you generally have to throw the baby out with the bathwater and leave yourself completely vulnerable to supply chain attacks. Because not short-circuiting taking upstream updates leaves you open to attack.

Theres shades of the old normal in this stuff, but absolutely this is the dial being turned up to 11 and I dont know if theres any right answers for small teams out there.

So yes "async" is easy, but "multithreaded/parallel" is a lot more error prone and explicit.

EDIT: I should also note I havent been in the space for a few years so Im not fully current on how it looks today

And likewise if theres an issue then its much more straightforward for it to unwind what it did in nixos vs a traditional software install and not accidentally mess with other users/services on the system.

This isnt the same as dropbox putting in a bunch of work to make the UX "just work", or even stripe doing the same for payments. This is "send me an api call that is in 1 of 3 forms, and get a response back in this form". The heavy lifting is in making that fast and cheap, and because they havent demonstrated a secret sauce in making it hard to outperform actual results that leaves a lot of room for competitors to get their existing models to run faster and cheaper for the same use case.

Instagram: I have to move all my posts and also convince all my network to move over

Github: not a terrible example

If I decided to move off of jev tomorrow it would be an api key and a base api path update. Maybe 30 seconds of work.

Its very cool, but the harness is doing a _ton_ of heavy lifting.

Well, same as my lack of sympathy for github and their "inability" to deal with "unprecedented AI generated traffic", I dont buy it. Seems really simple to setup an algorithm of "existing app from pre-AI is submitting another update gets put in the priority queue while everyone else gets the shared queue".

By breaking the problem into discrete steps and aggressively restarting the prompt from the current state after completion of said steps