I have long enjoyed the writings of Robin Hanson, but while I followed the beginnings of his focus on cultural drift, he has lost me since, to the point where I mostly skip his blog posts when they show up in my RSS reader.

So I did the natural thing and asked Claude to catch me up, then critique the arguments, and then to channel the man himself for a rebuttal. Obviously, Robin might disagree with this characterization, but I found it the right level of "dumbed down" for myself, and far from AI slop.

I just had a short session with Claude that gave me an idea. I finished by saying thanks and that "another you is aleady implementing it". Claude replied with a single thumbs-up emoji, and all I could think of was:

On Monday I gave an informal presentation on how I use Claude Code (CC)to a small group of collegues. Here are the slides. If you are a regular CC user, there will be little new for you in there.

Two metaphors are maybe worth mentioning, because my thoughts keep returning to them:

• Siebenmeilenstiefel or seven-league-boots, the magic boots from the fairy tale that let you cover a lot of ground quickly.
• Morden from Babylon 5 asking "What do you want?". He's the guy who shows up offering you exactly what you want, and the catch is you have to actually know what that is.

The latter is often the main sticky point, I think. Once you know well enough what you want, you are able to ask for it and make CC let it magically appear. And then have enough taste and understanding to judge the result.

But one has to answer the question for oneself first, which mostly means breaking the larger goal down into concrete steps, or having enough understanding of the code-base to have an opinion on the changes that CC suggests - on a detailed conceptual level, not on a "typing"-level any more.

Quoting Simon Willison:

AI-assisted programming significantly reduces the cost of building the wrong thing.

I had a similar thought the other day. Now that code just magically appears when you ask for it, you better ask for the right things. That includes several aspects, like the background knowledge to know what is feasable, the taste in judging the choices that the AI makes, and the general direction where you you are headed.

In other words: Knowing what you want. And that is a tricky question, as all 90s kids know.

Claude agrees this is a good metaphor for AI, but points out that the shadows used the question to actively sow chaos, while LLMs are more neutral.

There are very few things that I miss from not actively following Twitter anymore, but Anders Sandberg's posts are certainly among them. Luckily, he runs a blog too.

Quoting him on the cope bubble, that is the opposite of the hype bubble:

I often find people unable to comprehend that there can be a simultaneous hype bubble and real progress. But the cope bubble is more insidious: it is not telling you that people are full of misleading hype, but that there is nothing there. Hence no need to critically look for information, no interest in disconfirmation.

Where on this plot surface do you find yourself?

Last night I re-watched Tron from 1982. And just now I glanced at Claude's thinking where it reasoned about what "the user" wants, that is me. This struck me as very similar to how the "programs" in Tron talk about the mythical "users", which they are not even sure exists and whose wishes need to be guessed. Very prescient of the film-makers!

Claude Opus 4.5 is really good as coding agent, and I'm having a blast with it. It's even more fun in "YOLO-mode", a.k.a. --dangerously-skip-permissions. This way one does not need to approve anything; Claude gets to do whatever it sees fit to get the job done. This enables longer tasks because it can do trial and error on its own, and also requires less attention from us users.

Is it safe though? When will Claude mess up and delete important data? After all, unrestricted access to the command line is as powerful a tool as they come. I have no good answer here, so I recently looked into various ways to prevent the agent from doing damage. As far as I know, these are the common approaches:

• Using the online version that clones a git repo into its own sandbox and has yolo-mode enabled by default. This is great when nothing outside the repo is needed for the task, otherwise it becomes a hassle. Also, I just spent ten minutes figuring out why a project did not run there while it does just fine locally: It turns out the sandbox runs an old ´uv´ that did not know about recent python versions, thus a quick uv self update resolved it. Still annoying.
• Running in a container like Docker. The desktop version for Macs even has a dedicated command for this: docker sandbox run claude. Ultimately though, I don't like the friction this introduces. Suddenly one has to maintain the Dockerfile and what to install there, mounting directories or copy data back and forth, etc.
• A separate local user, that lacks admin privileges, is another way to isolate the coding agent. Less friction than a container, since all installed software is still available, but still some overhead. For example setting up git & GitHub for a separate clone of the repos, since file ownership and permissions otherwise are a problem.
• Then there is the built-in sandbox of Claude Code. I cannot yet judge how much of a difference this really makes, especially considering how good Claude is at finding work-arounds when things do not go its way.

