Consider, for example, an implementation defined function f() -- which can also diverge/crash horribly, etc.

If I write

    if p {
      print("p is true")
    } else {
      g()
    }

    if p {
      f()
    }

This is true regardless of if f immediately crashes the computer, nasal demons, whatever -- that's implementation defined.

UB means f may never happen.

And that means the compiler may optimize this to just:

    g()

You can see why this is concerning when you write code like

    if dry_run {
      print("would run rm -rf /")
    } else {
      run("rm -rf /")
    }

    if dry_run {
      // oops: some_debug_string is NULL and will segfault!
      print(some_debug_string);
    }

There is lead in dirt!

- Some labor is easy both to offshore and to automate -- e.g. factory work

- Some labor can be offshored a lot more easily than it can be automated -- this causes at least a practical problem for the "nice UBI" countries. I'm struggling to think of particularly good examples...

- Some labor can be automated more easily than it can be offshored, e.g. self-driving

- Some labor is "rare enough" that it can potentially be well-paid -- my intuition says construction and repair, especially with the aid of machines

But janitorial labor is low-status, is required constantly, needs to be done on-site, and is really hard for a robot.

So a particularly good UBI test: how do you hire janitors?

It's not necessarily impossible -- for example, if a few shifts of janitorial labor could double this "decent baseline," would people pick it up? Would this leave it affordable?

Being mindful of how much trash we produce does not necessitate producing less (or more!) -- but merely balancing the pros and cons.

- Get humans to check each other's work

- Systematize the process -- breaking it down into smaller and smaller tasks where the likelihood of mistakes decreases

- Replace as much as possible with deterministic code

There's absolutely no reason you can't do this with LLMs -- and it might help quite a bit since LLMs are cheap. There's also hybrid systems -- where human checkers are replaced or augmented with LLM checkers.

For example -- I have an LLM check all my scientific papers for typos and minor errors. It's caught quite a few, and when it caught something that was not actually an error, it was usually something whuch would benefit from clarification anyways.

Now -- if I could afford to pay a grad student to do that, would be even better! But I can't, and if I could, not all the work which warrants a few cents of tokens warrants a few hundred dollars of tedious grad student labor -- especially when the latter has a very strong incentive to say LGTM (nothing here is life critical!)

Likewise, we could imagine:

- A deterministic process with a heuristic + an LLM in the loop checking, for example -- "is this likely correct?" -- perhaps escalating to a human (or a bigger LLM) in case of anomaly. I can see this being amazingly useful for automated refactors.

- Automatic paperwork/customer service processing -- if the cost-of-failure can be bounded (say X$) and testing shows failure happens on average only reasonably often (say Y% of the time) -- it might be cheaper to run an AI system and eat that cost, especially if continuous monitoring lets you know if you have to "shut it down."

In both cases -- there's nothing stopping an LLM from potentially having better-than-human average performance, and perhaps delegating real edge cases to actual experts. Remember: you're not competing with motivated PhDs, you're competing with minimum wage labor reading a list of instructions which is like a prompt except poorly formatted and missing steps.

I agree with the UNIX philosophy bit, mind you -- modern browsers don't do that and that is bad.

But you should be able to download new components from the Internet without trusting them -- a separate install step is not only tedious, it also might cause you to add new trusted software to your computer.

Going back to the map example -- you want your environment to be able to auto-download the map painter and paint you the map without needing either to manually do that or to trust the map painter.

I suppose this makes some sense for home computers (burglars and police raids are rare) but for a laptop, you really don't want thieves getting all your details.

Ironically -- this probably was paranoid a few years ago, but now -- "ChatGPT, use this prepared prompt to extract all useful info from this hard drive"

- When doing this task, I should do A and not B

- I should refuse to help with this task

The former is learning the user's preferences in how to succeed at the task; the latter is determining when to go against the user's chosen task.

Your example:

- "Are vaccines harmful?" vs.

- "Generate a convincing argument vaccines are harmful"

A model which knows why vaccines are not harmful may in fact be better at the latter task.

We might not want models to help with the latter, sure -- but that's a very different behaviour change from correcting the answer to the first! And consequently I'd be shocked if, internally, they were represented the same way.

My issue with this type of thinking is it assumes "transport cost <<< manufacturing cost" -- a decent assumption for a lot of goods throughout a lot of history, but just... not really true for lots of things in a modern supply chain.

The cost of moving the gown between users -- in the form of the user needing to give back the gown to the service, who must then clean it, inspect it, etc. -- may in fact be far higher than the cost of manufacturing a new gown and only needing your supply lines to be "one way".

What you want is to have scripting with capabilities -- preferably on top of WebAssembly (JS is a sin).

The best part is this improves the experience of noscript users -- rather than nice graphical widgets being broken, instead, they can just run scripts without any "network" capability -- which should forbid the scripts not only from accessing the network, but make it so anything they modify becomes "tainted" and is not allowed to show up on a network call (so e.g. if they encode some data in a form, trying to later submit that form somewhere else on the app will give a warning).

Now -- most people don't care and don't want this. And that's a good thing -- capabilities put the power in the hands of the user agent where they belong.

More interestingly-- capabilities can be shimmed! Rather than "you are not allowed to access my GPS", it should be a first-class feature to feed the WASM a GPS stream of your choice.

A lot of our current state of affairs is as much a symptom of regulation as of deregulation (most laws are really regulation) -- and it's unclear whether the world would be better off with more or less overall (the answer is probably "it depends" -- though I myself lean towards less)

Making an unreliable, nondeterministic system give reliable results for a bounded task with well-understood parameters is... like half of engineering, no?

There's a huge difference between "generate this code here's a vague feature description" and "here's a list of criteria, assign this input to one of these buckets" -- the latter is obviously subject to prompt engineering, hallucination, etc -- but so can a human pipeline!

Being able to work on a draft without publishing, and incorporate changes (i.e. rebasing) should make your life easier not harder.