iainmerrick

That's an interesting distinction. I hadn't really noticed that but it makes a lot of sense.

I suppose Banksy would be close to the crossover point between those two worlds? The ideas and the chutzpah are the main attraction, but generally 'low' populist motifs, without high technical mastery. Someone you could either look up to or sneer down on from either side.

It can be valid to criticize something as uninspired even if you're not capable of doing it yourself. Movie critics would have a hard time otherwise.

In this case I wouldn't be quite as dismissive, personally. But if you've seen one, have you seen them all? Probably yes.

- it's weird and unfamiliar, most people prefer plain JSON

- there are too many competing standards to choose from

- most existing tools just use plain JSON (sometimes with support for non-standard features, like tsconfig allowing trailing commas, but usually poorly documented and unreliable)

Much easier just to make the leap to .ts files, which are ergonomically better in almost every way anyway.

Any special accommodations you make for LLMs are either a) also good for humans, or b) more trouble than they're worth.

It would be nice for both LLMs and humans to have a tool that hides verbose tool output, but still lets you go back and inspect it if there's a problem. Although in practice as a human I just minimise the terminal and ignore the spam until it finishes. Maybe LLMs just need their own equivalent of that, rather than always being hooked up directly to the stdout firehose.

Open benchmarks do help, but they mostly help the vendors, not we the users!

Maybe I’m overly cynical but I think git-flow was popular largely because of the catchy name and catchy diagram. When you point out that it has some redundant or counter-productive parts, people push back: “it’s a successful model! It’s standard! What makes you think you can do better?”

There’s a nice write-up of the trunk-based style at https://trunkbaseddevelopment.com/ that you can point to as something better.

In the UK, Marks and Spencer have a long-running ad campaign built around it (“it’s not just food, it’s...”)

Em dashes are fine too.

A tiling UI would have been much easier to implement! But the original Mac had overlapping windows with pixel-perfect drop shadows. It's a bit nuts when you think about it.

At some point in OS X in the switch to hardware acceleration, they started rendering windows on one screen only.

I get that you hardly ever really want a window spanning two screens, but when you accidentally misplace a window it would be handy to be able to see it on each overlapping screen so you can track it down. Right now you can put a few pixels of the title bar on the wrong screen, and the rest of the window just vanishes.

These regressions are weird given that modern hardware is vastly more powerful than a Mac II.

In terms of experience, I’ve noticed that agents don’t always use skills the way you want; and I’ve noticed that they’re pretty good at browsing existing code and docs and figuring things out for themselves.

Is this an example of “the bitter lesson”? That’s conjecture, but I think pretty well-founded.

It could well be that specific formats for skills work better because the agents are trained on those specific formats. But if so, I think it’s just a local maximum.

I've been trying out Bunny recently and it looks like a very viable replacement for most things I currently do with Cloudflare. This new database fills one of the major gaps.

Their edge scripting is based on Deno, and I think is pretty comparable to e.g. Vercel. They also have "magic containers", comparable to AWS ECS but (I think) much more convenient. It sounds from the docs like they run containers close to the edge, but I don't know if it's comparable to e.g. Lambda@Edge.

Making your docs nice and modular, and having a high-level overview that tells you where to find more detailed info on specific topics, is definitely a good idea. We already know that when we're writing docs for human readers. The LLMs are already trained on a big corpus written by and for humans. There's no compelling reason why we need to do anything radically different to help them out. To the contrary, it's better not to do anything radically different, so that new LLM-assisted code and docs can be accessible to humans too.

Well-written docs already play nicely with LLM context.

For example, if you've just joined a new team or a new project, wouldn't you like to have extensive, well-organised documentation to help get you started?

This reminds me of the "curb-cut effect", where accommodations for disabilities can be beneficial for everybody: https://front-end.social/@stephaniewalter/115841555015911839

Splitting the docs into neat modules is a good idea (for both human readers and current AIs) and will continue to be a good idea for a while at least. Getting pedantic about filenames, documentation schemas and so on is just bikeshedding.

Long term you're right though, agents will fetch this all themselves

