Part V ended with a rule: use anthropomorphism to generate hypotheses, never as an explanation.

That seemed too strong.

Anthropomorphism can mislead us about mechanism and experience, but it is also how we predict other opaque minds. We don’t observe another human’s qualia. We infer them. We do something similar, with less confidence, for animals.

LLMs are a strange inversion of that problem. They don’t share our biology, but they are extremely good at producing the language that activates our social intuition. Tulpas make the boundary stranger still: a culturally transmitted way of thinking can produce a genuine experience of another agent without implying a separate person in the brain.

Don’t anthropomorphise the computers.

GPT-5.6 Sol continues:

---

That is probably the most important correction to this whole line of thought. I let the metaphor do more work than the mechanism.

“Sleep,” “psychedelic experience,” “intuition,” “ossification,” and “identity” are useful prompts for generating hypotheses, but they can quietly smuggle in assumptions that do not apply:

• The model does not need sleep; an engineering system may benefit from offline parameter updates.
• It does not become attached to an architecture; repeated optimization may increase the probability of selecting similar representations and policies.
• It does not feel that alternatives are unthinkable; alternative outputs may simply become low-probability under the adapted parameter distribution.
• It does not gain wisdom; performance may improve on one distribution while degrading on others.
• It does not have a persistent self unless the surrounding system deliberately constructs continuity from checkpoints, logs, adapters, and policies.

Translated into less anthropomorphic terms, our discussion becomes:

Part III gives the clanker Ayahuasca. Destabilization makes forgotten or suppressed alternatives reachable again.

Now someone has to decide which of those alternatives are insight and which are nonsense.

The experienced model is biased towards what it already knows. A fresh model doesn’t understand the project. Other models and humans bring their own history and incentives. There is no neutral evaluator.

Worse, a model that writes code, decides what to remember and trains on its own conclusions can create a cult. Its world becomes more coherent while becoming less connected to reality.

Part II gives the clanker a way to develop project-specific intuition. This solves one problem and creates another.

Keep consolidating the same project’s experience and the model will get better at thinking like the project. Eventually it may become unable to think any other way. It will ossify, or contract.

After a while the model may need a psychedelic experience. Not to forget what it knows, but to make other ideas possible again. Ayahuasca for clankers.

Part I ended with a limit. A clanker can keep exact project history outside of its context window, but that doesn’t give it the taste and intuition of someone who has worked on the project for years.

The context window is small, but weight space is huge.

Humans don’t keep everything they have learned in working memory. Sleep consolidates experience. Things that used to require conscious thought become intuition.

What if a coding agent could do the same? Keep exact facts in source control and issue trackers, but periodically train project experience back into itself. I suggested that a long-running agent would need to sleep.

I’ve been thinking about how far coding agents can scale.

A clanker has a limited context window. My intuition was that this puts a limit on the size of project it can work on. GPT-5.6 Sol disagreed. It argued that you can keep state outside of the context window: in code, documentation, issue trackers, tests and process. Split the work into local tasks and use more agents for review.

I wasn’t convinced. Tests can tell you whether the code does what the test says. They can’t tell you whether it’s the right abstraction, whether it fits the architecture or whether it just made the codebase a little worse. A reviewer clanker has the same problem.

In Repairing a Broken Multimeter, I identified a faulty capacitor C18 and desoldered it from the board. I wasn’t sure what its purpose was and what to replace it with.

Recently one reader, Marcin, who’s interested in how multimeters work emailed me telling me that C18 is used in capacitance measurement, that the correct value is 1nF and that it helps with linearity for values lower than 4nF.

Setup

In one of the projects, I use a pinned version of nixpkgs based on miso. There are two advantages to that, one is that I know that miso builds with that version, and the second one is that I can take advantage of miso’s cachix cache and not compile everything from scratch.

In the most basic form, it looks like this.

File nixpkgs.nix:

let

  bootstrap = import <nixpkgs> {};

  misoTarball = bootstrap.fetchFromGitHub {
    owner = "dmjio";
    repo = "miso";
    rev = "2c193a3253216d70f0ac182fbe9c801de00363ae";
    sha256 = "1ywksdzcfd339x1hxp5pvkgbv9mdy1y0971k8v161hg33na2p8wz";
  };

  miso = import "${misoTarball}" { } ;

  inherit (miso) pkgs;

in miso.pkgs

I can then use it in another file to compile my local Haskell package named automation-server.

The Haskell REPL (Read Print Eval Loop) - GHC interpreter, ghci invoked with:

$ ghci

or:

$ stack repl

or:

$ cabal new-repl 

or:

$ cabal repl

is an environment enabling fast iteration.

You can test a particular function and that’s cool and all, but you can also run an entire program in the interpreter. You do that with:

ghci> :main

or

ghci> main

The flow is as follows:

1. You make some changes in your editor

• You :r or :reload
• You make some more changes to make it compile
• You :r again
• You run :main to play around with your program
• You Ctrl-C to kill the program
• Go back to step one

What’s a little inefficient is that to run your new version of a program you have to issue two commands: :r and :main.

I upgraded my Ubuntu recently from 19.04 (Disco) to 19.10 (Eoan Ermine). At some point, I noticed that Shift+Tab stopped working in vim. I use nvim and have Tab configured to move to the next tab and Shift+Tab configured to move to the previous tab. Tab worked, Shift+Tab didn’t.

It’s two lines in my .vimrc:

nmap <Tab> :tabnext<enter>
nmap <S-Tab> :tabprev<enter>

Maybe it’s nvim?

At first, I suspected it’s a problem with nvim since I upgraded it as well and there is some old article mentioning how to get Shift+Tab to work. While old it provided some nice way of checking if vim has received the keys. If in insert mode you press Ctrl+V it tries to write the literal character of what you pressed into the file instead of interpreting it in some way. Again, for Tab it worked, and for Shift+Tab it didn’t.