I think a more realistic model is not fully open source, but apps with extremely open/flexible APIs and data models that allow arbitrary front-ends (likely with a default one provided by whoever provides the API). Kind of like Stripe's model, but the audience of "developers" is bigger since anyone can be a "developer" with Claude Code

Or maybe it will be the more established open source model where the code is free but the maintainers offer hosting/some default product

I'm really interested in how LLMs will enable more customizable, personal software. Our PMs & Designers are writing a lot of code now, and our engineers are spending time figuring out how to make a system that's easy for PMs & designers to extend/add to.

It's not a big leap to apply that model to a company and its customers, where the company builds a well-abstracted, easily extensible base that 1) Customers can easily extend/customize for their workflows 2) Customers can self-host or run fully isolated, much easier (probably not quite there yet, but is a possible world)

> Our PMs & Designers are writing a lot of code now, and our engineers are spending time figuring out how to make a system that's easy for PMs & designers to extend/add to

Sounds like your developers are relegating themselves to being review monkeys instead of developers

In a post Claude Code world that's the job of engineers - the engineering is designing good abstractions, scalable systems, and things that are easy to contribute to. This is what the highest leverage senior engineers have always done, the audience has just changed

Engineering has moved up another layer of abstraction (just like we moved past managing buffers & writing machine code)

The "open source" part is the wrapper on top (up to you if you believe that's meaningful here)

Good engineering has always been about minimizing the amount of effort it takes for someone to understand and modify your code. This is the motivation for good abstractions & interfaces, consistent design principles, single-responsibility methods without side-effects, and all of the things we consider "clean code".

These are more important than ever, because we don't have the crutch of "Teammate x wrote this and they are intimately familiar with it" which previously let us paper over bad abstractions and messy code.

This is felt more viscerally today because some people (especially at smaller/newer companies) have never had to work this way, and because AI gives us more opportunity to ignore it

Like it or not, the most important part of our jobs is now reviewing code, not writing it. And "shelfed" ideas will now look like unmerged PRs instead of unwritten code

I've found it really valuable to pair with people, sit at a computer together while they're driving and using AI. It's really interesting to see how other people prompt & use AI to explore the problem.

Interesting thought (I think recently more than ever it's a good idea to question assumptions) - but IMO abstractions are important as ever.

Maybe the smallest/most convenient packages (looking at you is-even) are obsolete, but meaningful packages still abstract a lot of complexity that IMO aren't easier to one-shot with an LLM

Concretely, when you use Django, underneath you have CPython, then C, then assembly, and finally machine code. I believe LLMs have been much better trained on each layer than going end-to-end.

I hear this often, but I think this discounts the fact that this was mostly true for the US/Western Europe at a time where they enjoyed unilateral super-powerism as a result of winning WWII. I'm not sure that kind of prosperity is normal (though I hope it could be).

I'm worried the harsh reality for most humans is that life is often not that easy. And if it is, it won't be for long

But there is still enough wealth for all of those houses to exist. That tells me the world is wealthy enough, but it is in the hands of different people

Has it been many people's experience that big companies intentionally remove experienced engineers from your team to something unrelated, in the name of fungibility? I've surely seen efforts within a team to make sure that there's not a single person who's necessary for the team to reach full productivity, and I think most would agree this model does not make for resilient teams. But many of the best engineers I know have had much more energy invested in getting them to stay than to leave

We just went through a ton of layoffs, while those companies are making record profits.

At the end of the day writing good code is rarely the "end" someone is shooting for. It's more research, more features, more experimentation, etc. Maybe hobby projects and library maintainers are the exceptions.

In my experience, big companies have the biggest incentive to write good code. They have the highest conviction in their bets, and they know with high confidence they will be around in 10 years. One large tech company I worked at had a rule of thumb that all code would need to be maintained for ~7 years - at which point, as the author points out, the entire team may have been replaced. This is precisely when the time it takes to write good code is a worthy investment

"Why are we trying to make Yahoo Search faster? I already am fine with my 2-3s wait time"