danpalmer

There's a subtlety to (1), in that people can be incompetent at things that don't matter, but competent at things that do, and people often latch on to the wrong incompetence.

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 have a blog post that I've been meaning to write about why I moved from Fastmail to Gmail. I love Fastmail as a product, but I realised it wasn't what I wanted anymore from my email.

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.

In my experience the models perform substantially worse if asked to create small PRs or commits. They lack the ability to sequence work and understand dependencies efficiently enough to manage it – it's not that they can't do small PRs, it's that doing them takes vastly more resources which then hits context limits etc. And if you want to then go back and edit a stack of commits or PRs, rebasing work into the middle, that's even more. I don't think any of this scales linearly in the amount of code or number of commits.

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.

I've never seen someone with only solar, basically everyone is still connected to the grid, so you don't stop getting electricity, you just start getting a bill.

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.

That prompt is unrealistic. Shops already have opening hours, prices, locations, etc. If you leave all those up to the model then there's no correct answer and the models will perform better – the less you constrain them the more they can output the median answer. If you constrain them with all those real requirements, they can get things wrong and we can see where they actually fall short.

Glad this got found and fixed, but I continue to be astounded at the amount of work people put into making SQLite do things that would be much simpler with other systems.

It's hard to get past the beginning of this article and take it at all seriously. The quote someone who missed a sunset because they asked google and supposedly got the wrong time... but they didn't think to look at the sun or lack thereof to check? Also when I put "when does the sun set today" I get a single exact figure at the top of my results, not from AI, which is honestly the best kind of result – an exact correct answer.

I think this depends on perspective. Compared to an Electron app, it's significantly better. Compared to a hand-optimised app implemented in a low level language it's not great.

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.

Nice find and summary. Of I'm not surprised to see the ~75MB for the high graphical fidelity of the app.

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?!).

Apple weather is fully native from what I understand. I suspect the 250MB comes from the video backgrounds they play. Arguably that would be a reasonable thing to sacrifice on low memory systems, you'd barely notice.

So can a chiropractor!

Is it? Seems to work for me?

Exactly, this issue was really solved by the mid 2010s. Twitter had a much longer run (10+ years) of solid reliability than they did of spotty reliability (2-3 years?).

Setting aside any feelings about Musk, ad quality, or even product direction choices like locking down public access...

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.

As someone who previously used GitHub a lot, and now works with stacked changelists (PRs) a lot, I'm not sure this really changes much.

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).

"We spent $447 to destroy our small business' reputation by not paying attention to anything"

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.

There are like 4 companies doing this right now.

This is a totally fair opinion to have, but I think it's a niche one. Most people want a predictable flat rate.

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.

This is why "unlimited" subscriptions are going to go away, because people can't just use what they paid for, they have to drain every bit of value out in every way they can.

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.

I don't know why you think this matters, you're not blue either.

No it wouldn't, because each Mastodon server can choose who to federate with and many servers don't federate openly or don't federate with smaller hosts for technical, scaling, or even political reasons.

I've done it, self hosted Mastodon limited my ability to participate in the social network in a way that it does not on ATProto.

Also you can't port between instances. Whereas this is fundamental to the ATProto ecosystem.

Host your own PDS, use an alternative relay and App Server, like Blacksky.

No this is my point, Mastodon doesn't solve this problem in the general case. The shift to Mastodon did not solve the problem of social network admins with too much power, because of the lock-in to instances. Most instances are fine, but there have been many that have caused their users a lot of difficulty, and users fundamentally don't own their data.

The way most users use Bluesky is no different, but the protocol is different, and it is possible to not fall afoul of these issues – data is portable, you can choose your moderation, UI, algorithms, etc, all separately rather than being forced to take a whole package and lose control.

See Blacksky for a completely separate stack, governed separately, that is still fully compatible. That's not possible with Mastodon or even ActivityPub.

I'm not coming at this cold, I've worked on the skill for PR (CL) creation in the Google monorepo. I'm not talking about raw LLM outputs here. It's a hard problem that is fairly fundamental to the training material being used for LLMs today.

I'm sure we can improve things, I'm sure it will get better over time, but I'd say we're a small fraction of the way towards where we need to be, and trending in the wrong direction with long trajectory development creating bigger changes on average.

I'm not going to do the protocol justice in an HN comment, but a core goal is to separate the entities that control the data, the entities that run the network, and the entities that control the interfaces (and recommendation algos etc).

If your Mastodon admin goes rogue, you a) have to get your data out of their hands, and b) have to rebuild your Mastodon presence in a new location, all your connections, history, etc are gone. That's exactly the same problem that Twitter users faced.

On ATProto, you can self-host your data while still making use of Bluesky/etc, in a way that you can't do with Mastodon or even email. You can choose who your UI comes from and just switch UI and keep everything, you can switch who your moderators are and keep everything else, etc.

Check out Blacksky, they're doing amazing work running a whole separate ATProto system that is fully compatible with, and actually the same social network as Bluesky. You can transparently migrate, at a protocol level, something Mastodon/ActivityPub doesn't attempt to tackle.

The answer to big platforms enshittifying is not to move to smaller versions of the same thing. This didn't work for GitHub -> Codeberg/Sourcehut, it didn't work for Twitter -> Mastodon. Because the problem is not necessarily the size, it's the power. Codeberg is exerting power beyond what it should and users have little recourse and get caught up in the issues, some Mastodon servers are fine but there have been plenty of admins who had the power go to their heads or had fallings out with other parts of the network, and again it's the users who get caught up in it.

The answer is building systems that prevent that power trip from ever happening. This is why Bluesky is a better answer to Twitter than Mastodon – the company has its faults, but the approach is a fundamental step forward that Mastodon did not take. The same thing is true of things like Tangled for a software forge. It's no surprise that both of these are based on ATProto, although I'm not saying ATProto is the only option here.

But this is my point, they're not really controllable in this way. There are no fixed rules (like tests or linters) for small PRs, it's not good enough to do it by line count.

A good PR tells a story to the reader that leaves them confident in the result. That means knowing the reader and how they think, and that is something LLMs are very bad at.

PR review sucks because engineers often don't optimise their code authoring for it. When they do it's a joy.

PR review of agent generated code sucks because agents are, in my experience, very poor at authoring for review. This makes sense because the review process is not represented in the resulting code artifact which is what they're trained on. Agents are always producing much larger changes than should be in a single step, and often touch unrelated code with poor judgement of whether it should be included or not.

We've seen several new restaurants crop up on a busy restaurant street near us, and they all have AI generated logos and food images. All are bad, some are comically bad, some are just false advertising.

So far none seem to be gaining traction.

To me it just sets such a low bar for effort on such a basic part of the experience that I assume the rest of the experience and the food is similar trash.

It's the lack of attention to detail that bugs me. It's just bad policy making. Writing good policies that encourage the right behaviour and discourage the wrong behaviour, policies that promote a good culture, are HARD.

Saying "no crypto" has a wide range of impact, from pushing away crypto projects, to pushing away businesses who see it as an overreach, to pushing away free speech advocates.