Rogue Amoeba is home to fantastic MacOS audio products for consumers and professionals alike. Rogue Amoeba - Strange Name. Great Software.

Repo for "Large Language Model Reasoning Failures" - Peiyang-Song/Awesome-LLM-Reasoning-Failures

I find it difficult to coherently collect my thoughts on LLMs. They’re undeniably an interesting technology. There are also people I follow online that I have a lot of respect for and who I trust, making a strong case that they’re finding LLMs useful in many aspects of their work. Yet I find it difficult to get excited, even interested in the technology. That’s largely due to its provenance. I’ve used LLMs a couple of times on their free plans, but every time I think about trying something bigger, which would require signing up for a subscription, I stare at the pricing page, thinking, “I’m not going to pay money for my own code”. Because that’s what the coding models are: they’ve taken our code and reprocessed it for sale. I was wondering if I’m too hung up on this. I know that there are debates in court around the legality of training on publicly available code. But even if training is legally sound, I’ll argue not everything that’s legal is morally okay. Yes, a human could read my code and copy it all or in part. But they’re not turning into a machine that then rents out that gained knowledge many times over. At best, they rent out that gained knowledge just once, by offering their own time and skill. It’s the competition of one that makes this manageable. And it can be, and often is, reciprocal. I.e. someone taking my open-source code will often share code of their own. A machine entering this implicit contract and creating mass competition completely upends the economics. We’re all made fools to have unwillingly fed this thing that is now entering the market as an automated junior engineer. The older ones among us are probably the lucky ones as we’ve progressed far enough along our careers to make straight-up coding the less important aspect of our work. It must be tough for entry-level engineers to compete with this. The only option is probably to run with it and find ways to leverage it. It’s the age-old doping conundrum: If everyone else is taking performance-enhancing drugs, you can either quit the sport or take pills yourself. There is another aspect to the usage of LLMs that I’m experiencing and that I didn’t quite expect. I am a techie and, of course, I am interested in the technology per se. I _have_ played with it. But I find it hard to muster any motivation to engage with it further. I enjoy writing code, approaching a problem, and breaking it down into parts I can solve, building a bigger system. There’s a craft to it. LLMs are taking over the part of the process I like. It’s like instead of enjoying a meal, you’re left describing the ingredients to be cooked. I’m not the first to observe this; it’s been memed before. But what I find beyond that is that it even impacts my willingness to continue my own coding. The fact that an easier way exists drains me of motivation to walk my own path. You see, while I love coding, and regard it as a hobby, unlike, say, running, it is _also_ my job. So while a bike could “solve” my running, the _whole_ point of running was the exercise and not to get anywhere. There's still motivation to code left in me but it is being impacted. Another example: I’ve been a subscriber to a high-quality programming video course for quite a while. On a recent event where they demoed their latest projects, they leaned heavily on LLMs to build the scaffolding. I have a lot of respect for the authors; I love and use a lot of their libraries, and I’m sure they use LLMs responsibly. But when I saw how they worked on this material, interest just whiffed out of me. I’m sure there’s craft in how to set up your agents and all that, and I believe them when they say they get good results and a speed boost. But it’s not a craft I’m interested in. My immediate gut reaction was, well, there’s little to learn from this. When the time comes, if it comes, I’ll be able to write those prompts as well. There’s no need to watch someone do that. The whole craft part has been abstracted away, so what’s the point of even watching? There are, of course, other impacts I haven’t even touched on, which are at least as important as what I mentioned above: the externalities. The environmental impact, the impact of slop on all manner of systems (open source projects, security reports, just to name our own industry - I can’t even begin to imagine what slop does to news reporting), the cost and performance impact of scraping on web projects, like ours. Using LLMs is like taking steroids, but everyone else is getting acne. Doesn’t that sound familiar? That’s right, privatise the profits and socialise the losses. That’s how industries “too big to fail” get to play fast and loose without the risk of having to pay up when the bill comes due. It is all too depressing, and I want no part in it. As I said, I’m struggling to find coherence in my feelings about LLMs, so I’ve just left them in a pile of paragraphs. I’m sure some LLM could give it more structure, but I simply do not care to engage.

Feeding slop is an act of war

The Xcode 26 System Prompts collection contains a couple of chat templates, but more interestingly: typical LLM-targeted documentation of new-ish technology to prime their context for stuff that’s not well-represented in training data. For example, ever wondered when to use the new `InlineArray`? See Swift-InlineArray-Span.md > ### When to Use InlineArray > > InlineArray is ideal for: > > * Performance-critical code paths > * Fixed-size collections that never change size > * Avoiding heap allocations and reference counting overhead > * Collections that are modified in place but rarely copied > * Embedded systems or low-level programming > > > Not suitable for: > > * Collections that need to grow or shrink > * Collections that benefit from copy-on-write semantics > * Collections that are frequently copied or shared between variables > That is a very good summary that is painfully absent on the InlineArray API docs. As a Swift veteran, you usually look for a Swift Evolution proposal for the new tech then an try to find out there what this is all about. Which is to say: I don’t mind quick summaries for busy developers like these! The collection also has docs for 3D charts, `VisualIntelligence` (I didn’t know that framework existed!), and UIKit Liquid Glass guides and `AttributedString` tutorials. These documents are probably not written by a human, or team of humans, because of inconsistent tone and all. So I’d wager they were LLM-generated themselves. I do hope they were edited for misinformation at least! If you use agentic coding tools, it’s sensible to copy Apple’s docs into your setup. For Claude Code, you’d drop these into a `docs/` folder somewhere to look up, but then you need an index to tell Claude to look there. Per project, that can get repetitive, and as a global setting, it can pollute your context. So maybe a clever solution would be to use ‘formalized’ Skills like Antoine van der Lee’s SwiftUI Expert Skill that is available in Claude Code as a plugin to bundle everything. Thanks Joachim for sharing the link on Mastodon! * * * Hire me for freelance macOS/iOS work and consulting. Buy my apps. Receive new posts via email.