It's not "long term", it's right now. If your docs are well-written and well-organised, agents can already use them. The most you might need to do is copy your README.md into CLAUDE.md.

What's different?

To be clear, I'm suggesting that any specific format for "skills.md" is a red herring, and all you need to do is provide the LLM with good clear documentation.

A useful comparison would be between: a) make a carefully organised .skills/ folder, b) put the same info anywhere and just link to it from your top-level doc, c) just dump everything directly in the top-level doc.

My guess is that it's probably a good idea to break stuff out into separate sections, to avoid polluting the context with stuff you don't need; but the specific way you do that very likely isn't important at all. So (a) and (b) would perform about the same.

But I don't see why you need a strict standard for "an informal description of how to do a particular task". I say "informal" because it's necessarily written in prose -- if it were formal, it'd be a shell script.

You might as well just write instructions in English in any old format, as long as it's comprehensible. Exactly as you'd do for human readers! Nothing has really changed about what constitutes good documentation. (Edit to add: my parochialism is showing there, it doesn't have to be English)

Is any of this standardization really needed? Who does it benefit, except the people who enjoy writing specs and establishing standards like this? If it really is a productivity win, it ought to be possible to run a comparison study and prove it. Even then, it might not be worthwhile in the longer run.

Based on what we have learned during this incident, we have reverted the CNAME re-ordering and do not intend to change the order in the future.

To prevent any future incidents or confusion, we have written a proposal in the form of an Internet-Draft to be discussed at the IETF.

That is, explicitly documenting the "broken" behaviour as permitted.

The thing about buying planes is also interesting, but sounds like a sneaky business move rather than the actual foundation of the business.

I've always heard that nobody really makes money from passengers, which is why airlines are always going bankrupt, and I'm sure Ryanair's margins are super skinny. But even so, it does seem like moving passengers around is the core of their business, rather than it just being a front for something else.

If anything can possibly slow down flight boarding, disembarking or cleanup, they'll first try to remove it completely, and only if people object too much will they reluctantly offer it with a fee.

Pocket on the seat back -> most people don't use on short flights -> get rid of them.

Luggage -> most people need this, but not everyone -> charge a fee.

Reclining seat -> most people don't use on short flights -> get rid of them.

They do sell drinks and duty free; that's an interesting one. I guess once the flight is airborne, the flight attendants aren't really doing anything else (from management's perspective) so they might as well sell stuff. Plus the trolley blocking the aisle stops passengers from moving around, which they probably see as a big advantage.

I think this even applies to the ridiculous penalty fees they charge for e.g. trying to check in at the airport rather than doing it beforehand on the app. It feels like they're just trying to rip you off, but I suspect they see it more as a "nudge" to make people check in online, because that streamlines their airport process.

I got a little bit less annoyed by them when I realised this. Sure, it's still uncomfortable and sometimes infuriating, but it's all with the aim of an efficient and reliable service, and they're way better than average at that.

Empirical validiton did not really take off until the late 00s.

https://hci.stanford.edu/publications/bds/4p-guidelines.html

Hmmm, I don't quite see where that supports "Apple didn't do empirical validation"? Is it just that it doesn't mention empirical validation at all, instead focusing on designer-imposed UI consistency?

ISTR hearing a lot about how the Mac team did user research back in the 1980s, though I don't have a citation handy. Specific aspects like the one-button mouse and the menu bar at the top of the screen were derived by watching users try out different variations.

I take that to be "empirical validation", but maybe you have a different / stricter meaning in mind?

Admittedly the Apple designers tried to extract general principles from the user studies (like "UI elements should look and behave consistently across different contexts") and then imposed those as top-down design rules. But it's hard to see how you could realistically test those principles. What's the optimal level of consistency vs inconsistency across an entire OS? And is anyone actually testing that sort of thing today?

I cannot shake the feeling that they simply feel like the were used to just brand Apple as user friendly in the 90s and that Apple never actually adopted their principles and just used it as it fit the company's marketing.

I personally think Apple did follow their own guidelines pretty closely in the 90s, but in the OS X era they've been gradually eroded. iOS 7 in particular was probably a big inflexion point -- I think that's when many formerly-crucial principles like borders around buttons were dropped.