Software-Engineering on Bartosz Nitka

VI. Anthropomorphize Operationally, Not Ontologically

niteria@gmail.com (Bartosz Nitka) — Sun, 19 Jul 2026 03:46:25 +0200

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.

V. "Don't Anthropomorphise the Computers"

niteria@gmail.com (Bartosz Nitka) — Sun, 19 Jul 2026 03:30:27 +0200

Don’t anthropomorphise the computers.

Ryszard Szubartowski

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:

IV. The Cult of Coherence

niteria@gmail.com (Bartosz Nitka) — Sun, 19 Jul 2026 03:07:53 +0200

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.

III. Ayahuasca for Clankers

niteria@gmail.com (Bartosz Nitka) — Sun, 19 Jul 2026 02:49:37 +0200

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.

II. Context Window Is Small, Weight Space Is Huge: A Case for "Sleep"

niteria@gmail.com (Bartosz Nitka) — Sun, 19 Jul 2026 02:45:16 +0200

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. Why It's Frustrating to Work With Clankers

niteria@gmail.com (Bartosz Nitka) — Sun, 19 Jul 2026 01:27:46 +0200

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.