For example, a software engineer might be fairly mediocre at programming, understanding systems, debugging, etc, but might have really good people skills and be great at effecting change in the organisation, and that person might be worth promoting into management.

A learning experience for me was working with people nearly twice my age with decades of experience yet who were at my level, or much less experienced people who were at my level. Promotion and level are not a judgement of skill as an engineer in an abstract sense, they're a judgement of value to the company – you can be great, but if you're not using that in your current role your level may not reflect that.

I think there's a tension between explicit and implicit organisation. If you want a really good email client, Fastmail is great, but while I did care about that at one point in my life, what I want now is really just the big box at the top of the email telling me about my package arriving today or showing my boarding pass. Fastmail is excellent for explicit organisation, but its implicit organisation isn't great. Gmail is the other way around. I don't like the Gmail UI or any of the organisation features, but I also don't really need to use them.

This is all in addition to the fact that the models are generally poor at storytelling, because that requires a theory of mind of the person you're communicating with. Authoring for review is storytelling, it's making changes in such a way as to build confidence in the reviewer. I believe current LLMs are still years away from this.

In my opinion, if you can't do these things, you're just cosplaying software engineering. Vibe coding has its uses, as does LLM programming, I do a lot of this! But we're kidding ourselves and dropping our standards dangerously low if we think that this is software engineering.

If you look at your solar stats or battery stats every day, then yeah you'll notice sooner. But most people don't. Most of the apps for these things suck anyway.

I think this makes perfect sense for people with solar who aren't obsessed with it.

I've not done a lot of Swift/iOS/macOS, but I have a passing familiarity. These numbers are basically what I'd expect for a normal app. In other words I think the relative optimisation comes from the fundamentally better technology choice rather than from being particularly careful about performance.

I am however surprised that 10MB is Swift language runtime - with ABI compat this is supposed to be shared, and that the weather daemon is >6MB (surely this is just a simple API client?!).

I'm not sure I agree. My experience of Twitter was that the web app was reasonable and reliable. That reliability seems to me to have been collateral in the transition, a bunch of things broke, famously 2FA for a while, a few redirects broke in the domain switch, the public access lockdown also presented as server errors and 404s for a while until the necessary error states were added, and it has had some spotty downtime. Most of these things are better now than a year ago, but not all, and that's only getting back towards what it was before.

The only notable feature addition I'm aware of is Grok, and again that's pretty debatable.

So I'm interested in what you think has improved. Maybe I'm missing things, but it's not my perception.

If there's an expectation that you might merge a whole stack, I think you're aiming for the wrong thing. And it seems like landing the whole stack is the biggest push GitHub are making here. Part of the point is independently reviewable and independently mergable. If you're going to merge in one go then just put everything in one PR and review commit by commit in that PR. The commit by commit review flow used to suck, but since ~2021 it has been fine.

I feel like GitHub have built what users (who haven't used a true stacking system) asked for, not what they actually need to change their workflow for the better.

A great implementation would be asking hard questions like: what's the role of a single commit? Should PRs be single commit only? What's the real benefit here? How do you encourage smaller units of review (because it doesn't look like this does).

As they say, "Guns don't kill people, rappers do". LLMs don't ruin businesses, people do. Your customer that is annoyed with spam isn't annoyed at GPT 5.6, they're annoyed at your business.

Treat your customers better than this.

I've paid for cloud services at some non-trivial scale, and pricing them out becomes a big job. Understanding what you're going to pay month to month, how changing one part of your infra changes pricing, etc, is hard. I absolutely don't want to take that work into my personal life.

Things sold as "unlimited" are always done so within some scope that makes it hard to abuse, on purpose. Unlimited free refills, but you can't bring a bucket to take home. Unlimited home bandwidth, but you can't use it to run servers.

Yes you can technically do this, but the result is that Cursor will just change their subscription model. Because they rely on the "unlimited" access being within a scope they control that gives them tools to manage volume.