ExFed

Being fair, they might’ve done it to make it a detestable as possible to force some kind of policy change… Still, it’s hardly a joke anymore.

They built it. They’re making money on it. Is that still satire?

I can’t see some tasks, particularly booking concert tickets, being done by AI agents

I’m not sure I follow… Care to elaborate?

I can absolutely see the potential for abuse and a race to produce faster agents. Now that I think about it, before too long “Time To First Token” will become an uninteresting metric, and agents will all be steerable/interruptible mid-task, enabling legit real-time language processing (as opposed to the batch-mode they currently have).

One of my favorite papers! On a similar note, I recently started reading A Philosophy of Software Design by John Ousterhout. Although it’s a lot more recent (2018), I’d argue it’s required reading in light of the LLM hype craze.

Absolutely, the author needs to be able to reason about their changes, no matter what. However, the reason why I think the two situations are fundamentally different, though, is that it’s a lot easier to validate the existence of features than it is the non-existence of bugs or malicious behavior. The biggest risk to removing code is breaking preexisting features, whereas the biggest risk to adding code is introducing malicious behavior.

Agreed. I have a sense that, eventually, development communities will figure out etiquette and policies to govern LLM usage. But how do you enforce that kind of policy? Right now, it’s essentially a judgement call by the maintainers. It’s hard to catch sneaky LLM usage.

On the other hand, I think there are objectively good ways to use LLMs for software:

• High-level design and planning
• Technical Research (although this tends towards the most popular tech)
• POCs & rapid prototyping
• “Textbook” solutions
• TDD Red/Green development (where the LLM generates failing tests based on the high-level spec, and the programmer writes the implementation)

25kLOC delta in a single PR should be cause for instant rejection

Not to pick at nits, but it would be VERY different if it was 1k lines added and 24k lines removed. There’s something extremely satisfying about removing 10k+ lines of unnecessary code.

I want a patch. Heck, I’d settle for a sticker.

The / character isn’t a part of the base64 encoding. In fact, only one part of the URL looks like base64. No plain base64 tool (whether via CLI, self-hosted, or otherwise) will be able to decode an entire URL like that. You’ll first need to parse the URL to isolate the base64 part. This is literally solved with a single line of bash:

echo "https://link.sfchronicle.com/external/41488169.38548/aHR0cHM6Ly93d3cuaG90ZG9nYmlsbHMuY29tL2hhbWJ1cmdlci1tb2xkcy9idXJnZXItZG9nLW1vbGQ_c2lkPTY4MTNkMTljYzM0ZWJjZTE4NDA1ZGVjYSZzcz1QJnN0X3JpZD1udWxsJnV0bV9zb3VyY2U9bmV3c2xldHRlciZ1dG1fbWVkaXVtPWVtYWlsJnV0bV90ZXJtPWJyaWVmaW5nJnV0bV9jYW1wYWlnbj1zZmNfYml0ZWN1cmlvdXM/6813d19cc34ebce18405decaB7ef84e41" | cut -d/ -f6 | base64 -d

See TIO for example.

edit: add TIO link

Agreed. As nice as clap is, it’s not a combinator. Parser combinators have a the really nice feature of sharing the same “shape” as the data they parse, which makes them trivial to generate from a schema … or to just use them to represent your schema in the first place ;) .