For now, I take the risk and run yolo-Claude on my laptop without a container or separate user. All code is under version control and pushed to remote. And I make sure to have frequent backups, just in case.

What I dont't do however, is run Claude with root-access on a remote server. It would most likely be fine for a while, until it would not. Claude makes a great sysadmin sidekick though: earlier today, the maintenance interface (iDRAC) of one of our servers hung itself and in this session Claude showed showed me how to reset it remotely, which I did not know before was possible.

Here's another example for the kind of task that I no longer do myself but rather hand off to the AI, because it does it so well. I asked like this:

Let's implement a new option --fib_eff that gets a single value or a range, like 0.9 or 0.7-0.9 , in order to set the fiber efficiencies in the simulation. see fiber_efficiency.md how to do that. set the eff after loading the HDF file, dont modify it. Ranges like 0.7-0.9 are to be interpreted as a random value within that range, uniformly distributed. ask if this was unclear, othweise get crackin and iterate. example command: uv run andes-sim flat-field --band H --subslit slitA --wl-min 1600 --wl-max 1602 --fib_eff 0.5-0.95

As expected, Claude had no problem figuring this out. This the resulting commit. The image above is the ouput of that example command.

I did not have to to type anything else than the prompt above. And in doing that, I needed to get clear for myself what I actually wanted, which is always a good thing to do first. The rest is just typing.

The whole project, a CLI to make simulated spectra, was "vibe-coded" this way, me caring little about the actual code that Claude produced, only taking the occasional glance at it. It is therefore probably not great for a long-term maintained code-base, but it already does what I need it to and I have no intention to take this much further.

I notice it in myself, and in the vibes on the interwebs: this dissonance between on the one hand loving how useful AI is for oneself, and at the same time being annoyed when others use it "on you", or force you to use a bad one.

The examples are aplenty. Slop bug reports, all the companies that try to use chatbots for support questions, and the general feeling that companies push AI a bit too hard down our throats.

But when used right and with taste, it can be fantastic. This is not a contradiction; both the good and the bad exist, and the gap between them will probably only get larger.

A good rule-of-thumb for oneself may be to not make anyone read or interact with AI slop against their will. That means having read and understood AI-generated things to a degree that one feels comfortable standing for it, before sharing. Alternatively being very clear about when this is not the case, so that everyone can choose they level of attention accordingly.

ChatGPT is a mere three years old by now -- it sure feels longer. By now, many seem to either have dismissed LLMs as useless (or evil) or have quickly taken them for granted. But I continue to be amazed and find I get more and more value from Claude et al.

What I probably like the most is that LLMs remove friction. What often slows us down is not the lack of ideas or things to do and try, but the sum of the small hurdles and hoops one has to jump though before getting anywhere.

Well, no more. Config problems with your web-app? Data needs to be converted to or from an obscure custom format? Need to understand why your code does not do what you think it should? Or understand someone else's code quickly? LLMs got you covered. It's like rubberducking but the duck talks back and can solve the entire problem for you!

Yes, they make mistakes and one may need to verify the results. But in may cases this is trivial, or not really necessary, for example when discussing different tools or solutions to a problem. Skimming through the alternatives quickly lets one choose a path forward that is very likely better than it would have been without asking the model.

This is an import aspect: having some taste and quick judgement helps a lot, in other words knowing what you want. If you really do, you probably are able to explain it well enough to an LLM and get it to execute for you. If not, then LLMs can help you too, but one needs to have enough clarity of mind to recognize this as a different mode of operation, where non-leading questions and iterations on the problem can improve one's thinking very much like a discussion with a collegue or expert would have done.

To quote TheZvi:

AI is the best tool ever invented for learning. AI is the best tool ever invented for not learning. You can choose which way you use AI. #1 is available but requires intention.