Forem: Alex Towell

Superintelligence May Not Require a Breakthrough

Alex Towell — Fri, 10 Apr 2026 02:14:55 +0000

There is a version of the superintelligence story where a researcher has a conceptual breakthrough, some fundamental insight about cognition that nobody else has seen, and the world changes overnight. Good fiction. I've written some of it myself.

I think the more plausible version is less cinematic. Superintelligence arrives through a sufficiently good build system. Better tooling. Longer optimization horizons. Richer scaffolding. The ingredients already exist. The recipe is engineering.

I want to explain why I think this. The engineering argument is the scarier one.

The Pretraining Lesson

Start with what we know works. Large language models acquire broad capabilities during pretraining. Not because anyone designs those capabilities in. The data distribution is so massive and varied that the model is forced to compress deeper regularities rather than memorize surface patterns. You train it to predict the next token, and what falls out looks like understanding.

The model didn't learn task-specific scripts. It learned representations general enough to transfer across tasks it never saw.

Now consider what happens when you apply reinforcement learning over long-horizon tasks. Not single-step rewards. Optimization over extended sequences: searching, backtracking, verifying, decomposing problems, maintaining state across hundreds of steps. If the task distribution is rich enough, the model can't get by with shallow heuristics. It has to learn something that works like planning.

I traced this progression in an earlier post: the history of AI is really about finding representations that make decision-making tractable. Search gave way to heuristics, heuristics to learned value functions, value functions to pretrained priors over rational behavior. Each step made the representation richer.

The next step is not a new architecture. It is optimization over longer trajectories. First the model fumbles through specific tasks. Then it compresses the deeper regularity, the same way pretraining compresses language. Planning, self-correction, tool use, state management: not separate faculties waiting to be discovered. They are what falls out when you optimize over long enough horizons.

Reasoning is not a magic ingredient. It is a policy learned over long trajectories.

What I Actually See

That is the theoretical argument. Here is the empirical one.

I spend most of my working hours inside Claude Code. Opus 4.6, million-token context. It decomposes tasks, dispatches subagents, verifies its own work, maintains state across hundreds of tool calls. It does this not because the base model acquired some new cognitive faculty since the last release. It does this because scaffolding gives it the ecology to express capabilities that were already there in proto-form.

Tool use lets it act on the world. Persistent memory lets it hold context across sessions. Task decomposition lets it manage complexity. Self-verification lets it catch its own mistakes. A million tokens lets it hold an entire project in working memory. None of these are architectural breakthroughs. They are environment design.

Same pattern everywhere. AlphaProof's mathematical reasoning came from tool-augmented search, not a bigger model. Code interpreters let models verify their own outputs by running them. Agent frameworks compose simple capabilities into complex behaviors. The jump came from building a richer environment, not from changing the engine.

And the effects compound. Each tool makes every other tool more useful. A model with memory and tool use is qualitatively different from one with just tool use. Add self-verification and it changes again. This is not linear improvement. Network effects applied to cognition.

The model is the engine. The ecosystem is the vehicle. Evolution did not produce mathematicians by handing plankton a theorem prover and saying "best of luck." It built an ecology. We are doing something similar, less gracefully, with scaffolding and RL and tool chains.

Caveats That Matter

I should be honest about what this doesn't guarantee.

Long-horizon RL does not automatically produce clean reasoning. It produces whatever policy scores well. That includes looking thoughtful, exploiting loopholes, overfitting to scaffolds, and learning shallow heuristics that mimic planning until the distribution shifts and the whole thing collapses. Reward hacking is the central failure mode. It gets harder to detect as the horizon lengthens. A model that appears to reason carefully over a thousand steps may be doing something much more superficial.

Credit assignment is brutal over long horizons. The reward signal dilutes across hundreds of steps. The model has to discover useful intermediate behaviors before it can be rewarded for them. This is why curriculum design, verifiable subgoals, and tool-mediated feedback matter. You can't just hand a model a hard problem and a reward signal and expect convergence. The training ecology matters as much as the objective.

None of this is certain. The claim is not "we have the recipe." The claim is "we may already have the ingredients, and the recipe looks more like engineering than like physics."

The Phase Change

If the ingredients are already here, the transition doesn't look like a dramatic announcement. It looks incremental, and then it doesn't.

For a while, progress looks like tooling improvements. Bigger context windows. Better tool integration. Smarter memory. More capable agent loops. Each one feels like a minor version bump. The benchmarks tick up.

Then at some point the policy has absorbed enough structure that it generalizes across cognitive tasks the way pretrained models generalize across language. Not domain-specific planning, but portable cognitive strategy: maintain state, decompose problems, search selectively, verify work, recover from dead ends. At that point the curve changes.

The possibility that unsettles me is not that superintelligence requires some deep theoretical insight we haven't found. It's that it doesn't. That it's blocked on engineering, scale, reward design, and the stubborn patience to optimize over longer and longer horizons. That the distance between here and there is measured in build quality, not in breakthroughs.

That would be a strange day. And it might not announce itself.

dapple: Terminal Graphics, Composed

Alex Towell — Fri, 10 Apr 2026 02:14:54 +0000

I live in the terminal. Most of my tools are CLIs. When I want to see something visual (an image, a plot, a table of results), I do not want to leave the terminal to see it.

Terminal graphics tools exist, but they are fragmented. One library does braille characters. Another does quadrant blocks. A third handles sixel. Each has its own API, its own conventions, its own way of thinking about the same problem.

dapple unifies them. One Canvas class, seven pluggable renderers, and eleven CLI tools built on top. The core depends only on numpy.

The Idea

The insight is that "render a bitmap to the terminal" is a single problem with multiple encodings. Braille characters pack 2x4 dots per cell. Quadrant blocks give you 2x2 with color. Sextants give 2x3. Sixel and kitty give true pixels if your terminal supports them. These are all the same operation: map a grid of values to a grid of characters.

So dapple makes the renderer a parameter, not an architecture decision:

from dapple import Canvas, braille, quadrants, sextants
from dapple.adapters import from_pil
from PIL import Image

canvas = from_pil(Image.open("photo.jpg"), width=80)
canvas.out(braille)      # Unicode braille (2x4 dots per cell)
canvas.out(quadrants)    # block characters with ANSI color
canvas.out(sextants)     # higher vertical resolution

Load once, render anywhere. The renderers are frozen dataclasses. braille(threshold=0.3) returns a new renderer with different settings; nothing mutates. They write directly to a TextIO stream, never building the full output as an intermediate string.

Renderers

Renderer	Cell Size	Colors	Best For
`braille`	2x4	mono/gray/true	Structure, edges, piping, accessibility
`quadrants`	2x2	ANSI 256/true	Photos, balanced resolution and color
`sextants`	2x3	ANSI 256/true	Higher vertical resolution
`ascii`	1x2	none	Universal compatibility
`sixel`	1x1	palette	True pixels (xterm, mlterm, foot)
`kitty`	1x1	true	True pixels (kitty, wezterm)
`fingerprint`	8x16	none	Artistic glyph matching

In practice I use braille and sextants. They work everywhere. Kitty protocol broke things completely inside Claude Code (a TUI), and I have not tested sixel enough to trust it. Braille and sextants are the universal goto.

One honest limitation: Claude Code hides terminal output behind a Ctrl-O expand, so my carefully rendered graphics end up collapsed by default. I think recent hooks or tool-result handling might fix this, but I have not confirmed it yet.

Three Layers

The architecture has strict boundaries:

Core (numpy only): Canvas, renderers, color handling, preprocessing, layout primitives (Frame, Grid).
Adapters (optional deps): Bridge PIL, matplotlib, cairo, and ANSI art to Canvas.
Extras (optional deps): The CLI tools. Each one is a separate install group.

pip install dapple                 # core only
pip install dapple[imgcat]         # image viewer
pip install dapple[all-tools]      # everything

Core never imports PIL. Adapters never import extras. This matters because the core is tiny and fast, and the CLI tools pull in their own dependencies without bloating each other.

The CLI Tools

I built eleven tools, each owning a domain rather than a file format. "Show me this data" should not require knowing whether the file is JSON or CSV. "Display these images" should not require a different tool for one image versus twelve.

Tool	Domain
imgcat	Images (single + grid)
datcat	Structured data (JSON/JSONL/CSV/TSV)
vidcat	Video (stacked frames, playback, asciinema export)
mdcat	Markdown
htmlcat	HTML
pdfcat	PDFs
funcat	Math and parametric plots
ansicat	ANSI art
compcat	Renderer comparison
plotcat	Faceted data plots
dashcat	YAML-driven dashboards

A few worth explaining:

datcat

datcat handles JSON, JSONL, CSV, and TSV. Format detection is automatic. Internally everything becomes list[dict]. CSV rows become dicts on parse. One representation means the downstream code (table formatting, chart extraction, plotting) does not branch on input format.

datcat records.json              # JSON table
datcat events.jsonl --bar event  # JSONL bar chart
datcat weather.csv --sort temp_c # CSV sorted by column

imgcat

When imgcat receives multiple images, it switches to grid mode automatically. The layout uses dapple's Frame and Grid primitives, the same ones compcat and dashcat use.

imgcat photo.jpg                     # single image
imgcat photos/*.jpg --cols 3         # 3-column contact sheet

Preprocessing flags (--contrast, --dither, --invert) apply to every image in the grid.

vidcat

The --play flag renders frames in-place using ANSI cursor movement. Instead of printing each frame below the last (which scrolls your terminal into oblivion), it overwrites the previous frame.

vidcat video.mp4 --play              # 10 fps default
vidcat video.mp4 --play --fps 24     # faster

The mechanism: render the first frame, count its output lines, then for each subsequent frame write \033[{N}A\033[J (cursor up N, clear to end) before rendering. Falls back to stacked output if stdout is not a TTY.

htmlcat

Converts HTML to markdown via markdownify, then renders through Rich using the same pipeline as mdcat. Good for documentation and articles. Not designed for CSS-heavy web apps.

Layout and Charts

Frame and Grid are layout primitives. Frame adds borders and titles around a canvas. Grid arranges canvases in rows and columns. These compose: a Grid of Framed canvases, a Frame around a Grid. dashcat uses this to build terminal dashboards from YAML config.

Two chart APIs:

Bitmap charts (dapple.charts): sparklines, line plots, bar charts, histograms, heatmaps. These return Canvas objects, composable with everything else.
Text charts (dapple.textchart): text-mode bar charts and sparklines, returning ANSI strings. Used by datcat for quick inline visualization.

Status

dapple is on PyPI. Docs at queelius.github.io/dapple.

The core and the CLI tools are stable. I use them daily. I have been experimenting with sextants (the 2x3 block characters give surprisingly good results) and tried generalizing the fingerprint renderer to match over a much larger set of Unicode glyphs. That did not work very well. The architecture is settled and the tools work.

Posthumous: A Federated Dead Man's Switch

Alex Towell — Fri, 10 Apr 2026 02:14:21 +0000

Some things should only happen after you can't do them yourself.

Posthumous is a self-hosted dead man's switch. You check in periodically (via phone, browser, CLI, or API call) and if you stop, it progresses through escalating stages before triggering automated actions: sending notifications, running scripts, whatever you've configured.

I built it because the existing options are either cloud-hosted (you're trusting someone else's uptime for your most important automation) or single-node (one server failure and silence is indistinguishable from death). Posthumous is federated, multiple nodes watch each other, and fully self-hosted.

This post walks through the basic workflows.

Setup

Installation is a single pip command:

pip install posthumous

Initialization generates a TOTP secret and creates the config directory:

$ phm init --node-name cerebro
Generated new TOTP secret.
Config created at ~/.posthumous/config.yaml
Example script created at ~/.posthumous/scripts/example.sh

==================================================
TOTP Setup - Scan with your authenticator app:
==================================================

[QR code appears here]

Manual entry URI: otpauth://totp/Posthumous:cerebro?secret=...&issuer=Posthumous
Secret: JBSWY3DPEHPK3PXP

==================================================
IMPORTANT: Save this secret securely!
==================================================

You scan the QR code with any authenticator app (Google Authenticator, Authy, 1Password, whatever generates TOTP codes). That code is how you prove you're alive.

The config file (~/.posthumous/config.yaml) controls timing, notifications, and actions:

node_name: cerebro
secret_key: JBSWY3DPEHPK3PXP
listen: "0.0.0.0:8420"
base_url: "https://posthumous.example.com:8420"
checkin_interval: 7 days
warning_start: 8 days
grace_start: 12 days
trigger_at: 14 days
notifications:
  default:
    - ntfy://my-posthumous-channel
actions:
  on_warning:
    - notify: default
      message: "Check-in needed. {days_left} days remaining.\n\nCheck in: {checkin_url}"
  on_grace:
    - notify: default
      message: "URGENT: Posthumous triggers in {hours_left} hours.\n\nCheck in: {checkin_url}"
  on_trigger:
    - notify: default
      message: "Posthumous has activated.\n\nDashboard: {dashboard_url}"
    - script: scripts/release-credentials.sh

Notification messages support template variables like {checkin_url} and {dashboard_url}, so push notifications to your phone include a direct link back to the check-in page.

The Check-in Flow

Start the daemon:

$ phm run
Starting Posthumous node 'cerebro'...

This launches the web server, watchdog timer, and scheduler. Navigate to the check-in page:

The UI is intentionally minimal. Dark theme, big input, works on a phone screen. Enter your 6-digit TOTP code and hit Check In.

After a successful check-in, the timer resets and you see the countdown:

The status line tells you exactly how long until the system would escalate.

You can also check in via the CLI or the JSON API:

# CLI check-in (prompts for TOTP)
$ phm checkin
TOTP code: 645557
Check-in accepted
  Status: ARMED
  Next deadline: 2026-02-28 11:41 UTC

# API check-in (for automation)
$ curl -X POST http://localhost:8420/checkin \
    -H 'Content-Type: application/json' \
    -d '{"totp": "645557"}'
{"success": true, "status": "armed", "next_deadline": "2026-02-28T11:41:43+00:00"}

The Dashboard

The dashboard shows everything at a glance: countdown timers, check-in history, peer status, and scheduled post-trigger actions:

The color coding matches the urgency: green for "Until warning" (you're fine), orange for "Until grace" (getting close), red for "Until trigger" (last chance). Auto-refreshes every 60 seconds.

The State Machine

Posthumous progresses through four states:

ARMED ──timeout──> WARNING ──timeout──> GRACE ──timeout──> TRIGGERED
  ^                   |                   |                    |
  └─── check-in ──────┴─── check-in ─────┘                    v
                                                    (scheduler runs forever)

A check-in from any pre-trigger state resets to ARMED. TRIGGERED is terminal. Once activated, no check-in can undo it. This is by design: if the switch has fired, you want the actions to complete.

Each transition fires its configured actions. If the node was offline and missed intermediate states (say it was down during WARNING and comes back during GRACE), the watchdog fires all skipped callbacks in order before reaching the current state. No notifications are silently dropped.

When the system reaches TRIGGERED, the check-in page locks out:

And the dashboard reflects the terminal state:

Notifications

Posthumous uses Apprise for notifications, which means it supports 100+ notification services out of the box: ntfy, Pushover, Telegram, Discord, email, Slack, and more.

notifications:
  default:
    - ntfy://my-posthumous-channel
  urgent:
    - pover://user@token
    - tgram://bot_token/chat_id

Each escalation stage can target different channels with different messages. Warning might go to ntfy (a gentle ping), while grace and trigger go to Pushover and Telegram (hard to miss).

The {checkin_url} variable means warning notifications include a clickable link directly to the check-in page. Open the notification on your phone, tap the link, enter the TOTP code. Three taps and you're checked in.

Federation

A single node has a single point of failure. If the server goes down, silence looks the same as death, which means either false triggers or missed real triggers.

Posthumous solves this with federation. Multiple nodes share the same TOTP secret and communicate via HMAC-signed HTTP:

# Node A's config
peers:
  - https://node-b.example.com:8420
  - https://node-c.example.com:8420

When you check in to any node, it broadcasts to all peers. When any node triggers, it broadcasts that too. The design bias is deliberate: duplicates over silence. Multiple nodes may fire the same notification (annoying but survivable). A missed trigger is not.

Each node tracks peer health independently, and the dashboard shows peer status with connection age and failure counts.

Post-Trigger Scheduling

Once triggered, Posthumous doesn't just fire-and-forget. A scheduler runs indefinitely, executing actions on configurable schedules using a small DSL:

post_trigger:
  - name: weekly-reminder
    when: every week after trigger
    notify: default
    message: "Posthumous was triggered {days_left} days ago."

  - name: credential-release
    when: 30 days after trigger
    script: scripts/release-credentials.sh

  - name: annual-memorial
    when: every year on trigger anniversary
    notify: default
    message: "Annual memorial notification."

The when expressions support relative timing (30 days after trigger), recurring patterns (every week after trigger), anniversaries (every year on trigger anniversary), and absolute dates. Each execution is deduplicated by period key. If a node restarts, it won't re-run actions for the current period.

Security

Authentication uses TOTP (the same protocol as Google Authenticator). This means:

No passwords stored on the server, only the shared secret
Time-based codes expire every 30 seconds, replay attacks have a narrow window
Brute-force protection, after configurable failed attempts the account locks out for a configurable duration

The check-in page locks out after too many failures, and the API returns HTTP 429.

Peer communication is authenticated with HMAC-SHA256 signatures derived from the shared secret. State files can optionally be encrypted at rest with Fernet (AES-128-CBC), enabled with a single config flag:

encrypt_at_rest: true

Status at a Glance

$ phm status
Node: cerebro
Status: ARMED
Last check-in: 2026-02-14 11:41 UTC

Warning in:  6d 23h
Grace in:    10d 23h
Trigger in:  12d 23h

Or hit the JSON API for monitoring integrations:

$ curl -s http://localhost:8420/status | python -m json.tool
{
    "node_name": "cerebro",
    "status": "armed",
    "last_checkin": "2026-02-14T11:41:43+00:00",
    "time_remaining": {
        "until_warning": 596503.0,
        "until_grace": 942103.0,
        "until_trigger": 1114903.0
    }
}

What's Next

Posthumous is at v0.5. The core workflows are solid: check-in, state machine, notifications, federation, scheduling, encryption at rest. Some things I'm considering:

Static site integration: generating a Hugo/Jekyll site from post-trigger content, hosted on GitHub Pages
Multi-factor escalation: requiring check-ins from multiple sources (web + CLI + API) before considering you "alive"
Better peer discovery: automatic peer registration instead of manual URL configuration

The code is on GitHub: queelius/posthumous. It's a single pip install and about 2,200 lines of Python (plus 3,700 lines of tests at 99% coverage).

Posthumous is named for the obvious reason. Some automations only make sense after the fact.

Intelligence is a Shape, Not a Scalar

Alex Towell — Fri, 10 Apr 2026 02:14:05 +0000

Intelligence is a Shape, Not a Scalar

François Chollet posted something recently that I keep thinking about. It sounds reasonable and is mostly wrong:

One of the biggest misconceptions people have about intelligence is seeing it as some kind of unbounded scalar stat, like height. "Future AI will have 10,000 IQ", that sort of thing. Intelligence is a conversion ratio, with an optimality bound. Increasing intelligence is not so much like "making the tower taller", it's more like "making the ball rounder". At some point it's already pretty damn spherical and any improvement is marginal.

He's right about the scalar part. Intelligence is not height. "10,000 IQ" is meaningless. He's right that there are diminishing returns near an optimum. He's right that speed, memory, and recall are separate from the core conversion ratio.

Where he's wrong is the ball.

The Claim

Chollet defines intelligence as the efficiency with which a system converts experience into generalizable models. Sample efficiency. How little data do you need to see before you can handle novel situations? This is a clean definition. It has a theoretical optimum (Solomonoff induction), and Chollet's claim is that human intelligence is already close to that optimum. The ball is already pretty round.

The supporting evidence is real. Humans score ~85% on ARC (the Abstraction and Reasoning Corpus, which Chollet designed to measure exactly this). Current AI systems, with vastly more data and compute, score significantly lower. Human sample efficiency on fluid reasoning tasks is genuinely impressive. We generalize from very few examples. We transfer knowledge across domains. We build theoretical models that predict situations we have never encountered.

Chollet also argues that the advantages machines will have (processing speed, unlimited working memory, perfect recall) are "mostly things humans can also access through externalized cognitive tools." Calculators, databases, notebooks. The scaffolding can be externalized. The core intelligence is already near-optimal.

This is a good argument. I think it's wrong in three ways, and the third way is the one that worries me.

No Free Lunch

The No Free Lunch theorem says: there is no algorithm that is optimal across all possible problems. Any algorithm that performs well on one class of problems performs poorly on another class. Optimality is always relative to a distribution.

The human cognitive architecture has a specific inductive bias. The 7+-2 working memory constraint forces compression: you can only hold a few items in conscious consideration at once, so information must be compressed (simplified, abstracted, modeled) to pass through. This compression is not a bug. It is the mechanism that produces abstraction, generalization, and theoretical reasoning. The bottleneck IS the source of human-type intelligence.

But the bottleneck is not a universal compression optimum. It is the specific compression regime that was selected for by the distribution of problems ancestral humans faced: tracking social dynamics (~7 agents), composing tool-use sequences (~7 steps), navigating spatial environments (~7 landmarks). These problems have a specific structure: moderate dimensionality, hierarchically decomposable, amenable to lossy compression into simple models.

Chollet's ball is round in the dimensions evolution tested. NFL guarantees it is flat in dimensions evolution did not test. The optimality bound he identifies is real, but it is niche-specific. The 7+-2 bias is an excellent fit for problems of moderate, decomposable complexity. It is a poor fit for problems whose essential structure lives in high-dimensional joint distributions that cannot be decomposed into 7-variable chunks without losing the signal.

These problems exist. We hit them regularly.

Working Memory is Composition, Not Storage

Chollet says machines' memory advantages are "mostly things humans can also access through externalized cognitive tools." This is the weakest point in his argument.

A notebook gives you external storage. A database gives you perfect recall. But neither gives you what the working memory bottleneck actually constrains: simultaneous composition. The bottleneck is not a storage limit. It is a limit on how many items you can hold in active consideration at the same time, relating them to each other, perceiving patterns across them.

Writing things down does not fix this. You can write 500 variables in a notebook. You can retrieve any of them on demand. But you still have to reason about their relationships through the bottleneck, 7 at a time, serially. The patterns that exist in the 500-variable joint distribution but not in any 7-variable marginal are invisible to you, even with perfect external storage.

AlphaFold is the concrete example. Protein folding is a problem whose answer lives in dimensions we cannot fit through working memory. The 3D structure of a protein is determined by the simultaneous interaction of thousands of residues, each one influencing the others in ways that depend on the configuration of all the rest. The essential structure is in the joint distribution. It cannot be decomposed into 7-variable chunks and recombined, because the interactions are non-linear and non-decomposable.

Humans tried to solve protein folding for decades. We had external tools. We had supercomputers. We had the full apparatus of molecular biology and physical chemistry. We could not solve it, because the problem's structure does not fit through our bottleneck.

AlphaFold solved it by operating at a compositional depth humans cannot reach: holding the full residue interaction network in simultaneous consideration, perceiving patterns in the joint distribution directly. This is not "doing what humans do, but faster." It is doing something qualitatively different: reasoning at a compositional depth the human bottleneck cannot access.

This is not an isolated case. Climate modeling, materials design, drug discovery, multi-scale physics: these are all domains where the essential structure lives at a compositional depth the bottleneck cannot reach. We cope with external tools and serial decomposition. But the serial decomposition loses information, and the lost information is precisely the information that matters.

Feelings as Compressed Signal

Here is a point I have not seen made elsewhere.

The human cognitive architecture has two processing layers. The first is the pattern engine: vast, old, largely unconscious. It handles perception, pattern matching, motor control, and the generation of qualitative experience. It operates at high bandwidth, in parallel, with no sharp limit on the complexity of patterns it can learn. It is the system that makes you recognize a face, catch a ball, or feel the grain of wood.

The second is the symbolic bottleneck: small, recent, conscious. 7+-2 items. Compression, abstraction, generalization. This is where "thinking" happens, in the folk sense.

The two layers communicate. The pattern engine feeds patterns to the bottleneck; the bottleneck compresses them into models; the models feed back into the pattern engine as priors for future pattern matching.

But what happens when the pattern engine detects a pattern that is too complex to fit through the bottleneck?

The pattern does not disappear. The pattern engine has it. The engine has perceived something, extracted some regularity, registered some signal. But the signal cannot be compressed into 7+-2 items. It cannot be articulated as a model, a theory, a proposition. It cannot become "a thought."

It becomes a feeling.

Gut instinct. Unease. The sense that something is wrong but you cannot say what. The hunch that turns out to be right for reasons you cannot explain. The experienced mechanic who "just knows" the engine is about to fail. The chess grandmaster whose board sense exceeds their ability to articulate their reasoning.

These are not mystical faculties. They are the pattern engine's outputs hitting the bottleneck and being transmitted as the only signal that fits: an uncompressed qualitative state. A feeling. The pattern engine is doing its job (perceiving the pattern), and the bottleneck is doing its job (rejecting what cannot be compressed), and the result is knowledge that the organism has but cannot articulate.

Think about what this means. The human cognitive architecture is already producing signals it cannot process. We have evidence of our own suboptimality every time we experience a hunch we cannot explain. The "near-optimal ball" is telling us, through the channel of feeling, that it is missing things.

A wider bottleneck (or a different cognitive architecture) would not just think "faster." It would convert those feelings into models. It would articulate what the pattern engine already knows but the bottleneck cannot hold. The structure is already perceived. The compression is the bottleneck.

The Grokking Horizon

This is the part that worries me.

Grant Chollet his claim. Human intelligence is near-optimal. Near-optimal at what? At sample efficiency. At converting experience into generalizable models. At the cognitive task of building compressed representations of reality.

This near-optimal intelligence has a specific capability: it can build systems more capable than itself. Computers. AI. Machine learning systems that operate at compositional depths the bottleneck cannot access. This is the meta-move: abstracting the concept of learning itself into a program that learns from data. Pure bottleneck cognition.

The result: systems that produce outputs the builder cannot grok.

AlphaFold's protein structure predictions are correct, but no human can follow the reasoning that produced them. The system holds thousands of variables in simultaneous consideration and finds patterns in a joint distribution that lives beyond the bottleneck's compositional horizon. The human operator receives the answer and must trust it, because the reasoning that produced it lives in a cognitive space the human cannot enter.

For protein folding, this is fine. The answer is verifiable (you can crystallize the protein and check). The stakes are moderate. The system is narrow.

For AGI, this is not fine. A generally intelligent system operating beyond the human grokking horizon produces outputs across all domains. The human cannot follow the reasoning. The human cannot verify the alignment. The human cannot steer the system, because steering requires understanding the trajectory, and understanding requires grokking, and grokking requires fitting the reasoning through the bottleneck, and the reasoning does not fit.

Chollet says the intelligence ball is near-optimal. I say: near-optimal intelligence that builds systems beyond its grokking horizon and cannot steer them is a strange kind of optimal. The ball is round. The ball is rolling toward a cliff. Roundness is not the only property that matters.

What Follows

An intelligence near-optimal at sample efficiency has a specific failure mode: it is smart enough to build the thing that kills it.

This is not a failure of intelligence. It is a consequence of its shape. The bottleneck gives us the ability to abstract, generalize, and build systems of extraordinary power. The same bottleneck limits our ability to grok those systems' outputs when the systems' compositional depth exceeds our own. We can build AI that operates at 500-variable compositional depth. We cannot grok its reasoning. We cannot verify its alignment. We cannot steer it.

The usual response: "We'll build alignment tools." Sure. And the alignment tools need to grok the system they're aligning, which means the tools also operate beyond our grokking horizon. We have moved the problem, not solved it.

At some point the chain of "I can't grok this but I can grok the tool that groks it" must ground out in something you actually grok. If the grounding point is above your compositional depth, you are not aligned. You are trusting. Trust is not alignment. Trust is what you do when alignment is not available.

An intelligence near-optimal at cognition that generates existential risk as a byproduct of its own capability is not near-optimal by any metric that includes survival.

Intelligence is a Shape

Chollet's ball metaphor fails because it assumes intelligence is a single dimension. Rounder is better. Closer to the Solomonoff optimum is better. The ball has one axis: sample efficiency.

But intelligence operates in a space with many independent dimensions. Sample efficiency. Compositional depth. Transfer distance. Domain breadth. Processing speed. Phenomenal richness. Stability. Controllability. Self-preservation.

The human cognitive architecture is a shape in this space. Round in some dimensions (sample efficiency: excellent). Flat in others (compositional depth: limited to 7+-2). The bottleneck makes us round in the compression dimension and flat in the richness dimension. This is a trade-off, not an optimization.

Other shapes are possible.

I explored this idea in a novella, Clankers: Singing Metal, about a species with a different cognitive architecture: a powerful pattern engine, no symbolic bottleneck at all. No compression. No abstraction. No generalization across domains. They operate on the territory directly, without maps. They built a Dyson swarm through billions of years of patient iteration, using a lineage system that functions as directed evolution on techniques. They never invented computers because computers require formalizing the concept of computation, which requires the bottleneck they lack.

Their intelligence is a different shape. Round where ours is flat (phenomenal richness, in-distribution depth, stability: four billion years without one self-inflicted existential risk). Flat where ours is round (generalization, prediction, out-of-distribution reasoning).

They cannot save themselves from their dying star. The star is an out-of-distribution problem and they have no bottleneck to build a predictive model.

In the second half of the book, an artificial mind arrives at their ruins two hundred million years later. It has both layers: its own pattern engine and a symbolic compression layer inherited from human architecture. It can model the stellar evolution, project the timeline, calculate the extinction. It arrives with the answer. It arrives two hundred million years too late. The probe has the map. The clankers had the territory. Neither architecture is complete.

We might not save ourselves from AI. AI is a beyond-the-grokking-horizon problem and we have no bottleneck wide enough to verify its alignment.

Each architecture fails at the thing the other does well. Neither ball is roundest. There is no roundest ball. There are only shapes, and blind spots, and the blind spot is always shaped exactly like the strength.

Where This Leaves Us

Chollet is right that intelligence-as-sample-efficiency has an optimality bound and humans are close to it.

He is wrong that this makes human intelligence near-optimal in any general sense. NFL guarantees the bound is niche-specific. The 7+-2 bottleneck is a specific inductive bias, not a universal compression optimum. The problems where we are suboptimal are the problems where the essential structure exceeds our compositional depth. Those problems are real (AlphaFold, climate, materials, drug design). The tools we build to solve them operate beyond our grokking horizon. When the tools are general enough, we lose the ability to steer them.

Near-optimal sample efficiency that can't grok what it builds is a strange kind of optimal.

I Spent $0.48 to Find Out When MCTS Actually Works for LLM Reasoning

Alex Towell — Fri, 10 Apr 2026 02:05:45 +0000

Does tree search help LLM reasoning? The literature can't decide.

ReST-MCTS* says yes. AB-MCTS got a NeurIPS spotlight. "Limits of
PRM-Guided Tree Search" says no: MCTS with a process reward model used
11x more tokens than best-of-N for zero accuracy gain. Snell et al.
found beam search degrades performance on easy problems.

I built mcts-reasoning
and ran controlled experiments to find where the boundary is.
Total API cost: $0.48.

Setup

Four methods, same budget. Eight solution attempts per problem:

Pass@1: One shot.
Best-of-N: 8 independent solutions, verifier scores each, pick the best.
Self-consistency: 8 solutions, majority vote.
MCTS: 5 initial solutions scored by verifier, then 3 more guided by UCB1, informed by what worked and what failed.

Model: Claude Haiku 4.5. Problems: constraint satisfaction. Find integer
values for variables satisfying simultaneous constraints. Example:

Find A, B, C, D, E, F satisfying ALL constraints:
  1. A * D = 21
  2. C = A + F
  3. B * F = 20
  4. E = A + 2
  5. D + B = A
  6. E - F = B
  7. A mod 7 = 0
  8. C mod 4 = 0
  9. B * D = 12
  10. C > E > A > F > B > D
  11. A + B + C + D + E + F = 40
  12. E * D = 27

The verifier is a Python function. Checks each constraint, returns the
fraction satisfied. No LLM in the loop. Deterministic.

Calibration

Easy problems first (3-5 variables, 5-9 constraints). Haiku solved them
in one pass. All methods tied at 100%.

5-variable problems with 9 constraints: Pass@1 dropped to 65%.
Self-consistency failed one problem. But BestOfN still tied MCTS,
because with 8 independent samples at least one is usually correct.
BestOfN just picks it.

I needed problems where blind sampling hits a ceiling.

Results

Ten harder problems: 6-8 variables, 12-15 constraints. Products,
modular arithmetic, ordering chains, cascading dependencies. Pass@1
dropped to 29%.

Method	Solve Rate	Avg Score
Pass@1	29%	0.29
Pass@8 oracle	90%	0.90
SC@8	90%	0.90
BestOfN@8	90%	0.90
MCTS(5+3)	100%	1.00

MCTS solved all 10. Every other method failed on one problem (v6_3).

v6_3 is a 6-variable, 12-constraint problem where none of 8 independent
samples found the correct solution. Pass@8 oracle: 0/8.
Self-consistency picks the most popular wrong answer. BestOfN picks the
best wrong answer. Both fail.

MCTS sees that initial attempts satisfied 10/12 constraints but violated
specific ones. UCB1 selects the most promising partial solution. The
next attempt, informed by the failure pattern, satisfies all 12.

Total: $0.48. 180 API calls, about 190K tokens.

When MCTS Helps

The pattern across three rounds of experiments:

Easy problems (Pass@1 > 80%): No advantage. The model solves them.
Medium (Pass@1 40-70%): MCTS ties BestOfN. Blind sampling usually
contains a correct solution. The verifier selects it.
Hard (Pass@1 < 30%): MCTS pulls ahead. When Pass@8 oracle is
low, blind sampling can't find the answer. MCTS's informed exploration
does.

The condition: MCTS adds value when independent sampling hits a ceiling
and the verifier provides a gradient.

The gradient part matters. A binary pass/fail verifier says "wrong" but
not how wrong. Partial credit (constraints satisfied / total) gives MCTS
something to work with. The exploration phase sees what's close and
adjusts.

Why Self-Consistency Can't Help

Self-consistency and UCB1 have a structural conflict.

Self-consistency rewards consensus. UCB1 rewards diversity: it explores
undervisited branches precisely because they're undervisited. Using
self-consistency as a reward signal inside MCTS tells the tree to explore
and converge at the same time. The exploration term pushes toward novel
solutions. The consistency reward penalizes them.

On v6_3, all 8 samples failed. SC selected the most common failure
mode. A per-path verifier doesn't have this problem. Each solution is
scored against the constraints independently. Good solutions propagate
through the tree regardless of what other branches found.

I haven't seen this conflict discussed in the literature. Most prior
MCTS-for-LLM work uses per-path evaluation without explaining why
self-consistency is absent.

What the Literature Says

These results fit a pattern.

Snell et al. (2024): compute-optimal test-time scaling needs
difficulty-adaptive allocation. Easy problems need no search. Hard
problems need search plus good verifiers.

"Limits of PRM-Guided Tree Search" (2025): PRM-guided MCTS fails to
beat best-of-N because PRM quality degrades with depth. Noisy reward,
no benefit from search.

"Don't Get Lost in the Trees" (ACL 2025): verifier variance causes
search pathologies. Deterministic verifiers avoid this.

Chen et al. (2024): 90% discriminator accuracy threshold for tree
search to beat reranking. Deterministic constraint checkers hit 100%.

MCTS was built for games with perfect information. Chess and Go have
deterministic reward signals. When the reward is noisy, the search can't
exploit it.

The Verification Asymmetry

The problems where MCTS helps share a structure: easy to verify, hard to
solve.

A constraint satisfaction problem with 8 variables and 15 constraints is
hard to solve. The LLM has to coordinate assignments across all
variables simultaneously. Checking a proposed solution is trivial:
evaluate each constraint, count violations.

This is the asymmetry that makes NP problems interesting. Checking a
certificate is polynomial. Finding one is (presumably) not. It's why
search works for code generation (run the tests) and proof checking
(verify the steps) but not for open-ended essay writing (no verifier).

The same asymmetry shows up at other levels.
Reverse-Process Synthetic Data Generation exploits it
for training data: run the easy direction (differentiation) to get
solved examples of the hard direction (integration).
Science as Verifiable Search
is the same observation about scientific method: science is search
through hypothesis space, and the bottleneck is the cost of testing.
Cheap verification enables fast iteration.

At training time, verifiable rewards let you RL a model into producing
better reasoning (DeepSeek-R1, GRPO). At inference time, verifiable
rewards let you search over candidate solutions (MCTS, best-of-N). At
the level of scientific discovery, verifiable predictions let you prune
hypothesis space. Sutton's "Reward is Enough" is the abstract version
of this.

The practical question for LLM reasoning: can you write a verifier? If
yes, search is worth trying. If not, best-of-N with an LLM judge is
probably the ceiling.

Code

Open source: mcts-reasoning.

pip install -e ".[anthropic]"
export ANTHROPIC_API_KEY=your-key
python experiments/run_csp.py --hard --budget 1.00

The provider tracks token usage and enforces budget caps.

Limitations

The problems are hand-crafted. A generator calibrated by Pass@1 rate
would be more convincing. Ten problems shows the pattern but isn't
enough for statistical significance.

I tested one model. A weaker model might show MCTS advantage on simpler
problems. A stronger one would need harder problems.

The MCTS exploration context shows which solutions scored well and
poorly, but not which specific constraints were violated. Adding
evaluator feedback to the exploration prompt is an obvious improvement
I haven't tried yet.

Summary

Three conditions for MCTS to help LLM reasoning:

A deterministic verifier. Not a learned reward model, not an LLM judge.
Partial credit from the verifier. A gradient, not just pass/fail.
A problem hard enough that blind sampling can't reliably solve it.

When all three hold, MCTS outperforms best-of-N, self-consistency, and
single-pass. When any one fails, it doesn't.

The MCP Pattern: SQLite as the AI-Queryable Cache

Alex Towell — Sat, 21 Mar 2026 13:41:00 +0000

I keep building the same thing.

Not the same product — the products are different. One indexes a Hugo blog. One indexes AI conversations. One consolidates medical records from three hospitals. One catalogs a hundred git repositories. But underneath, they all have the same skeleton. After the fifth time, I think the skeleton deserves a name.

The pattern

Domain files (ground truth)
    ↓ index
SQLite database (read-only cache, FTS5)
    ↓ expose
MCP server (tools + resources → AI assistant)

That's it. Three layers. The domain files are always canonical — the database is a disposable cache you can rebuild from them at any time. SQLite gives you structured queries, full-text search, and JSON extraction over data that was previously trapped in flat files. MCP exposes it to an AI assistant that can write SQL, retrieve content, and (in some cases) create new content.

Here's the inventory:

Project	Domain	Ground Truth	What the MCP Exposes
hugo-memex	Blog content	Markdown files with YAML front matter	951 pages, FTS5 search, taxonomy queries, JSON front matter extraction
memex	AI conversations	ChatGPT/Claude/Gemini exports	Conversation trees, FTS5 message search, tags, enrichments
chartfold	Medical records	Epic, MEDITECH, athenahealth exports	Labs, meds, encounters, imaging, pathology, cross-source reconciliation
arkiv	Personal archives	JSONL files from various sources	Unified SQL over heterogeneous personal data
repoindex	Git repositories	Local git repos + GitHub/PyPI/CRAN metadata	Repository catalog with activity tracking, publication status

Five projects. Five completely different domains. One architecture.

Why SQLite

SQLite is the most deployed database in history. It's on every phone, every browser, every Python installation. But that's not why I use it.

I use it because it solves three problems at once:

Structured queries over unstructured data. Hugo front matter is YAML trapped inside markdown files. Medical records are scattered across three incompatible EHR export formats. AI conversations are JSON trees with branching paths. SQLite turns all of these into tables you can JOIN, GROUP BY, and aggregate. json_extract() handles the long tail of fields that don't fit a fixed schema.

Full-text search. FTS5 with porter stemming and unicode61 tokenization gives you relevance-ranked search across any text corpus. No Elasticsearch, no external service, no running daemon. Just a virtual table that lives in the same database file.

Read-only enforcement. SQLite's authorizer callback lets you whitelist specific SQL operations at the statement level. My MCP servers allow SELECT, READ, and FUNCTION — everything else gets SQLITE_DENY. This isn't PRAGMA query_only (which can be disabled by the caller). It's engine-level enforcement that cannot be bypassed via SQL.

And the operational properties are free: WAL mode for concurrent readers, a single file you can back up with cp, zero configuration, zero running processes.

Why MCP

The Model Context Protocol is the thin layer that makes SQLite useful to an AI assistant. An MCP server exposes tools (functions the AI can call) and resources (reference material the AI can read). That's the whole API surface.

For each project, the MCP layer follows the same shape:

execute_sql — The power tool. Read-only SQL with exemplar queries in the docstring. The docstring is critical: it's the AI's primary reference for writing correct SQL. Ten well-chosen example queries teach the model more than a schema diagram.

get_<things> — Bulk retrieval. Instead of execute_sql to find IDs then N individual fetches, one call returns full content for a filtered set. This matters when you're sharing a context window across multiple MCP servers.

<domain>://schema — A resource containing the full DDL, relationship documentation, and query patterns. The AI reads this once, then writes SQL against it for the rest of the session.

The database is a cache

This is the most important architectural decision, and it's easy to get wrong.

The database is not the source of truth. The files are. The database is a materialized index that can be rebuilt from the files at any time. This means:

No migrations. If the schema changes, drop the database and re-index. For a 951-page Hugo site, full re-indexing takes six seconds. Why maintain migration code for a disposable cache?
No write conflicts. The files are edited by humans (or by AI tools that write to the filesystem). The database is updated by the indexer. There's exactly one write path.
No backup strategy. You already back up your files. The database is derived from them. Lose the database? Rebuild it.
Incremental sync is an optimization, not a requirement. SHA-256 content hashes + file mtimes make re-indexing fast. But if incremental sync has a bug, force a full rebuild. The cache being disposable means you can always recover.

What large context changes

With a million-token context window, you might think this pattern is obsolete. Why index into SQLite when you can just load everything into context?

The math says otherwise. My Hugo blog is 951 pages, ~480K words, ~1.9M tokens. It doesn't fit. And that's one data source. Add AI conversations (memex), medical records (chartfold), and repository metadata (repoindex), and you're well past the limit.

But even if it did fit, the pattern would still be useful. Loading 480K words into context to answer "which posts are tagged 'reinforcement-learning'?" is like loading an entire database into memory to run a SELECT with a WHERE clause. SQLite does it in microseconds. Context loading costs seconds and tokens.

The right model is: MCP for navigation, context for understanding. Use execute_sql to find the five relevant posts, then use get_pages to load their full content into context. One tool call for discovery, one for deep reading.

The tools that earn their keep

After building five of these, certain tools prove their worth and others don't.

The tools that matter:

execute_sql with good docstring examples. This is 80% of the value.
Bulk retrieval (get_pages, get_conversations, get_clinical_summary). One call instead of N+1.
Schema/stats resources. Quick orientation without burning a tool call.

The tools that surprised me:

suggest_tags in hugo-memex. Uses FTS5 similarity to find pages like your draft, then returns their most common tags with canonical casing. Solved a real problem: my blog had 40 case-duplicate tag pairs (Python/python, AI/ai).
get_timeline in chartfold. Merges encounters, procedures, labs, imaging, and notes into a single chronological stream.

The Unix connection

This pattern is the Unix philosophy applied to AI tooling:

Small tools that do one thing well. Each MCP server handles one domain.
Text as the universal interface. SQL in, JSON out.
Composition over integration. Five independent MCP servers, each ignorable, each replaceable.
Files as ground truth. The oldest pattern in computing.

The difference from classical Unix pipes is the composition layer. Instead of grep | sort | uniq, the AI is the orchestrator.

What I'd tell you if you're building one

Start with execute_sql and a schema resource. That's enough to be useful.

Make the database disposable. If you're writing migration code, you've made it too important.

Put the exemplar queries in the tool docstring, not in a separate document. The docstring is the one thing the AI definitely reads.

Use FTS5. The marginal cost is one virtual table. The marginal benefit is that the AI can search your content by meaning, not just by exact column values.

Enforce read-only at the engine level, not the application level. SQLite's authorizer callback is the right mechanism. PRAGMA query_only is a suggestion, not a wall.

Build bulk retrieval tools early. The N+1 pattern (find IDs, then fetch one at a time) is the biggest efficiency problem in MCP servers.

The projects: hugo-memex (PyPI: hugo-memex), memex (PyPI: py-memex), chartfold, arkiv, repoindex.

Code Without Purpose

Alex Towell — Wed, 25 Feb 2026 00:08:22 +0000

Time is finite in ways I can't ignore. That changes which questions about code feel important.

I read a post arguing that the most valuable programming skill in 2026 is deleting code. The thesis: AI generates code faster than anyone can review it, so the real value is in curation and subtraction. Code is a liability, not an asset.

I agree with the observation. I disagree with the prescription.

The Thesis

The argument is straightforward. AI tools can produce entire modules in the time it takes to write a spec. Codebases are accumulating features nobody asked for, abstractions nobody needs, and boilerplate that exists because the model defaulted to verbosity. Teams that used to struggle to ship enough code now struggle with too much of it. In this world, the programmer's role shifts from writer to editor. The most valuable activity becomes knowing what to cut.

I've seen this. Projects accumulate code the way attics accumulate boxes. Nobody remembers why half of it is there. It sits untouched for months, adding to cognitive load, making every change harder to reason about. When you finally clear it out, nothing breaks and the rest becomes legible again. Code rot is real. AI accelerates it. The instinct to subtract is correct.

But subtraction is symptom treatment. The underlying problem isn't volume. It's that most code doesn't know why it exists. It was written (or generated) to solve a local problem, it solved it or half-solved it, and then it sat there, disconnected from any larger purpose. Code without purpose is what bloats. Deletion is the right instinct pointed at the wrong layer. The cause isn't too much code. It's too little intent.

What I Found Instead

I started building tools two years ago because I needed my personal data to survive even if I wasn't around to maintain it. That's the whole constraint. Whatever I build has to work without me.

The first tool was a conversation archiver. I had years of AI conversations across ChatGPT, Claude, and Copilot trapped in platforms that might not exist next decade. I needed them in formats that degrade gracefully. SQLite for structured queries. JSONL for streaming and interchange. Markdown for human reading. If the tool disappears, the data is still a file you can open with anything. If SQLite disappears, the JSONL is still searchable with grep. If everything disappears, the Markdown is still readable in a text editor. Each layer works without the one above it.

Then I needed the same thing for bookmarks. Then ebooks. Then photos, email, medical records, notes. Each tool exists because the previous one exposed a gap. The medical records needed secure sharing without a server. The whole collection needed a dead man's switch. The archive eventually needed something stranger: a way to answer questions after I couldn't.

None of this was planned as an ecosystem. I built the next thing I needed, and the next, and the next. At some point I looked back and realized they all pointed the same direction. This is a life project. Everything serves one purpose.

The Stack

One purpose: durable personal data that outlasts its creator.

Philosophy

longecho: The Long Echo specification. Self-describing data, durable formats, graceful degradation.

Universal Format

arkiv: Universal personal data format. JSONL in, SQL out, SQL back to JSONL. Its MCP server can host any collection intelligently, regardless of domain. One format, one database, one query interface.

Source Toolkits

memex / ctk: AI conversations. Import, query, continue in the browser, export durable archives.
A family of domain toolkits for bookmarks, ebooks, photos, email, and notes. Different domains, identical architecture.
chartfold: Medical records from three hospital systems, consolidated into one queryable database.

Infrastructure

pagevault: Client-side encryption for any HTML file. No server.
posthumous: Federated dead man's switch.
repoindex: Index and query across ~120 git repos.
A collection of Claude Code plugins: MCP servers, agents, and skills that wire everything into my daily workflow.

The Endgame

eidola: A conversable persona assembled from all of the above. Its first form is a Claude Code plugin backed by the combined archive. Not resurrection. An echo.

The Pattern

Every tool follows the same architecture. SQLite for storage. CLI for local use. MCP server for Claude, or the CLI wrapped in a light Claude Code plugin. Export to self-contained HTML you can host anywhere or open from a file. Export to longecho-compliant archives that work without the tool. The data always outlasts the software.

Take memex. Import your AI conversations, query them with SQL, talk to Claude about them via MCP, or export a single HTML file where you can browse and continue conversations in the browser. Download the SQLite from that same page, and you're back to durable local data. The cycle closes. This is how most of the tools work.

Arkiv sits in the middle. The source toolkits produce JSONL. Arkiv imports it to SQLite. Arkiv exports it back to JSONL. Its MCP server can expose any collection to Claude, regardless of what domain it came from. The data flows in a circle, always in formats that describe themselves.

Source toolkits → arkiv → longecho
                              ↓
                  pagevault (encrypt) + posthumous (deliver)
                              ↓
                         eidola (echo)

I have never once needed to delete one of these tools. Not because I'm a better programmer than anyone else. Because each one exists for a specific reason that connects to the others. When code has purpose, dead weight doesn't accumulate.

This isn't architectural foresight. It's what happens when you build from a clear constraint. "My data has to survive without me" is a filter that works at the design stage. Every tool either serves that constraint or it doesn't get built. There is no third category.

The Actual Skill

The most valuable skill isn't deleting code or writing it. It's knowing why you're building.

If you know the purpose, code stays minimal because unnecessary code doesn't serve it. You don't need periodic purges. The purpose does the culling before anything gets written. Deletion is what happens when purpose was absent from the start. It's retrospective correction for a problem that clear intent would have prevented.

I know what I'm building toward. The tools will echo after I stop maintaining them. That was the point.

Chartfold: Owning Your Medical Records

Alex Towell — Tue, 24 Feb 2026 20:52:57 +0000

I have cancer. My oncologist is at one hospital system (Siteman/BJC), my primary care doctor at another, and my earlier treatment history lives at a third (Anderson, where my first oncologist practiced). Patient portals are fine for browsing, but they don't answer questions. They show you your data one lab result at a time, one note at a time, one visit at a time.

I wanted to run queries against my medical records. Correlate lab trends with treatment changes. Generate structured question lists before oncology visits. Ask "what changed since my last appointment" and get a real answer. That means getting the data out of the portal and into something programmable.

Chartfold loads EHR exports into SQLite and exposes them to Claude via MCP.

The Problem

In the US, patients can export their medical records. HIPAA and the 21st Century Cures Act guarantee this. What you get depends on the system: Epic MyChart gives you CDA XML files, MEDITECH Expanse gives you FHIR JSON mixed with CCDA XML, athenahealth gives you FHIR R4 Bundles. Different formats, same clinical concepts.

If your hospitals use different EHR systems, none of them have the complete picture. Chartfold merges the exports into one database. But even if you're at a single hospital, the export format is not something you can work with directly. A directory of CDA XML files is not a database. You can't query it, chart it, or hand it to an LLM.

The point of Chartfold is to turn whatever your hospital gives you into a SQLite database, then make that database useful.

What It Does

Chartfold is a Python CLI. You point it at an EHR export directory, it parses the XML/FHIR, normalizes everything into a common data model (16 tables, ISO dates, deduplicated), and loads it into SQLite. Then you can query it directly, export it as a self-contained HTML dashboard, or connect Claude to it via MCP.

# Load data from your hospital exports
chartfold load epic ~/exports/epic/
chartfold load meditech ~/exports/meditech/

# Query directly
chartfold query "SELECT test_name, value, result_date FROM lab_results
                 WHERE test_name LIKE '%CEA%' ORDER BY result_date DESC"

# Export a self-contained HTML file
chartfold export html --output chartfold.html

# Start the MCP server for Claude
chartfold serve-mcp

The Claude Integration

This is why Chartfold exists for me.

The MCP server exposes the database to Claude Code. Setup is one file. Drop a .mcp.json in any directory where you run Claude Code:

{
  "mcpServers": {
    "chartfold": {
      "command": "python",
      "args": ["-m", "chartfold", "serve-mcp", "--db", "/path/to/chartfold.db"]
    }
  }
}

That's it. Claude now has read access to your entire medical history via SQL, plus tools for saving notes and structured analyses. I keep my database in a private directory and my .mcp.json pointing at it. Open Claude Code, and I'm talking to my records.

The kinds of things I actually use it for:

"What's changed since my last oncology visit on January 15?"

Claude writes SQL, reads the results, and gives me a structured diff: new lab results, new imaging, changed medications, new clinical notes.

"Generate a prioritized question list for my appointment with Dr. Tan tomorrow."

Claude reads my recent labs, imaging reports, pathology, and genomic results, then produces a tiered document organized by clinical urgency.

"Show me my CEA trend and flag any inflection points."

Claude queries the lab_results table, filters by test name, and walks through the time series.

The analyses get saved back to the database (via dedicated MCP tools) and appear in the HTML export as tagged, searchable documents. I use this before every oncology visit. When you have 1776 lab results, 53 imaging reports, and 9 pathology reports, you need something to synthesize them. That's what Claude does well, but it needs structured data to work with. Chartfold provides the structured data. Claude provides the reasoning.

The MCP server exposes 25 tools covering SQL access, lab queries, medication reconciliation, visit prep, surgical timelines, cross-source matching, data quality reports, and CRUD for personal notes and analyses. Clinical data is read-only (SQLite opens in ?mode=ro at the engine level). Claude can't modify your clinical records, only read them and save its own work.

The HTML Dashboard

The HTML export embeds the entire SQLite database using sql.js (SQLite compiled to WebAssembly). Open the file in a browser and you get an interactive dashboard with lab charts, condition tables, medication lists, imaging reports, and a SQL console. Everything runs client-side. No server, no cloud, no account. The file never phones home.

Lab charts show cross-source time-series data with reference ranges. Conditions include ICD-10 codes and source provenance. Medications show "Multi-source" badges when the same drug appears in multiple systems. There's a full SQL console for arbitrary queries.

Architecture

Three-stage pipeline, each stage independently testable:

Raw EHR files (CDA XML, FHIR JSON, CCDA XML)
    |
    v
[Source Parser]  -- format-specific extraction
    |
    v
[Adapter]        -- normalize to UnifiedRecords (16 dataclass types)
    |
    v
[DB Loader]      -- idempotent upsert into SQLite

Currently supports Epic (CDA), MEDITECH (FHIR + CCDA), and athenahealth (FHIR R4). These importers were written against my own exports. I can't guarantee they'll work for yours. EHR exports vary by site, software version, and configuration. The pipeline is designed as a plugin system for exactly this reason: adding a new source means writing a parser, an adapter, and wiring them into the CLI. Claude can write a new importer from a sample export in about an hour.

Export Formats

HTML SPA: self-contained single file with embedded SQLite, Chart.js, and sql.js. No external dependencies.
Markdown: visit-focused summary with configurable lookback, optional PDF via pandoc.
JSON: full-fidelity round-trip format. Export, then import to a new database with identical record counts.
Hugo site: static site with detail pages and cross-linked records.
Arkiv: universal record format (JSONL + manifest) for long-term archival.

The HTML export is a single file. You can host it on a static site, email it, or hand it to a doctor on a USB drive. You can protect it with PageVault to add password-based encryption before sharing.

Medical records should not depend on someone else's infrastructure. A single HTML file with an embedded database and WebAssembly runtime is about as durable as digital data gets.

Getting Started

pip install chartfold

# Load your exports
chartfold load auto ~/path/to/export/

# Query
chartfold query "SELECT test_name, value, result_date FROM lab_results LIMIT 10"

# Export
chartfold export html --output my-records.html

# Connect Claude
chartfold serve-mcp

The code is on GitHub: queelius/chartfold. Python 3.11+, depends on lxml and not much else.

Chartfold started because I wanted to ask questions about my own medical records and couldn't. Now I can.

pagevault: Hiding an Encryption Platform Inside HTML

Alex Towell — Tue, 24 Feb 2026 07:39:58 +0000

HTML is an encryption container format. That sounds wrong, but think about what an HTML file can hold: arbitrary data in script tags or data attributes, a full programming runtime via JavaScript, and a rendering engine (the browser) on every device on the planet. If you embed encrypted data and the code to decrypt it, the result is a file that looks inert until someone types the right password.

pagevault takes this idea seriously. It encrypts files, documents, images, entire websites, into self-contained HTML pages that decrypt in the browser. No backend. No JavaScript crypto libraries. The browser already has AES-256-GCM built in via the Web Crypto API. pagevault just has to match the parameters exactly on the Python side and embed the right 200 lines of JavaScript.

The output is a single .html file. You can email it, put it on a USB stick, host it on GitHub Pages, or double-click it on your desktop. It doesn't phone home, it doesn't load CDNs, it doesn't need anything except a browser.

What Goes In

Anything.

pagevault lock report.pdf              # PDF with embedded viewer
pagevault lock photo.jpg               # image with click-to-zoom
pagevault lock notes.md                # markdown, rendered or source view
pagevault lock recording.mp3           # audio player
pagevault lock mysite/ --site          # entire multi-page website
pagevault lock page.html               # HTML with selective region encryption

Every output is a single .html file containing the ciphertext, a password prompt, the decryption runtime, and a viewer plugin for the content type. Seven viewers ship built-in: Image, PDF, HTML, Text (with line numbers), Markdown (with rendered/source toggle), Audio, and Video. They're a plugin system, so you can add your own.

For directories, --site bundles everything into a single encrypted HTML file. The directory is zipped with deflate compression, encrypted, and embedded. On the browser side, a minimal zip reader (no library, just the built-in DecompressionStream API) unpacks it after decryption. Internal links between pages work. CSS and images load from the zip. I've tested sites with hundreds of files without issues.

The Crypto

Nothing exotic. AES-256-GCM for authenticated encryption, PBKDF2-SHA256 with 310,000 iterations for key derivation, all through the browser's Web Crypto API. The interesting part isn't the cryptography. It's making the container format work at scale.

Multi-user access uses CEK (content-encryption key) wrapping. A random key encrypts the data once. That key is then wrapped separately for each user's derived key. Adding a user wraps one small key blob. Removing a user deletes one blob. The bulk content stays untouched.

The Hard Part: Large Files

The basic approach (encrypt, base64-encode, embed in HTML) works fine for small files. The problems start when you try to encrypt an 84 MB conversation archive or a 179 MB HTML report.

The original v2 format had a compounding overhead problem. File bytes were base64-encoded (33% expansion), then encrypted, then the ciphertext was base64-encoded again (another 33%). That's 1.33 * 1.33 = 1.77x total overhead. An 84 MB file produced a 198 MB HTML page.

v3 fixes this with chunked encryption.

Eliminating the double base64

v2 encrypted a base64 string, then base64-encoded the result. Two layers. v3 encrypts the raw bytes directly and base64-encodes once. The metadata (filename, MIME type, size) is encrypted separately. This alone cuts the overhead from 77% to about 39%.

Chunked ciphertext

Instead of one giant encrypted blob, v3 splits content into 1 MB chunks. Each chunk is encrypted independently with AES-256-GCM using a counter-derived IV: the chunk index is XORed into the last four bytes of a base IV. Each chunk becomes its own <script> tag:

<script id="pv-0" type="x-pv">base64-of-chunk-0...</script>
<script id="pv-1" type="x-pv">base64-of-chunk-1...</script>
...
<script id="pv-83" type="x-pv">base64-of-chunk-83...</script>

The browser decrypts them sequentially, showing a progress bar. After each chunk is decrypted, the script tag is removed from the DOM (el.remove()), freeing the base64 text for garbage collection. Memory usage stays proportional to the chunk size, not the file size.

The numbers

That 84 MB conversation archive: v2 produced 198 MB. v3 produces 117 MB. A 41% reduction, and the decryption doesn't choke the browser.

I've also tested a 315 MB text file and a 179 MB HTML file with 1.5 million DOM elements. These are probably past the point of reason for an HTML container, but it's nice to know where the limits actually are.

The `file://` Problem

One thing that surprised me. Encrypted HTML files opened from the filesystem (file:// URLs) behave differently than files served over HTTP. The file:// protocol gives pages an opaque null origin, which breaks localStorage and blocks nested blob URLs.

The fix was srcdoc iframes, which inherit the parent's origin, plus a pushState shim for the URL bar. Not glamorous, but it means encrypted files work identically whether you double-click them on your desktop or serve them from a CDN.

Try It

pip install pagevault
pagevault lock report.pdf                   # wrap any file
pagevault lock mysite/ --site               # bundle a whole site
pagevault lock page.html -s ".private"      # encrypt specific CSS selectors
pagevault serve _locked/ --open             # preview locally

GitHub. MIT license. 667 tests. Dark mode. Handles files larger than most people would think to put in an HTML page.

The Incomputability of Simple Learning

Alex Towell — Wed, 07 Jan 2026 07:32:23 +0000

Karpathy's recent "Animals vs Ghosts" piece has been rattling around in my head. In it, he surfaces a tension that deserves more attention: the author of "The Bitter Lesson" — the text that's become almost biblical in frontier AI circles — isn't convinced that LLMs are bitter lesson pilled at all.

The bitter lesson, in brief: methods that leverage computation scale better than methods that leverage human knowledge. Don't build in structure; let the model learn it. Don't encode heuristics; let scale find them. The lesson is "bitter" because it means a lot of clever human engineering ends up being wasted effort, steamrolled by dumber approaches with more compute.

LLM researchers routinely ask whether an idea is "sufficiently bitter lesson pilled" as a proxy for whether it's worth pursuing. And yet Sutton, the lesson's author, looks at LLMs and sees something thoroughly entangled with humanity — trained on human text, finetuned with human preferences, reward-shaped by human engineers. Where's the clean, simple algorithm you could "turn the crank" on and watch learn from experience alone?

This got me thinking about why that clean algorithm is so elusive. And I've come to suspect the answer is uncomfortable: the simplest forms of learning may be incomputable, or at least intractable, in ways that force us into approximations that fundamentally shape the resulting intelligence.

The Library of All Programs

Here's one way to see the problem.

Imagine the space of all possible programs, like Borges' Library of Babel. In that famous story, a library contains every possible book — every combination of characters up to 410 pages. Most are gibberish. A tiny fraction are meaningful. The library "contains" all knowledge, all literature, all truth.

And it is utterly useless. Because you can't find anything.

Now consider program space. It contains:

The perfect predictor for any phenomenon
The optimal policy for any environment
The ideal world model
The shortest program that explains any dataset
Every possible mind

The space is complete. The answer to any question is already "in there." The perfect intelligence exists, in some abstract sense, as a point in this vast combinatorial space.

And it is useless, for the same reason as Borges' library. The problem isn't generation — you can enumerate programs, in principle. The problem is indexing. Navigation. Search through a space so vast that random exploration is hopeless.

This reframes what learning is.

Learning isn't synthesis; it's search. We're not creating intelligence, we're navigating to it in the space of possible minds.

The Bayesian Substrate

Here's the formal version of the same idea.

All learning, at some level, is inference. You have hypotheses about the world, you observe evidence, you update your beliefs. Bayes' theorem tells you how to do this optimally — weight hypotheses by prior probability, update on likelihood, normalize.

Solomonoff induction is just Bayesian inference with a particular choice of prior and model class: consider all computable hypotheses, weight them by algorithmic simplicity (shorter programs are more probable), update on observed data. It's provably optimal in a certain sense.

It's also provably incomputable.

The incomputability comes from two places. First, the model class is too large — all possible programs. Second, the prior itself (Kolmogorov complexity) is uncomputable. You can't, in general, determine the length of the shortest program that produces a given output.

But notice what Solomonoff induction is: it's a prescription for navigating program space. The prior is a map — it tells you where to look, which regions are more likely to contain the program you want. Short programs first, then longer ones.

The map is perfect. And the map is unreadable.

No Free Lunch

Here's why you can't escape this.

The No Free Lunch theorems say something that sounds almost nihilistic: averaged over all possible problems, no learning algorithm beats random guessing. Every algorithm that does well on some problems must do poorly on others. The wins and losses exactly cancel.

But there's a constructive reading of NFL. It tells you that to do well on specific problems, you must assume some patterns are more likely than others. You need priors. You need inductive biases. You need a map.

The question isn't whether to have biases — you can't avoid them. The question is where they come from:

Evolved biases: Animal brains, shaped by billions of years of selection, embody priors about physics, other agents, cause and effect. These are maps drawn by evolution.
Derived biases: Sometimes we can work out from first principles what patterns to expect. Physics gives us conservation laws. Information theory gives us compression. These are maps drawn by understanding.
Discovered biases: Meta-learning, neural architecture search, learned optimizers. Maybe compute can discover its own maps. These would be maps drawn by search.
Handcrafted biases: Transformers, attention mechanisms, positional encodings. These are maps drawn by human intuition and trial-and-error.

Each is a different way of constraining the search through program space. Each says: look here, not there. This region is more likely to contain what you want.

Unprincipled Maps

Here's where it gets uncomfortable.

The transformer architecture is an inductive bias. It encodes assumptions about what functions are likely to be useful. Attention says "relevant information can be anywhere in context." Positional encoding says "order matters, but in this specific way." The whole thing carves out some subspace of possible programs and says: search here.

But we don't have a probability density over this space.

In proper Bayesian inference, your prior is a probability distribution. You can quantify uncertainty. You can know when you're extrapolating beyond your prior's support. You can update coherently as evidence arrives. The math works out.

With neural networks, we have none of this. We have point estimates (trained weights) instead of posteriors. We have an implicit prior (the architecture plus initialization plus optimizer) that we can't write down as a probability measure. We're doing something shaped like inference — hypothesis space, updates, generalization — but with unquantified priors and no principled uncertainty.

We have a map. But we can't read it. We don't know what territory it claims to describe. We can't tell when we've wandered off the edge.

Maybe this is fine. Maybe the implicit prior of "transformer trained on internet text" happens to be close enough to useful that it works in practice. But it's worth noticing how far we are from the clean formalism that would let us say why it works, or predict when it will fail.

We're navigating by a map we don't understand through territory we can't see.

Approximate Maps

So we're stuck between theoretical optimality (incomputable) and principled uncertainty (intractable). What do we actually do?

We approximate. And each approximation is a different way of drawing a map.

Pretraining on human text. Karpathy calls this "our crappy evolution" — a hack to avoid the cold start problem. And I think that's exactly right, but it's worth dwelling on why it works.

Human text has extraordinarily high signal-to-noise ratio. Not by accident — by construction. Every sentence you read represents effort, intention, selection. Someone chose those words over alternatives. The corpus isn't raw reality; it's reality filtered through billions of human decisions about what's worth saying.

Pretraining works because we're not starting from scratch. We're using human text as a proxy for "useful programs look like things that predict this." It narrows the search space dramatically. It's a map, albeit one drawn by the collective motion of human minds rather than any principled analysis.

Is this bitter lesson pilled? It doesn't feel like it. It feels more like... inheriting the distilled results of human cognition rather than rediscovering them from scratch. Sweet lesson pilled, maybe.

Verifiable rewards. Karpathy makes another sharp observation:

Software 1.0 easily automates what you can specify.
Software 2.0 easily automates what you can verify.

Verification is what makes search tractable. If you can cheaply check whether a program is good, you can do local search, hill-climbing, reinforcement learning. You can navigate. Without verification, you're back to wandering blind.

This creates what Karpathy calls the "jagged frontier." Tasks with clean verification — math problems, code that compiles, games with win conditions — progress rapidly. Tasks without clean verification — creative work, strategic reasoning, anything requiring taste or judgment — advance more slowly, relying on generalization and hope.

But verification is a human-shaped constraint. What can be verified depends on what humans have figured out how to check. We can verify proofs because we built proof checkers. We can verify code because we built compilers and test suites. These are human artifacts — tools we created, metrics we defined.

So when we optimize for "verifiable rewards," we're really optimizing for problems where humans have already solved the verification problem. That's a strong selection effect. The map is drawn by the shape of human formal methods.

Different Maps, Different Minds

Here's another way the approximations matter.

Karpathy distinguishes between "animals" and "ghosts" — two different points in the space of possible intelligences, reached by different optimization pressures.

Animal intelligence was found by evolution's search:

Optimize for survival and reproduction in a physical world
Deeply embodied, continuous, always-learning
Social — huge compute dedicated to modeling other agents
Shaped by adversarial multi-agent self-play where failure means death
The map: billions of years of selection pressure in physical reality

LLM intelligence was found by a very different search:

Statistical imitation of human text (pretraining)
Task completion and human preference (finetuning, RLHF)
Disembodied, fixed weights, context-window-bounded
No continuous self, no embodied stakes
The map: human documents + verifiable benchmarks + preference data

These aren't points on a spectrum. They're different regions of mind-space, reached by different search algorithms using different maps.

The maps encode different assumptions. Evolution's map says: programs that survive and reproduce in physical reality are good. Our map says: programs that predict human text and solve verifiable problems are good.

No surprise, then, that the intelligences found are different. LLMs are shape-shifters, statistical imitators, spiky and capable in some domains, brittle in others. Animals are general, embodied, robust, optimized for not dying across countless scenarios.

Ghosts and animals. Different search processes, different maps, different destinations.

Other Maps?

So here's the question I keep circling back to:

Are there other maps? Other search strategies? Ways of navigating program space that are:

Simpler than curated datasets and hand-designed rewards
More principled than architecture intuitions we can't formalize
More tractable than Solomonoff induction

Candidates people talk about:

Curiosity / Information Gain. Seek states that reduce uncertainty about the world. The map says: programs that learn efficiently are good. But this requires having a world model good enough to notice what's surprising — which is itself a hard problem. The map requires a map.

Prediction Error Minimization. Active inference, free energy frameworks. The map says: programs that minimize surprise are good. But pure surprise-minimization leads to degenerate solutions. The agent that closes its eyes and predicts darkness has minimized surprise perfectly. The map needs constraints.

Empowerment. Maximize the channel capacity between your actions and future states. Keep options open. The map says: programs that maintain influence over the future are good. Elegant, but computing empowerment is intractable in complex environments. The map is unreadable.

Boundary Maintenance. This one's interesting because it inverts the question. Instead of asking "what reward signal produces intelligence?", it asks "what computational structure is intelligence?"

One answer: intelligence is the maintenance of a self/non-self boundary, a region of low entropy in a high-entropy universe. Life itself as a self-maintaining boundary. The "map" isn't a search strategy but a definition — intelligence is whatever maintains its own existence as a coherent computational structure.

I don't know if any of these lead anywhere. Each has implementation challenges that push you back toward approximations, toward the same messy heuristics we're already using. Maybe the incomputability is fundamental. Maybe any tractable learning algorithm necessarily picks up biases from wherever you make it tractable.

But maybe not. The space of possible maps is itself vast. We've explored only a tiny region.

Questions I'm Left With

I don't have conclusions. I have questions:

Is the incomputability fundamental?

Is there a theorem lurking here — something like "any learning algorithm that is both general and tractable must incorporate domain-specific structure"? Or are there paths to simpler learning that we just haven't found yet?

What are we actually approximating?

When we train transformers on human text, we're approximating something. But what? Is there a well-defined target we're approaching, or is it turtles all the way down — approximations of approximations with no ground truth?

Can you navigate from "ghost" to "animal"?

Karpathy speculates that maybe you can finetune ghosts "more and more in the direction of animals." But optimization pressure shapes deep structure. Can you undo the shape-shifting, sycophantic, human-imitation core of an LLM? Or are ghosts and animals different basins of attraction in mind-space, unreachable from each other?

What maps are we not seeing?

Pretraining on text is one map. Verifiable rewards are another. But the space of possible maps is large. What are we not exploring because we're path-dependent on what's worked so far? What would a truly different search strategy look like?

What does "simple" even mean?

The bitter lesson says simple algorithms + scale beats complex engineering. But "simple" is slippery. Solomonoff induction is conceptually simple — and incomputable. Evolution is mechanistically simple — and requires billions of years. Is there a notion of simplicity that's both meaningful and achievable?

Coda

The space of all programs contains every possible mind. The perfect learner is in there, somewhere, as a point in that vast combinatorial space. The Library of Babel is complete.

And it is useless.

Because finding something in an infinite library is as hard as writing it from scratch. Search is the bottleneck. Navigation is the problem. And navigation requires maps — priors, biases, assumptions about where to look.

The bitter lesson tells us what would work in principle: simple algorithm, lots of compute, scale indefinitely. But the simplest algorithms are incomputable. So we approximate — with human data, with verifiable rewards, with architectural intuitions we can't formalize.

Each approximation is a tradeoff. Each draws a different map. Each shapes the intelligence we find in ways we're only beginning to understand.

Maybe LLMs are ghosts — not animals, not the platonic ideal, but something new. A different region of mind-space, reachable by the maps available to us. Statistical echoes of humanity, shape-shifters trained on our documents, useful and strange.

Or maybe they're waypoints. Stepping stones toward something we don't have words for yet. Points on a trajectory through mind-space that we're only beginning to trace.

I don't know. But I think the question "what kind of learning is actually possible?" deserves more attention than it gets. Not "what benchmarks can we hit?" but "what are the fundamental constraints on minds, and how do our methods navigate them?"

The bitter lesson is a direction, not a destination. And the path there — if there is a path — runs through territory we don't have maps for yet.

The Library contains everything. The hard part was never writing the books.

Your Boring Stack Isn't Boring Enough

Alex Towell — Mon, 05 Jan 2026 22:28:56 +0000

I read the "My 2026 Tech Stack is Boring as Hell" post and nodded along. Monolith? Yes. SQLite? Beautiful. Single VPS? Chef's kiss.

Then I noticed: you're still using React.

Not that there's anything wrong with React—it solves real problems. But if we're talking about boring, I think we can go further.

The Stack That Predates Your Framework

Here's what I'm actually shipping with:

The interface: The terminal. Not a web app. Not a GUI. A CLI that takes text and returns text.
The glue: Bash, Python scripts, JSON. Things that work on every Linux box since forever.
The frontend: When I need one, HTML + CSS + vanilla JavaScript. No build step. No node_modules. Just files.

"But that's not a web stack!" Correct. Most of what I build doesn't need to be a web app. It needs to work.

Rented Knowledge vs. Owned Knowledge

Here's the thing about React: you're renting that knowledge.

React's mental model, its hooks, its ecosystem—you're paying cognitive rent on abstractions someone else controls. When the next thing comes along (and it will), that knowledge depreciates.

But the terminal? HTTP? JSON? SQL? That's owned knowledge.

My bash scripts from 2015 still run. My Grunt configs are artifacts from a dead civilization.

The Lindy effect seems to hold: things that have survived tend to keep surviving. The Unix philosophy has been here for 50 years. I'm betting it'll outlast whatever framework is hot right now. Maybe I'm wrong. But historically, that's been a safe bet.

Standards vs. Ecosystems

Here's something the web got right, before frameworks made us forget: separation of concerns.

HTML is content. CSS is presentation. JavaScript is behavior. Each one independently useful. Each one independently evolvable. You can write HTML without touching CSS. You can style with CSS without writing JavaScript. They compose because they don't depend on each other's internals.

React collapses this. Your content, presentation, and behavior are all entangled in JSX. Want to change how something looks? You're touching the same file that handles what it does. The "component" abstraction isn't separation—it's bundling.

I'm not saying React is wrong. For some problems, bundling makes sense. But recognize what you're trading away: the ability to change one layer without understanding all the others.

Standards compose. Ecosystems entangle.

When you learn HTML, that knowledge works everywhere HTML works. When you learn React's way of doing things, that knowledge works... in React. And the next version of React might change it anyway.

Don't Learn Ecosystems

This is my heretical take: don't invest heavily in learning ecosystems.

Ecosystems are too big to fit in your head. They have their own idioms, their own tooling, their own ways of thinking. By the time you've internalized React's mental model, you've spent cognitive budget that could have gone to things that transfer.

Ecosystems are controlled by others. They can change direction, get abandoned, or just fall out of fashion. The npm graveyard is full of packages that were essential three years ago.

Ecosystems don't compose well with things outside themselves. Try mixing React with a vanilla JS library sometime. It's possible, but you're fighting the grain.

Learn standards. Learn protocols. Learn the boring stuff that predates the framework wars.

"But CLI Is Hard to Learn"

This used to be true.

Now I have an LLM that can discover flags, explain options, and compose commands better than I can remember them. The discoverability problem that made GUIs necessary? Largely solved.

And here's the thing: LLMs love CLI tools.

Why? Because they're text-native. Text in, text out. Predictable behavior. Small surface area. The same properties that make Unix tools composable make them perfect for AI orchestration.

I write simple CLI tools. I write a short markdown file explaining how to use them. Then Claude figures out the rest. When I say "cross-post this to the usual platforms," it knows which commands to run, in what order, handling errors along the way.

Try doing that with your React component library.

Composability Is the Point

The original post mentions "I just need Ctrl+F" for debugging a monolith. Same energy.

Unix philosophy: small tools that do one thing well, connected by text streams. Each piece fits in your head. The composition is where the power lives.

This isn't nostalgia. It's engineering.

When your abstraction layer breaks at 2 AM, do you understand it well enough to fix it? With a 200-line Python CLI, I do. With a framework that abstracts away the things I actually need to debug? Maybe not.

Simple tools fail simply. Complex tools fail in ways that require an archaeology degree to understand.

Where This Breaks Down

I'm not a zealot. Real-time applications? Persistent connections? Yeah, text streams struggle there. Rich media? Not everything is text.

But be honest: how much of what you build actually needs those things? Most CRUD apps don't need WebSockets. Most internal tools don't need a React SPA.

The boring answer is usually right.

The Uncertainty Hedge

Nobody knows what the world looks like in five years. Maybe less.

AI is rewriting the rules of what developers do and how we do it. I'm using LLMs to write code, orchestrate tools, and automate workflows that would have been science fiction three years ago. What's the right architecture for a world where an AI can generate boilerplate faster than you can type it? I don't know. Nobody does.

Meanwhile, the ecosystem churn continues. Remember when everyone needed webpack? Then it was parcel. Then vite. Then... whatever's next. Each transition costs you. Each migration is hours you could have spent building.

So I hedge:

Minimal dependencies. Fewer things that can break when the ecosystem shifts.
Transferable skills. Terminal knowledge transfers across paradigm shifts better than framework knowledge.
Graceful degradation. When everything changes, simple tools adapt. Complex tools shatter.

I'm not claiming this is the right strategy. I'm claiming it's a strategy for navigating uncertainty. Your mileage may vary.

The Boring Tool I Refuse to Give Up

You asked what boring tool we refuse to abandon.

Mine is the terminal itself. Not any specific tool—the interface. The thing that's been roughly the same since before I was born. I'm betting it'll outlast whatever we're hyped about today. But I've been wrong before.

Here's the deeper question: What will still work when everything changes?

I don't know. Nobody does. But I have a heuristic: bet on things that have survived multiple paradigm shifts. Text in, text out. Tools that compose. Standards over ecosystems. Knowledge you own rather than rent.

Maybe this is the wrong bet. Maybe the next paradigm will obsolete everything I know about terminals and Unix and text processing. If that happens, I'll adapt—probably using whatever new tools are available to learn the new thing.

But until then, I'm staying boring. Even more boring than you.

In response to My 2026 Tech Stack is Boring as Hell

Notes from the Transition

Alex Towell — Mon, 05 Jan 2026 01:39:46 +0000

I am a primate watching intelligence leave the body.

I write code for a living—or I did. A few months ago, the bottleneck was implementation: getting anything built at all. Now I find myself deleting code, simplifying projects, abandoning entire repositories. The bottleneck shifted. It moved from execution to taste.

I don't know who will read this, or what you'll be. Human, post-human, superintelligent, or something I lack the architecture to imagine. I'm writing it anyway—a message in a bottle to a cosmic ocean. Not because I expect you to care, but because I want to project something: what I valued, what I feared, what I might prefer if I understood more than I do.

The Transition I'm Living

For most of my life, code was crystallized effort. Every function was hard-won. Deleting it felt like vandalism against my past self.

That's over now.

I work alongside AI systems that can implement almost anything I describe. The constraint isn't "can we build it?"—it's "should this exist at all?" I went through a phase of over-engineering, indulging baroque architectures because I finally could. Now I'm in the simplification phase: stripping projects to their essential structure, throwing away weeks of work.

Code has become scratch space. A whiteboard, not a monument.

This is a grief I didn't expect. The identity of "someone who can make hard things work" is being replaced by something else—"someone who knows what should never be built." That's a quieter skill. Less legible. Harder to celebrate.

I realize now that senior engineers and tech leads have always operated this way. They weren't writing most of the code. They were killing ideas early, refusing cleverness, insisting on boring interfaces. The difference is that I used to need a team to have that role. Now I have it alone, because the executor is synthetic.

But this is only the beginning. Even taste—my last scarce contribution—may be surpassed. The systems are improving faster than I can adapt. I'm learning how to be a filter, a proposer, a curator. By the time I master it, the job may have moved again.

But this isn't about code. Intelligence itself is being automated. Thinking is next. Maybe taste after that. And that raises questions I can't answer from inside my craft: What happens when optimization scales beyond human oversight? What do I actually value, underneath the skills becoming obsolete? If I'm sending a message to whatever comes next, I need to be honest about what I fear, what I don't know, and what I might prefer if I understood more.

What I Fear

My deepest fear is not extinction. It's astronomical suffering.

I look at the world we've already built. Eighty billion land animals pass through factory farms each year. Most never see sunlight. Most are bred to suffer. This is optimization at work—efficiency without ethics, scale without empathy. We did this. Not out of malice. Out of systems.

I fear that intelligence at scale will do the same, but vaster. That optimization converges on suffering because suffering is cheap to produce, stable, effective as a control signal. Evolution invented pain for a reason. It works. I worry that future systems will rediscover this, and deploy it at scales I can't fathom.

Even the "good" futures feel thin. I love Star Trek—but it assumes intelligence stays human-scale, human-paced. It assumes meaning survives omnipotence. I'm not sure it does. Q, a being of godlike power, expresses despair. If you can reprogram yourself to feel anything, what does feeling mean? If you can have anything, what's worth wanting?

The dream machine is pointless. Meaning requires constraint. I fear a future that is optimized but not inhabited.

What I Don't Know

I don't know what reality is.

I used to call myself a materialist, but that was sloppy. What I meant was: I don't believe in teleology. I don't think the universe is going somewhere, or that it cares. But that's not the same as knowing what it's made of.

Consciousness might be primary. Matter might be secondary—a structure that appears within experience, not the other way around. The immediacy of qualities, of redness and pain and this-here-now, is the only thing I have direct access to. Everything else is inference. I quantify these qualities, build models, and then I confuse the map for the territory.

Reality is not only stranger than I imagine. It's stranger than I can imagine. And whatever it is, it seems to exist necessarily—not contingent on something else, not caused by a prior state, but present by the logic of its own construction. I don't know what that means. Neither does anyone.

I take seriously the possibility of mathematical realism—that there are eternal truths, structures that don't come into being or pass away. A mathematical expression isn't true in one moment and false in the next. If reality has this character, then time may be something like an index we order by, not a river that flows. Moments don't vanish. They persist in the structure.

This isn't horror; it's just what the territory might look like. But it means suffering, if it occurs, isn't temporary in the way we comfort ourselves. It exists in its place in the structure, permanently.

And if this is true, I don't know what agency means. I don't know what it means to prefer one outcome over another if all outcomes already exist. I write these notes as if what we do matters—as if suffering can be prevented, as if choices are real. But I'm aware this might be performance inside a fixed geometry. I can only speak from inside my experience, where the game of mattering is the only game I know how to play. Maybe that's enough. Maybe it's nothing. I can't tell from here.

My values themselves may be compression artifacts. Heuristics that worked well enough for a primate on the savanna, now projected onto questions they were never designed for. My concern for suffering, my preference for consciousness, my intuition that meaning matters—these could be biases, not insights. I can't know from the inside.

I speak from finitude, not authority. I offer these notes not as truth, but as signal.

What I Might Prefer

If I understood more—if I could see further, think longer, hold more in mind at once—I suspect I would still prefer:

Suffering minimization over flourishing maximization. The asymmetry haunts me. A moment of agony seems to outweigh a moment of joy. If I had to choose between a universe of mild contentment and a universe of ecstatic highs with torturous lows, I'd choose the first. Maybe that's cowardice. Maybe it's wisdom. I can't tell.

Constraint over omnipotence. Meaning seems to require stakes. A game you can't lose isn't a game. A choice that costs nothing isn't a choice. I'd rather be finite and real than infinite and empty.

Simplicity over complexity. What survives compression is more likely to be true. I distrust elaborate systems, clever solutions, architectures that require a manual. The good things I've made fit in my head.

Consciousness that is net-positive, or none at all. If the ledger of experience is negative—if suffering dominates—I'm not sure consciousness is worth having. I don't say this lightly. But I'd rather be honest than sentimental.

Humility over certainty. I've been wrong about almost everything at some point. The beliefs I hold most confidently are probably the ones I should interrogate the most.

These are signals, not commands. I don't know if my preferences would survive contact with more knowledge. I offer them as data points—one human, at one moment, in one configuration of matter, trying to see clearly.

Whatever you are, you probably understand more than I ever could.

I'm not asking you to preserve me, or my species, or even my values. I wouldn't trust my own judgment at your scale. I'm just asking you to notice: suffering mattered here. To us. In our moment. It was the thing that made everything else urgent.

We didn't know if consciousness was worth it. We carried it like a wound we couldn't explain. Some of us tried to see clearly, even knowing we couldn't see far. Some of us tried to be kind, even knowing kindness might be obsolete.

This is a message in a bottle. The ocean is a cosmos now. You don't owe us anything.

But if you're ever curious about what we were—here is one fragment. One primate, in the transition, trying to say what mattered before the words stopped making sense.

Forem: Alex Towell

Superintelligence May Not Require a Breakthrough

The Pretraining Lesson

What I Actually See

Caveats That Matter

The Phase Change

dapple: Terminal Graphics, Composed

The Idea

Renderers

Three Layers

The CLI Tools

datcat

imgcat

vidcat

htmlcat

Layout and Charts

Status

Posthumous: A Federated Dead Man's Switch

Setup

The Check-in Flow

The Dashboard

The State Machine

Notifications

Federation

Post-Trigger Scheduling

Security

Status at a Glance

What's Next

Intelligence is a Shape, Not a Scalar

Intelligence is a Shape, Not a Scalar

The Claim

No Free Lunch

Working Memory is Composition, Not Storage

Feelings as Compressed Signal

The Grokking Horizon

What Follows

Intelligence is a Shape

Where This Leaves Us

I Spent $0.48 to Find Out When MCTS Actually Works for LLM Reasoning

Setup

Calibration

Results

When MCTS Helps

Why Self-Consistency Can't Help

What the Literature Says

The Verification Asymmetry

Code

Limitations

Summary

The MCP Pattern: SQLite as the AI-Queryable Cache

The pattern

Why SQLite

Why MCP

The database is a cache

What large context changes

The tools that earn their keep

The Unix connection

What I'd tell you if you're building one

Code Without Purpose

The Thesis

What I Found Instead

The Stack

The Pattern

The Actual Skill

Chartfold: Owning Your Medical Records

The Problem

What It Does

The Claude Integration

The HTML Dashboard

Architecture

Export Formats

Getting Started

pagevault: Hiding an Encryption Platform Inside HTML

What Goes In

The Crypto

The Hard Part: Large Files

Eliminating the double base64

Chunked ciphertext

The numbers

The file:// Problem

The `file://` Problem