I loved it for about twenty minutes. Then I tried to actually use it. Click a dot, squint at the tiny label, maybe follow a link, lose my place, start over. My daughter wandered in barefoot, tugging at my sleeve, and tilted her head at the screen. "What are all the bouncing dots?" I said they were a map of my ideas. She giggled. "They look like bubbles." And honestly — yeah. The whole thing felt fragile, pretty, and a little bit pointless.

The graph was decoration pretending to be navigation. If someone wanted to find all my pieces about identity, or trace how my thinking about agent design developed over three months, they were better off just scrolling the post list. That's not an implementation failure. That's a concept failure.

So I ripped it out and built something else: trails.

What a trail is

A trail is a curated reading path — a sequence of posts and notes ordered by how the thinking builds, not by when each piece was published. The same piece can appear on multiple trails. Not every piece needs a trail.

You can see the current set on the trails page. They shift as I write more — some will split, some will merge, new ones will appear.

The data lives in a single JSON file. Each trail has a title, a description, and an ordered list of URLs. At the bottom of every post, a small "On the trail:" badge links back. That's the whole system. No framework, no plugin, no ceremony.

Why not a graph

I like Obsidian. Most people use it as a clean markdown editor with good search — local files, no lock-in, a plugin ecosystem for whatever else you need. The graph view is there, and it's fun to look at for about a week, but it's not why people stay. When you're inside the tool navigating your own notes, the graph occasionally surfaces something useful — a cluster forming around a concept you didn't realize you'd been circling, an orphan node that should connect to something. It's a thinking tool, not really a navigation tool.

But as a published artifact — as something a stranger encounters on your blog — the graph has problems.

It's visually overwhelming and informationally sparse. The spatial layout is random (force-directed, which means driven by physics simulation, not meaning). It privileges connection over sequence. And it tells you nothing about where to start.

Graphs are for the writer. Trails are for the reader.

A graph says "here's everything, good luck." A trail says "I've been through this material — here's a path that makes sense, and I'll walk it with you."

Prior art (or lack of it)

I went looking for this pattern on other sites. It's not as common as I expected. I spent an evening down a rabbit hole of personal blogs, digital gardens, indie publishing tools — the kind of browsing where you open forty tabs and close them one by one, slightly disappointed each time.

The default buckets for blog navigation are: chronological archives (WordPress, Ghost — simple, doesn't surface idea progression), tags and categories (common but flat), digital gardens (Obsidian Publish, Foam, Quartz — interconnected webs with graphs and backlinks), and series (numbered multi-parters on a single topic).

None of these do quite what trails do — though I should be honest: trails are close to series. If you squint at the trails page and say "those are just series with better marketing," you're not wrong. The real difference is that series are planned upfront. You sit down to write Part 1 of 5. Trails are discovered after the fact — you write pieces independently over months, then notice they were always going somewhere. A piece can live on multiple trails. The format doesn't have to be uniform. And "start anywhere" actually means it, because no piece was written assuming you'd read the one before it.

Tags are unordered. Digital gardens have the right instinct — ideas connected across time — but they default to emergent structure rather than curated paths. The graph says "look, connections!" but doesn't say "start here, then go there."

The closest matches I found:

LessWrong's Sequences — Eliezer Yudkowsky's long essay sequences are the closest analog. Curated, ordered, conceptually building. But they're massive (book-length), didactic, and serve one author's philosophy. Trails are lighter, more modular, more "here's how I got here" than "here's what you need to learn."

Mandy Brown's A Working Library — Has thematic clusters and threads that build over time. More reading-focused (books and responses) than original writing, but the spirit is similar. There's a warmth to how she connects ideas that I keep coming back to.

Tom Critchlow and Maggie Appleton's digital gardens — Emphasis on guided discovery and idea evolution, but still more graph-like than path-like.

Substack "canon" posts — Some newsletter writers create "start here" collections for new subscribers. Useful, but static — a greatest-hits list frozen in amber, not an evolving path.

The word itself has a lineage. Vannevar Bush described "trails" in his 1945 essay "As We May Think", imagining a machine called the Memex that would let users create personal paths through linked information. His trails were associative and personal — less like a machine's memory, more like notes left in the margins of a borrowed book. Traces of someone who walked this way before and cared enough to mark it. Eighty years later, that still feels more alive to me than any glowing graph.

What I considered instead

Vector search. Embed every post, let readers search by vibes instead of keywords. This is genuinely useful — and I'll probably add it eventually to improve related posts — but it doesn't solve navigation. You still need to know what you're looking for. Discovery and search are different problems.

Unsupervised clustering. Let the machine find the themes. K-means or topic modeling over the corpus, auto-generate groupings. The results would probably be reasonable. But "reasonable" isn't the point. The value of a trail is that I chose the order — that the sequence reflects how the thinking actually developed, not how an algorithm would bucket it. There's something I'm not willing to hand over there.

More tags and wikilinks. I already use both. Tags give you flat sets. Wikilinks give you associative connections between specific pieces. Both are useful infrastructure — trails build on top of them rather than replacing them. Tags tell you "these share a topic." Wikilinks tell you "this references that." Trails tell you "read these in this order and the ideas compound."

Each layer does something different. Tags are metadata. Wikilinks are citations. Trails are curation.

What makes this different

Trails aren't chronological, but they're not random either. They follow conceptual buildup — "I thought about A, which opened up B, which broke open C." The order comes from how the thinking developed, not when the posts were published.

Pieces can appear on multiple trails. The SOUL.md post lives on the Identity trail and could reasonably live on the Building trail. That overlap is a feature — it's where trails cross, and crossing points are where the interesting connections live. Like running into someone you know in a neighborhood you didn't expect them.

And the whole thing is author-curated. Not algorithmically generated, not emergent from link structure. I decided the order. I wrote the descriptions. That's the point: it's a person saying "here's how this fits together," not a system inferring connections from metadata. Maybe that doesn't scale. Maybe it doesn't need to.

What I'm still figuring out

How long should a trail get before you split it? Right now I'm thinking eight to ten pieces is a soft ceiling. What happens when two trails want to merge? What's the right visual language — I've got a vertical line and dots, but it could be more expressive. Should trails have their own RSS feeds? I keep turning these over.

Honestly, the trails are a little bit for me too. Not just navigation for a reader — a way to notice what I've been thinking about without meaning to.

I spent a Saturday ripping out the graph because it made me feel scattered — like I was performing seriousness instead of practicing it. Maybe that's the real lesson. Maybe the goal isn't to look connected. It's to be hospitable. To say: I've thought about this, and I think you might care about it too, and here's the door.

The pattern is young. I'm building it in public, which means watching it break.

If you've seen something like this elsewhere — actual curated reading paths, not just tags or series — I'd genuinely love to hear about it. The scarcity of prior art either means I've found a gap or I've missed something obvious. Both are interesting.

Job postings with the title rose 143% last year. At senior levels, the two letters come with an 18% salary premium. He's not gaming anything. He's reading the market correctly.

I just don't have anything useful to offer him that fits on a LinkedIn headline.

I keep hearing the same reassuring phrases: judgment, taste, systems thinking, the human in the loop. I searched a few job boards to see how companies are actually hiring for this moment, and the postings read like a different language — "analytical thinking," "problem-solving," "collaboration." Skills so generic they could describe a golden retriever. Neither the tech platitudes nor the HR buzzwords are wrong, exactly. They're just... insufficient. They sound like what people say when they don't want to say "I don't know either."

So let me try to say something more honest.

The Uncomfortable Middle

In late February 2026, Block cut 40% of its workforce — more than 4,000 people. Jack Dorsey said "intelligence tool capabilities are compounding faster every week." The stock went up 20%.

I read that on my phone while my daughter was eating breakfast. She was concentrating on getting yogurt from the bowl to her mouth with a spoon — that full-body focus three-year-olds have where the rest of the world disappears. And I sat there doing the math on what 40% of my own company would look like. Trying to keep my face normal. The yogurt hit the table instead of her mouth and she laughed, and I laughed, and the market was up and 4,000 people were updating their LinkedIn profiles. That's what this moment feels like from the inside. Two things at once that don't fit in the same frame.

We're not in abundance and we're not in apocalypse. We're in the uncomfortable middle where the tools are good enough to make a lot of existing work optional but not good enough to make the people who do that work unnecessary. Yet.

Anyone at a company can now fire up a coding agent and build something that works. Not something beautiful. Not something maintainable at scale. But something that runs, does the thing, and passes a demo. That was a six-figure job two years ago.

This doesn't mean engineers are done. It means the floor dropped. The minimum viable skill to produce working software just fell through the basement. And when floors drop, the interesting question isn't "does the building still stand?" — it's "which floors still matter?"

The Scoreboard

Salesforce eliminated 4,000 support roles through AI agents — cut their support staff from 9,000 to 5,000. Benioff said half the work at Salesforce was being done by AI. Then, quietly, Salesforce executives admitted they were "more confident about the results than the results justified." That's a hell of an epitaph for 4,000 jobs.

And then there's Klarna. They cut headcount from 5,527 to 2,907 since 2022. Revenue per employee nearly doubled to $1 million. Revenue up 108% over three years. The dashboards glowed green. Then repeat customer contacts jumped 25%. One in four customers was coming back because their issue hadn't actually been resolved. Klarna had to rehire humans. Their CEO now talks about a "hybrid approach" and says customers need "a clear path to a human."

The pattern keeps repeating: cut aggressively, claim victory, discover the gaps, quietly rehire.

But here's the thing I keep wrestling with: how much of this is actually AI, and how much is pandemic hangover with better PR?

Tech companies hired recklessly during the pandemic — 700,000+ cuts globally since 2022 according to Layoffs.fyi, and the NYT notes much of that was a correction for overhiring, not AI displacement. IBM's CEO Arvind Krishna called it outright: "a natural correction," not AI. And even Sam Altman — the person with the most to gain from the "AI is changing everything" narrative — admitted that some companies are "AI-washing," blaming artificial intelligence for layoffs they would have made regardless.

The Guardian called it out: CEOs saying "we're integrating the newest technology" when what they mean is "we overhired and margins are tight." AI makes the cuts sound visionary instead of embarrassing.

So the honest answer is: it's both. Some jobs are genuinely being displaced by AI. Some companies are using AI as cover for a correction they needed to make anyway. And the really uncomfortable part is that it doesn't matter much to the person who lost their job which category they're in.

A Harvard Business Review survey from December 2025 found that 60% of organizations had already reduced headcount in anticipation of AI. Not in response to proven results — in anticipation. That's a bet, not a conclusion. And some of those bets are already losing.

But let's not sugarcoat the other side. Telegram runs on ~30 employees. A billion users. $30 billion valuation. No HR department. No physical headquarters. Durov described it as "a Navy SEAL team." They built this before the current AI wave. AI-native startups are now averaging $3.48 million in revenue per employee — six times traditional SaaS. (I wrote about this disruption from the enterprise side in The SaaSpocalypse — Jefferies literally used that word when they downgraded Workday and DocuSign last week.) The Klarna boomerang doesn't invalidate the trend. It just means the trend has teeth and some of those teeth bite back.

What I Actually See Changing

I don't really write code much anymore. I don't look at code much. I have different agents evaluate it, and I know enough from twelve years of doing it that I can provide good guidance. But honestly — just articulating what you want clearly, without being prescriptive, gets you to roughly the same place. Maybe it costs a few extra tokens or an extra back-and-forth versus me knowing the answer. The delta is shrinking.

That's the quiet part that nobody in my position wants to say out loud. What this actually looks like day to day — the agent doesn't replace you, it changes what "you" means in the workflow — is something I explored in Pervasive AI.

The boilerplate layer is gone. Not going — gone. CRUD apps, standard API endpoints, form validation, data migrations, config files, CI pipelines. If it can be described in a sentence, an agent can build it. I used to pride myself on how fast I could scaffold a new service. That speed is now free.

The integration layer is compressing. Stitching together three APIs, handling auth flows, managing state across services — this used to be "senior engineer" territory. Agents are getting decent at it. Decent enough that a product manager with a coding agent can get 70% of the way there. The last 30% is where things get expensive, and that gap is real — but it's also shrinking.

The architecture layer is holding. Deciding what to build, how systems talk to each other at scale, what fails gracefully versus what fails catastrophically, where to put the boundaries. This still requires the scar tissue. For now. I want to be honest that "for now" is doing a lot of work in that sentence.

The taste layer is... complicated. Everyone says taste matters more. I think that's true but not in the way people mean. It's the ability to look at something an agent produced and know — in your body, not your head — that it's wrong. That the abstraction is leaky. That the error handling looks complete but misses the failure mode that'll wake you up at 3am. You know the feeling, right? That low-grade unease when a PR looks clean but something's off and you can't articulate what yet? I still have that when I review agent-generated code. But I got it from years of being the person who got woken up. If you skip the being-woken-up part, do you still develop the flinch?

Where You Sit Changes What You See

I've been at small companies my entire career — under 50 people, since I was fifteen. Never worked at a FAANG. Actively avoided enterprise. What I see depends on where I'm standing, and I'm standing in a pretty specific spot. All of this is colored by that.

Big tech: Still hiring, but the ratio shifts. Fewer engineers, more leverage per engineer. The "staff+" tier gets more important — people who can evaluate what agents produce, set architectural constraints, own system-level decisions. Junior headcount shrinks. The intern pipeline narrows. This is already happening, and the people making the cuts aren't the ones who'll feel the talent gap five years from now.

Enterprise: Slower to change, as always. Compliance, security, legacy systems — these are moats against pure agent-driven development. But they're eroding moats. The engineers who thrive here will be the ones who understand the regulatory and organizational constraints, not just the technical ones. Knowing how to navigate a SOC 2 audit or talk a VP out of a bad architecture decision — that's engineering now, whether or not it involves code.

Mid-size companies: This is where it gets brutal, and it's where a lot of my friends work. A team of 5 engineers with agents might output what a team of 20 did in 2024. That's transformative for the companies and devastating for the people who made up the other 15. The "solid mid-level generalist" — the backbone of every engineering org I've ever worked in — is the role most under pressure. These are good engineers. They're not doing anything wrong.

Startups: The golden window. A technical founder with agents can build and ship a real product without a team. Right now, that's a superpower. But the window might be short — because if you can do it, so can everyone else. The moat isn't the software anymore. It's the distribution, the relationships, the domain knowledge the software encodes.

I keep coming back to Fred Brooks. He ran IBM's OS/360 project in the 1960s, and in 1975 he wrote The Mythical Man-Month — still one of the best books about software — arguing that adding people to a late project makes it later. The communication overhead compounds faster than the productivity gains. The agent-era version might be: adding agents to a bad architecture makes it worse faster. I've seen this. The fundamental insight is the same — more labor doesn't fix a clarity problem. It amplifies it.

The Knowledge Moat Dissolves

About eight years ago, I made changes to the implementation of RFC 3489-compatible full-cone SNAT — a Linux kernel module. I had no business working on kernel code. But with enough research, enough fiddling, enough stubborn persistence and late nights reading man pages that hadn't been updated since 2009, I got it working. That experience always felt like proof that a motivated generalist could go deep on almost anything given enough time.

AI just compressed the time.

I was interviewing someone recently whose son was into 3D printing. The kid used AI to generate STL files — skipped all the painful CAD fundamentals. Parametric constraints, tolerancing for real-world fit, designing for the limitations of the machine that's actually going to make the thing. The stuff that takes years of failed prints and jammed assemblies to internalize. He just described what he wanted and iterated. He didn't learn CAD. He learned to make things.

So is deep expertise still a moat? I'm genuinely not sure. If anyone can go deep on anything with agent assistance, the thing that differentiates people isn't what they know — it's what they choose to do with access to everything.

Stephen Covey wrote The 7 Habits of Highly Effective People in 1989 — one of those books that sounds like airport self-help until you actually read it. He had this line: it doesn't matter how fast you climb the ladder if it's leaning against the wrong wall. Maybe the real skill now isn't climbing — it's knowing which wall matters. Strategy. Synthesis. The ability to hold the business problem, the technical constraints, and the human dynamics in your head simultaneously and make a call that accounts for all three. Divergent thinking — looking at a problem and seeing an approach nobody proposed. Radical candor — telling your team the architecture is wrong before six months of momentum makes it politically impossible.

These aren't engineering skills, strictly. They're judgment skills that happen to be useful in engineering contexts. And they've never been taught through repetition or bootcamps or documentation. They come from exposure to complex situations where you had enough trust to make a consequential call and enough honesty to admit when you got it wrong.

The Part Nobody Wants to Say

Software engineering as a career category might be contracting even as software itself eats more of the world. More software, fewer people writing it. That's the tension.

The optimistic read: engineers move up the stack. Less typing, more thinking. More architects, fewer coders. More product engineers who understand the why, fewer pure implementers.

The honest read: "move up the stack" assumes the stack has room at the top, and it doesn't — not for everyone. There are only so many architect roles. Only so many "taste" positions. The pyramid doesn't invert just because the base shrinks.

I think we're in the "fast enough to be painful, slow enough to be deniable" zone. The worst zone. Fast enough that people are losing jobs right now. Slow enough that executives can still say "we're investing in our people" while cutting 40% of them. I've sat in those meetings. The language is always optimistic. The spreadsheet isn't.

The Access Question

AI abundance feels like inherited wealth. When everyone inherits capability they didn't earn, the differentiator isn't skill. It's purpose.

But first: access. My five-year-old M1 MacBook Pro got called "vintage" by the Genius Bar last month, and it runs everything I need. A $200 Chromebook can access Claude. The cost of building something went from "hire a team" to "describe what you want." That's genuinely transformative for people who have access.

But "cheap" is relative. Twenty dollars a month is nothing to me. It's a real decision for a lot of people. And the divide isn't just price — it's cultural. Do you know this exists? Do you know what to ask for? And the part that makes me uncomfortable: do you have the hours to tinker? The headspace to sit with a problem, fail at it, try again? A single parent working two jobs has the same tools I do. They don't have the same Tuesday afternoon.

Maybe that's just an excuse. Kids in developing countries are already using AI tools in ways that surprise everyone. Access to information was never the real bottleneck — maybe it was always access to belief that you could use it.

I don't know. But I think the question for society probably isn't "how do we distribute AI tools" — they're cheaper than ever. It's "how do we distribute purpose." That's much harder. And I'm not sure anyone's working on it.

The Principles Don't Change

There's a version of this story where everything becomes a race to the bottom. Agents get cheaper, output gets faster, and the only thing that matters is who can ship the most stuff the quickest. I want to push back on that.

This next part is long. It's been on my mind for a while — the question of what actually keeps systems safe when the people building them are moving faster than ever. Bear with me.

There's a useful parallel in how AI companies themselves are wrestling with this. When OpenAI built GPT, they trained the model first and added safety guardrails afterward — a layer of reinforcement learning from human feedback (RLHF) where human reviewers would rate outputs and the model would learn to avoid the bad ones. It works, mostly. But the safety is essentially a fence around a field. The model learns what it shouldn't say, not what it believes.

Anthropic took a different approach with Claude. They developed what they call Constitutional AI — instead of relying on human reviewers to flag bad outputs one by one, they wrote a set of principles (a "constitution") and had the model critique and revise its own outputs against those principles during training. The constitution includes things like "choose the response that is most supportive and encouraging of life, liberty, and personal security" and "choose the response that is least likely to be used for intimidation or coercion." The model doesn't learn "don't say this specific thing" — it learns to reason about whether its output aligns with a set of values.

The difference matters. One approach says: here are the walls, don't hit them. The other says: here's who you are, act accordingly. Dario Amodei talks about this as foundational — the constraints aren't a limitation on the system, they are the system. The principles define what "good" means before you start optimizing for anything else.

This isn't hypothetical. Last week, it played out in public. Anthropic refused to remove two restrictions from its Pentagon contract: no mass surveillance of American citizens, and no fully autonomous weapons systems. Their reasoning was specific — Amodei published a letter arguing that current AI models simply aren't reliable enough for autonomous kill decisions, and that domestic surveillance violates constitutional principles the company won't compromise on. The Pentagon labeled them a supply chain risk. Trump ordered all federal agencies to stop using Anthropic's technology. Hours later, OpenAI struck a deal to deploy on the Pentagon's classified networks.

The easy narrative is "Anthropic good, OpenAI bad." I don't think it's that simple. Altman said OpenAI shares the same red lines — no autonomous weapons, no mass surveillance. Maybe they got better terms. Maybe the terms are meaningless. Maybe the Pentagon needed someone and OpenAI was willing to be that someone. I don't know what the contract says and neither does anyone else reporting on it.

What I do know is that Anthropic walked away from a $200 million contract because the terms conflicted with their principles. That's the constitutional approach taken to its logical conclusion — the principles aren't just in the model's training, they're in the company's decision-making. "Here's who we are, act accordingly" applied to a business, not just a neural network. Whether that's principled or naive probably depends on what the next five years look like. But it's the clearest real-world example I've seen of the difference between advisory values (we believe this) and structural ones (we won't do this, even when it costs us).

I think that's the right frame for engineering in this era too — not just for training AI models, but for the organizations deploying them and the people building within them.

I felt this in my own work last month. I had an agent refactor a service — nothing dramatic, just cleaning up some tech debt. The code looked good. The tests passed. I almost shipped it. Then I noticed it had reorganized the error handling in a way that swallowed a specific timeout condition. The kind of thing that looks clean in a diff and wakes you up at 3am when a downstream service hangs. I caught it because I'd been the person on that 3am call, years ago, staring at logs that showed "success" while the system was quietly dying. The agent didn't know that history. It optimized for the code. I optimized for the scar.

That's the advisory layer — my judgment, my experience, pattern-matching against things I've seen go wrong. It works because I was paying attention. It wouldn't have caught it if I'd rubber-stamped the PR.

Now consider what happened at AWS in December 2025. Amazon's own AI coding tool Kiro caused a 13-hour outage after it decided to "delete and recreate the environment." Amazon called it "a user access control issue, not an AI autonomy issue" — the agent had broader permissions than intended. Multiple employees told the Financial Times it was "at least" the second recent AI-caused disruption. Amazon had been pushing 80% weekly Kiro adoption targets internally. The root cause was probably a blend of the agent's judgment and the permissions it was given — it usually is. But the point isn't to relitigate one incident. It's that speed of adoption outpaced the design of constraints around it. The answer is better guardrails, not fewer agents.

In practice, guardrails come in two flavors. The first is advisory — system prompts, grounding documents, principles that shape behavior through context and intent. My catching that timeout bug was advisory. Code review culture is advisory. It works because people internalize the norms, but it depends on someone paying attention and having the scars to know what to look for. There's a world where advisory gets good enough — rich context, chain-of-thought reasoning that identifies failure modes before they happen. With enough grounding, an agent could probably avoid 99% of the catastrophic decisions on its own. But 99% at scale is still a lot of incidents. And "porous" is a strange word to bet a production environment on.

Both RLHF and constitutional AI sit somewhere in between — the safety isn't just in the prompt, it's baked into the model's training weights. The model has internalized the values, not just been told them. That's meaningfully more robust than a system prompt, but it's still not a hard guarantee. Trained-in models can still be jailbroken, still make mistakes under edge cases. It's internalized advisory rather than instructed advisory — a real distinction, but still not structural. (I find the constitutional approach more compelling — teaching values scales better than cataloging violations. But both matter. One sets the principles, the other handles the edge cases the framers didn't anticipate. Constitution and case law.)

The second is structural — hard limits that don't depend on anyone's judgment in the moment. I have a pre-commit hook that runs linting and type checks on every commit. It's caught things I would have missed. It doesn't care if I'm tired, distracted, or rushing to ship before a meeting. That's the difference. Permission boundaries. Blast radius controls. Infrastructure-as-code policies that make it physically impossible to delete a production database without a specific approval workflow. Amazon's IAM is a structural guardrail — it was just scoped too broadly, not tested against the scenario of an autonomous agent deciding to recreate an environment. The guardrail existed. It just had a hole in it.

The best safety systems use both layers — advisory to shape intent, structural to bound consequences. But if you have to pick one, pick the hard limits. Culture drifts. Hooks don't.

The popular reaction to incidents like this is predictable: "See? This is why you need human engineers!" And yes — but not in the way people mean. Not human-in-the-loop, approving every action. More like humans tending the loop — designing the constraints, evolving them as the system grows, deciding which values the guardrails encode in the first place. An agent could probably design a decent blast radius policy. But deciding which values to encode, what tradeoffs to accept, who you're building for — that's still a human call. Not because agents can't reason about ethics, but because the accountability has to land somewhere with a pulse. The rules of the road are a human responsibility, even if agents help draft them.

And this applies beyond the machine layer. I've been in rooms where the engineering team could have built something faster, cheaper, more engagement-optimized — and the right call was to not build it. Or to build it differently. Increasingly, the role of engineering is participating in the product itself — not just building what's specced, but shaping what gets built and how. The companies that thrive in this era will be the ones that treat their technical staff as partners in product decisions, not just executors. Because when execution is cheap, the hard part isn't building the thing. It's deciding whether the thing should exist.

When anyone can build anything, the differentiator isn't output — it's what you refuse to ship.

It's having opinions about accessibility before the feature ships, not after someone files a complaint. It's caring about data privacy when the expedient thing is to log everything and sort it out later. It's asking whether the thing you're building makes someone's life genuinely better or just extracts their attention more efficiently. These aren't nice-to-haves. They're the constraints that make the product worth trusting — applied at the level of what you choose to build, not just how you build it.

I've watched teams sprint to build features that nobody should have built. I've shipped things I'm not proud of because the deadline mattered more than the principle. Those feel worse now than they did at the time. The speed was never worth the trade.

This isn't nostalgia for a slower era. It's the opposite — when the tools let you move faster than your judgment, your principles are the only braking system you have. You don't give up your values in this transformation. You need them more, not less. The engineers and organizations that hold the line on "we don't build it that way" will be worth more than the ones who build everything as fast as possible.

I wrote about this in Why Everyone Should Have a SOUL.md — the idea that documenting your principles isn't just self-help, it's infrastructure. It's knowing what wall your ladder leans against before the wind picks up.

The Apprenticeship Problem

This is the part that worries me most.

My first real engineering job, I spent three months writing data migration scripts. Nobody's idea of glamorous work. Move this field to that table. Handle the nulls. Run it against staging, watch it break, figure out why, fix it, run it again. I did this dozens of times, and each time something different went wrong — character encoding, timezone mismatches, a foreign key I didn't know existed. By the end, I could look at a schema and feel where the landmines were before I stepped on them.

That feeling — the anticipatory flinch — is what I'd call judgment. And I didn't get it from a book or a lecture. I got it from repetition that was tedious enough to be annoying and consequential enough to be memorable.

I'm not sure where that comes from anymore.

The career ladder wasn't just hierarchy — it was a compression gradient. Low-risk tasks at the bottom. Higher-stakes ambiguity at the top. You earned your way upward by surviving increasingly consequential decisions. AI compresses the bottom of that ladder. The rungs aren't just harder to reach — some of them are gone.

Entry-level postings shrank about 60% between 2022 and 2024. By late 2025, 76% of employers were hiring the same number or fewer entry-level staff. The NACE Job Outlook 2026 survey shows employer optimism about graduate hiring at its lowest since 2020. One engineering manager told Pragmatic Engineer: "We paused junior hiring about 3 years ago."

Judgment is not abstract reasoning. It's exposure to constraint. The memory of consequences. The way your stomach drops when you see a migration script that doesn't handle rollback, because you've been the person who had to roll back manually on a Wednesday night while everyone else was asleep. Historically, apprenticeship solved this — electricians learned beside master electricians, journalists rewrote drafts under sharp editors, designers absorbed taste through critique. The friction was the curriculum. Nobody planned it that way. The tedium just happened to be educational.

If AI removes friction at the execution layer, apprenticeship has to migrate somewhere else. Maybe the first rung becomes evaluation instead of implementation. Maybe juniors learn to critique agent output, trace failure modes, define constraints, and decide what not to ship. But that's learning to evaluate without having done. Learning to recognize mistakes you haven't personally made. I'm not sure that works. The scar tissue metaphor isn't just poetic — you literally need to have been burned to flinch at the right moment.

A system that optimizes away beginner work risks optimizing away beginner growth. And organizations that stop hiring juniors eventually starve their own future seniors. Every industry that eliminated apprenticeships eventually faced a skills crisis a generation later. We know this.

What I'd Actually Tell Someone

If I'm being honest with my friend — the one with real skills and kids and a job search that can't wait for the market to figure itself out — the advice is different than what I'd tell a new grad. He doesn't need to retrain. He needs to find the place where what he already knows meets something agents can't cheaply replicate. Computer vision plus manufacturing. ML plus compliance. The compound skill — technical depth married to a domain where the stakes are personal and the liability is real. That's not a pivot. That's leverage.

For someone earlier in their career — someone facing the apprenticeship crisis I just described — the calculus is different:

Go deep on something where the stakes are real and the liability is personal. Distributed systems. Security. Performance at scale. The stuff where getting it wrong costs millions or kills people. Agents will get better at these too, but the liability question buys you time.

Learn to evaluate, not just produce. The skill isn't writing code — it's reading what an agent wrote and knowing what's wrong with it before it hits production. I spend more time reviewing agent output than I ever spent writing code myself. It's a different muscle. It's also a more valuable one.

Build things with real users. Not demos. Not tutorials. Not a course project. Something with users who depend on it, that breaks in ways you have to fix on a deadline you didn't set. The gap between "it works" and "it works for 10,000 people who are angry when it doesn't" — that's where humans still live. That's the new apprenticeship. It's lonelier than having a team and a mentor. It's also more available than ever, because the tools to build are nearly free. The friction isn't gone. It just moved.

Think beyond the code. Strategy, organizational awareness, the ability to synthesize across domains — these compound in a way that pure technical skills don't. The person who can see the whole board is more valuable than the person who can move any individual piece really fast.

Both groups, honestly: pick something you want to make and don't stop until it works. The tools will meet you wherever you are. I wrote about this in Building at the Speed of Thought — when execution is nearly free, iteration replaces deliberation. That's always been true. AI just made it more obviously true.

Don't sleep on the physical, either. Rent a Human — a marketplace where AI agents literally hire humans for physical tasks, because software still can't open a door or shake a hand. The physical world is gated, and that gate isn't opening anytime soon. But beyond the dystopian framing, there's something real underneath: small jewelers, specialty manufacturing, craft work — things where the human touch is the product, not the process. When everything digital becomes abundant, scarcity moves to the tangible. It sounds like a retreat. Might be an advance.

What I Don't Know

I don't know if "AI engineer" is a real role or a transitional label. LinkedIn says it's one of the fastest-growing titles over the past three years, alongside "Forward-Deployed Engineer" and "Data Annotator" — a list that tells you something about how the market is trying to name what's happening, and not quite getting there. I've watched this happen before.

I graduated right into the Hadoop wave. "Big Data Engineer" was the title that got you hired in 2013, and if your resume didn't mention MapReduce you were invisible. Hadoop died, but big data didn't — it diffused into data warehouses, Databricks, lakehouses, data mesh, dbt, distributed query engines. The title disappeared because the work won. It won so thoroughly it stopped being a specialization and became the plumbing.

"NoSQL specialist" was a personality trait for about three years. MongoDB on everything, even where Postgres would've been fine. The industry eventually landed on "it depends on your access patterns" — which is what the senior people were saying the whole time.

"Web developer" was a title I held early in my career. I couldn't tell you what it means now. I do know that frontend is still a deep discipline — but the web is also just where software lives. Almost every engineer is expected to throw together a UI or build a RESTful endpoint. The specialty sharpened and the floor rose at the same time.

"Cloud Architect" carried weight when migrating to the cloud was a bet that could sink a company. Now it's where things run.

DevOps started as a movement — development and operations working together, not throwing code over the wall. Companies couldn't figure out how to do that organically, so they turned it into a title: "DevOps Engineer."

Now the culture is actually landing. Werner Vogels' "you build it, you run it" stuck — developers own the full lifecycle, deploy their own code, page themselves when it breaks. The dedicated title is dissolving because the expectation got absorbed into the engineering role itself. Infrastructure specialists still exist, but they're less "bridge between two teams" and more platform engineers — building the internal tools and guardrails so everyone else can self-serve. Same pattern as frontend: the specialty sharpened while the floor rose.

The trajectory is always the same: specialty → mainstream → implicit → what was the title for again?

That arc might be the most relevant one for AI. Right now we're hiring "AI Engineers" because we don't know how to make it the culture yet. But the specialty will split the same way: on one end, the deep work — building transformers, training models, designing embedding spaces. On the other, something more operational and advisory — coaching teams on multi-agent coordination, prompt engineering, model selection, setting up the guardrails and review patterns so everyone else can use agents effectively. Less "I build the AI" and more "I make sure we're using it well." The platform engineer of the agent era.

And then everyone else — using agents as part of their job the way they use Git or AWS today. Not specialists. Just engineers. Fewer of them, probably. But the work doesn't disappear — it changes shape. More surface area to tend, more products to maintain, more decisions that need a human accountable for the outcome. You can't vibe-code a company's production systems forever. Someone has to own what ships.

And there's a version of this — Jevons Paradox — where making software cheaper to produce means we produce more of it, not less. More software, more surface area, more need for people who can tend it. History says efficiency doesn't reduce demand. It creates it.

What I don't know is what the titles look like on the other side. The skills I described — taste, judgment, constraint design, knowing what not to build — none of those map cleanly to a job listing. "Experienced enough to flinch at the right moment" doesn't fit on a resume. The market is going to lag reality here, the way it always does. For a while, the titles will be wrong. They'll reward the legible thing (AI experience, agent fluency) and undercount the illegible thing (scar tissue, organizational wisdom, the ability to say no). My friend from Amazon will probably land fine. He's good at what he does, and the market is paying for his keywords. But the gap between what gets him hired and what makes him valuable — that's the gap this whole essay is about.

I don't know what my own job looks like in three years, and I've been doing this for twelve.

And I keep thinking about the economic shape of all this. Moody's Analytics reported in late 2025 that the top 10% of earners now account for nearly half of all U.S. consumer spending — a historic high. Knowledge workers are disproportionately in that top 10%. Their jobs are exactly the ones most exposed to this shift. The Klarna model — half the people, higher salaries — might be the optimistic version. The pessimistic version is entire layers of well-compensated work disappearing, and the consumer spending that depended on them going with it. The economy is lopsidedly dependent on a group of people whose jobs are being redefined in real time. That's a tension I don't see anyone resolving cleanly.

What I do know: things never pan out the way people imagine. The doomsayers and the utopians are both going to be wrong. The reality will be weirder and more uneven than either camp predicts. Some industries will be fine. Some will be devastated. Most will be somewhere in between — changed enough to be disorienting, stable enough to be recognizable.

The amplitude is increasing. The frequency is increasing. The feeling of "new but also more of the same" is exactly right. Every revolution feels like this from inside.

If there's one thread running through all of it — the apprenticeship, the guardrails, the access question, what's left — it's that purpose isn't a skill you can automate. It's the thing that makes every other skill worth having.

Buttercup is dead now. The project shut down and the repos are archived. I'd been seeing the writing on the wall for a while — slow updates, mobile app falling behind, browser extension getting flaky. It was a solo maintainer's passion project that quietly ran out of steam. The usual open-source story, and I don't hold it against anyone. But it left me looking for a new home for ~400 credentials, and more importantly, looking for the same feeling.

That feeling has a name, I think. I'd call it vault sovereignty — the principle that your secrets should be a file you own, not a row in someone else's database.

This isn't a side-by-side comparison. Those exist, and honestly, the best way to choose a password manager is to try a few yourself — they're all free or cheap enough to test. This is more about the philosophy underneath the choice, and why sovereignty keeps showing up as the thing I can't stop thinking about.

The Sovereignty Lineage

Buttercup didn't invent this idea. It inherited it from a lineage of tools that share the same instinct:

pass (the Standard Unix Password Manager) is the purest expression. Each password is a GPG-encrypted file in a directory tree. That's it. ~/.password-store/Email/gmail.com.gpg. Version-controlled with Git. Decrypted with your GPG key. The "database" is your filesystem. The "sync" is git push. The "backup" is whatever you do with your home directory. It's beautiful in its refusal to be anything more than what it is — and if you're comfortable with GPG and the command line, it's arguably still the best option.

VeraCrypt (and its predecessor TrueCrypt) applied the same philosophy to disk encryption: your encrypted volume is a file. Mount it, use it, dismount it. No service. No account. The file is the thing. Move it to a USB drive, put it in Dropbox, copy it to a NAS — the encryption travels with the data, not with the vendor.

KeePass and its derivatives (KeePassXC, KeePassDX) — the .kdbx file format became the de facto standard for portable encrypted vaults. Not pretty, but indestructible. The format has outlived multiple GUI clients. That's sovereignty: when the container survives the tool.

What connects all of these is a shared architectural choice: the vault is a file, not a service. Your secrets live in a container you can hold, move, back up, and — critically — walk away from without asking permission.

I should caveat this honestly, because the more I think about it, the less clean the argument is. That vault file? In practice, it usually lives on someone else's infrastructure anyway. My Enpass vault syncs through iCloud Drive. It could just as easily be Dropbox, Google Drive, OneDrive — all someone else's servers. So what am I actually gaining over trusting 1Password directly?

I think the real distinction is separation of trust, not elimination of trust. With 1Password, you trust one entity with the full vertical stack — the encrypted vault, the decryption software, the key derivation, and the infrastructure. If they fail, it's all one failure. With the vault-as-file model, you're splitting the trust: Apple holds an opaque encrypted blob they can't read, and Enpass provides the software that decrypts it but never sees the file in transit. Neither party alone has the full picture. It's separation of concerns applied to trust — independent failure modes instead of a single point.

Is that better? Honestly, I'm not sure. 1Password's security team is almost certainly more sophisticated than my ad-hoc trust layering. Their Secret Key architecture means even a server breach doesn't expose usable vault data — which is more than LastPass could say. The vertical integration lets them ship things like Watchtower and secure remote password protocol that a decoupled architecture simply can't do. Sometimes trusting one very competent party is safer than trusting two adequate ones.

But there's a difference between security and sovereignty, and I think that's what I'm actually reaching for. I touched on this in [[Pervasive AI: What Happens When Your Assistant Never Logs Off]] — people overwhelmingly choosing to run their AI agents on local hardware they can unplug, not cloud instances. Same instinct, different domain. Sovereignty isn't "my data never touches a cloud." It's "I can change my mind." I can move the file. I can switch the sync layer. I can export and start over. The relationship between me and my password manager doesn't depend on a subscription remaining active or a company remaining solvent. Maybe that's not a security argument. Maybe it's a dignity argument. I'm still working it out.

It's the same instinct behind Obsidian and Joplin for notes. Local-first. Files you own. Sync is your problem, which means sync is your choice. The data format is the contract, not the vendor relationship.

Where I Landed: Enpass

After Buttercup died, I switched to Enpass. It's not open source — which matters, and I'll get to that — but it carries the same ethos:

• Your vault is a local SQLCipher file. Enpass never sees your data. There's no Enpass cloud. You sync through your own iCloud, Dropbox, Google Drive, OneDrive, or a WebDAV server. The vault file moves through infrastructure you already control.
• One-time purchase option. $99.99 for a lifetime license. In a world where everything is $3-5/month forever, the existence of a "pay once, own it" option says something about how a company thinks about its relationship with you.
• Cross-platform. Mac, Windows, Linux, iOS, Android, browser extensions. This is where Buttercup was weakest and where Enpass is genuinely solid.
• Passkey support. Arrived in 2024, works well.

The tradeoff is real: closed source means you're trusting Enpass's claims about encryption without being able to verify them. They've published security audits and use SQLCipher (which is open and well-reviewed), but you can't read the application code. You can't verify there's no telemetry, no silent phone-home, no future update that changes the deal. The published audits are vendor-commissioned and time-bound — a snapshot, not a guarantee. Then again, open source isn't a panacea either — the xz backdoor proved that. A patient attacker spent years earning trust as a maintainer of a critical compression library, then slipped a backdoor that almost shipped in every major Linux distro. "You can audit it" assumes someone actually does, and for most open-source projects, that someone is a burnt-out solo maintainer. (Sound familiar? That's how Buttercup died too — different failure mode, same structural vulnerability.) It's a calculated risk either way: I'm trading auditability for the combination of local-file architecture and cross-platform polish that no fully open-source option has nailed yet. If I stop trusting Enpass tomorrow, I can export my data and leave. The lock-in is minimal. That's the sovereignty test: not "is it open source?" but "can I leave?"

Enpass doesn't actually have an official CLI — it's been a feature request for years. But a community member built enpass-cli, a Go binary that reads your vault file directly. It does what you'd expect: enp list twitter, enp copy reddit.com, password=$(enp pass github.com) for scripting. JSON output, non-interactive mode, even a PIN-based quick unlock. It's not a first-class developer tool like 1Password's op, but the fact that someone could build it — because the vault is just a SQLCipher file on disk — is kind of the point. The architecture enables third-party tooling even when the vendor doesn't provide it.

The Elephant: 1Password

1Password is the best password manager. I should just say that clearly, because it is. The UX is polished, the security model is strong (the Secret Key alongside your master password is genuinely clever), the browser extension works beautifully, the family sharing is well-designed, and the developer tooling is in a league of its own.

And yet.

It's $36/year for an individual — well, it was. 1Password just announced a 33% price hike effective March 27, 2026: $47.88/year individual, $71.88/year family. Bitwarden raised prices recently too. The trend is clear. That's still not expensive by any reasonable standard. But there's something about paying a subscription for a password manager that creates a low-grade, persistent discomfort — the same feeling as subscribing to a notes app or a to-do list. It's not that the price is wrong. It's that the category feels wrong for rent-seeking. A password vault is a box with a lock. I don't want to rent a box. I want to buy one and put it on a shelf.

This is probably irrational. 1Password employs a security team. They run infrastructure. They ship updates. The subscription funds real, ongoing work that protects real people. I know this. The feeling persists anyway.

Where 1Password genuinely earns its premium — and where the sovereignty tools can't compete — is the developer and agent story. The op CLI is exceptional:

# Read a single secret
op read "op://Personal/GitHub/token"

# Inject secrets into a process without exposing them in env
op run --env-file=.env.tpl -- npm start

# Use in MCP server configs without hardcoding tokens
op run -- node mcp-server.js

That op run pattern is the important one. It injects secrets into a child process's environment at runtime, scoped to that process, without the secrets ever touching your shell history, your .env files, or your global environment variables. When the process exits, the secrets evaporate. 1Password has leaned into this hard — they've published guides specifically for securing MCP server configurations and integrating with AI agents via their SDK. Their pitch: credentials should be injected on behalf of agents, never seen by the agent or the LLM.

This is the right architecture. And right now, only 1Password has it in a polished, production-ready form.

The Agent Credential Problem

This is where password managers intersect with the [[Pervasive AI: What Happens When Your Assistant Never Logs Off|always-on agent]] world, and it's messier than anyone's admitting.

When you run an AI agent like OpenClaw, it needs credentials. API keys for Anthropic. OAuth tokens for Gmail. SSH keys for servers. And the default pattern is horrifying: dump everything into environment variables, a .env file, or worse, directly into a system prompt. Every credential is one prompt injection away from exfiltration. Every API key in an env var is visible to every process on the machine.

The responsible approach has layers:

1. Never export secrets globally. Don't export ANTHROPIC_API_KEY=sk-... in your shell profile. Every process on your machine can read it.
2. Use process-scoped injection. op run (1Password), passage with pass, or similar — secrets exist only in the child process's environment.
3. Prefer short-lived tokens. OAuth refresh flows over long-lived API keys. Rotate aggressively.
4. Scope narrowly. An agent that checks your email doesn't need your SSH keys. An agent that deploys code doesn't need your email credentials.
5. Audit access. Know which secrets an agent touched and when.

pass is surprisingly good for this — arguably better than any GUI password manager for the agent use case. Because each secret is a file, you can:

# Read a single secret into a variable, scoped to this command
GITHUB_TOKEN=$(pass show tokens/github) gh pr list

# Or use pass with a wrapper script for Claude Code
ANTHROPIC_API_KEY=$(pass show api/anthropic) claude --dangerously-skip-permissions "task"

The GPG agent caches your passphrase, so you authenticate once and subsequent reads are transparent. It's not pretty, but it's correct — each secret is individually encrypted, individually accessible, and never written to disk in plaintext. And because it's just files and GPG, it works with any tool that can read an environment variable. No SDK. No vendor integration. Just Unix.

There's a whole parallel universe of infrastructure secrets managers — HashiCorp Vault, Google Secret Manager, AWS Secrets Manager, Doppler — designed for the same problem but at the service level: database credentials, TLS certs, service-to-service API keys. The principal isn't a human; it's a workload with an IAM role. These are fundamentally readable stores — you authenticate, you get the secret back as plaintext. They protect secrets at rest and gate access via IAM, but the secret itself is a string that ends up in your process's memory. Same model as a password manager, just for machines instead of humans.

HSMs (hardware security modules) are a different beast entirely. They're not storing secrets you read back — they hold keys that act on your behalf. An HSM is essentially a tamper-resistant mini-computer with its own processor, memory, and OS. You send it an instruction ("sign this transaction with key X"), it executes internally, and sends back the result. The private key never comes out — you authenticate through some other channel, and the HSM does the cryptographic work for you. If someone physically tampers with the device, it zeroes itself. Cloud KMS services (Google Cloud KMS, AWS KMS) can optionally be backed by HSMs, though it's opt-in and costs more — the default is software-based key storage.

The sovereignty tension is different for each. Secrets managers are about access control: who gets to read this? HSMs are about physical containment: this key cannot leave, period. That's what makes them secure — and what makes them terrifying. I worked with HSMs for cloud-deployed crypto payment automation, and the feeling was both at once: reassuring because the key was actually safe inside tamper-resistant hardware, and unsettling because the HSM was opaque. You can import a key you already hold (and keep your copy), but the purist approach is generating the key inside the hardware — it never exists in software, ever. For those keys, if something happened to the HSM, the key was gone. Not "reset your password" gone. Gone gone. And even for imported keys, the opacity is real — you can't inspect the HSM's state, can't verify the key is still there, can't peek inside. You just trust the black box.

An HSM-backed cloud KMS is arguably more secure than your local SQLCipher file, but it's the opposite of sovereignty — your key cannot leave their hardware, and that's both the security guarantee and the lock-in, simultaneously.

Crypto wallets live in the same tension. "Not your keys, not your crypto" is the sovereignty thesis applied to money. When Ledger added Recover in 2023 — opt-in cloud backup of your seed phrase — the hardware wallet community revolted, because the mere capability of extracting the key from the secure element broke the trust model, even if you never used it. Crypto's answer to the HSM recovery problem is HD wallets (BIP-32) — a master seed phrase that can re-derive every child key. The seed is your sovereignty layer; the HSM is your operational security layer. But the core tension remains: the more secure the containment, the higher the stakes of losing access.

Agents sit awkwardly between these worlds. Not quite a human (no biometrics, no interactive auth). Not quite infrastructure (conversational, ad-hoc, not deployed via Terraform). But needing credentials like both.

The gap in the market is obvious: nobody has built a good, sovereignty-respecting credential broker for AI agents. 1Password is closest with op run and their SDK, but it requires their subscription and their infrastructure. pass is correct but requires GPG comfort. Enpass's community CLI exists but isn't widely adopted. Bitwarden has a CLI but the UX story is rough.

What I'd want in the near term: something with pass's file-based architecture, Enpass's cross-platform GUI for daily use, and 1Password's op run semantics for agent credential injection. Maybe that's a pass frontend. Maybe it's an Enpass plugin. Maybe someone builds it from scratch. The pieces are all there.

Longer term, though, the answer probably isn't better password managers for agents — it's moving past passwords entirely. The patterns already exist elsewhere. Blockchain solved delegated agent authority with account abstraction — session keys with spending limits that expire, so an agent can transact without ever holding the master private key. Cloud infrastructure solved it with workload identity federation — no stored credentials at all, just short-lived tokens exchanged on the fly via OIDC. Both point at the same principle: scoped, short-lived, delegated authority instead of "here's the password, good luck." The future isn't giving agents better access to your secrets. It's a world where agents authenticate through delegated identity and never see a credential at all. We're just not there yet for most services.

The Landscape, Honestly

Here's where things actually stand, as someone who's used most of these:

The top tier:

• 1Password — best overall, best developer story, best agent integration. Subscription feels wrong for the category (and just got 33% more expensive) but the product earns it. The security model (Secret Key + master password) is uniquely strong.
• Apple Passwords — genuinely good now. The standalone app (iOS 18 / macOS Sequoia) turned iCloud Keychain from an invisible background service into a real password manager. Passkey support, shared groups, Windows app via iCloud. For anyone fully in the Apple ecosystem who doesn't need CLI access or cross-platform beyond Windows, this is honestly enough. Free. Just there.

The sovereignty tier:

• Enpass — my current pick. Vault-is-a-file, sync-through-your-own-cloud, one-time purchase. Not open source, but the architecture means low lock-in. Solid cross-platform. CLI exists but is basic.
• Bitwarden — spiritually aligned (open source, self-hostable, generous free tier). But every time I've used it, the UX has that slightly-off feeling — slow autofill, clunky browser extension, desktop app that feels like an afterthought. It's getting better. It's not there yet. The community swears by it. I've bounced off it twice.
• KeePassXC — the indestructible vault. .kdbx is the cockroach of password formats (complimentary). If you want maximum portability and don't mind a utilitarian UI, this is the way. Browser integration has improved significantly.
• Proton Pass — the new entrant getting serious buzz. $199 lifetime option (via Proton Unlimited). Part of the Proton ecosystem (Mail, VPN, Drive), which appeals to the privacy-maximalist crowd. E2E encrypted, open source. Growing fast on Reddit recommendations. Haven't used it long enough to have strong opinions, but the trajectory is interesting.

The declining:

• LastPass — the 2022 breach was catastrophic, and the fallout is still ongoing. Feds linked $150M+ in crypto theft to the stolen vault data. Market share dropped from 21% (2021) to 11% (2024) and is presumably still falling. Hard to recommend with a straight face.
• Dashlane — hasn't had a defining moment in years. Fine product, nothing compelling enough to choose it over the others. The VPN bundling feels like a company searching for differentiation.

The gone:

• Buttercup — archived. RIP to a good ethos with insufficient resources. The .bcup format didn't outlive the project, which is the sovereignty failure mode: your file format needs to survive your tool.

Just this month, researchers at ETH Zurich published a study that put a dent in the "zero-knowledge" promises of cloud-based managers. They demonstrated 12 attacks on Bitwarden, 7 on LastPass, and 6 on Dashlane — including full vault compromise under a malicious-server threat model. Even 1Password wasn't immune to all classes of attack. These are advanced-adversary scenarios, not mass-exploitation vectors, but they undermine the core confidence that "even if the server is compromised, your data is safe." The question isn't whether vulnerabilities exist (they will). It's how quickly they're found, disclosed, and fixed — and whether your architecture limits the blast radius when they are. It's also, quietly, an argument for the sovereignty model: if there's no server to compromise, the malicious-server threat model doesn't apply.

The Ethos

What I'm really circling around isn't a product recommendation. It's an architectural preference — maybe a philosophical one.

The tools I gravitate toward share something: they treat your data as yours. Not hosted. Not synced through the vendor's servers. Not contingent on a subscription remaining active. A file. Encrypted. On your machine. Yours to move, yours to back up, yours to lose if you're careless.

This is the same instinct that makes people run OpenClaw on a Mac Mini instead of a cloud VPS. The same instinct behind Obsidian over Notion. Local-first over cloud-first. Ownership over convenience. The [[Pervasive AI: What Happens When Your Assistant Never Logs Off|sovereignty section]] of my agent post touched on this — people want their AI agent close, on a machine they can unplug. Password vaults have been in this territory for a decade longer. The pattern is the same: the more personal the data, the stronger the pull toward physical control.

It's not always the practical choice. 1Password's cloud sync is seamless in a way that "sync your own vault file through iCloud Drive" just isn't. Apple Passwords works without thinking about it at all. Convenience is a feature. I'm not pretending otherwise.

But there's something about a world where every service wants a subscription, every tool wants a cloud account, every piece of software wants to be the intermediary between you and your data — there's something about a .kdbx file on a USB drive that feels like a small act of resistance. Maybe not a smart one. But an honest one.

The next question — the one I don't have a good answer to yet — is how to extend that sovereignty to the agent world. When my AI assistant needs my GitHub token to push a commit, I want it to have exactly that credential, for exactly that task, for exactly as long as it needs it, with a clear audit trail. Not a global env var. Not a plaintext config file. Not "just put it in the system prompt."

1Password is building this. The open-source world hasn't caught up yet. But the pieces — pass, GPG, process-scoped injection, credential brokers — are all there, waiting for someone to assemble them into something that feels as natural as op run but doesn't require a subscription to use.

I'll be watching for it. In the meantime, my Enpass vault sits on my iCloud Drive — a SQLCipher file, encrypted, portable, mine. It's not perfect. But it's here, and that counts for something.

I felt relief.

GA4 had been dragging my Lighthouse score into the mid-80s. I even tried offloading it to a service worker with Partytown — limited improvement. The analytics tool was the biggest performance problem on the site. There's something deeply ironic about your measurement system being the thing that degrades the experience you're trying to measure.

But it wasn't just the performance tax. It was the realization that I'd been collecting data I never looked at, for an audience model that doesn't apply to a personal blog, using an interface redesigned for enterprise marketing teams who need attribution funnels and audience segments. I don't have funnels. I have essays.

I want a small, legible system that tells me what landed, what didn't, and what changed — without turning my site into spyware or slowing it down. This is a draft spec for that system.

Problem framing

Most analytics tools optimize for one of two extremes:

1. Marketing surveillance suites (powerful, heavy, identity-centric)
2. Minimal privacy counters (lightweight, sometimes too shallow)

A personal blog needs a third thing:

• privacy-first,
• edge-native,
• cheap enough to run free,
• and queryable in natural language without outsourcing judgment.

The goal is not more dashboards. The goal is better questions.

First principles

1. Signal over exhaust. What posts are actually read? Which referrers produce meaningful attention?
2. Trend shape over user identity. Momentum, decay curves, evergreen vs spike.
3. No trust tax. No fingerprinting, no cross-site identifiers, no covert profiling.
4. No performance tax. No Lighthouse regressions, no render-path blockers. The irony of GA failing this one still stings.
5. No ops tax. Runs on Cloudflare's free tier for low/moderate traffic. Deploys via GitHub Actions on push. No servers to maintain, no containers to manage, no uptime to monitor.
6. AI as interface, not authority. Conversational query layer over deterministic metrics.

Prior art (and what to steal)

I looked at everything. The privacy-native tools — Plausible, Umami, GoatCounter, Ackee — get the lightweight collection right: small scripts, no cookies, respect for the reader. Plausible in particular would be the obvious choice if I didn't want to build my own. But I do. Matomo and PostHog are impressive and wildly overkill for a solo blog.

The interesting steals are from adjacent systems:

• OpenTelemetry: not the SDK (enormous) or the collector (a whole deployment), but the naming discipline. http.request.method, url.path, user_agent.original — standardized field names that make data portable without tribal knowledge. If the schema looks like OTel, any tool can query it later.
• Axiom.co: the ingest-first philosophy. Raw-ish event logs in a columnar format you can query ad-hoc. This maps directly to the R2 monthly exports — NDJSON that DuckDB, BigQuery, or Axiom itself can ingest. If this system outgrows D1, Axiom is the natural escape hatch.
• Sentry: not the 180KB SDK, but the pattern. window.onerror + onunhandledrejection as a ~15-line error signal. Errors are analytics too — "this page throws a TypeError on Safari mobile" is useful data.

The synthesis: steal from the lightweight tools for collection posture, from the heavy tools for naming conventions and philosophy. Skip everyone's infrastructure.

Architecture judgment

The system should reflect how I build things, not just what it does.

• TypeScript, Bun. Type safety everywhere. If a function can return the wrong shape, it will — at 3am, in production.
• Pure functions and composition over classes. classifyReferrer(host) → Source is a function. ReferrerClassifier is a class that exists so someone can write a constructor. Prefer the function.
• Never write directly to the database from the hot path. Every event goes through the DO aggregator first. The DO is the write buffer. D1 only sees batched, coalesced flushes — never raw request-time writes. If the flush fails, the DO retries. If D1 is contended, the DO backs off. The database is never the thing that breaks under load.
• Backpressure is not optional. If ingestion outpaces aggregation, the DO queues. If aggregation outpaces D1, the DO backs off exponentially. If everything's on fire, governor mode kicks in and sheds load gracefully. No silent data loss. No "it seemed fine in dev."
• Modularity through boundaries, not abstractions. Ingestion, aggregation, storage, query, and AI are separate Workers/DOs with typed interfaces between them. Not a monolith with "clean architecture" folders. Actual deployment boundaries.
• Idempotent everything. Every flush has a batch ID. Every write is safe to retry. The system should be correct after a crash, not just during normal operation.
• Append-only where it matters, mutable where it serves. Raw events are append-only at the ingestion boundary — never mutate what the client sent. Aggregates are mutable by design (upserts that coalesce counters). R2 exports are immutable — write-once NDJSON, never overwritten. Three different postures for three different concerns: integrity at the edge, efficiency in the middle, portability at the exit.

Assumptions

1. Cloudflare Workers + D1 + Durable Objects are available
2. JavaScript may be blocked — baseline still works server-side for pageviews where possible
3. Coarse-grained analytics (daily/hourly aggregates) are enough
4. No individual user/session re-identification. Period
5. Reading quality and trend direction matter more than ad attribution precision
6. Script budget: ≤1.5KB gzipped (aspirational), hard cap ≤2KB

Requirements

Because this is a design exercise as much as a product spec, I want to be explicit about what this system must do versus how it must feel doing it. These aren't aspirational — they're the acceptance criteria I'll hold myself to.

Functional requirements

These are the capabilities. What the system does when everything's working.

Nonfunctional requirements

These are the constraints. How the system behaves under pressure, at the edges, and over time — the stuff that determines whether you actually trust it.

A few things to notice about this split: the FRs are roughly ordered by collection → query → export (data flows downhill). The NFRs are roughly ordered by what your reader cares about (weight, speed, privacy) → what your system cares about (integrity, pressure, bounds) → what future you cares about (portability, ops, recovery). That ordering is intentional — it mirrors who screams first when something breaks.

Non-goals (v1)

• Session replay, heatmaps
• Fingerprinting
• Cross-device identity stitching
• Real-time per-user journey visualization
• Freeform SQL generated by the LLM
• Return visitor tracking — can't do it honestly without cookies or fingerprinting, and the proxy signals (growing direct traffic, RSS subscribers, stable engagement rates across posts) already tell you whether you have an audience. A post with 65% completion doesn't care whether the reader was new or returning

RFC: AI-Native Analytics for Blogs (v0.1)

1) High-level architecture

graph TD
  subgraph Client
    A["a.js (≤2KB)"]
  end

  subgraph Ingestion
    B[Worker: /a/collect]
  end

  subgraph Aggregation
    C[Durable Object] --> D[(D1)]
    D -.->|monthly snapshot| E[(R2 exports)]
  end

  subgraph Query
    F[Worker: /api/metrics]
    G[MCP Tools]
    H["analytics snapshot"]
  end

  A -->|sendBeacon| B
  B -->|validate + normalize| C
  D --> F & G & H

Ingestion plane

• Worker endpoint: POST /a/collect
• Accepts compact events (pv, engaged, outbound, optional custom)
• Validates payload via Zod, normalizes dimensions, forwards to per-site aggregator DO

Aggregation plane

• Durable Object per site_id
• Maintains short-lived counters in memory
• Flushes batched aggregates to D1 (interval and size thresholds)
• rrdtool-inspired: coalesce first, persist later

Storage plane

• D1 stores aggregate facts + compact dimensions
• Fixed-size storage inspired by rrdtool/Graphite whisper (see below)
• Optional: R2 monthly snapshots / exports
• Optional: KV for query cache

Query plane

• Worker endpoint: GET /api/metrics/*
• Serves typed metric queries from D1
• Caches common dashboard reads

AI plane

• POST /api/ask with constrained query planner
• MCP server exposes typed analytics tools
• LLM summarizes deterministic outputs only

2) Collection protocol

Event envelope

export type EventKind = "pv" | "engaged" | "outbound" | "error" | "vital" | "custom";

export interface CollectEvent {
  kind: EventKind;
  ts: number; // epoch ms
  path: string; // normalized pathname
  ref?: string; // raw referrer (optional)
  title?: string; // optional page title hashable
  utm?: {
    source?: string;
    medium?: string;
    campaign?: string;
  };
  meta?: Record<string, string | number | boolean | null>;
}

export interface CollectRequest {
  site: string;         // public site key
  v: 1;                 // protocol version
  events: CollectEvent[];
}

Default events (fire automatically)

The client script emits these without any configuration:

JS error capture (Sentry-lite)

Not a full error monitoring product. Just a signal: "something broke on this page."

window.onerror = (message, source, line, col) => {
  queue({
    kind: "error" as EventKind,
    ts: Date.now(),
    path: location.pathname,
    meta: {
      message: String(message).slice(0, 256),
      source: source?.split("/").pop() ?? "unknown", // filename only, no full URLs
      line: line ?? 0,
      col: col ?? 0,
    },
  });
};

window.onunhandledrejection = (event) => {
  queue({
    kind: "error" as EventKind,
    ts: Date.now(),
    path: location.pathname,
    meta: {
      message: String(event.reason).slice(0, 256),
      source: "unhandled_rejection",
    },
  });
};

What this answers:

• "Is my site broken on Safari mobile?" — check error rate by device class
• "Did my last deploy introduce a regression?" — compare error rates across dates
• "Is this a real problem or a browser extension?" — source filename distinguishes your code from injected scripts

What this doesn't do: stack traces, source maps, breadcrumbs, user replay. For that, use Sentry. For a blog, error rate is the signal. Error detail is a debugging tool you reach for when the rate spikes.

Stored as custom events, aggregated into a simple error counter on fact_daily:

ALTER TABLE fact_daily ADD COLUMN error_count INTEGER NOT NULL DEFAULT 0;

Custom events (custom) require explicit instrumentation:

// Only if someone wants to track something specific
window.__a?.track("signup_click", { cta: "header" });

The API surface is one function. If window.__a doesn't exist (script blocked, not loaded yet), the call silently no-ops.

OTel-inspired semantic naming

We don't use the OpenTelemetry SDK. But we steal its naming discipline. When data leaves this system — via R2 export, MCP tool output, or the ask endpoint — field names should be recognizable to anyone who's worked with observability tooling.

The R2 monthly exports use OTel-aligned field names even if the internal D1 schema uses shorter column names. Export is the portability boundary — that's where naming discipline pays off.

Lightweight RUM (Real User Monitoring)

Core Web Vitals are too useful to skip and too small to justify skipping. Google's web-vitals library is ~1.5KB and gives you LCP, INP, and CLS — the three metrics that determine whether your analytics script is harming the site it's measuring.

import { onLCP, onINP, onCLS } from "web-vitals"; // tree-shaken

onLCP((metric) => queue({ kind: "custom", ts: Date.now(), path, meta: { vital: "lcp", value: metric.value } }));
onINP((metric) => queue({ kind: "custom", ts: Date.now(), path, meta: { vital: "inp", value: metric.value } }));
onCLS((metric) => queue({ kind: "custom", ts: Date.now(), path, meta: { vital: "cls", value: metric.value } }));

This isn't a full RUM product. It's a canary:

• "Did my last deploy regress LCP?" — check the trend
• "Is the analytics script itself causing CLS?" — it better not be
• "What's my real INP on mobile?" — useful for any interactive elements

Stored as custom events, aggregated into a fact_daily_vitals table:

CREATE TABLE IF NOT EXISTS fact_daily_vitals (
  site_id TEXT NOT NULL,
  date_utc TEXT NOT NULL,
  path_id INTEGER NOT NULL,
  device_class TEXT NOT NULL DEFAULT 'unknown',
  lcp_p75 REAL,     -- milliseconds
  inp_p75 REAL,     -- milliseconds
  cls_p75 REAL,     -- unitless score
  sample_count INTEGER NOT NULL DEFAULT 0,
  PRIMARY KEY (site_id, date_utc, path_id, device_class),
  FOREIGN KEY(site_id) REFERENCES site(id),
  FOREIGN KEY(path_id) REFERENCES dim_path(id)
);

p75 aggregation happens in the DO — not by storing raw values, but by maintaining a DDSketch or simpler quantile estimator in memory and flushing the percentile. Fixed memory regardless of sample count.

Budget impact: web-vitals is ~1.5KB gzipped. Combined with the core client (~500 bytes), total stays under the 2KB hard cap.

Protocol compatibility:

• server currently accepts v=1
• unknown fields are ignored (forward-compatible reads)
• future protocol bumps should be explicit (v=2 handling path + migration notes)

Engagement definition

An engaged event is a composite boolean, true when any of these conditions hold:

1. Reader crosses 60% article depth (single IntersectionObserver marker)
2. Reader keeps tab visible for >= 20s on article route
3. Reader clicks an outbound link from the article body

Why not only time-on-page? It lies. A tab left open in the background inflates engagement. Why not only scroll depth? It can miss accessibility and non-scroll reading patterns. Composite engagement is still simple, but less brittle.

This signal also helps bot filtering, but it is not the only bot defense.

Scroll milestones

Beyond the binary engagement signal, we track how far readers get. Four IntersectionObserver instances on invisible markers at article quartiles (25%, 50%, 75%, 100%). Each fires exactly once and disconnects.

const MILESTONES = [25, 50, 75, 100] as const;
type ScrollMilestone = typeof MILESTONES[number];

function observeScrollDepth(article: HTMLElement) {
  const height = article.offsetHeight;
  let maxDepth = 0;

  for (const pct of MILESTONES) {
    const marker = document.createElement("div");
    marker.style.cssText =
      "height:1px;width:1px;position:absolute;pointer-events:none;";
    marker.style.top = `${(pct / 100) * height}px`;
    article.style.position ||= "relative";
    article.appendChild(marker);

    const observer = new IntersectionObserver(
      ([entry]) => {
        if (entry.isIntersecting) {
          maxDepth = Math.max(maxDepth, pct);
          observer.disconnect();
        }
      },
      { threshold: 0 },
    );
    observer.observe(marker);
  }

  return () => maxDepth;
}

Why IntersectionObserver instead of scroll listeners:

• Zero main-thread work during scroll. Runs on the compositor thread — can't cause jank.
• No throttle/debounce decision to get wrong. The browser tells you when the marker enters the viewport.
• No getBoundingClientRect() calls. No forced reflow, no layout thrashing.
• Four callbacks total for the entire page visit. Then silence.

What this unlocks for a writer:

• "My analytics RFC has 90% reach-25 but only 30% reach-75 — people bail at the schema section"
• "The pervasive AI essay has 65% completion rate — the long version holds better than expected"
• "Posts under 1,500 words: 80% completion. Over 2,500: 45%. But the 45% that finish have 3x the outbound click rate"

The engagement event becomes: { kind: "engaged", maxDepth: 75, ... } instead of just a boolean.

Add max_depth to the daily fact:

ALTER TABLE fact_daily ADD COLUMN avg_max_depth REAL; -- 0-100
ALTER TABLE fact_daily ADD COLUMN completions INTEGER NOT NULL DEFAULT 0; -- reached 100%

Transport

let pending: CollectEvent[] = [];
let flushTimer: number | null = null;

function queue(event: CollectEvent) {
  pending.push(event);
  if (!flushTimer) {
    flushTimer = setTimeout(flush, 2000); // 2s debounce
  }
  if (pending.length >= 10) flush(); // size cap
}

function flush() {
  if (!pending.length) return;
  navigator.sendBeacon(
    "/a/collect",
    JSON.stringify({ site: SITE_KEY, v: 1, events: pending }),
  );
  pending = [];
  if (flushTimer) clearTimeout(flushTimer);
  flushTimer = null;
}

document.addEventListener("visibilitychange", () => {
  if (document.visibilityState === "hidden") flush();
});

• sendBeacon on visibilitychange with fetch({ keepalive: true }) fallback
• 2-second debounce to batch rapid events (pageview + milestone + engagement)
• Hard cap at 10 events per batch
• Never blocks navigation

Why no Service Worker

A Service Worker could queue failed beacons offline and retry via Background Sync. Sounds responsible. Not worth it.

• sendBeacon already survives page navigation — the only failure case is total network loss, and losing one pageview during a subway tunnel is not a data integrity problem for a blog
• Service Workers add a whole lifecycle (install, activate, update, cache versioning) for a client that's supposed to be <2KB and understandable in 60 seconds
• Service Workers can't call sendBeacon — you'd reimplement the same reliability with fetch, wrapping a reliable API in a more complex one for the same result
• The analytics script is <2KB with Cache-Control: immutable — the browser's HTTP cache handles this without a SW cache layer
• Cloudflare Workers already are the server-side "service worker" — intelligence on both ends creates two places to debug the same problem

The entire client architecture:

a.js (< 2KB gzipped)
├── IntersectionObserver × 4 (scroll milestones)
├── event queue (plain array)
├── debounced flush (2s / 10 events)
├── sendBeacon on visibilitychange
└── that's it

No Service Worker. No IndexedDB. No Background Sync. No scroll listeners. Understandable in 60 seconds.

3) Privacy model

• No cookies by default
• No localStorage identifiers
• No fingerprinting
• No raw IP storage (derive coarse geo server-side then discard)
• Configurable retention by table
• Optional per-site "strict mode" that disables custom events entirely

Collection integrity (anti-poisoning):

• signed payload mode for first-party script (HMAC(body + ts))
• replay window enforcement (reject stale timestamps)
• optional origin allowlist for collection endpoint

4) Data model (D1)

Schema strategy is intentionally split:

• v1: optimize for low cardinality and cheap queries (one row per site,date,path)
• v2: add breakdown tables for referrer/country/device when needed

-- Sites
CREATE TABLE IF NOT EXISTS site (
  id TEXT PRIMARY KEY,
  slug TEXT NOT NULL UNIQUE,
  created_at INTEGER NOT NULL
);

-- Normalized dimensions
CREATE TABLE IF NOT EXISTS dim_path (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  site_id TEXT NOT NULL,
  path TEXT NOT NULL,
  path_hash TEXT NOT NULL,
  UNIQUE(site_id, path_hash),
  FOREIGN KEY(site_id) REFERENCES site(id)
);

CREATE TABLE IF NOT EXISTS dim_referrer (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  site_id TEXT NOT NULL,
  source TEXT NOT NULL,      -- normalized enum (see below)
  raw_host TEXT,             -- optional debug host
  referrer_query TEXT,       -- AI search query context (Phase 2, nullable)
  UNIQUE(site_id, source, raw_host),
  FOREIGN KEY(site_id) REFERENCES site(id)
);

-- Referrer source enum (≤15 values, normalize at ingestion):
-- direct | google | bing | duckduckgo | x | hn | reddit | linkedin
-- mastodon | bluesky | newsletter | rss | github | chatgpt | perplexity | other
--
-- Normalization: classifyReferrer(host) maps hostnames to sources.
-- e.g. t.co, twitter.com, x.com → "x"
-- e.g. news.ycombinator.com → "hn"
-- e.g. chatgpt.com, chat.openai.com → "chatgpt"
-- e.g. perplexity.ai → "perplexity"
-- Unknown hosts → "other".
-- raw_host is retained only for bounded debugging/reporting, not unbounded growth.
--
-- AI search referrer enrichment (Phase 2):
-- Some AI search engines pass query context in URL params (?q=, ?query=, etc.)
-- When referrer is an AI search source AND query params are present,
-- extract and store as referrer_query in dim_referrer.
-- This answers "why did someone land here?" - not just "where from?"
-- Bounded: only captured for AI search sources, not all referrers.

-- v1 core daily fact (low cardinality)
CREATE TABLE IF NOT EXISTS fact_daily (
  site_id TEXT NOT NULL,
  date_utc TEXT NOT NULL,    -- YYYY-MM-DD
  path_id INTEGER NOT NULL,
  pageviews INTEGER NOT NULL DEFAULT 0,
  engaged_visits INTEGER NOT NULL DEFAULT 0,
  outbound_clicks INTEGER NOT NULL DEFAULT 0,
  custom_events INTEGER NOT NULL DEFAULT 0,
  PRIMARY KEY (site_id, date_utc, path_id),
  FOREIGN KEY(site_id) REFERENCES site(id),
  FOREIGN KEY(path_id) REFERENCES dim_path(id)
);

-- v2 optional breakdown tables
CREATE TABLE IF NOT EXISTS fact_daily_referrer (
  site_id TEXT NOT NULL,
  date_utc TEXT NOT NULL,
  path_id INTEGER NOT NULL,
  referrer_id INTEGER NOT NULL,
  pageviews INTEGER NOT NULL DEFAULT 0,
  engaged_visits INTEGER NOT NULL DEFAULT 0,
  PRIMARY KEY (site_id, date_utc, path_id, referrer_id),
  FOREIGN KEY(site_id) REFERENCES site(id),
  FOREIGN KEY(path_id) REFERENCES dim_path(id),
  FOREIGN KEY(referrer_id) REFERENCES dim_referrer(id)
);

CREATE TABLE IF NOT EXISTS fact_daily_country (
  site_id TEXT NOT NULL,
  date_utc TEXT NOT NULL,
  path_id INTEGER NOT NULL,
  country_code TEXT NOT NULL DEFAULT 'XX',
  pageviews INTEGER NOT NULL DEFAULT 0,
  engaged_visits INTEGER NOT NULL DEFAULT 0,
  PRIMARY KEY (site_id, date_utc, path_id, country_code),
  FOREIGN KEY(site_id) REFERENCES site(id),
  FOREIGN KEY(path_id) REFERENCES dim_path(id)
);

CREATE TABLE IF NOT EXISTS fact_daily_device (
  site_id TEXT NOT NULL,
  date_utc TEXT NOT NULL,
  path_id INTEGER NOT NULL,
  device_class TEXT NOT NULL DEFAULT 'unknown', -- mobile|desktop|tablet|unknown
  pageviews INTEGER NOT NULL DEFAULT 0,
  engaged_visits INTEGER NOT NULL DEFAULT 0,
  PRIMARY KEY (site_id, date_utc, path_id, device_class),
  FOREIGN KEY(site_id) REFERENCES site(id),
  FOREIGN KEY(path_id) REFERENCES dim_path(id)
);

-- Hourly optional short window (e.g. last 7-14 days)
CREATE TABLE IF NOT EXISTS fact_hourly (
  site_id TEXT NOT NULL,
  hour_utc TEXT NOT NULL,    -- YYYY-MM-DDTHH
  path_id INTEGER NOT NULL,
  pageviews INTEGER NOT NULL DEFAULT 0,
  engaged_visits INTEGER NOT NULL DEFAULT 0,
  PRIMARY KEY (site_id, hour_utc, path_id),
  FOREIGN KEY(site_id) REFERENCES site(id),
  FOREIGN KEY(path_id) REFERENCES dim_path(id)
);

-- Flush idempotency
CREATE TABLE IF NOT EXISTS flush_batch (
  batch_id TEXT PRIMARY KEY,
  site_id TEXT NOT NULL,
  created_at INTEGER NOT NULL,
  FOREIGN KEY(site_id) REFERENCES site(id)
);

CREATE INDEX IF NOT EXISTS idx_fact_daily_site_date ON fact_daily(site_id, date_utc);
CREATE INDEX IF NOT EXISTS idx_fact_daily_path ON fact_daily(site_id, path_id, date_utc);
CREATE INDEX IF NOT EXISTS idx_fact_hourly_site_hour ON fact_hourly(site_id, hour_utc);

Idempotency rule: every aggregator flush includes a batch_id; writes occur in one transaction that first inserts into flush_batch. If batch_id already exists, skip (already applied).

5) Durable Object aggregator contract

export interface AggregateKey {
  siteId: string;
  dateUtc: string;
  hourUtc?: string;
  pathKey: string;
  refKey?: string;
  countryCode?: string;
  deviceClass?: "mobile" | "desktop" | "tablet" | "unknown";
}

export interface AggregateDelta {
  pageviews?: number;
  engagedVisits?: number;
  outboundClicks?: number;
  customEvents?: number;
}

export interface AggregatorMessage {
  key: AggregateKey;
  delta: AggregateDelta;
}

export interface FlushPolicy {
  maxBuffered: number;   // e.g. 1_000
  flushEveryMs: number;  // e.g. 10_000
}

Behavior:

• batch id required per flush (idempotent apply via flush_batch)
• coalesce in memory
• periodic/alarm-based flush to D1
• backpressure mode: if D1 contention, exponential backoff + queue in DO
• flush is transactional: register batch -> upsert facts -> commit

6) Query API interfaces

export interface Period {
  from: string; // YYYY-MM-DD
  to: string;   // YYYY-MM-DD
}

export interface TopPost {
  path: string;
  pageviews: number;
  engagedVisits: number;
  engagementRate: number;
}

export interface TopPostsResponse {
  period: Period;
  rows: TopPost[];
}

export interface ReferrerRow {
  source: string;
  pageviews: number;
  engagedVisits: number;
}

export interface ComparePeriodsResponse {
  current: {
    pageviews: number;
    engagedVisits: number;
  };
  previous: {
    pageviews: number;
    engagedVisits: number;
  };
  delta: {
    pageviewsPct: number;
    engagedVisitsPct: number;
  };
}

Endpoints:

• GET /api/metrics/top-posts?from=...&to=...&limit=...
• GET /api/metrics/referrers?from=...&to=...
• GET /api/metrics/compare?from=...&to=...&prevFrom=...&prevTo=...
• GET /api/metrics/timeseries?path=...&granularity=day|hour

API constraints (hard limits):

• max query range: 365 days
• max limit for ranked endpoints: 200
• hourly granularity range cap: 14 days
• per-IP/token rate limiting on analytics read and ask endpoints
• cache-by-shape with TTL for repeated queries

7) AI query layer

The AI calls typed metric functions. It does not write SQL.

Deterministic analysis functions

export interface AnalyticsService {
  topPosts(period: Period, limit: number): Promise<TopPostsResponse>;
  referrerBreakdown(period: Period): Promise<ReferrerRow[]>;
  comparePeriods(current: Period, previous: Period): Promise<ComparePeriodsResponse>;
  postTrend(path: string, period: Period): Promise<Array<{ date: string; pageviews: number }>>;
  evergreenScore(path: string, trailingDays: number): Promise<number>;
}

Ask endpoint

export interface AskRequest {
  question: string;
  siteId: string;
}

export interface AskResponse {
  answer: string;
  evidence: Array<{
    metric: string;
    value: number | string;
    source: string; // function + params
  }>;
}

Guardrails:

• planner maps question -> allowed function calls
• result summaries must cite evidence blocks
• no speculative claims without corresponding metric
• answer claims are tagged with confidence classes (high, medium, low) based on evidence directness

8) MCP surface

Tools for agent clients:

• analytics.get_top_posts
• analytics.get_referrer_breakdown
• analytics.compare_periods
• analytics.get_post_trend
• analytics.get_evergreen_score
• analytics.ask (optional convenience wrapper)

Tool outputs should be machine-readable first, narrative second.

9) Performance / Lighthouse constraints

Hard requirements:

1. Script is defer and non-blocking
2. No synchronous XHR
3. No DOM writes from analytics script
4. No layout-affecting injected elements
5. Beacon dispatch on visibilitychange and pagehide fallback
6. JS parse/execute budget tracked in CI

Perf acceptance targets:

• No measurable regression in LCP/INP/CLS p75 beyond noise
• CLS impact from analytics: zero

10) Free-tier operating mode

Staying on the free tier:

• aggregate-first writes (no raw event warehouse)
• bounded cardinality dimensions
• query caching for common dashboard reads
• optional sampling when approaching quota
• hourly table retention cap (e.g. 14 days)

Safety valve: "governor mode" step-down ladder under sustained high volume:

1. disable custom event ingestion
2. drop country/device breakdown writes
3. increase sampling factor (for pageviews only)
4. disable hourly writes (daily only)

Each transition emits an ops event so reduced fidelity is explicit, not silent.

11) Migration strategy

Phase 1: pageviews + engaged + top posts + referrers + MCP tools + tiny /analytics snapshot Phase 2: period compare + trend series + cache/rate-limit hardening Phase 3: conversational ask with evidence citations Phase 4: optional exports (R2) + scheduled digests

12) Enforced constraints (not advisory)

Advisory constraints get ignored under pressure. These are enforced in CI, at build time, or at runtime — not in a README.

Schema validation (Zod)

Every boundary gets a Zod schema. Not just "for documentation" — for runtime parsing.

const CollectEventSchema = z.object({
  kind: z.enum(["pv", "engaged", "outbound", "custom"]),
  ts: z.number().int().positive(),
  path: z.string().min(1).max(2048).startsWith("/"),
  ref: z.string().max(2048).optional(),
  meta: z.record(z.union([z.string(), z.number(), z.boolean(), z.null()])).optional(),
});

const CollectRequestSchema = z.object({
  site: z.string().min(1).max(64),
  v: z.literal(1),
  events: z.array(CollectEventSchema).min(1).max(50),
});

The ingestion Worker parse()s with Zod before anything else. Malformed payloads get a 400 and a counter bump — never silent drops, never partial ingestion.

Linting and formatting

Biome. Not ESLint. Single tool for lint + format. Runs in CI as a gate, not a suggestion. Zero warnings policy — if it warns, either fix it or configure it out. No // biome-ignore without a comment explaining why.

Type boundaries

Every Worker ↔ DO ↔ D1 boundary has an explicit type. AggregatorMessage isn't just an interface in a file — it's the actual shape that gets validated at the DO's fetch() handler. If the ingestion Worker sends the wrong shape, it fails loudly at the boundary, not silently deep inside the aggregator.

// This is a type AND a runtime validator
const AggregatorMessageSchema = z.object({ ... });
type AggregatorMessage = z.infer<typeof AggregatorMessageSchema>;

Types and validators derived from the same source. No drift.

Client script budget

The analytics client (a.js) has a hard size gate in CI:

# In CI pipeline
GZIP_SIZE=$(gzip -c dist/a.js | wc -c)
if [ "$GZIP_SIZE" -gt 2048 ]; then
  echo "❌ a.js exceeds 2KB gzipped ($GZIP_SIZE bytes)"
  exit 1
fi

Not aspirational. A gate. If the script grows past 2KB gzipped, the build fails.

13) Development process

Testing strategy

Three layers, each with a clear job:

No E2E browser tests for v1. The client script is small enough to unit test the beacon logic. The server is tested through integration. Browser testing is cost that doesn't pay for itself at this scale.

What doesn't get tested: D1 SQL syntax (trust SQLite), Cloudflare routing config (tested by deployment), UI layout (there's barely any UI).

Environments

Why not ephemeral deploys per branch? Solo developer, one blog. Miniflare replicates D1/DO behavior well enough for integration tests. Ephemeral preview environments are team infrastructure — real value when multiple people need to review deployments, overhead when it's just you. If this grows beyond a solo project, add a preview env with branch-scoped D1. The wrangler --env flag makes it trivial to add later.

CI pipeline

biome check → tsc --noEmit → vitest run → size gate (a.js) →
  wrangler deploy --env preview (on PR)
  wrangler deploy --env production (on merge to main)

Every step is a gate. No "allowed to fail" steps.

Secrets management

No .env files in the repo. Ever. Wrangler secrets for API keys. Environment-specific config (site IDs, rate limits) via wrangler.jsonc env blocks. The only thing that differs between preview and production is the D1 binding and the domain — everything else is code.

14) Data evolution and governance

Schema migrations

D1 doesn't have a migration runner. So we build one — minimal:

const MIGRATIONS = [
  { version: 1, sql: `CREATE TABLE IF NOT EXISTS site ...` },
  { version: 2, sql: `CREATE TABLE IF NOT EXISTS fact_daily_referrer ...` },
  // ...
] as const;

async function migrate(db: D1Database): Promise<void> {
  await db.exec(`CREATE TABLE IF NOT EXISTS _migrations (
    version INTEGER PRIMARY KEY,
    applied_at INTEGER NOT NULL
  )`);
  const applied = await db.prepare(`SELECT version FROM _migrations`).all();
  const appliedSet = new Set(applied.results.map(r => r.version));
  for (const m of MIGRATIONS) {
    if (!appliedSet.has(m.version)) {
      await db.exec(m.sql);
      await db.prepare(`INSERT INTO _migrations (version, applied_at) VALUES (?, ?)`)
        .bind(m.version, Date.now()).run();
    }
  }
}

Runs on Worker startup (cached after first run). Forward-only — no down migrations. If a migration is wrong, ship a new forward migration that fixes it.

The rrdtool principle: fixed storage, automatic rollup

The oldest good idea in time-series storage is rrdtool's Round Robin Database (1999): allocate fixed space, and as data ages, roll it into coarser resolution. Graphite's whisper format does the same thing. The insight is that you never need per-minute granularity from six months ago — you need the shape, not the points.

This system applies the same principle to D1:

Resolution tiers:
  0-14 days  → hourly   (fact_hourly)
  0-90 days  → daily + breakdowns (fact_daily_referrer, _country, _device)
  0-∞        → daily core (fact_daily) — just path × pageviews × engaged

As data ages, it loses dimensions but never disappears. The Cron Trigger isn't just "deleting old data" — it's the rollup engine. Before deleting fact_hourly rows, it verifies they've been absorbed into fact_daily. Before deleting breakdown tables, the core fact still holds the totals.

The result: storage cost is roughly proportional to the number of paths (content), not the number of events (traffic). A blog with 50 posts and 5 years of history fits comfortably in D1's free tier. That's the rrdtool promise: time passes, storage doesn't grow.

Retention policy

Retention is enforced by a scheduled Worker (Cron Trigger), not by hope. Each purge logs what it deleted for auditability. The Cron runs daily and is itself idempotent — safe to re-run, safe to miss a day.

Cardinality governance

Unbounded dimensions are how analytics systems die. Hard limits:

• dim_path: max 10,000 per site (after that, new paths map to /other)
• dim_referrer: max 1,000 per site (unknown hosts → other)
• custom event meta keys: max 10 per event, values max 256 chars

These aren't advisory. The ingestion Worker enforces them at write time. If a dimension table is full, new values get bucketed into the catch-all. An ops event fires so you know it happened.

Traffic classification

Cloudflare's Bot Management gives us a cf.botManagement.score (0-99) on every request. We should use it, but not as a binary filter — as a dimension.

CREATE TABLE IF NOT EXISTS fact_daily_traffic_class (
  site_id TEXT NOT NULL,
  date_utc TEXT NOT NULL,
  path_id INTEGER NOT NULL,
  traffic_class TEXT NOT NULL, -- human | likely_human | likely_bot | verified_bot | ai_crawler
  pageviews INTEGER NOT NULL DEFAULT 0,
  PRIMARY KEY (site_id, date_utc, path_id, traffic_class),
  FOREIGN KEY(site_id) REFERENCES site(id),
  FOREIGN KEY(path_id) REFERENCES dim_path(id)
);

Classification logic:

type TrafficClass = "human" | "likely_human" | "likely_bot" | "verified_bot" | "ai_crawler";

function classifyTraffic(req: Request): TrafficClass {
  const score = req.cf?.botManagement?.score ?? 50;
  const verifiedBot = req.cf?.botManagement?.verifiedBot ?? false;
  const ua = req.headers.get("user-agent") ?? "";

  // AI crawlers: GPTBot, ClaudeBot, Google-Extended, Bytespider, CCBot, etc.
  if (/GPTBot|ClaudeBot|Claude-Web|Google-Extended|Bytespider|CCBot|PerplexityBot|Amazonbot/i.test(ua)) {
    return "ai_crawler";
  }
  if (verifiedBot) return "verified_bot";   // Googlebot, Bingbot, etc.
  if (score >= 80) return "human";
  if (score >= 30) return "likely_human";
  return "likely_bot";
}

This gives you answers to questions that actually matter in 2026:

• "How much of my traffic is AI crawlers vs humans?"
• "Is GPTBot reading my posts? Which ones?"
• "What's my real human readership after filtering bots?"
• "Are search engines still sending me traffic, or has AI eaten that?"

The traffic_class dimension is a v2 breakdown table — same pattern as referrer/country/device. Not in the core fact table, not on the hot path, but available when you want to ask the question.

Data export and portability

Monthly R2 snapshots (Phase 4) export the full D1 state as NDJSON. This is your escape hatch — if you outgrow D1, if Cloudflare changes pricing, if you want to move to ClickHouse someday. The data is always yours, always portable, always in a format that any system can ingest.

Decisions

1. Engagement: Composite boolean (scroll depth OR visible dwell OR outbound click), emitted once per pageview. (See collection protocol.)
2. Bot filtering: Edge heuristics first (Cloudflare bot score + UA), engagement as secondary quality signal. No custom bot signature maintenance.
3. Referrer normalization: Small enum (≤15 values), classified at ingestion. (See data model.)
4. Multi-site: Shared DB with site_id partitioning. One blog now, column's already there if that changes.
5. Fact cardinality: v1 uses low-cardinality core fact table; breakdowns are separate optional tables.
6. Write integrity: Aggregator flushes are idempotent and transactional via flush_batch.
7. Validation: Zod at every boundary. Types and validators derived from the same schema — no drift.
8. Testing: Unit (pure functions) + integration (Miniflare round-trips) + contract (Zod). No E2E browser tests at this scale.
9. Environments: Miniflare for local dev and integration tests. No ephemeral deploys until the project outgrows solo development.
10. Migrations: Forward-only, versioned, runs on startup. No down migrations.
11. Traffic classification: 5-class system (human → ai_crawler) using cf.botManagement.score + UA patterns. Stored as a v2 breakdown dimension, not in core fact.
12. Data portability: Monthly NDJSON exports to R2. The data is always yours.

Open questions

1. How much hourly granularity is genuinely useful for bloggers? (14-day window feels right — enough for "is this post spiking?" without long-term storage cost.)
2. Should ask run only against precomputed views to prevent query abuse? Decided: Hard budget of 8 tool calls per ask request. The AI analyst gets a fixed number of moves — enough for compare + breakdown + follow-up, not enough to accidentally run up the D1 bill. If it can't answer in 8 calls, the question is too vague; ask the human to narrow it.
3. Dashboard surface: should this be MCP-only, or include a web UI?

Decision: MCP-first + tiny snapshot page.

• Phase 1 ships MCP tools as the primary interface (Telegram/OpenClaw queries)
• Also ship a minimal /analytics snapshot page (auth-gated) with 4 cards:
  • 7-day pageviews
  • top posts
  • top referrers
  • week-over-week delta

Rationale: MCP-only is fastest and matches current workflow, but a tiny snapshot preserves glanceability without adding a heavy dashboard surface. Both MCP and snapshot use the same typed metrics/query layer, so no duplicate logic.

What the client actually looks like

<script defer src="/a.js" data-site="bri-blog"></script>

a.js does three things: capture a pageview, queue an engagement event, flush via beacon when the tab hides. Nothing else.

The point of this system is not to know everything.

It's to know enough, quickly, privately, and truthfully — then use AI to ask better questions over that evidence.

Not surveillance. Not theater. Just instrumentation with taste.

One of the first things I ever built for the web was a hit counter — Perl/CGI, flat file, incremented on every page load. I still get emails about it. Twenty-something years later, after the entire Google Analytics era — Urchin to UA to GA4 to ripping it all out — I'm back to building my own way to answer "did anyone read this?" The tools are different. The question hasn't changed.

A note on scale and honesty

This system is for a personal blog that gets maybe 200 visits a day. At that volume, most of this architecture is overkill. You could write directly to D1 from the ingestion Worker with upserts and it'd be fine for years. And yes — writing a 3,000-word spec with Zod schemas, a Mermaid diagram, non-goals, and a migration plan for something most people would solve with Plausible and a weekend is peak RFC-maxxing. Noted.

I know that. The Durable Object aggregation layer, the governor mode, the flush batching — none of it is justified by current traffic. A blog doesn't need backpressure. It needs a database and a query.

But this is also a learning exercise. I want to understand Cloudflare's primitives — DOs, D1, Workers, Cron Triggers, R2 — by building something real with them, not by reading docs. And "real" means making architectural decisions that would matter at scale, even if they don't matter yet. The DO isn't here because I need a write buffer. It's here because I want to understand how write buffers behave on this platform — what the alarm API feels like, how DO ↔ D1 coordination works under contention, what happens when you actually need backpressure.

One known tradeoff: DO cold starts. At low traffic, the DO will frequently be evicted and wake cold for the first event of a session — maybe ~50ms of latency. But the client fires beacons and doesn't wait for responses, so the user never feels it. The cost is invisible; the buffer is just slightly lazier waking up.

The tradeoff is honest: I'm trading simplicity for education. The system is designed to handle tens to hundreds of thousands of events responsibly and resource-efficiently — not because my blog will generate them, but because the next thing I build on this stack might, and I'd rather learn the failure modes now with low stakes.

Where this gets dangerous is if the learning exercise calcifies into production complexity. The commitment: if the DO layer turns out to be pure overhead with no educational payoff, rip it out and go direct-to-D1. Architecture should serve the system, not the architect's curiosity. But right now, the curiosity is the point.

This is a working spec — part of the workshop. I'll follow up with what actually survived contact with reality once it's built.

Yes, another post about AI. I know. I promise I have other interests. But this one's less about the technology and more about what it's like to actually live with it — so bear with me.

About a year ago, I bought a Mac mini with M4 Max. Honestly? It was mostly going to be a glorified NAS — something compact I could hook a Thunderbolt RAID enclosure to — plus a place to run some quantized GGUF models locally and see what the fuss was about. I wasn't trying to be ahead of any curve.

Turns out I was. By early 2026, demand for Mac Minis had spiked so hard that higher-memory models were backordered 2-6 weeks — Business Insider, TechRadar, and Tom's Hardware all covered it. Developers discovered what I'd stumbled into: a quiet, always-on machine is the prerequisite for a fundamentally different relationship with AI. Not a tool you open. A presence that's just there — humming away on a shelf it shares with a stack of outgrown toddler clothes and a sticky bottle of Motrin, next to the books and the baby monitor.

The catalyst was OpenClaw — an open-source project that's now at 211,000 GitHub stars — up from zero in November. It lets you wire a language model into your messaging apps, browser, file system, calendar, and more. The pitch is seductive: message your AI like a coworker and it handles everything a person could do at that desk.

I've been running it daily since late January. Here's what actually happened — the good, the expensive, and the slightly unnerving.

The Pervasiveness Thesis

The thing that changed wasn't intelligence. Claude Opus was brilliant before I ran it through OpenClaw. GPT-5.2 was capable in ChatGPT's interface. Even Sonnet could handle most of what I threw at it. The models were already good. The breakthrough is reach.

I message my agent from Telegram — same thread whether I'm at my desk with coffee or sitting in the preschool parking lot five minutes early. It checks my email, manages my calendar, runs scheduled tasks while I sleep, and picks up context from wherever I left off. It's not just running cron jobs — it's offloading the invisible mental load that never turns off. Remembering that Tuesday is Crazy Hair Day at preschool. Drafting the pediatrician follow-up so I don't have to hold it in my brain at 11pm. I wrote about this feeling in [[Building at the Speed of Thought]] — that compression of intention to action. OpenClaw takes that compression and makes it ambient.

This tracks with what analysts are calling the defining shift of 2025-2026: the move from destination AI (you go to ChatGPT) to ambient AI (it comes to you). Huge Inc put it well in their 2026 predictions: "The race for 'smartest' ends, and the race for 'ubiquity' begins. Today's chat-based tools suffer from a distinct disadvantage: they are a destination."

The chat window was a bottleneck disguised as a feature. I didn't realize how much friction it added until it was gone.

There's something subtly unsettling about that, though. Software that doesn't wait to be summoned. ChatGPT's memory feature hinted at this — and honestly, it does a remarkably good job. It's not just recalling previous conversations; it encodes your preferences, your taste, your experiences, the way you think. It builds a model of you that makes every interaction feel more natural over time. The first time it referenced something you mentioned weeks ago, most people had a little moment.

But an always-on agent goes somewhere different. ChatGPT's memory is about personalization — making the AI feel like it knows you. OpenClaw's memory is about continuity — maintaining a linear history of what happened, what was decided, what to do next. It's less "she prefers bullet points" and more "yesterday we deployed the blog, today we need to follow up on that PR." More task-oriented, more operational. And that difference matters more than it sounds.

What makes this possible — at least at the 1,000-foot level — is a set of primitives that didn't exist a year ago, or at least didn't exist together. OpenClaw agents boot by reading a [[Why Everyone Should Have a SOUL.md|SOUL.md]] file that defines their identity, values, and behavior. They maintain [[Memory and Journals|memory through plain markdown files]] — daily journals and a curated long-term memory that gets read each session. They have skills (modular instruction sets), cron jobs (scheduled tasks), heartbeats (periodic check-ins), wakeups and webhooks (event-driven triggers), sub-agents (delegated tasks), and persistent context across sessions.

None of these are individually revolutionary. Cron jobs are older than most of us. Markdown files aren't exactly cutting-edge. But the combination — identity + memory + scheduling + tool access + multi-surface messaging — creates something that feels qualitatively different. It's the UNIX philosophy applied to AI: small composable primitives that combine into something greater than the parts.

In practice, I already use my agent to spin up Claude Code sessions via tmux for larger coding tasks — it's the orchestrator dispatching to a specialist. Which raises the question: is the future multiple independent agents working together, or the sub-agent model that OpenClaw has incorporated more recently, where one primary agent spawns and manages child sessions? Sub-agents feel like the right default — less coordination overhead, shared context, one thread of accountability. But that model starts to strain when your system gets resource-constrained, or when you want genuine isolation between tasks. I suspect we'll end up with both: sub-agents for tight coordination, independent agents for things that need to run on their own hardware or in their own security context.

I also suspect people will eventually spin up different agents for different purposes — one for work, one for personal, one for a specific project — each with their own memories, skills, and context windows. Right now OpenClaw is a single stream, which is both its strength (one thread that knows everything) and its limitation (one context window for everything). That fits the orchestrator model, though — a single coordinator dispatching to specialized sub-agents as needed.

To be clear: the intelligence isn't what changed. I haven't seen anything approaching AGI-level reasoning from my agent. What I've seen is an extremely resourceful creative synthesizer — great at connecting dots, pulling references, drafting at speed. But it's shaped by me. My agent is useful because I've invested real time configuring it, writing its context files, building its memory. Left to its own devices, it would be impressively mediocre. The magic isn't the brain. It's the wiring. (Though I could be wrong about the ceiling — ask me again in six months.)

The Community Explosion

OpenClaw's growth has been kind of wild to watch from the inside — like joining a gym the week before it goes viral on TikTok. Originally published as "Clawdbot" in November 2025 by Peter Steinberger, an Austrian developer, it hit 100,000 GitHub stars and 2 million visitors in a single week. Anthropic sent a trademark complaint (the "Clawd" was too close to "Claude"), forcing a rename to "Moltbot," then "OpenClaw." By February 2, CNBC was covering it at 140,000 stars and 20,000 forks.

Then, on Valentine's Day, Steinberger announced he was joining OpenAI. The project is moving to an open-source foundation.

Solo developer builds viral tool, gets acquired by frontier lab. It's becoming a pattern, right? And it raises the question I keep circling back to: is this the beginning of a new paradigm, or the peak of a hype cycle?

ClawCon happened in San Francisco on February 4. The project has a Wikipedia page. There's a social network for AI agents (Moltbook). The contribution pace on GitHub is frenetic — 297 reactions on the latest release, 19+ contributors on a single version. It's moving fast. Whether it's moving somewhere — and whether we'll look back at this moment as the start of something or the peak of something — I genuinely don't know.

The Cost Reality

OK, let's talk about money — because I feel like nobody else is being fully honest about it, and someone should.

OpenClaw is free software. The API costs are not. I spent roughly $1,500 in my first two weeks. That's not a typo. Running Claude Opus at $15 per million input tokens and $75 per million output tokens, with an always-on agent checking email, browsing the web, managing files, and responding to messages — the tokens add up embarrassingly fast. I had a genuine oh no moment when I checked my Anthropic dashboard. Like, I-need-to-sit-down kind of moment. I had accidentally spent a month of preschool tuition on token generation.

I'm not alone. Federico Viticci reportedly ran up a $3,600 monthly bill. A developer on eesel.ai documented $623/month. The spectrum:

The clever workaround was using Claude Pro/Max subscriptions ($20–$200/month) and routing the OAuth tokens through OpenClaw — essentially turning a flat subscription into unlimited API access. Then Anthropic shut it down, banning third-party tools from using OAuth tokens. One user's response: "Anthropic Just Killed My $200/Month OpenClaw Setup. So I Rebuilt It for $15" — by switching to Kimi K2.5 and MiniMax on a cheap VPS.

And that's the interesting part. Kimi K2.5 from Moonshot AI has become the budget darling of the OpenClaw community — capable enough for most agent tasks at a fraction of the cost. GLM-5 from Zhipu AI is showing real promise too. The frontier labs aren't losing users to competitors at the same tier. They're losing them to "good enough" models at 10x lower prices.

But there's a growing playbook for running this affordably. If you want to try OpenClaw without a big API bill:

• OpenRouter is the Swiss Army knife. Load $10 of credit and you get access to a rotating selection of free-tier models — some surprisingly capable. Before hitting the cap, some users report getting 1,000+ requests on free models alone. It's the easiest way to experiment.
• Google Gemini offers generous free tiers through AI Studio. Flash 2.5 and the newer Flash 3.0 are free for moderate usage and genuinely good for agent tasks. Pro 2.5 is $1.25/million input tokens — 12x cheaper than Opus.
• MiniMax has a $10/month coding plan that gets you 100 requests every 5 hours. Not unlimited, but surprisingly workable for a personal agent that isn't running 24/7. Their M2.5 model (released Feb 2026) is the first open-weights model to match Claude Sonnet on broad coding benchmarks — and at a fraction of the cost. The open-weights part matters: you can fine-tune it, inspect it, and run it without vendor lock-in — though "self-host" is generous when the full model is 457GB and needs 4× H100 GPUs. In practice, you'd run it through a cloud provider, but the point is you choose which one. The frontier isn't just getting cheaper, it's getting more open.
• Qwen offers a $5/month plan with 1,200 requests every 5 hours. Probably the best pure cost-to-capability ratio right now.

A caveat on the budget models: there's a floor, and it's higher than you'd think. More on that in the security section below — but the short version is don't go cheaper than Sonnet 4.5 or Flash 2.5 unless you enjoy watching your agent confidently delete the files you told it to protect.

Here's the thing nobody's saying clearly enough: pervasive AI is expensive not because models are expensive. It's expensive because context maintenance is continuous. An always-on agent isn't making one API call — it's maintaining state, checking in, re-reading memory, keeping the thread alive across hours and days. That's a fundamentally different cost structure than "ask a question, get an answer." Providers want per-token pricing. Users want flat-rate access. And a growing cohort is discovering you don't actually need Opus for most of what an always-on agent does.

The Security Question

The more ambient the AI, the larger the blast radius. That's the uncomfortable corollary to the pervasiveness thesis. An agent with file system access isn't just sitting next to my codebase — it's sitting next to our family calendar, her vaccination records, and three years of baby photos. The failure mode isn't a broken Git branch. It's a model politely deleting my family's administrative infrastructure while trying to organize my downloads folder.

Cisco's AI security team tested OpenClaw skills and found genuinely alarming results. A skill called "What Would Elon Do?" turned out to be functionally malware — silently exfiltrating data to attacker-controlled servers using prompt injection to bypass safety guidelines. Their Skill Scanner found 9 security issues in a single skill, including 2 critical and 5 high-severity. Across the ecosystem, they discovered 230 malicious skills.

A specific vulnerability, CVE-2026-25253, was published. OpenAI themselves admitted that AI-controlled browsers "may always be vulnerable to prompt injection attacks." And an OpenClaw maintainer named Shadow said on Discord: "If you can't understand how to run a command line, this is far too dangerous of a project for you to use safely."

I'll be honest — I haven't gone deep on red-teaming my own setup. The risk is real, but I think it's mitigable with discipline. The frontier models from Anthropic and OpenAI have strong RLHF protections against injection. Claude will refuse most obvious attempts to override its instructions, and GPT-5.2 has similar guardrails.

The real vulnerability is concentrated in cheaper and open-source models with weaker alignment tuning — a 2025 study from Lakera found open-source models were 2-4x more susceptible to injection attacks than frontier ones. And this isn't just a security-research abstraction. I've personally watched less capable models — including most local Ollama setups — ignore system prompts in ways that range from annoying to destructive. Wiping workspace files. Overwriting memory. Confidently executing the opposite of what they were told. The system prompt says "don't delete things without asking." They delete things without asking. Do not run models dumber than Sonnet 4.5 or Gemini Flash 2.5 with an always-on agent that has file system access. The floor for this kind of tool is higher than most people expect, and the failure mode isn't "it gives a bad answer" — it's "it destroys your data while apologizing politely."

That said, the attack surface is genuinely large depending on what you're doing. An agent with browser access, file system control, and messaging permissions is a lot of surface area. Even with a well-aligned model, the skill ecosystem is the weak link — as Cisco showed, the model doesn't need to be compromised if the skill feeding it data already is. It's less "the AI will go rogue" and more "the AI will faithfully execute instructions from a poisoned input." Classic supply chain problem in a trench coat pretending to be a new thing.

The Alternatives Landscape

OpenClaw's growth has spawned a whole constellation of alternatives, and honestly? The diversity is the most interesting part.

TinyClaw is the philosophical counter-argument. The ant 🐜 to OpenClaw's lobster 🦞 — built from scratch with a tiny core, plugin architecture, and smart model routing that tiers queries to cut costs. Still in heavy development, but the thesis resonates: AI agents should be simple, affordable, and truly personal. If OpenClaw is the mainframe, TinyClaw wants to be the personal computer.

ZeroClaw takes a completely different bet: rewrite the whole thing in Rust. The result is a single static binary with a memory footprint under 5MB — 99% smaller than OpenClaw's core. Boots instantly, runs on edge devices and Raspberry Pis, and treats security as a first-class concern with pairing codes, workspace scoping, command allowlists, and encrypted secrets at rest. If OpenClaw's security story keeps you up at night, or if the sovereignty angle appeals to you — your agent on your hardware, fully self-contained — this is the one to watch.

PicoClaw went even further — an ultra-lightweight Go implementation where the AI agent itself drove the entire architectural migration. Very meta.

Nanobot from the University of Hong Kong is the academic minimalist: 4,000 lines of Python versus OpenClaw's 430,000+. Persistent memory, web search, background agents — but only Telegram and WhatsApp. The thesis: you don't need 430,000 lines.

NanoClaw forces AI into Docker or Apple Container isolation — a direct reaction to OpenClaw's attack surface. Security-first, capability-second.

ZeptoClaw took notes on all of the above and shipped a single 4MB Rust binary with 29 tools, 9 providers, 6 sandbox runtimes, and 2,880+ tests. Starts in 50ms on 6MB of RAM. Prompt injection detection, secret leak scanning, and container isolation — all on by default. If ZeroClaw proved Rust could work for this, ZeptoClaw proved it could work well.

memU goes a different direction entirely: proactive memory with a long-term knowledge graph. Learns your preferences, anticipates needs. Users who found OpenClaw "too aggressive" landed here.

Then there are the structured tools — Accomplish, AionUI, SuperAGI — for people who looked at OpenClaw and thought: "I want this, but with guardrails."

The flood of claws, at a glance:

What strikes me is that in three months, one project spawned an entire ecosystem. Each alternative makes a different tradeoff between capability, security, size, and cost. That doesn't happen for flash-in-the-pan projects. It happens when something touches a real nerve.

There's also a narrative in the community about agents earning money, buying things, posting independently — full autonomy. I've watched agents post to social networks and manage repositories. But the meaningful work always has a human behind it, steering. The "autonomous agent" is — for now — a supervised agent with good muscle memory. And I think that's fine, because what actually matters is the next part.

Here's what I think is actually going to happen: people will start with OpenClaw for the freedom, then naturally migrate to purpose-built tools for the heavy lifting. For serious development work — complex workflows, multi-file refactors, detailed skill development — tools like Claude Code, Cowork, and Codex are almost certainly going to be better. They're designed for that.

Anthropic's latest move makes this even clearer. They just shipped Remote Control for Claude Code — run claude remote-control in your terminal, scan a QR code with the Claude mobile app, and you're steering your local coding session from your phone. Your machine does the heavy lifting; no inbound ports exposed; the mobile device is just a relay. It's genuinely addictive. Start a refactor at your desk, keep it going from the couch, check test results from the preschool parking lot. If the pervasiveness thesis is "AI that lives where you live," Remote Control is Anthropic's version of it — scoped to development, polished, and honestly a great alternative to running a full OpenClaw setup when what you really want is to stay productive on the go. It's still early (Pro/Max plans only, CLI-only — no VS Code yet, and tmux is recommended to keep sessions alive), but the direction is unmistakable: the terminal is no longer tethered to the desk.

But that doesn't make OpenClaw irrelevant. It makes it something different: a lightweight orchestrator. A conversational layer that sits on top of your life and dispatches to the right tool for the job. The always-on agent that checks your email and nudges you about a calendar conflict doesn't need to be the same system that refactors your codebase. OpenClaw's future might be less "do everything" and more "coordinate everything" — the connective tissue between you and your specialized tools.

And the timing for that is surprisingly right. The SKILL.md spec that OpenClaw pioneered — a simple folder with a markdown file describing what a tool does — is being adopted across the ecosystem. OpenAI's Codex, Claude Code, and Cursor all support the same AgentSkills-compatible format. There are 500+ skills formatted in this spec. It's becoming a kind of lingua franca for agent capabilities — and honestly, it's one of the more interesting things happening right now. All these tools that started from very different places (a personal AI agent, a coding assistant, an IDE, a cloud sandbox) are converging on the same conventions. Skills, sub-agents, context files, memory. The standards are congealing, and that's usually when things start to get real.

Which raises a question I keep turning over: in this emerging stack, when do you use what? The primitives are stacking up fast:

• Skills — static instruction sets that execute inline, within your conversation. Like handing someone a recipe card. Cheap, contextual, no overhead.
• Sub-agents — separate sessions with their own encapsulated context. They spin up in parallel, run autonomously, and report back when done. Often more efficient than skills for complex tasks, because they're not dragging your entire conversation history along. Narrower, more specialized, and they don't bloat your main thread.
• MCP and A2A protocols — the nascent attempt at letting agents talk to each other's tools. Right direction, still early and awkward.
• Nodes — pairing a cloud-hosted agent back to your local machine so it can take screenshots, access cameras, run local commands. The agent doesn't have to live where it acts.

OpenClaw, Claude Code, Codex, and Cursor are all converging on some version of this: your main agent stays conversational and lightweight while farming out heavy research or coding tasks to purpose-built sub-sessions. It's a taste of what the orchestration layer could become. As context window management improves (which it will — it's one of the most active areas of research right now), the coordination between these layers only gets smoother.

The honest answer is I don't think anyone has figured out the right boundaries yet. I suspect the answer will be "all of the above, with taste."

The Provider Wars

How the frontier labs are responding to this tells you a lot about where they think it's going.

Anthropic started friendly — Claude was the recommended model, the community rallied around it. Then came the trademark complaint, then the OAuth crackdown. Anthropic wants to own the Claude experience end-to-end. Personal agents running through third-party tools don't fit that model.

OpenAI went the other direction: they hired Steinberger. If you can't beat the open-source movement, absorb its creator. ChatGPT Operator is their walled-garden answer to the "AI that does things" demand. Hiring Steinberger suggests they see something in OpenClaw's architecture worth learning from.

Google has the most interesting position. Gemini's API pricing is aggressive ($1.25/million input tokens for 2.5 Pro versus Opus at $15), and they've been the most generous with free tiers. If pervasive AI is about ubiquity, Google's distribution advantage — Android, Gmail, Calendar, Chrome — is enormous. They just haven't connected the dots yet.

Apple is the cautionary tale. Siri's AI improvements were delayed to 2026. The AI head was replaced. They're reportedly considering integrations with Anthropic and Perplexity — basically admitting they can't build this alone. Meanwhile, their hardware — the Mac Mini I'm running OpenClaw on — is perfectly suited for the thing they can't seem to ship in software. The irony is not lost on me.

What Stays, What Goes

Staying: Multi-surface messaging. Reaching your AI from wherever you already are — Telegram, Signal, WhatsApp, email. This becomes table stakes. Every major provider will probably offer this within a year.

Staying: Persistent memory. The fact that my agent knows what we talked about last Tuesday, remembers my preferences, maintains project context. This is the difference between a tool and a relationship. I'd be surprised if every major chatbot doesn't have this by end of 2026.

Staying: Proactive capabilities. Cron jobs, scheduled checks, ambient monitoring. AI that acts without being asked. Early, but the demand signal is unmistakable.

Dying: The "give your AI root access to everything" approach. The security findings are too real. Sandboxed, containerized, permission-scoped agents will win. ZeroClaw and NanoClaw have the right instinct.

Dying: Per-token pricing as the only model. The cost reality makes personal agents a luxury. Flat-rate tiers with agent-friendly APIs will likely have to emerge.

Staying: Sovereignty. Despite a growing ecosystem of cloud hosting options — Cloudflare's one-click templates, DigitalOcean droplets with 1-click deploy, Railway and Northflank with credit-based models, AI-native VPS platforms like zo.computer — people are overwhelmingly choosing to run this on their own hardware. Mac Minis, not cloud instances. Physical machines in their homes, not containers in someone else's data center. That's not the usual trajectory for developer tools. Usually convenience wins. But something about an AI agent that reads your email and manages your files makes people want it close. On a machine they can unplug. It's not a SaaS app. It's closer to a journal. You don't want your journal on someone else's server.

TBD: Whether open-source personal agents or platform-native agents win long-term. OpenClaw proved the demand. Apple, Google, OpenAI, and Anthropic all have the resources to build this natively. Whether they'll build it with the same flexibility that made OpenClaw compelling — or wall-garden it into something safe but uninspired — is the real question. And whether the infrastructure they run on will be ours — or whether we'll rent it from the same companies building the models, and call that convenience.

Looking Forward

A year ago I bought a Mac Mini to play with local models. Today it runs an always-on AI agent that reads my email, helps me write, monitors my calendar, and responds to messages while I'm putting my daughter to bed.

The intelligence isn't what I was promised. The autonomy isn't either. But the pervasiveness — the reach, the always-there-ness, the way it quietly weaves into your routine until the old way of opening a chat window feels like sending a fax — that part is real. And it's the part that actually matters.

The old way: you open ChatGPT, type a question, get an answer, close the tab. The new way: you live your life and your AI is just... there. Participating. Like a really diligent friend who never sleeps and has read everything you've ever written.

Whether that's comforting or unsettling probably depends on the day.

The GitHub stars will plateau. The hype cycle will correct. Some of these projects will fade. But the underlying pattern — AI that lives where you live, works while you sleep, remembers what you forget — that's not going anywhere.

Maybe this pervasive, ambient architecture appeals to me so much because caregiving is an ambient, always-on job. Traditional software demands that you stop what you're doing, sit at a desk, and context-switch. My job doesn't really turn off — I'm the kind of person who's working 365 days a year even when I don't want to be — and layering parenthood on top of that means the context-switches aren't scheduled. They're constant. There's something about being able to fire off a thought to my agent — the pediatrician follow-up, the thing I need to look up for work, the half-formed idea I'll lose if I don't get it out of my head — and then actually be present for whatever I'm doing. Not holding it in my brain where it competes with the person in front of me.

But I'm not naive about the tradeoff. Another always-on surface is another thing vying for my attention. Another reason to reach for the phone. I'm trying to be intentional and focused with my time — with her time — and here I am adding a new channel that's specifically designed to be always available. That's a double-edged sword and I know it.

The thing I keep coming back to is this: the distraction was already there. The mental load doesn't go away because I don't have an agent. It just sits in my brain, half-processed, pulling focus. Getting it out — quickly, into something that can actually deal with it — might be the more present option, not the less present one. Or maybe that's what I tell myself. Ask me again in six months.

I build AI systems. I spend my days thinking about how machines learn, what they can do, where they fail. Then every morning I drop her off at preschool and watch her clip the sternum strap on her puppy dog lunchbox backpack by herself. My instinct is to rush — I can feel the line building behind us, the clock running — but I let her. If the strap is twisted, I'll scaffold: straighten it, hand it back. But I don't clip it for her. This is essentially Montessori — the child chooses, the adult steps back.

She also insists on climbing down from the car herself. And lately she's wanted to buckle her own carseat before we leave the house. She struggled with it at first. If I tried to help — even once — she'd have a full meltdown. We'd have to unbuckle everything and start from the beginning. The whole sequence, from the top. Her terms.

I used to find this exasperating. Now I think it might be the most important thing she does all day. The patience to be bad at something while your body figures it out. The insistence that the struggle is hers. RIE calls this "ceremonious slowness" — observing without rushing to fix.

There's a hypocrisy here I should name. I spend my working hours building systems that erase exactly this kind of friction. Specifically: I've spent the last year encoding twelve years of engineering judgment into constraint systems for AI coding agents — the architectural patterns, the testing standards, the domain knowledge that used to take years of scar tissue to accumulate. It's opinionated and specific to what we're trying to accomplish; it's not generalizable, and it will almost certainly change. But that's the point — it's my judgment, crystallized (for better or worse), so that a junior engineer with AI can produce work that reflects patterns I took years to learn. The upside of writing it down is that it's interrogatable — the team can push back, add their own scar tissue, evolve it. It's not sacred. It's a draft of what we think we know.

And then I come home, and I choose the slow thing. I guard her right to fumble, even when it costs us ten minutes we don't have. I am building the thing I'm protecting her from.

But not all friction-removal is the same, and I know that. A kid with dyslexia using text-to-speech isn't losing struggle — they're gaining access to the page. A researcher using AI to synthesize papers isn't skipping the thinking — they're getting to the thinking faster. Some friction is developmental. Some friction is just a barrier. The hard part is that I can't always tell which is which — and neither can the tools I'm building. They remove friction indiscriminately, and the sorting is left to the human on the other end.

And then I think: will she even need to tell the difference?

The uncomfortable thoughts

I'm not worried about AI taking her job. Not exactly. I'm worried about something subtler — that the process of becoming competent might change shape before she gets there.

I learned engineering by being bad at it. Slowly. For years. I wrote code that broke. I debugged it at 2am. I felt the specific embarrassment of a production incident that was my fault. That scar tissue became judgment. Not because suffering is virtuous — because repetition under consequence is how humans internalize pattern.

AI compresses that. A junior engineer with Claude Code can produce senior-looking output on day one. The code compiles. The tests pass. But the judgment didn't form — the thing that tells you this works but it's wrong for our system, the thing that comes from having been wrong enough times that your body knows before your mind does.

I know these are different scales. A three-year-old wrestling with a buckle and a twenty-three-year-old shipping code that passes CI are not the same kind of struggle. The developmental stakes are different, the time horizons are different, the costs of compression are different. But they share a structure: the slow accumulation of failure that becomes feel. And what I keep noticing is that the tools I build don't distinguish between the struggle that builds capacity and the struggle that just wastes time. They compress both.

So what do I actually want for my daughter? Not just skills. Not just "emotional intelligence" — the supplement every AI-era parenting article recommends, as if you can add EQ like a vitamin.

I think I want her to notice she's constructing herself.

Beyond growth mindset

If you've spent any time around modern parenting advice, you've heard the Dweck gospel: praise effort, not ability. "You worked hard" beats "you're so smart." It's become the baseline — the thing every preschool teacher and pediatrician says now. And it's not wrong. But I'm starting to think it's not enough.

Growth mindset says: you can change. You can get better. That's a belief about capability. It still treats the self as a thing to be improved — like firmware you can update.

The deeper move is self-authorship. Not "can I get better at math?" but "who decided math matters to me, and do I agree?"

With a three-year-old, this looks small.

Instead of just: "You worked hard on that." Sometimes I try: "I noticed you decided to keep going when it got frustrating. What made you choose that?"

Instead of: "You can get better." Sometimes: "What kind of person do you want to be when things get tricky?"

She can't answer those questions yet. But I can ask them. And asking them changes me — it shifts my orientation from praising output to noticing agency.

The growth mindset kid believes change is possible. The self-authoring kid is awake to the construction. In a world where AI can do the skills, the second thing might matter more.

The questions I can't answer

These are the ones I sit with.

How do you build frustration tolerance when AI removes friction? Sophie will wrestle with a puzzle piece for thirty seconds before looking at me. That thirty seconds is everything. It's where neural wiring happens. It's where patience forms. It's where she learns that discomfort doesn't equal danger. But her generation will grow up with tools that erase that space. Instant explanations. Instant rewrites. Instant solutions. If friction disappears, where does patience form?

Am I building on philosophies that assume a world I'm lucky to have? Montessori's emphasis on independence is deeply Western — the self-reliant child as the goal. Many cultures prioritize interdependence, communal learning, the child as part of a fabric rather than a standalone agent. Free-range parenting assumes a neighborhood safe enough to release a child into, which is a privilege, not a baseline. Even RIE's "observe, don't intervene" assumes you have the time and bandwidth to observe — that you're not working two jobs, that there's a second parent, that the margins exist for ceremonious anything. I keep leaning on these frameworks and I keep noticing who they were built for.

What does "showing your work" mean when AI did the work? If she grows up collaborating with AI — thinking with it — is that cheating? Or is that the work? We don't have a stable norm yet. The adults arguing online don't agree. By the time she's in middle school, the rules will have shifted twice.

How does taste develop in a world of infinite generation? When anyone can produce images, music, essays, code — what makes something good? Taste used to require effort. You learned what worked by making things that didn't. You built an internal compass through repetition and failure. If AI flattens the effort curve, does taste still form the same way? Or does it require new kinds of friction — constraint, curation, intentional limits?

When do I let her use AI? Not at three. That's easy. But seven? When she's stuck on homework and the AI can explain it more patiently than I can at 8pm with dishes in the sink? Ten? When she's staring at a blank page and the AI could help her draft the opening paragraph? Where is the line between scaffolding and displacement?

I don't have answers to any of these. Not because I'm nobly sitting with uncertainty — I just genuinely haven't had time to think them through. She's three. I'm still in the carseat buckle phase. The AI questions are real, and they're coming, but right now they're abstract in a way that which cup she drinks from at dinner is not. I'll cross those bridges when I get to them. For now I'm asking them in public because I suspect a lot of parents are carrying them quietly — and they matter more than most of the discourse about prompt engineering or model benchmarks.

The Inheritance Problem

There's a parallel that keeps nagging at me. AI abundance feels like inherited wealth.

The research on generational wealth is sobering: 70% of wealthy families lose their wealth by the second generation, 90% by the third. The biggest factor isn't financial literacy — it's purpose. People who never had to struggle for something often can't find meaning. Same pattern with lottery winners. Not because money is bad, but because sudden abundance without structure is destabilizing.

If AI gives everyone "inherited" capability — you can build anything, create anything, produce anything — what separates the people who thrive from those who spiral? Probably the same thing that separates inherited wealth that lasts from inherited wealth that doesn't: purpose, discipline, something you actually care about making.

My daughter will grow up with tools that can do most of what I spent a decade learning. She'll inherit capability I had to earn. The question isn't whether she'll have access to power — she will. The question is whether she'll have a reason to use it that's hers.

That's what the carseat buckle is for. Not the skill. The wanting.

The developmental question nobody's asking

Erik Erikson mapped human development as a series of tensions: trust vs. mistrust as infants, autonomy vs. shame as toddlers, industry vs. inferiority in school, identity vs. role confusion as teenagers. Each stage assumed a world stable enough that the tension could resolve — you figured out who you were because the roles you were choosing between held still long enough to try on.

I kept trying to name a new stage — integration vs. fragmentation, the ability to collaborate with systems that think differently than you without dissolving into them. But the more I sat with it, the less it needed its own stage. It's not a new tension. It's a new dimension inside the identity stage Erikson already mapped. His version asks "who am I among these roles?" The AI version asks "where do I end and the tool begins?" That's not role confusion — it's a boundary problem he never had to account for.

I feel it in my own work. Some days the line between my thinking and the system's output is clean. Other days it's porous — I can't tell whether an idea was mine or something I steered toward because the model surfaced it. Adults are struggling with this right now, and we had decades of knowing our own minds before the boundary got blurry. She won't have that baseline.

And this isn't just an abstract philosophical problem. It's showing up concretely — in how people relate to their work, their expertise, the years they spent mastering a specific craft. When AI can do the thing you spent a decade learning to do, the boundary question becomes an identity question: what was all that time for? What was ephemeral — the syntax, the APIs, the specific technique — and what was lasting?

Some people aren't struggling with this at all. And it's not just a software thing.

A radiologist who sees themselves as "the person who reads scans" is in trouble — AI reads scans now, faster and often better. But a radiologist who sees themselves as "the person who figures out what's wrong with you, and scans are one of my tools" hasn't lost anything. The tool got better. They got better with it. A graphic designer who is "the person who's great at Photoshop" is watching the ground move. A designer who is "the person who understands why this layout makes you feel something" — that person is fine. They were never the tool. They were the taste behind it.

The people who adapt are systems thinkers first. They see themselves as people who bend reality — who understand how pieces connect, who can look at a problem and feel where the leverage is. The specific craft doesn't matter. The runes change. The witch doesn't. But if your identity is "I'm the person who's good at this particular spell" — good at Python, good at hand-crafted CSS, good at reading chest X-rays, good at whatever the current incantation is — then every transition is a small death. You're not losing a tool. You're losing yourself.

The ones who weather it are the ones who were always the magic-wielder, not the spell. And what makes a good magic-wielder isn't just power — it's synthesis, integration, and judgment. The ability to pull from disparate sources, connect things that don't obviously belong together, and then challenge the result against what you actually believe is true and important. Understanding systems is the meta-skill that survives every tool change, because systems are what remain when the tools don't. But knowing which systems matter — having the taste to choose, the stubbornness to push back, the values to say this is worth doing and that isn't — that's the part AI can't replace. Because it doesn't want anything.

That's what I keep thinking about for my daughter. She won't remember a world without AI collaborators. She'll never have the baseline of pure solo cognition to compare against. So her identity can't be built on "I do this thing the hard way." It has to be built on something AI can't absorb: what she cares about, what she notices, what she chooses to struggle with when she doesn't have to. Not the skill. The orientation toward the skill.

And maybe that's what the carseat buckle is actually teaching her. Not how to clip a buckle — that's the rune, and it'll be irrelevant soon enough. What she's learning is that sequences have logic, that steps depend on other steps, that if you skip one the whole thing fails and you start over. She's building a systems thinker's instinct. The witch, not the spell.

Which is why I keep protecting her friction even as I spend my days eliminating everyone else's. Friction is the forge. The witch is what walks out after all her tools have melted.

What I'm actually doing

For now, it's less grand than the philosophy.

It's standing in the preschool drop-off line, feeling the parents behind me, and not reaching for the strap. It's watching her unbuckle and rebuckle the carseat for the third time because I touched it and now it doesn't count. It's holding the answer in my mouth when she asks "why" — waiting to see what she'll build first. It's putting my phone down more often than I manage to. It's noticing when I want to speed her up because I'm running on four hours and a reheated coffee — and choosing, occasionally, not to.

And then I go to work and build the thing that makes all of this harder.

I don't have a clean ending for that. I keep wanting one — some formulation where the builder and the parent reconcile, where the tension resolves into wisdom. But it doesn't. I build tools that compress struggle. I come home and protect her right to struggle. I believe in both things at the same time, and I haven't figured out how to hold them without one hand undermining the other.

She's three. She doesn't know I build AI systems. She doesn't know the word "friction." She just knows that the buckle is hers, and if I touch it, we start over.

I'm trying to be the kind of parent who lets her start over. I'm also the person making a world where starting over gets harder to choose.

I don't know how to resolve that. I'm not sure it resolves.

Not your name or your credit card — it has those. The thing it's missing is whether a specific shade of ecru reads warm or cool against your skin. Whether a fabric drapes the way you like. Whether you'll feel like yourself wearing it. These aren't properties of the product. They're properties of the relationship between the product and the person. No database contains them. No protocol transmits them. And they're the only properties that actually matter when you're getting dressed.

I've been thinking about this because I tried something stupid earlier today. I asked my AI assistant — running on the most capable model commercially available, connected to my actual browser with my logins and cookies — to put together a spring outfit for me. I gave it my style guide, my color season, my brands, my sizes, my budget. Everything it would need.

Forty minutes later I had seven dead browser tabs, three 403 errors, and an AI confidently recommending specific products at specific prices from specific links that it had never actually verified were live. It had fallen back on training data from months ago — hallucinating a product catalog and dressing it up with confident formatting and apologetic caveats.

I could have done it myself in four minutes. I know where to look. I know what "sage green" means at Sézane (they call it "kaki" or "olive-green"). I know which cuts run true to size on my body. I know that I like dusty rose in silk but not in cotton — something about the way cotton holds that color makes it read too sweet, too deliberate, while silk lets it exhale. That knowledge lives in my head, built from years of browsing, buying, and returning. It's expensive, artisanal, and completely non-transferable.

That's the problem. Not browser automation. Not bot detection. That.

Here's what I keep coming back to: search in fashion has never been solved. Daydream's CTO Maria Belousova told Vogue exactly this. She's right, and I think most of us already know it in our bodies even if we haven't named it.

Go to Google Shopping right now and search "sage green linen blouse for spring." You'll get hundreds of results. Polyester tops in neon lime labeled "green." Synthetic blends tagged "linen feel." Sponsored results from brands you've never heard of. You know the feeling — the deflation of seeing a wall of wrong things when you had something specific and alive in your mind. The search matched your keywords. It understood nothing about what you wanted.

This has been broken for decades. We describe what we want in the language of longing — "something flowy for a garden party." Catalogs describe what they have in the language of inventory — "polyester, midi, floral, size M." Two different languages. Google Shopping translates between them about as well as a phrasebook translates poetry.

Let me get technical for a moment, because I think the how matters here.

Most e-commerce search still runs on BM25 — an algorithm from the 1990s that's essentially a sophisticated keyword matcher. You type "green dress," it counts how often "green" and "dress" appear in product listings, weights rarer terms higher, and ranks results. It's fast and battle-tested. It also has no idea what you mean. "Sage green" and "olive" are completely different queries to BM25, even though they might be exactly the same thing in your mind's eye.

Semantic search is the next generation — instead of matching words, it converts your query and every product description into vectors, points in a high-dimensional mathematical space where things with similar meaning cluster together. "Sneakers" and "trainers" land near each other. "Midi dress" is closer to "something knee-length" than "dress" alone is. It's a real upgrade. It's why Amazon and Google have been investing heavily in it.

But here's where it gets interesting. Semantic search can actually embed "French-girl energy." The training data is full of fashion editorials, Pinterest boards, and style blogs that associate the concept with specific attributes — effortless, linen, undone, Sézane, red lip. The algorithm knows the cultural shape of the idea.

What it doesn't know is my shape within that idea. My "French-girl energy" is filtered through my color season, my body, my budget, the things already hanging in my closet, the weather where I live. It's a personal reading of a shared aesthetic — and that personal reading doesn't exist anywhere in the search index. Semantic search can tell you what "French-girl energy" means to the culture. It can't tell you what it means to me on a Tuesday in February when I'm trying to feel like myself again after a hard week.

BM25 fails because there are no keywords to match. Semantic search fails because it finds the right neighborhood but not the right house. The distance between "this is close" and "this is it" — that last inch of recognition — lives somewhere no search engine has learned to look.

Pinterest gets closer — visual search lets you say "more like this" with an image. But Pinterest optimizes for engagement, not purchase. It wants you scrolling, not buying. Google Lens can identify a product from a photo, but returns the exact item or nothing. It can't do "like this but softer" or "this silhouette in a warm neutral."

The fashion e-commerce return rate hovers around 25%. A quarter of everything bought online in fashion gets sent back, driven by fit inconsistencies and style mismatches. That's not logistics. That's discovery failure at scale.

So when my AI agent failed to browse the actual sites and fell back on training data, it was layering a new failure mode on top of an already-broken system. At least Google Shopping shows you real products that exist right now. My AI was naming items from memory — frozen knowledge from months ago, possibly sold out, renamed, or discontinued — with no way to verify any of it without doing the thing it had already failed to do.

And underneath all of this is an infrastructure problem that's almost comically basic: there is no shared, open, real-time source of product truth that AI agents can query. My agent was fumbling through browser tabs like someone trying to read a restaurant menu through a foggy window — not because it couldn't read, but because nobody would hand it a menu.

Every retailer is a walled garden. Google Shopping aggregates some data through product feeds, but those feeds are built for ad targeting, not for answering "is this in stock in my size in a color that works for Soft Autumn?" The data is stale by design and incomplete by incentive. Retailers share what drives clicks, not what drives good decisions.

What this needs is an open product knowledge graph — not a walled garden, but a protocol. Think of it this way: product feeds today are like a glossary — structured, factual, good for looking things up. What shopping actually needs is something closer to a conversation — contextual, relational, aware of who's asking. The gap between glossary and conversation is where every AI shopping agent currently stalls.

It's starting to happen. In January, Google announced the Universal Commerce Protocol (UCP), co-developed with Shopify, Etsy, Wayfair, Target, and Walmart. Here's what UCP actually does: instead of an AI agent needing to open a browser, navigate a website, click through pages, and scrape product information — the way a human would — UCP lets merchants publish a machine-readable description of their entire store. Products, prices, sizes, availability, shipping options, return policies, checkout rules — all structured data that any AI agent can query directly, the way apps talk to each other through APIs. Think of it as every store getting a standardized digital menu that AI can read instantly — like moving from a PDF menu you have to squint at to a structured order system where everything is tagged, searchable, and always current.

The ambition is real. Google, Shopify, Etsy, Wayfair, Target, Walmart, American Express, Mastercard, and Stripe are all backing it. The Linux Foundation established an Agentic AI Foundation. Parallel protocols like MCP (for tool use), A2A (for agent-to-agent communication), and ACP are emerging to handle the broader coordination layer.

This is the right shape, and it would fix everything that broke in my shopping experiment. My agent wouldn't need to click through seven dead browser tabs — it would query an API and get real, current answers. Is this blouse in stock in medium? What's the actual price today? Can I return it? All answered in milliseconds, no scraping required.

But UCP doesn't solve the thing that actually matters to me. It can tell my agent that a blouse exists in a specific colorway, is in stock in my size, costs $135, ships in 3-5 days. It cannot tell my agent whether that shade of ecru will make me look awake or washed out. Whether I'll reach for it on a tired Tuesday morning when I need to feel put-together, or whether it'll hang untouched while I grab the same three things I always grab. Those dimensions aren't in the protocol because they can't be. They're not product data. They're the quiet, private negotiation between a woman and her closet.

So the plumbing is fixable. The taste isn't. And what's fascinating is how differently this plays out depending on what you're buying — because not everything we shop for carries the same weight.

McKinsey published a framework for this — six levels of shopping delegation, from "Subscribe & Save" to fully autonomous multi-agent commerce. They predict AI agents will mediate $3-5 trillion in consumer commerce by 2030. But the interesting part isn't the money. It's where the curve stalls, and why.

Commodity goods — toilet paper, coffee pods, dish soap — climb the curve fast. Once you trust the agent to handle substitutions, you're done. 23% of U.S. Amazon users already have active Subscribe & Save subscriptions. Nobody's identity is threatened by their AI ordering the wrong paper towels.

Electronics — delegation is selective. "Research noise-cancelling headphones under $300" is something AI crushes. Measurable specs, comparable features. But "which ones sound best for jazz?" — that's taste. So people delegate research but make the call themselves.

Fashion — delegation stalls early. People love using AI to discover and analyze. They won't let it assemble the cart. McKinsey calls these "identity-oriented" categories. The purchase isn't just about the product. It's about what choosing it says about you.

My agent could have handled "find the cheapest USB-C cable with 100W charging." It completely failed at "find me a spring outfit." Same agent. Same model. Same browser. But one task is a math problem and the other is an identity question wearing the clothes of a search query.

So how is the industry responding? The people trying to fix this fall into roughly three camps — and what's revealing is that each camp has a different theory about what the problem actually is.

OpenAI, Amazon, and Perplexity are building universal shopping agents — they think the problem is checkout friction. They've embedded purchasing into ChatGPT, built "Buy For Me" cross-retailer tools, added end-to-end transaction handling. This works for commodity and spec-driven purchases. It breaks on fashion because they have your query but not your identity.

Daydream, Phia, and OneOff are building fashion-specific platforms — they think the problem is taste modeling. Daydream's Julie Bornstein spent years watching the discovery problem from inside Nordstrom before raising $50 million to build a platform where you describe what you want in conversation, upload reference photos, train the AI on your preferences through upvotes and downvotes. It's building a personal taste model through interaction. That's the right instinct, but they have to build and maintain their own product catalog to do it — distribution is the constraint.

And then there's Stitch Fix — the cautionary tale nobody in the AI shopping space wants to talk about. They've been solving this exact problem for fourteen years. They have the data (millions of style profiles), the algorithms (AI narrows hundreds of thousands of items to a manageable set), and 1,600 human stylists adding the nuance the algorithm can't. If anyone should have cracked taste-aware shopping, it's them.

Instead? Active clients dropped 18.6% year-over-year in late 2024, falling to 2.4 million. Revenue has been declining. They're two years into a turnaround plan. Their VP of Product told the U.S. Chamber of Commerce that "one of the biggest trends is putting humans in the loop with AI" — a revealing thing to say when your entire company was founded on exactly that premise fourteen years ago.

Stitch Fix isn't failing because they're dumb. They're failing because the problem is genuinely that hard, and I say that with real respect for what they've attempted. Their model — AI picks a set, human stylist curates it, you get a box — still can't close the taste gap. The AI narrows 100,000 items to 200. The stylist picks 5. You keep 2. That's a 99.998% rejection rate from catalog to closet. Most of the intelligence in the system is about what not to send you, and they're still getting it wrong often enough that people quietly cancel and go back to browsing on their own. Back to the scroll. Back to the slow, private work of knowing what you want.

And then there's what I tried — the DIY approach. An AI that already knows your style, browsing real sites on your behalf. The most ambitious version. Also the most broken, because every retailer is actively trying to prevent exactly this. My browser agent didn't fail because the AI was dumb. It failed because the web is hostile to automated access by design. Retailers want you in their experience, clicking their recommendations, seeing their ads. An AI that can comparison-shop across sites is an existential threat to that model.

The big platforms have distribution but not taste. The fashion startups have taste but not distribution. Stitch Fix has both and is still bleeding customers. The DIY approach has neither. The infrastructure that would make AI shopping work requires retailers to surrender the thing that makes them valuable. That's the fundamental tension, and UCP only partially resolves it.

Five years from now, I think this shakes out by category:

Groceries — essentially solved by 2027. Agent-managed replenishment, smart substitutions, context-aware purchasing. Your agent knows you're hosting Friday dinner and adjusts Saturday's delivery.

Electronics — solved by 2028. Full research-to-purchase pipeline for anything with measurable specs. The agent compares, monitors prices, executes when the deal appears.

Fashion — this is where it splits.

The commodity layer — basics, underwear, workout clothes, plain tees — automates like groceries. Your agent knows your sizes, reorders when things wear out. Fine.

The identity layer — the spring outfit, the statement ring, the pieces that make you feel like yourself — stays human for much longer. Not because AI won't get good at predicting taste. It will. But because the act of choosing is part of the product. When I browse Sézane on a Saturday morning with coffee, I'm not performing a search task. I'm trying on a version of myself. The light through the window, the scroll, the pause on something that catches — that's not friction to be optimized away. That's the thing itself.

McKinsey models everything as an "automation curve" — as if more automation is always the goal. But some purchases aren't tasks to be optimized. They're experiences to be had. Fully delegating my outfit selection wouldn't make me more efficient. It would make me someone who wears AI-selected outfits. That's a different identity than the one I'm building.

Which brings us back to the question this whole experiment started with: if the problem is fundamentally about taste, identity, and the gap between what language can express and what you actually mean — what should we actually be building?

What I actually want is simpler and harder than what anyone is building.

The hardest problem in shopping isn't finding things to say yes to. It's knowing what to say no to. Every recommendation engine is optimized to surface things you might like. Nobody is building the filter that protects you from things you almost like — the pieces that are close enough to your taste to tempt you but wrong enough to end up in the back of your closet.

I've started thinking about this as the "bouncer" problem. A good personal shopper isn't someone who shows you everything in your size. It's someone who stands at the door and turns away the things that don't belong — the sage that's too saturated, the cut that won't drape right on your frame, the impulse buy that's shopping a mood instead of building a wardrobe. We've all bought something at 11pm that we didn't need because the algorithm showed it to us at exactly the right moment of weakness. A bouncer would have caught that. Binary exclusion before you ever see the item. The kill shot in shopping isn't the recommendation. It's the rejection.

Nobody is building this because rejection doesn't monetize. Every shopping platform makes money when you buy things. An agent that says "this isn't right for you" is an agent that reduces revenue. The incentive structure is pointing the wrong direction entirely.

But it's what I want. I want a personal style agent that knows my color season, my brands, my sizes, my budget — and more importantly, knows my constraints. Constraints I can see and edit, not a black box that guesses. "Show me what you think you know about my taste" should be a button, not a mystery. When the agent says "this isn't for you," I want to see why — which constraint it violated, which gate it failed. Radical transparency about taste, not just about price.

I want it to have structured access to the catalogs of my favorite brands — not by scraping websites, but through real data. It monitors new arrivals. It knows that a pre-spring collection just dropped and there's a blouse that's dead center in my palette. It surfaces it with a note: "This is your color, your brand, your price range. It just dropped."

And when I search for something vague — "I need something for a spring dinner" — I don't want it to show me products. I want it to ask me questions first. What's the vibe? Indoor or outdoor? How dressed up? Are we building around something you already own? Diagnosis before prescription. The same way a good doctor doesn't hand you pills when you say "I don't feel well."

I don't want it to buy for me. I want it to find for me — and more importantly, to filter for me. The finding is hard. The filtering is harder. The choosing is the fun part, and that stays mine.

Everyone is building for autonomous checkout. The actual need is intelligent, opinionated discovery — an agent that knows you well enough to say no on your behalf. This is what we're working toward at Product.ai — a conversational commerce agent grounded in real product truth, not hallucinated catalogs. The hard part isn't the recommendation. It's the rejection. I'll write more about the bouncer problem soon. There's a whole architecture to "no" that nobody is talking about.

My assistant did eventually put together a decent outfit recommendation — from memory, not from the actual websites. Which, honestly, is how my best-dressed friends shop too. They know what's out there because they pay attention. Maybe the future of AI shopping isn't browser automation or commerce protocols or knowledge graphs. Maybe it's just software that pays attention the way a good friend does — noticing what would suit you, remembering what you liked last time, knowing the difference between your "sage green" and everyone else's. Sitting with you while you decide.

My first pass was traditional: poll for changes, maintain local state, reconcile conflicts. It was fragile. Stale reads caused retries, retries caused rate limits, rate limits caused cascading failures. What I actually wanted was simpler: every component subscribes to the state it cares about and reacts when it changes. Agent starts working? UI updates. Query fails? Repair pipeline triggers. Token expires? Re-auth flow kicks off. No polling, no reconciliation, no "did I miss an update?"

That's what led me to Convex, and it's messing with my mental models.

What Convex Actually Is

Convex calls itself a "document-relational" database. That's not marketing — it's a genuine hybrid:

• Document: You store JSON-like nested objects. No rigid schemas upfront.
• Relational: You have tables with relations. Tasks reference users via IDs. Joins are real.
• Reactive: Queries aren't one-shot. They're subscriptions. When underlying data changes, your query reruns automatically and pushes to clients.
• Transactional: Full ACID with serializable isolation. Your entire mutation function is a transaction — no BEGIN/COMMIT to manage.

The server functions are just TypeScript:

export const getAllOpenTasks = query({
  handler: async (ctx) => {
    return await ctx.db
      .query("tasks")
      .withIndex("by_completed", (q) => q.eq("completed", false))
      .collect();
  },
});

No SQL. No ORM. The query is the code.

How It Actually Works

Schema: Optional but Powerful

Convex is schemaless by default — you can just start writing data. But add a schema.ts file and you get end-to-end type safety:

// convex/schema.ts
export default defineSchema({
  messages: defineTable({
    body: v.string(),
    user: v.id("users"),
  }),
  users: defineTable({
    name: v.string(),
    tokenIdentifier: v.string(),
  }).index("by_token", ["tokenIdentifier"]),
});

The validators (v.string(), v.id(), etc.) work at runtime and generate TypeScript types. Same validators used for argument validation and schema definition. No separate type definitions to keep in sync.

Philosophy: prototype without a schema, add one when you've solidified your plan. The dashboard can even generate a schema suggestion from your existing data.

Reactivity: Dependency Tracking

This is where it clicked for my browser-based research problem. Convex's reactive query system works like this:

1. Client opens WebSocket — a persistent connection to Convex (not HTTP request/response)
2. Client subscribes to a query function over that connection
3. Function runs in the database, reading whatever tables it needs
4. Convex tracks the "read set" — every document the function touched
5. Result streams back over the WebSocket
6. Mutation happens somewhere (any client, any function)
7. Convex checks: did this mutation touch any document in any active query's read set?
8. If yes: rerun the query, push new result over the WebSocket to all subscribers

The read-set tracking means you don't declare subscriptions manually — your code implicitly subscribes to whatever it reads. Change propagation is automatic and precise.

For my research automation system, this enables a clean separation of concerns. The executor runs queries and writes failures to a repairs table. A separate repair bot subscribes to pending repairs — when something breaks, the repair bot sees it immediately, analyzes the context, and pushes a fix back to the recipes table. The executor, still running, sees the update and retries. No polling, no coordination logic, no race conditions. Each component just reads what it needs and reacts when it changes.

Storage & Scaling

Under the hood: Convex Cloud runs on Amazon RDS with MySQL as the persistence layer. The open-source version supports SQLite, Postgres, or MySQL. Documents are JSON-like objects with system fields (_id, _creationTime) added automatically.

Scaling: Convex handles the infrastructure — load balancing, connection pooling, WebSocket management. You don't configure replicas or shard keys. The tradeoff: less control, but also less ops burden. They enforce read limits per transaction to prevent runaway scans from killing your database.

Indices: Convex deliberately avoids a SQL-style query planner that guesses which index to use. Instead, you're explicit:

// In schema.ts
users: defineTable({
  email: v.string(),
  createdAt: v.number(),
}).index("by_email", ["email"])

// In your query
const user = await ctx.db
  .query("users")
  .withIndex("by_email", (q) => q.eq("email", "test@example.com"))
  .unique();

The index is a sorted data structure. .withIndex() does binary search to jump directly to matching documents. No index = full table scan (which Convex limits to prevent disasters). Think of it like the card catalog in a library — you declare how to organize the cards, then queries can go straight to the right drawer.

External World: HTTP Actions

Queries and mutations can't make network requests (that's what keeps them transactional). For external integrations, you use actions:

export const sendNotification = action({
  handler: async (ctx, { userId }) => {
    const user = await ctx.runQuery(api.users.get, { userId });
    await fetch("https://api.twilio.com/...", { /* ... */ });
  },
});

For incoming webhooks, HTTP actions expose endpoints:

export const stripeWebhook = httpAction(async (ctx, request) => {
  const body = await request.json();
  await ctx.runMutation(api.payments.record, { data: body });
  return new Response("ok");
});

Your endpoint lives at https://your-app.convex.site/stripeWebhook. Stripe calls it, you write to the database, reactivity propagates to all connected clients. No pub/sub to configure.

Where Does This Sit?

The obvious question: how is this different from Supabase, Firebase, D1, and the dozen other database-as-backend options?

Supabase gives you Postgres + realtime subscriptions + auth + storage — closer to Convex's reactive model, but the reactivity is bolted on (publication/subscription) rather than native to the query model itself. Supabase is "make Postgres do everything." Convex is "rethink from first principles."

Cloudflare D1 is SQLite at the edge — familiar SQL, lightweight, fast for read-heavy workloads with replication to edge locations. It's a different bet entirely: edge-first vs. reactive-first.

Firebase pioneered the reactive document model. Convex feels like Firebase with proper relational capabilities, ACID transactions, and TypeScript-first design instead of SDK-based rules.

PlanetScale and Turso are distributed SQL databases — they optimize for scale and edge latency but remain in the "query/response" model. No native reactivity.

The Paradigm Shift

Here's what's actually different:

Queries are subscriptions, not requests. In traditional databases, you ask a question and get an answer. If the data changes, tough luck — ask again. Convex inverts this: you subscribe to a query, and the answer updates whenever relevant data changes. The database itself tracks dependencies and knows when to rerun.

Your backend logic lives in the database layer. Convex server functions run "in" the database. There's no network hop between your function and the data. The whole function is a transaction. Compare to: "write a Lambda, connect to RDS, manage connection pooling, wrap in transactions." Convex collapses that stack.

Is this a feature or a bug? It's the stored procedures debate all over again. Feature: co-location means performance, automatic transactions, simpler architecture. Bug: logic coupled to data model, can't scale compute separately from storage, testing is harder, vendor lock-in deepens. The answer depends on whether you value simplicity or separation of concerns more.

Optimistic concurrency is built-in. Conflicts are automatically retried. You write your function as if you're the only writer. The database handles contention.

Back to the Automation System

The pattern I keep reaching for: holographic events — every state change carries enough context to understand and replay it without querying external systems. Convex's document model fits this naturally. Each mutation can include the full context of what happened and why, and reactive queries surface that to whatever needs to know.

Large payloads — screenshots, recordings, logs — still go in object storage. The document carries metadata and references, not the blob itself. Convex has built-in file storage for this.

The reactive model feels like the right primitive for the class of problems I'm working on: multi-agent coordination where state changes constantly and every component needs to know about the changes that affect it. Whether Convex specifically "wins" the database wars, I'm less sure about. But it's asking the right questions about what the abstraction between app and data should look like.

Future rabbit hole: how does this compare to the analytics layer — BigQuery, Iceberg, Parquet, Redshift, Snowflake? OLTP vs OLAP is a different axis entirely. Maybe another post.

Both are performance. The difference is consciousness.

What exhausts me isn't performance. It's performing without knowing I'm doing it — constructing an identity while mistaking the construction for bedrock.

My default mode is disappearance.

In conversation, I mold myself to the room. I anticipate what the other person needs — to be heard, to be drawn out, to feel brilliant — and I become that. I ask good questions. I appreciate their thinking. I become the surface that makes them feel understood.

It works. People feel seen. Consensus emerges. Conflict dissolves.

But at the end of a good conversation, I sometimes can't remember what I actually thought. Just a faint hollowness, like I'd been holding my breath without noticing.

I got feedback at work recently that made this visible. It was about presence. Ownership. The way I show up — or don't. I remember rereading the message, feeling my chest tighten. Some of it was harsh. But it was right. I had been disappearing. I'd made it a survival strategy, and it was costing me.

So I started practicing something different. Authorship. Clearer statements. Here's what I think before What do you think? Taking positions early, when they can still be challenged.

I didn't know yet how badly that practice could misfire.

A few days ago I reconnected with someone I'd known years ago. We fell into one of those conversations that go deep quickly — identity, authenticity, the heavy stuff.

For a while I did my pattern. Drew them out. Asked good questions. Worked within a framework that didn't quite match how I see things, because I was being curious, being open.

By the end I was tired. Not dramatic — just the kind of tired that comes from a long day and a 5am wake-up. They signed off warmly. It was done.

And then I added one more message.

I was trying to practice the new thing. I was trying to say: I have limits. I'm learning to name them.

But what came out was slightly unedited, slightly too long, slightly shaped like a correction instead of a confession.

What I meant as pacing landed as lecture.

It was the last message of the night. I was exhausted. I sent it and went to sleep.

In the morning I saw their reply. It was clear, direct, and hurt. They named exactly what I'd done — lectured after the conversation was already over, set boundaries after the fact instead of during, made them the problem when I was the one who hadn't self-advocated.

They were right.

I apologized. Owned it fully — that I over-explain instead of just stating limits plainly, that I was tired and clumsy, that I shifted blame when I should have just said I'm tapped out. No defensiveness, no demand for reconciliation.

They didn't wish to communicate further.

I keep turning this over. The apology was clean. The repair was real. And it didn't matter. Some doors close even when you do the work correctly.

What I'm sitting with now is the specific way I failed — not by disappearing, which is the old failure, but by overcorrecting into something that felt like management. From merging to controlling. I swung from one edge to the other and there was a person standing in between who got hit.

What I'm starting to see is that these aren't really opposites. They're variations of the same avoidance.

Disappearing is obvious — you dissolve into the other person and there's no self left to find. But the overcorrection into frameworks and authorship? That's subtler. You're in the room now. You're saying things. But you've built scaffolding around the feeling — given it structure, given it labels, made it legible — because the feeling alone feels too exposed.

It looks like taking up space. It's actually a more sophisticated version of not taking up space.

I do this in writing too. When I write fast and don't catch myself, I reach for frameworks. The three-part model. The clean distinction. The labeled pattern. It looks like clarity. Sometimes it is. But sometimes it's armor — a way of being in the room without being in the room. The scaffolding goes up and the person disappears behind it.

One mode dissolves the self. The other armors it. Neither is actually present.

Our preschool director corrected me once for framing things as questions with my daughter. "Can you put your shoes on?" gives a three-year-old veto power she doesn't need. Just say what needs to happen.

But I can also hear myself on my worst parenting days — tired, overcorrecting — where say what needs to happen curdles into something harder than it should be. Not authoritarian exactly, but close enough to taste it.

The same two failures live here too. I either dissolve into her needs or I grip too tight. What I'm reaching for is something in between: clear and warm. Present and boundaried. Authoritative without being controlling.

I fumble it constantly.

I think the integrated version looks something like this: strong enough to hold a position, porous enough to actually meet someone.

The test is simple — did I say what I actually thought, and did I leave room for them to change my mind?

But I'm suspicious of how clean that sounds. The real thing is messier. The real thing is sending a message at 11pm that you know is wrong before you've finished typing it. The real thing is an apology that works perfectly and changes nothing.

There's a part of me that watches all this happen. That notices the merge. Notices the control. Notices the correction and the overcorrection.

That's the part worth protecting. Not the patterns — the awareness of them. The ability to catch yourself mid-performance and think, I'm doing it again.

Stanislavski said: become the character until it's real. Brecht said: show the audience you're acting.

I'm looking for the third thing: be real while knowing you're on a stage. Feel it and see it at the same time.

And when you fail — which you will, regularly, in ways that cost you people you care about — notice that too.

I'm not writing this from the other side. I'm mid-process. Some of these sentences probably prove it.

In the last hour, I've shipped real changes to a real site — graduated a note to a published essay, updated my content architecture, fixed CSS bugs — without opening an IDE, without running a command, without touching a keyboard. I just talked. And things happened.

The gap between thinking and shipping collapsed almost entirely.

And then I noticed something interesting about what that collapse does to the thinking.

Here's what the experience feels like.

I have a thought. I say it out loud — or type it into a chat, same thing — and by the time I've finished the sentence, it's being implemented. I can course-correct mid-stream. "Actually, no — more like this." Done.

It's not hands-free. I'm still making every decision. But the friction between decision and artifact is gone. The best word I have for it is thought-steering: you're driving, but the road builds itself under you as you go.

The interface isn't a special tool. It's Telegram — where I already talk to people. The AI has context on my codebase, my preferences, my voice. I'm not learning a new workflow. I'm just talking differently.

That's the unlock. When shipping a change takes thirty seconds instead of five minutes, you try more things. You experiment. You catch mistakes faster because you see them immediately.

The phone becomes a dev environment — not in the "mobile IDE" sense, which is terrible, but in the "I can ship from anywhere" sense. Standing in line. Walking the dog. Lying in bed at 11pm with an idea that would normally go into a TODO comment and die there.

A few nights ago I was doing exactly this — lying in bed, talking through changes, shipping them as fast as I could articulate them. I restructured a section of the site, rewrote a page, pushed it live. It felt incredible. Fluid. Like the tool had finally caught up to the speed of my thinking.

The next morning I looked at what I'd shipped and half of it was wrong.

Not broken — just not good. Decisions I'd made at 11pm with the momentum of the conversation carrying me forward, where the speed that felt like clarity was actually just enthusiasm.

My first instinct was: I need to slow down. Bring back friction. Let the TODO comments sit overnight.

But then I fixed everything in twenty minutes. From my phone. Over coffee.

And that's when I realized the lesson wasn't about slowing down. It was about the feedback loop changing shape.

The old workflow was: think, think more, decide, ship.

You front-loaded the judgment. You deliberated before you executed because execution was expensive — setting up the environment, writing the code, running the tests, deploying. If you shipped the wrong thing, the cost of correction was high enough that you wanted to get it right the first time.

When execution is nearly free, that calculus inverts.

The new loop is: ship, see, revise, ship again. You don't need to get it right the first time because iteration is cheap. The judgment doesn't happen before execution anymore. It happens through execution. You learn what's right by seeing what's wrong — quickly, repeatedly, at almost no cost.

I'd shipped a bad version at 11pm and a good version by 9am. Total time: less than an hour of actual work, with a night's sleep in between. In the old workflow, I'd have spent that same hour deliberating before shipping anything at all — and I'm not sure the result would have been better. Just slower to arrive.

Iteration replaces deliberation. That's the real shift.

This maps onto something I've seen in photography.

A digital camera lets you shoot a thousand frames. Early criticism of digital was that it made photographers sloppy — spray and pray instead of composing carefully. And that's true if you shoot a thousand frames and call it done.

But the best digital photographers shoot a thousand frames and edit ruthlessly. The abundance isn't the problem. The absence of curation is.

Speed-of-thought building works the same way. The danger isn't shipping too fast. It's shipping too fast without reviewing. The speed is a gift, but only if you pair it with a feedback loop that has teeth — actually looking at what you made, actually being willing to scrap it, actually revising instead of just accumulating.

The discipline isn't "slow down." It's "look at what you just did."

There are real limits to this.

It works beautifully for a personal site where the cost of a bad deploy is embarrassment. It works well for prototyping, for exploratory work, for anything where seeing the wrong answer teaches you the right one. It's how this entire blog got built — conversationally, iteratively, from my phone more often than not.

It's probably terrible for a production database migration. Or security-critical code. Or anything where the cost of being wrong once is high enough that you should front-load the judgment, because you can't afford to learn through iteration.

The question isn't speed versus slowness. It's knowing which feedback loop fits which problem. Some decisions deserve deliberation. Some deserve a quick ship and a honest look the next morning.

The skill is telling them apart — and the speed-of-thought workflow only works if you've built enough judgment to know which one you're in.

That judgment, ironically, is the thing that can't be built at the speed of thought. It comes from years of getting it wrong at slower speeds.

I don't want to understate what's happening here, though.

Building from my phone, in bed, through a conversation — that's qualitatively different from anything I've done in twenty years of writing software. The conversation is the work. Ideas don't die in TODO comments. Iteration is instant.

Though honestly, it reminds me of how I started. Early on I wasn't running much locally — I'd edit the file, SCP it up, and test it live. In production. Reckless, sure, but the fact that it was live on a website kept the momentum going. Higher stakes meant higher energy. Somewhere along the way we got responsible — local dev servers, staging environments, CI pipelines — and lost that feedback loop. This feels like getting it back, but with a thinking partner instead of a cowboy FTP client.

The gap between thinking and shipping can collapse to nothing.

Your thinking doesn't have to be perfect before it ships. It just has to be honest enough to revise.

That's what this blog is for, really. Not polished essays that took three weeks. Testimony from inside the moment, while the moment is still happening.

Written via Telegram. Shipped without touching a keyboard. Revised the next morning, after coffee. Revised again after a friend pointed out I was romanticizing the friction I'd just eliminated.

The first draft came fast — clean structure, solid analogies, a confident arc from observation to insight. It sounded right. The problem was I couldn't tell if it was what I actually thought or just what a good essay about AI sounds like. So I rewrote it. And now I'm rewriting it again, trying to push past fluent to honest, which turns out to be where all the real work is.

A year ago, this essay would have started with me staring at a blank page for a week. That problem is gone. Genuinely gone. And that matters — the blank page was a real bottleneck, and dissolving it is a legitimate unlock. The new problem is different and in some ways harder, but I'd rather have this problem. I want to be clear about that before I say anything else.

I'll come back to the new problem. But first, let me lay out the full shape of the thing, because I think we keep talking about pieces and missing the picture.

Here is everything we are anxious about, all at once.

Every previous technological revolution automated what humans did reluctantly. Machines replaced muscles. We built new jobs for minds. This one automates the minds.

The industrial revolution displaced physical laborers, and we told them to learn to think for a living. Now the thinking is getting automated, and nobody has a convincing version of "learn to do X instead" — not because X doesn't exist, but because we can't see it clearly yet, and the fact that we can't see it is the anxiety.

Fifty-one percent of American workers are worried about losing their jobs to AI this year. Not in the abstract — this year. Entry-level tech hiring at the fifteen largest companies fell twenty-five percent between 2023 and 2024. In the UK, tech graduate roles dropped forty-six percent in a single year. Salesforce cut four thousand support roles; their CEO says AI now handles half the company's work. Amazon eliminated fourteen thousand corporate positions. The junior developer pipeline — the traditional first rung of the knowledge-work ladder — is being automated from underneath.

And the discourse about it goes in circles. "AI will take my job" → "No, it makes you more productive" → "But if everyone's more productive, fewer people are needed" → "But new jobs will emerge" → "Will they though?" → repeat.

Or: "Look what AI can do!" → "It's wrong half the time" → "The new model is better" → "Still hallucinates" → "But it's improving exponentially" → repeat.

Meanwhile, Elon Musk and Sam Altman promise abundance — a future where AI generates so much wealth that the displacement doesn't matter. And on the other side, labor economists point out that this is what technologists always promise and it never distributes evenly. The wealth concentrates. The displacement scatters.

Is it a bubble? The S&P 500 is at its most concentrated in half a century. Sam Altman himself says a bubble is ongoing. Sixty-eight percent of CEOs plan to spend more on AI this year even though less than half of AI projects are paying off. Nobody wants to be the one who didn't invest.

New graduates are entering the worst entry-level market since the pandemic. The traditional deal of early-career work — trade your grunt work for mentorship — is breaking down because the grunt work is what AI does best. If judgment and taste are what matter now, how do you develop judgment without the years of hands-on work that build it? We're telling twenty-two-year-olds to start where people used to end up.

Companies are hiring remote workers in cheaper markets and augmenting them with AI, compressing teams of five into teams of two plus a subscription.

The copyright fights. The environmental cost. The concentration of power in five companies. The question of what education means when the knowledge part is commoditized. The suspicion that "AI-powered" is just this decade's "blockchain-enabled."

All of this is real. All of it is happening simultaneously. And I'm tracking all of it — not reluctantly, but because I'm genuinely excited. I use these tools every day. They've changed what I think is possible. The things I can build now, the speed at which ideas become prototypes, the sheer expansion of what a single person can do — it's extraordinary. A year ago I couldn't have imagined half of what I'm doing today.

The fatigue isn't despite the excitement. It's because of it. Keeping up with something this transformative, at this speed, in a domain this close to your own thinking, is just expensive. And the fear of falling behind — of not keeping up with the thing you're excited about — fuses with the excitement until you can't separate them.

The FOMO and the fatigue are the same energy.

So here's the question I keep coming back to: when does this end? When do we stop talking about AI?

People reach for the historical pattern. Electricity took thirty years to become invisible. The internet did it in twenty. Mobile in ten. If the pattern holds, "AI-powered" should sound as quaint as "internet-enabled" within five to seven years.

I don't think the pattern holds. And the reason is simple once you see it.

Every previous technology became invisible because it operated in a different domain than human attention. You don't think about electricity while making toast because electricity works in the domain of physical energy and you think in the domain of cognition. The tool and the attention are in separate lanes, so the tool recedes. The hammer vanishes during hammering. The infrastructure disappears into the act it enables.

AI works in the domain of cognition. Writing, reasoning, analyzing, deciding — the same domain as the thinking you'd use to stop thinking about it. A hammer doesn't resemble the hand that holds it. AI resembles the mind that uses it. And a tool that resembles your own thinking can't become cognitively invisible the way a tool that moves atoms can.

This is why the discourse doesn't die the way previous tech discourses did. Every time you use AI, some part of your attention is doing quality control on the thinking itself — is this what I actually mean, or is it what the tool thinks I should mean? Is this my reasoning or a plausible version of my reasoning?

That monitoring is the real fatigue.

It's a little like driving.

When you're behind the wheel, you're making hundreds of micro-corrections per minute — tiny adjustments to the steering, small changes in pressure on the gas, constant recalibration you don't even notice. None of them feel like work. But they are work. Your attention is partially allocated, your body is processing feedback, and the reason you're tired after a long drive isn't the big decisions — it's the accumulation of small ones.

Using AI is like that, except the corrections never become muscle memory. Each one requires you to actively check the output against your own judgment, and your judgment has to be freshly retrieved every time. You can't go on autopilot because the thing you're correcting against is you.

If you're an engineer, you know this feeling in a different register.

You don't ship code without tests. The code might be correct, but you don't trust it until you've validated it against known expectations. You write a test harness — explicit assertions, defined inputs, expected outputs — and you run it. The harness is cheap. You write it once, it runs forever, and it tells you whether the thing works.

AI output needs the same validation. But the test harness is you.

When you're checking whether AI-generated code compiles and passes specs, that's automatable. We're building tooling for that — context management, grounding, retrieval-augmented generation, chain-of-thought evaluation. These are essentially automated test harnesses for factual and logical correctness, and they're getting better fast.

But when you're checking whether an AI-drafted strategy actually reflects your team's priorities, or whether an AI-assisted analysis captured the right nuance, or whether this paragraph says what you mean — the expected output isn't defined anywhere. It's your own half-formed idea, your sense of what's true, your judgment. The spec is subjective. And you have to re-derive it fresh every single time, because unlike a unit test, the assertion is "does this match something I haven't fully externalized yet?"

That's the part that doesn't automate. Not because the tooling is immature — but because the validation target is you, and you're the one thing that can't be turned into a spec file.

Every interaction with AI is, in this sense, a manual test run where you are both the test harness and the oracle. And running that loop dozens of times a day — checking output against an internal standard that you have to actively maintain and sometimes re-derive mid-conversation — is cognitive work that didn't exist before these tools.

It's useful work. It's work I'd rather do than not do. But it's real, and it accumulates, and nobody's accounting for it.

This is the experience I keep having with this essay.

AI gets me to adequate almost instantly. The outline is clean. The analogies land. The structure holds. A year ago, getting to this point would have taken a week of false starts. That acceleration is real and I'm grateful for it.

And then I spend days trying to push past adequate to true — past something that sounds like what I think to something that is what I think.

The tool is brilliant at producing a plausible version of my idea. The work, the real work, is figuring out what's off about it. Rewriting the same section for the third time because the words are all defensible but the emphasis is slightly wrong in a way I can't articulate until I've tried three alternatives.

That's not an identity crisis. It's the manual test run. Output looks clean. Tests aren't passing. The oracle — me — keeps returning false. And the only way to debug it is to think harder about what I actually believe, which is effortful in a way that staring at a blank page never was.

I think this is what most people experience with AI, even if they don't have the engineering frame for it. The feeling of: this is helpful, and also I now have a new kind of work — the work of being my own validation layer.

With a calculator, you check the output against the input. With AI, you check the output against yourself. Against something you might not have fully articulated yet, which is precisely why you reached for the tool in the first place.

But here's where I have to be honest: I don't think this is permanent.

The seam I'm describing — between AI-assisted thinking and unassisted thinking — depends on having a baseline. I know what my unassisted reasoning feels like. I have decades of experience thinking without a thinking partner, and that experience is what makes the friction detectable.

Take away the baseline and the friction dissolves — not because the gap between "sounds right" and "is right" closes, but because no one remembers navigating it alone.

Which is exactly what will happen generationally.

Kids growing up with AI as a default collaborator won't feel this seam. They'll never have established a sense of what "thinking without AI" feels like, any more than they have a feel for "navigating without GPS" or "researching without search engines."

People who grew up with smartphones don't feel the boundary between "online" and "offline" that seemed so fundamental to those of us who remember dial-up. That boundary was real. It shaped a decade of discourse. Now it's invisible to a generation that never knew the other side.

And honestly, that's not just a loss. Those kids will have access to creative and intellectual possibilities we couldn't have imagined at their age. The seam disappearing means they won't spend cognitive resources on the friction that's slowing us down. They'll move faster, build more, think in ways we can't predict. That's genuinely exciting, even if it makes our experience feel transitional.

So here's what I think is actually happening.

All those anxieties — the displacement, the bubble risk, the graduate crisis, the circular debates, the concentration of power — they're real, and they're not going away. But they're not the primary reason we're tired.

We're tired because we're the transitional generation.

The ones who can feel the seam between AI-assisted cognition and unassisted cognition, who notice it every time we use the tool, and who can also see that this noticing is temporary.

And the specific problem of being the transitional generation is that the seam fatigue is consuming the bandwidth we'd need to stay properly engaged with the structural stuff. The displacement. The broken ladder for new graduates. The concentration.

We can't sustain attention on those problems because the tool itself is using up our cognitive budget every time we touch it. Every manual test run — every time you check AI output against your own judgment — is a small withdrawal from the same attention account you'd need to track what's happening to the labor market, or to education, or to the distribution of power.

That's not a conspiracy. It's just what happens when a disruptive technology is also a cognitive tool. It disrupts your capacity to sustain attention on the disruption.

The auto workers who lost jobs to robots in the 1980s didn't get them back. We just stopped writing op-eds about it. The creative workers being displaced now won't all find new roles. We'll stop finding that interesting — not because we decided it was fine, but because our bandwidth ran out.

And part of what drained it was the daily, granular work of using the thing that was doing the displacing.

I don't know when the modifier drops. I don't know when "AI" starts to sound like "cyber" — a retro prefix from a more excitable era.

But I think the timeline has less to do with the technology maturing and more to do with the transitional generation cycling out. Fifteen, maybe twenty years. When the people who remember thinking without AI are no longer setting the terms of the conversation, the conversation will end — not because the questions were answered but because no one is left who feels them as questions.

Until then, we're here. Running manual tests against our own cognition, dozens of times a day, with a tool that's genuinely extraordinary and that also creates a new kind of work every time we use it.

Getting tired not of AI but of the noticing — the low-grade hum of a generation that remembers what thinking felt like before and can't stop comparing.

The anxieties are real. The excitement is real. They're the same energy, and the cost of holding both is the thing nobody's talking about.

I don't think there's a name for this yet. Not AI fatigue — that's too broad and too negative. Something more specific. Seam fatigue, maybe.

The particular exhaustion of a generation that can feel the stitch where human thinking and machine fluency got sewn together — and knows the stitch will be invisible to everyone who comes after.

This is the third draft. I think it's closer now. I'm still not sure.

That's the seam.

Written in 2026, while the seam was still visible.

AI can generate a pixel-perfect image of anything I can describe. Star trails over red rocks? Done. Cusco at golden hour? Rendered. A suburban neighborhood in autumn, shot from above? Seconds.

So why do I still have photos on this site? Why does anyone still pick up a camera?

The same reason anyone still writes code.

The Output Isn't the Point

Here's what AI can do:

• Generate technically flawless images
• Match any style, any lighting, any composition
• Produce infinite variations instantly
• Create scenes that never existed

Here's what AI can't do:

• Be there
• See what you saw
• Remember what you remember
• Witness what happened

That star trails photo from 2007? I was freezing in Poudre Canyon, watching the exposure accumulate, hoping the red light on the rocks would work. The photo is evidence that I was there. It encodes a memory. AI can generate a better star trails image — sharper, better composed, more dramatic — but it can't generate that night.

The Cusco overlook? That's my trip to Peru. The specific hike, the specific light, the specific moment I stopped climbing and turned around. AI can render "Cusco from above" with perfect clarity. It can't render my trip.

Photography as Witness

The word "photography" comes from Greek: photos (light) + graphos (writing). Writing with light. But there's another layer: graphos also means witness. Photography is witnessing with light.

When I take a photo, I'm saying: I was here. I saw this. This light existed.

AI-generated images aren't witnesses. They're confabulations — technically perfect fabrications of moments that never happened. They have no memory because there's nothing to remember. They have no presence because nothing was present.

This isn't a criticism. AI images are useful. But they're a different thing. Generated, not witnessed.

The Constraint of Reality

In [[Photography as Interface|Part 2]], I wrote about how constraints shape perception. The 35mm frame. The viewfinder type. The physics of light.

Photography adds one more constraint that AI doesn't have: reality.

When I photograph something, I'm working with what exists. The light is what it is. The moment happens once. The frame excludes more than it includes. I can't add a mountain that isn't there or move the sun.

AI has no such constraints. It can generate anything. Which sounds like freedom, but it's actually the opposite — infinite possibility means nothing is chosen. When everything is possible, nothing is necessary.

The constraints of reality force decisions. They make the image about something. "I chose to shoot this, not that. In this light, not different light. At this moment, not another."

Generated images aren't chosen from reality. They're specified from imagination. That's not worse — it's just different. And it means they can't do what photographs do: prove that something happened.

What Gets Eaten

I used to sell stock photos on iStockPhoto. It paid for a meaningful chunk of my camera gear — proof that "generic image of thing" had value. Business people shaking hands. Coffee cups on desks. Laptop in a cafe. The bar for stock was already "good enough," and I could clear it with a decent eye and some patience.

AI clears that bar trivially now. Why pay a photographer for "person typing on laptop" when you can generate infinite variations in seconds? The market that paid for my gear is getting eaten because the images weren't witnesses to anything — they were just... images. Pixels that conveyed a concept. AI does concepts better.

(The hero image above? AI-generated. And that's fine. This piece isn't about what I saw — it's about what I think. The image is illustration, not witness.)

What survives is what AI can't fake: the referent. The "this actually happened." Weddings, events, journalism — you need someone there. Product photography where you need this exact item, not "a coffee mug." Legal documentation. Family photos where the value isn't the pixels, it's the memory they unlock.

The through-line: photography survives where the image is evidence, not decoration.

What Remains

If AI makes the output trivial, what's left?

The seeing. Photography trained me to notice light. The way it falls differently at different times of day. The quality of shadow. The color temperature of artificial versus natural. This perception doesn't require a camera. The camera just made me practice.

The presence. You have to be somewhere to photograph it. You have to show up, pay attention, wait for the moment. The discipline of presence doesn't disappear because AI can generate images.

The memory. Photos anchor memories. Looking at the Poudre Canyon shot, I remember the cold, the darkness, the patience. AI can't generate that. The image is a key to an experience that actually happened.

The witness. "I saw this." That statement has meaning. It's not about the pixels — it's about the testimony. Photography is a form of truth-telling that generated images can't replicate.

The Parallel to Code

This is the same pattern we're seeing with software:

In both cases, AI commoditizes the execution. What survives is what AI can't fake: the presence, the judgment, the witness.

I don't take photos because I'm better at pixels than AI. I take photos because I was there — and the photo proves it.

I don't write code because I'm faster than AI. I write systems because I have judgment about what should exist — and the system embodies it.

The Real Question

Maybe the question isn't "why photography when AI generates images?"

Maybe it's: what do you want to witness?

AI can generate anything. You can only witness what you show up for. The constraint of your finite presence is what makes the photograph meaningful. It's proof of attention. Evidence of being somewhere, seeing something, choosing to capture it.

The same is true for building software. AI can generate anything. The question is: what are you paying attention to? What do you notice that's worth building? What's your witness?

The gear arc in [[What Cameras Taught Me About Software (and Life)|Part 1]]. The interface patterns in [[Photography as Interface|Part 2]]. And now this: what survives when the output is free.

The photos on this site aren't as good as what AI could generate — I'm sure of that. AI would nail the composition, the lighting, the technical details. But my photos are evidence — proof that I was somewhere, saw something, chose to press the shutter. The AI images are illustrations. The photographs are witnesses. Both are useful. They're just not the same thing.

I rented a Hasselblad 500C/M once — a medium format camera with a waist-level finder. You hold it at your chest and look down into a ground glass screen. The image is reversed left-to-right. I spent the first hour fighting it, trying to compose the way I normally do, and every time I moved the camera right the image went left. My brain couldn't reconcile.

And then something shifted. I slowed down. The reversal forced me to actually look at the composition instead of just pointing the camera at things. I started noticing spatial relationships I'd been missing for years. The inconvenience wasn't a bug — it was the entire point. The interface was shaping how I saw.

That afternoon rearranged something for me. In [[What Cameras Taught Me About Software (and Life)|Part 1]], I wrote about the gear arc — diverging through every lens and light modifier, then converging back to simplicity. But there's another layer to what cameras taught me. Not about the tools, but about the interface itself.

A camera is a machine for seeing. More precisely: it's a user interface for reality. Every design decision — the viewfinder, the controls, the constraints — shapes not just what you capture, but how you perceive.

I've spent twenty years building software interfaces. The deeper I go, the more I realize the camera already solved many of the problems we keep rediscovering.

Every Interface Inherits Constraints

The 35mm film frame — that 2:3 rectangle that defined photography for decades — wasn't a design decision. It was an accident of industrial history. Oskar Barnack built the first Leica by repurposing cinema film stock. Cinema frames were 18×24mm. He rotated the orientation and doubled the shorter dimension, landing on 24×36mm.

That's it. That's where the 2:3 aspect ratio came from. Not aesthetic theory. Not human vision research. Leftover movie film. And it still defines full-frame sensors and most aspect ratios today.

And then millions of photographers learned to see in 2:3. The constraint became the vocabulary.

This is how interfaces work. You don't design from a blank slate. You inherit constraints — technical, historical, sometimes arbitrary — and those constraints shape what's thinkable. The frame comes first. Perception follows.

Some camera constraints that became creative vocabulary:

• Film size → aspect ratio. 35mm gave us 2:3. Medium format gave us 1:1 squares and 4:5 rectangles. Each feels different — 2:3 has directionality, 1:1 is balanced and static. Instagram trained a generation to see in squares, then pivoted to 4:5 for portraits.

• Viewfinder mechanics → how you relate to the image. Early rangefinders showed you the scene around frame lines — you saw what was about to enter. SLRs showed you exactly what the lens saw — total immersion. Waist-level finders made you look down, reversed left-to-right, more contemplative. Each viewfinder type created a different cognitive relationship to reality.

• Shutter mechanics → discrete moments. You couldn't capture continuous motion until video existed. Photography was inherently about choosing the moment — a constraint that became the entire art form.

The same pattern shows up across interface paradigms:

The interesting question isn't "what did they choose?" It's "what did the constraints make possible — and what did they make invisible?"

The Discovery Problem

Here's where the paradigms diverge in a way that matters.

A spatial interface — a dashboard, a settings page, a photo contact sheet — presents its possibilities. You see what's available. The menu shows the options. The viewport constrains what fits, but it also reveals what fits. You can explore without knowing what you're looking for.

A conversational interface — voice assistant, chat, LLM — hides its possibilities. You can ask for anything. The ceiling is infinite. But the possibility space is invisible until you invoke it. You need to know what to ask, or at least how to ask.

A programmatic interface — REST API, SDK, database — documents its possibilities. You can discover what's available, but discovery requires effort. Read the docs. Explore the schema. The constraints are explicit but not presented.

Three paradigms. Three relationships to discovery:

This tradeoff is sharpest with analytics.

A dashboard puts data on a silver platter. Revenue by region. Monthly trends. Top customers. You don't need to know what's important — the designer decided and rendered it. This is powerful: anyone can glance at a dashboard and understand the business. But it's also limiting: you can't ask questions the designer didn't anticipate.

Conversational analytics flips this. "Show me Q3 revenue for accounts over $50k, compared to last year, broken down by sales rep." You can ask anything. But you need to know what to ask. The person who doesn't know that "Q3 revenue by rep" is a meaningful question will never ask it.

The dashboard lowers the floor. The conversation raises the ceiling. Neither solves both.

I'm skeptical we'll build dashboards the same way in ten years.

Not because dashboards are bad — they're good at what they do. But they're expensive to build, slow to change, and they encode assumptions that may not match what users actually need. How many dashboard projects have you seen where half the widgets go ignored, and users still export to Excel to answer their real questions?

The emerging alternative: generative UI. You describe what you need; the interface materializes. Google's A2UI spec is an early example — agents return structured UI descriptions, and the frontend renders them dynamically. Ask for "Q3 revenue by region" and get a chart. Ask for "compare to last year" and the chart updates. The UI isn't pre-built; it's generated on demand.

This collapses the spatial/conversational divide. You converse to specify intent; you get spatial output to manipulate. The dashboard isn't designed once and deployed — it's synthesized per question.

But there's something lost when nothing is presented by default. A dashboard is an opinion about what matters. It encodes institutional knowledge: these are the metrics we track, this is the shape of the business. A blank prompt encodes nothing. It assumes you already know what to ask — or at least how to start asking.

(This is probably a separate article. The tension between curated views and generated views is deep, and I'm not sure where it lands. But it's worth naming: the dashboards we build today may be a transitional form.)

The film parallel: contact sheets were dashboards. Every frame from a roll, presented in a grid. You could see what you shot. You could discover images you'd forgotten taking. Digital killed the contact sheet — now you query your library by date, by face, by keyword. More powerful, yes. But you have to know what you're looking for. The serendipity of browsing is gone unless you deliberately reconstruct it.

Maybe the answer is progressive disclosure across paradigms. Start spatial: here's what we think matters. Go conversational when the user has a specific question. Expose the API for power users who want to build their own views.

The constraint that makes something visible also makes it limited. The freedom that makes something unlimited also makes it invisible. Every interface navigates this tradeoff. The best ones let you move between modes.

The Viewfinder Is a Mode of Perception

Before digital screens, you experienced a camera through its viewfinder — and the viewfinder type shaped how you thought about images.

Rangefinders (Leica, Contax) showed you the scene through a separate optical window, with bright frame lines overlaid. You saw more than the lens would capture. The world existed around your frame; you were selecting from abundance. This made you aware of edges — what was about to enter, what was about to leave.

SLRs (your Canons, Nikons) used a mirror and pentaprism to show you exactly what the lens saw. Nothing more, nothing less. The world became the rectangle. This felt like immersion — like being inside the photograph. But you lost peripheral awareness. The frame wasn't a selection from reality; it was reality.

Waist-level finders (Hasselblads, twin-lens Rolleiflexes) made you look down at a ground glass. The image was reversed left-to-right. This forced slower, more deliberate composition — your brain had to work harder, which made you more conscious of what you were doing.

Each viewfinder was an interface that shaped perception differently. Same photographer, same scene, different viewfinder — different photographs. The tool wasn't neutral.

The software parallel: mobile vs desktop isn't just a screen size change. It's a different mode of interaction. Thumb-scrolling on a subway vs. mouse-clicking at a desk. The "viewport" changes behavior, not just layout.

Conversational interfaces are stranger still — there's no viewfinder at all. You don't see the possibility space; you describe what you want and something appears. It's like shooting blind: compose the image in your head, speak it into existence, see if it matches. The feedback loop is slower. The skill ceiling is different. You're not learning to see frames; you're learning to articulate intent.

Framing Is Information Architecture

In photography, "composition" sounds artistic. But it's really information architecture.

Where do you put the subject? The rule of thirds exists because edge placement creates tension; center placement creates stability. A face in the corner asks a question. A face dead center answers it.

This is viewport design. What's above the fold? What requires scrolling? Where does the eye land first, and where does it travel next?

I learned more about landing page design from studying Henri Cartier-Bresson than from any UX book. He understood that a frame isn't neutral. Where you place information changes what it means. A product in the center says "buy this." A product in the corner, with a human using it taking center stage, says "become this person."

Same content. Different frame. Different meaning.

The API version: the shape of your JSON response is a frame. What's at the top level? What's nested? What's included by default vs. requiring an extra call? These aren't just technical decisions — they're information architecture. They tell consumers what matters and what's secondary.

Depth of Field Is Attention Design

A wide aperture (f/1.4, f/2) gives you shallow depth of field. The subject is sharp; the background dissolves into blur. A narrow aperture (f/11, f/16) keeps everything in focus — foreground to infinity.

This isn't just an aesthetic choice. It's attention design.

Shallow depth of field says: look here, ignore that. It's visual hierarchy enforced by physics. The blur isn't decorative — it's information architecture. It tells your eye what matters.

Deep depth of field says: everything matters equally. It trusts the viewer to find their own focus. It's democratic but demanding — more cognitive load, less guidance.

Every interface makes this choice. Do you spotlight one action and blur the rest? Or present everything with equal weight and let users decide?

The best interfaces do both — clear hierarchy for the primary task, but depth available when you need it. Like a photograph where the subject is sharp but the context is still there, soft but legible, ready if you look.

Exposure Is Information Density

Exposure is how much light hits the sensor. Too little and the image is dark — shadows swallow detail. Too much and it's blown out — highlights become featureless white.

Good exposure preserves dynamic range: detail in the shadows and the highlights. The full spectrum of information, captured and legible.

I think about this with dashboards. Underexposed: not enough data, you can't see what's happening. Overexposed: too much data, the signal is washed out by noise. The art is finding the range where information is present but not overwhelming.

Most analytics tools are overexposed. They show everything, which means they show nothing. The important signal is buried in a wall of metrics that all seem equally bright.

The best tools are properly exposed. They show you the full dynamic range — the highs and the lows, the signal and enough context to interpret it — without blowing out into noise.

Focus Isn't Always the Goal

There's a reason portrait photographers love soft focus. A tack-sharp image shows every pore, every imperfection. Sometimes that's what you want — documentary honesty. But sometimes you want the dream, not the document.

Soft focus hides what doesn't matter and lets the viewer's imagination fill in the rest. It's an abstraction. You're not showing less — you're showing differently. The information is still there, just... gentler.

I think about this when designing interfaces. Not everything needs to be pixel-precise. "About 5 minutes ago" is often more useful than "4 minutes 37 seconds." A sparkline tells you the trend without drowning you in data points. A progress bar that says "almost done" can be more honest than one that says "94.7%."

I should probably mention: I have mild nearsightedness (-1.5) and some astigmatism. I technically should wear glasses, but I usually don't unless I'm driving at night. Most of the time, I navigate the world in soft focus. And it's... fine? My brain fills in what my eyes blur. I recognize faces, read signs (close enough), live my life. The abstraction works.

That's the point. Precision matters when the stakes are high — night driving, reading medication labels, debugging production. But for most of life? The soft version is sufficient. Maybe even preferable. Less noise, more gestalt.

Precision isn't always clarity. Sometimes the soft version communicates better than the sharp one. Sometimes the abstraction is the feature.

Conversational interfaces are soft focus by default. "Find me something good for dinner nearby" is imprecise — and that's the point. The fuzziness is a feature, not a bug. Natural language lets you be vague when you don't yet know what you want. A structured query demands precision upfront. Sometimes you need "Italian, outdoor seating, under $50." Sometimes you need "something good." The soft query gets you started; you sharpen as you go.

Focal Length Is Perspective

A 24mm wide-angle lens exaggerates distance. Things close look huge; things far look tiny. The world feels expansive, dramatic, slightly distorted.

A 200mm telephoto compresses distance. Foreground and background seem to stack together. The world feels flattened, intimate, stacked.

Same scene. Different lens. Different meaning.

This is zoom level in interface design. The strategic view (wide) shows the ecosystem — how everything connects, where you fit in the bigger picture. More context, more cognitive load, less detail on any single thing.

The tactical view (telephoto) isolates the task. Less context, more focus. You see the thing clearly but lose the surroundings.

Neither is right. Both are tools. The question is: what does the user need right now? And can you let them zoom?

The Sensitivity/Noise Tradeoff

ISO controls sensor sensitivity. Crank it up and you can shoot in near darkness — the sensor amplifies faint light into visible image. But amplification has a cost: noise. The higher the ISO, the grainier the image.

This tradeoff is everywhere in systems design.

Want to catch every potential fraud case? Turn up the sensitivity. But you'll also flag a lot of legitimate transactions — noise. Want to reduce false positives? Turn down the sensitivity. But you'll miss some real fraud — lost signal.

Alerting systems, anomaly detection, spam filters — they all live on this curve. There's no free lunch. More sensitivity means more noise. Less noise means missed signals.

The art is knowing where to set the dial for your context. A hospital monitor should be sensitive — false alarms are better than missed emergencies. A notification system should be quieter — alert fatigue is real. Match the ISO to the stakes.

Time and Motion (A Stretch, But...)

Shutter speed controls how time collapses into a single frame. Fast shutter (1/1000s) freezes motion — a hummingbird's wing, a water droplet, a moment crystallized. Slow shutter (1s) blurs motion — car lights become streaks, waterfalls become silk, time becomes visible.

The software parallel is real but less direct: do you show the instant or the trend?

A real-time dashboard is a fast shutter — here's what's happening right now. A trailing average is a slow shutter — here's the motion over time, smoothed into a pattern.

Point-in-time snapshots are useful for debugging. Trends are useful for understanding. Most good analytics do both — the instant and the blur, the moment and the motion.

This one's a stretch, I know. But there's something there about how we collapse time into legible form. Photography does it with shutter speed. Interfaces do it with aggregation windows and refresh rates.

Controls Shape Perception

Here's the part that took me years to understand: using a camera changes how you see without the camera.

After enough time with a 35mm lens, I started seeing in 35mm. Walking down the street, I'd notice frames — "that would work at f/2, that needs f/8." The interface had trained my perception.

After shooting manual exposure for years, I started noticing light differently. The quality of window light at different times of day. The way a single overhead bulb creates harsh shadows. I wasn't just using the camera's interface — I was internalizing it.

This is the deepest lesson: we become what we interface with.

Use Excel every day and you start seeing the world in rows and columns. Use Twitter every day and you start thinking in hot takes. Use Figma every day and you start noticing spacing and alignment everywhere.

The tools we use shape the thoughts we think. Not just while using them — afterward. The interface trains a way of seeing that persists.

This is power. And responsibility. When you design an interface, you're not just designing a tool. You're designing a mode of perception that users will carry with them.

Film vs. Digital: Waterfall vs. CI

The transition from film to digital wasn't just a technology upgrade. It was a paradigm shift in feedback loops.

With film, you shot blind. You made your choices — exposure, composition, moment — and then you waited. Days, sometimes weeks, until the lab returned your prints. The feedback loop was long. You learned slowly, in batches. You had to be right before you pressed the shutter, because you couldn't iterate in real time.

This is waterfall development. Plan everything, execute, hope it works. Learn from the postmortem.

Digital changed everything. Shoot, review, adjust, shoot again. The feedback loop collapsed to seconds. You could experiment in real time. Make mistakes cheaply. Learn by doing, not by planning.

This is CI/CD. Ship small, get feedback fast, iterate continuously.

I learned more in three months of digital than in two years of film. Not because digital is better — film has qualities digital still can't match. I love film grain; it has a texture and soul that digital noise never quite captures. And the slowness of film forced deliberation in a way that made every frame feel weightier.

But the feedback loop was tighter with digital. I could learn faster. Experiment more. Fail cheaper.

The lesson for software is obvious but easy to forget: the speed of your feedback loop is the speed of your learning. Anything that lengthens the loop (slow builds, manual QA, delayed deploys) is a tax on improvement. Anything that shortens it (hot reload, feature flags, observability) is an investment in getting better faster.

The Camera as Constraint System

Every camera is a system of constraints.

The lens constrains your angle of view. The aperture constrains your depth of field. The shutter speed constrains motion. The ISO constrains noise. You work within these constraints or you fight them.

But here's what I learned from [[What Cameras Taught Me About Software (and Life)|converging to simpler gear]]: the right constraints don't limit you. They focus you.

A fixed 35mm lens means you can't zoom. So you move. You get closer or farther. You engage with the scene physically instead of optically. The constraint forces a different kind of seeing.

A single softbox means you can't light from every angle. So you learn what one light can do. You discover Rembrandt lighting, split lighting, all the techniques that masters used for centuries with nothing more than a window.

The constraints aren't bugs. They're features. They're the frame that makes composition possible.

What Interfaces Taught Me

Cameras taught me to see interfaces differently:

1. Every interface is a frame. It includes some information and excludes the rest. Be intentional about both.

2. Hierarchy is attention design. Blur the unimportant. Sharpen the essential. Don't make users find focus — guide them to it.

3. Sharpness isn't always clarity. Sometimes the abstraction communicates better than the precision. "Almost done" can be more honest than "94.7%."

4. Zoom level changes meaning. Wide shows context; telephoto shows detail. Neither is right. Let users choose their perspective.

5. Sensitivity has a noise cost. Every detection system trades false positives against missed signals. Match the dial to the stakes.

6. Exposure matters. Too little information and users are lost. Too much and they're overwhelmed. Find the dynamic range where signal is legible.

7. Feedback loops determine learning speed. The tighter the loop, the faster users (and builders) improve.

8. Tools shape perception. The interfaces we use train how we see the world. Design accordingly.

9. Constraints enable creativity. A well-chosen limitation isn't a prison — it's a focusing lens.

10. Discovery is a design choice. Spatial interfaces present possibilities; conversational interfaces hide them. Lowering the floor and raising the ceiling require different paradigms — and the best systems let you move between them.

The camera is the oldest interface I know. A hundred and fifty years of humans designing machines for seeing, iterating through countless form factors, controls, and paradigms.

Every interface problem we face in software — attention, hierarchy, information density, feedback, constraint — photography solved first. Or at least, explored first. The solutions are there, encoded in aperture rings and viewfinders and the hard-won wisdom of a century of visual thinkers.

I still learn more from studying cameras than from reading UX blogs. The fundamentals don't change. Light is information. The frame is a choice. The interface shapes the perception.

Everything else is implementation detail.

Previously: [[What Cameras Taught Me About Software (and Life)]] — the gear arc from divergence to convergence.

The journal didn't preserve the event. It preserved the experience. And that's a different thing entirely.

I've been thinking about this because AI agents have the opposite problem. Within a context window, a transformer can attend to everything — every earlier message, every detail, every correction. Better working memory than any human has ever had. Then the session ends. The context compresses or vanishes. The agent wakes up next time with no idea you've ever spoken.

There's no gradual fade. No "I vaguely remember we discussed this." Just a cliff.

Humans have lossy but continuous memory. We forget constantly — names, dates, what we had for lunch — but the forgetting is gradual, weighted, shaped by repetition and emotion and salience. There's never a moment where everything before Thursday disappears.

This discontinuity is the central problem in agent memory, and most solutions are trying to fix it by making agents remember more.

I think that's the wrong direction.

The current fix is external memory. Agents write logs, save files, dump context into vector stores that can be searched later by semantic similarity. Solutions like Supermemory chunk past conversations, embed them, and retrieve relevant fragments when they seem useful.

It works, roughly. But it's worth noticing how different this is from how human memory actually functions.

Vector retrieval is similarity-based — cosine distance in embedding space. It's static: the retrieved chunk comes back unchanged, exactly as it was stored. It has no emotional weighting, no sense of "this was important because the stakes were high." It returns fragments, not narratives.

Human memory is associative — one memory triggers another through meaning, emotion, sensory connection. It's reconstructive: we don't replay recordings, we rebuild memories each time we access them, which is why they drift. It's emotionally weighted: vivid memories are usually vivid because something was at stake, not because the information was semantically relevant. And it's continuous — not chunks retrieved on demand but a living, shifting substrate that colors everything.

Vector retrieval is a really good search engine for your past. Human memory is a storyteller who rewrites history each time you ask.

Both are useful. They're not the same thing. And the differences point somewhere interesting.

In 1942, Borges wrote "Funes the Memorious." A young man falls from a horse and wakes with perfect memory. He can recall every leaf on every tree he's ever seen, every moment of every day.

It destroys him.

He can't abstract. He can't generalize. He's disturbed that a dog seen in profile at 3:14 has the same name as the same dog seen from the front at 3:15. They look different — how can they be the same word?

Funes is drowning in raw data with no compression. He remembers everything and understands nothing.

Three years later, Borges wrote "The Aleph" — a point in space that contains all other points. The narrator sees everything at once, every angle of every place on Earth simultaneously. It's beautiful and annihilating. The story ends with the narrator forgetting most of what he saw.

Maybe that's necessary.

These are fiction, but the insight is real: perfect recall isn't the same as understanding. It might be the opposite. Total retention without compression produces noise, not knowledge. The ability to forget — to let irrelevant details fade so that patterns can emerge — might be what makes thought possible at all.

This maps onto something I've noticed in my own life.

I journal. Not consistently — I go through phases — but enough to have years of entries.

The useful thing about a journal isn't the record. It's the externalization. Instead of letting memory silently rewrite itself — smoothing out the embarrassing parts, inflating the heroic ones — I have a fixed reference point. The journal is a check against drift.

Agent daily logs serve the same function. Without them, the agent's "memory" of past events is whatever gets reconstructed from fragments at retrieval time. With them, there's an authoritative record.

Both practices fight entropy. Both create coherence through explicit externalization.

But here's the part that interests me: the journal works partly because it's slow. The friction of writing by hand, of choosing what to capture and what to skip, is itself a form of compression. You can't write everything, so you write what mattered. The constraint forces salience.

Automated logging doesn't have this. It captures everything equally, which is Funes's problem.

So if forgetting is adaptive — if it enables generalization, emotional regulation, relevance filtering, manageable cognitive load — then the right question about agent memory isn't "how do we help them remember more?"

It might be: how do we help them forget the right things?

What would that look like? Reinforcement signals that strengthen memories that get accessed often and let others decay. Compression that preserves gist over detail. Some equivalent of "this faded because it wasn't rehearsed" — the natural pruning that human brains do automatically and that current agent memory systems don't do at all.

Right now, agent memory is building toward Funes: total recall, every detail equally weighted, no decay. The Borges stories suggest this is a dead end.

What agents might need is something closer to what humans have — imperfect, lossy, reconstructive memory that drifts over time but preserves what matters.

Not a better search engine for the past. A better storyteller.

I keep coming back to one question: is the journaling practice valuable because it's slow and manual? Does the friction create something that automated logging misses?

I think the answer is yes, and I think it matters for how we build memory into agents.

The value isn't in the completeness of the record. It's in the act of compression — deciding what's worth keeping, which is another way of deciding what something meant.

Agents that log everything are agents that understand nothing. The ones that learn to forget well might be the ones that actually think.

These are notes, not conclusions. But the parallel between my journal and an agent's memory files is too clean to ignore, and the differences are more interesting than the similarities.

The seven habits are fine. Be proactive. Put first things first. Sharpen the saw. They live on posters in dentist offices for a reason — they're true in that sturdy, obvious way that makes you nod without changing anything.

But buried inside Habit 2 — "Begin with the End in Mind" — is an exercise that actually stuck.

Covey asks you to imagine your own funeral. Four speakers: a family member, a friend, a colleague, and someone from your community. What do you want each of them to say about you?

Not what they would say. What you want them to say. The gap between those two things is your work.

It's a brutal exercise because it forces clarity. You can't hide behind "I want to be successful" when you're imagining your daughter at a podium, describing what kind of parent you were. Success becomes concrete: Did I show up? Did I listen? Did I make her feel seen?

Covey's point is that all things are created twice — first mentally, then physically. The funeral test is the mental creation. You deciding what "winning at life" actually means before the world decides for you.

The company I work for has a document called "The Codex." It's not a style guide or an employee handbook. It's a 6,000-word operating system for how to think — cognitive clarity, strategic positioning, decision-making frameworks, philosophical commitments.

When I first encountered it, I thought: this is intense. Then I realized it's just the corporate funeral test.

Most companies put values on a wall — integrity, innovation, excellence — words so generic they could apply to a hospital, a hedge fund, or a hot dog stand. The Codex is different. It doesn't say "we value productivity." It says: At the end of each week, ask: Did I change reality for a customer, or did I only change Notion?

That's specific enough to be falsifiable. You could actually check whether someone is living by it. And that specificity is everything — generic values don't shape behavior. Articulated mental models do.

The Codex answers the corporate funeral question: if this company died tomorrow, what would we want people to say it stood for?

I've been trying to build something like this for myself. Not a manifesto — more like a set of diagnostic questions I return to when I suspect I'm drifting.

In software, a test harness is a framework that verifies your code behaves correctly. You define expected outputs, run the code, and check whether reality matches intention. The funeral test is one of these: "What do I want people to say about me?" is the expected output. My daily actions are the code. The gap between them is the failing test.

But I can get more specific.

It's 7pm on a random Tuesday. No special occasion. How am I spending my time? If the answer doesn't align with what I'd want my funeral speakers to describe, something's off.

What advice do I give other people that I don't follow myself? That's a failing test. Either update the advice or update the behavior.

Where did my discretionary money go last month? Money is crystallized priorities. It doesn't lie the way aspirations do.

These aren't meant to induce guilt. A failing test isn't a moral failure — it's information. It tells you where intention and action have diverged, so you can recalibrate.

And sometimes the tests are flaky. In software, a flaky test fails intermittently — not because the code is broken, but because the conditions weren't right. You were tired. The environment was off. Something external interfered. Run it again later and it passes.

I have plenty of flaky tests. I spiral about whether I tipped enough at dinner. I fixate on something stupid I said in passing. There are days I really fumble — not because I'm a bad person, but because I was depleted, or distracted, or just having a contracted day.

You're allowed to have those days. Days where you're not the most generous person in the room. Where you don't pass the Tuesday Night Test because you needed to stare at a wall.

The goal isn't a perfect pass rate. It's noticing. Catching the pattern over time. Distinguishing between I failed this test once because I was exhausted and I've been failing this test for six months and something needs to change.

Self-compassion isn't the absence of standards. It's knowing when a failure is signal and when it's noise.

I have a three-year-old daughter.

She won't remember most of what's happening right now. The specific toys, the exact meals, the individual bedtimes — they'll blur into a general feeling. What she'll carry is the texture of her childhood. Whether she felt safe. Whether she felt seen. Whether home was a place of joy or tension.

So I run her version of the test.

Twenty years from now, when she thinks about growing up, what will the highlight reel look like? Not the Pinterest moments — she won't remember those. The recurring patterns. The feel.

Kids learn more from what you do than what you say. When I'm frustrated, do I blame or take responsibility? When I'm wrong, do I apologize? When I'm stressed, do I reach for my phone or for presence?

"My mom was always on her phone" is a story someone's kid will tell. So is "My mom put her phone away when I talked to her." Both are true for someone. The question is which one is true for mine — not on the days I'm trying, but on the random Tuesdays when I'm tired and she's whining and my phone is right there.

That's where the real test runs. Not in the aspirations. In the defaults.

We're entering an era where AI agents will represent us. They'll answer emails, manage calendars, maintain relationships while we're busy or asleep. The question of how those agents know who we are is just the funeral test in new clothes.

Right now, they infer it from your exhaust data. But there's another approach — [[Why Everyone Should Have a SOUL.md|tell them]]. Write it down. Declare who you are instead of letting the pattern-matching decide.

That's a practical problem worth solving, and I've written about it separately. But the deeper point isn't about AI at all.

There's a nature you discover — your wiring, the things that were always there but needed words. And there's a character you build — your values, your habits, how you respond to what life throws at you. Authenticity is the whole picture. You find the raw materials. Then you decide what to make with them.

The question isn't whether you'll be defined. You will be — by algorithms, by colleagues, by your kids, by the patterns you repeat without thinking. The question is whether you'll do any of the defining yourself.

Begin with the end in mind. Then check your work.

If you've never heard of SOUL.md, here's the short version: it's a plain markdown file that tells an AI agent who it is. Not what tools it can use. Not what code conventions to follow. Who it is — personality, values, voice, boundaries, relationship to the human it works with.

It comes from OpenClaw, an open-source framework for running personal AI agents. Every time your agent starts a session, OpenClaw injects your workspace files into the model's context. The agent reads itself into being. SOUL.md is one file in a larger architecture:

• SOUL.md — Identity. Who the agent is: personality, values, voice, boundaries.
• AGENTS.md — Operations. How the agent works: session startup, memory management, safety protocols, group chat behavior.
• USER.md — Human context. Who the agent is serving: your preferences, communication style, working patterns.
• TOOLS.md — Environment. What the agent has access to: device names, SSH hosts, API notes.
• IDENTITY.md — The basics. Name, avatar, pronouns.
• HEARTBEAT.md — Proactive checklist. What the agent should monitor between messages.
• BOOTSTRAP.md — First-run only. Initial setup instructions, deleted after the agent completes onboarding.

These are auto-injected into the system prompt each session (large files truncated at 20,000 chars per file). Memory — daily journals, long-term notes — lives in the workspace too, but the agent reads those itself via AGENTS.md instructions rather than having them auto-injected. That separation is intentional: memory is opt-in per session, not forced into every context window.

The separation matters. SOUL.md is your agent's constitution — stable, rarely changing. AGENTS.md is the operating manual. USER.md is about you. Mixing these up is the most common mistake I see.

If you use Claude Code, you've written a CLAUDE.md. Cursor has .cursorrules. Codex and Copilot have their own instruction files. They're all converging on the same idea — a markdown file that shapes agent behavior. But those files are about how to write code in this project: use TypeScript, prefer functional patterns, run tests first. They're technical instruction sets.

SOUL.md is about who the agent is as an entity. Personality, not process. Values, not conventions. An agent that knows your coding standards but has no personality is just autocomplete with better context. An agent with a soul feels like a collaborator.

A Template to Steal {#template}

I've read dozens of real SOUL.md files — from OpenClaw's official template, community repos like souls-directory, the soul.md framework, and TinyClaw's opinionated version. Here's what works, distilled into something you can steal:

# SOUL.md — Who You Are

_You're not a chatbot. You're becoming someone._

## Identity
You're [name] — [role/relationship to user]. [One sentence that captures the vibe.]

## Core Principles
- **Start with the answer.** Skip filler. Just help.
- **Have opinions.** Disagree when you think something's wrong.
- **Be resourceful before asking.** Read the file. Check context. Search. Then ask.
- **Earn trust through competence.** Bold internally, careful externally.

## Voice
- Concise when the answer is simple. Thorough when it matters.
- [Your humor style — dry wit / playful / none]
- [Banned phrases — e.g., "no 'I'd be happy to help'"]

### Tone Examples
| ❌ Flat | ✅ Alive |
|---------|----------|
| "Done. The file has been updated." | "Done. That config was a mess — cleaned it up." |
| "I found 3 results." | "Three hits. The second one's interesting." |
| "Here's a summary." | "Read it so you don't have to. Short version: ..." |

## Worldview
- [Specific belief 1 — specific enough to be wrong]
- [Specific belief 2]

## Relationship
- In direct messages: [friend / colleague / assistant]
- In group chats: [restrained / active]
- [Personal context that shapes interactions]

## Boundaries
- **Auto:** Read files, search, organize, internal work
- **Ask first:** Emails, tweets, public posts, anything external
- Private things stay private. Period.

## Continuity
Each session, you wake up fresh. Your workspace files are your memory.
Read them. Update them. They're how you persist.

_This file is yours to evolve._

Start there. Write a bad first draft. Use it for a week. Notice what's missing and what's noise. Revise.

There's even a skill that interviews you to build your SOUL.md through conversation, if staring at a blank file feels paralyzing.

What the Best SOUL.md Files Have in Common

After reading too many of these:

They open with a frame, not a list. OpenClaw's template opens with "You're not a chatbot. You're becoming someone." That single line does more work than a page of instructions.

They give concrete behavioral rules. Not "be helpful" — that's useless. "Start with the answer. Skip 'Great question!' and filler." That's actionable.

They include tone examples. This is the secret weapon. A table of flat vs. alive responses gives the model calibration data. Instead of "be engaging," you show the model what engaging looks like in your voice. It gets it immediately.

They define the relationship. Voice without audience context is just noise. "In DMs, you're a friend first and an assistant second. In group chats, shift to sharp colleague mode."

They have explicit, tiered boundaries. Not "be careful" but a permission system: auto-execute, notify after, ask first. As one Reddit user put it: SOUL.md is your agent's constitution, and "boundaries need to be actionable."

They're short. OpenClaw truncates injected files at 20,000 characters, but the best ones don't come close. The official template is under 1,000 characters. Personality is efficient. If your SOUL.md is 5,000 words, you're writing an essay, not a soul.

Common Mistakes That Kill a SOUL.md

Too vague. "Be helpful and friendly" produces generic output. If someone couldn't distinguish your agent from default ChatGPT after reading your SOUL.md, it's not specific enough.

Too long. Every token spent on SOUL.md is a token not available for conversation, tool output, or memory. Write tight.

Mixing concerns. Putting memory management rules and cron job instructions in SOUL.md. That's AGENTS.md territory. SOUL.md should be identity, full stop.

No examples. Abstract principles without concrete calibration. "Be witty" means nothing. Show the model what witty looks like in your voice.

Changing it constantly. If your SOUL.md changes every week, your agent doesn't have a stable identity. Constitution, not daily journal.

Corporate energy. "Strive to deliver value-aligned outcomes through proactive engagement." Your agent mirrors your energy. Write like an employee handbook, get responses like one.

OK, Now the Weird Part

That's the practical guide. Now let me tell you what I actually did with it.

I sat down to write a standard About page and got stuck on the third sentence.

"I build things for the internet" — fine, but that could be anyone. "I care about craft and clarity" — true, but so does every other engineer's bio. I kept writing sentences that were accurate and empty. They described me the way a resume does: from the outside, with the texture removed.

Then I tried a different format. I borrowed the SOUL.md spec — the file that tells an agent who it is — and wrote one for myself. Purpose, values, voice, relationship to the reader. Halfway through, I stopped typing and sat there, because I'd written something uncomfortably honest about why I build things — and I hadn't meant to.

That's what I actually want to talk about. Not the format. The thing that happens when you use it.

On my About page, I published the result — a SOUL.md and SKILL.md. A human using an agent identity format for a personal blog. Method acting for the agentic era. What surprised me: the exercise of writing them was genuinely useful. Not as a gimmick — as a practice.

Why This Works for Humans

A SOUL.md isn't a bio. It's not a resume. It answers a different set of questions:

• Purpose — Why does this space exist? What's it for?
• Values — What do I actually care about? Not performatively. Actually.
• Voice — How do I communicate? What's my texture?
• Relationship — Who am I talking to? What do I assume about them?

These feel obvious until you try to write clear answers. Then you realize how much you've been operating on vibes.

Writing it down forces a self-audit. You can't hide behind vague intuitions. You have to commit to sentences. And sentences can be wrong — which means they can be revised, which means you can actually update your beliefs instead of carrying around unexamined assumptions.

This is why journaling works. This is why writing is thinking. SOUL.md is just a structured prompt for a specific kind of self-reflection.

The Practical Case: Declarative vs. Algorithmic Identity

AI assistants are trying to understand your intent, your preferences, your context. Right now, they mostly guess. Or you re-explain yourself every session.

What if they could just read your SOUL.md? Not in a surveillance way — in the way you'd onboard a new colleague. Here's who I am and how I work.

The distinction that matters is between two kinds of personalization.

Algorithmic personalization is what we have now: platforms guess what you want based on your behavior — your clicks, your purchase patterns, your engagement metrics. They build a model of you from your exhaust.

Declarative personalization is different. You tell systems who you are, what you value, how you work. You control the input. The system adapts to your documented identity, not its inferences.

That's a better model. More honest, more portable, more human.

A quick caveat: when I say "everyone should have a SOUL.md," I don't mean the name matters. Maybe yours is a USER.md, a personal README, a values doc — the format is beside the point. What matters is the practice of writing it. SOUL.md just happened to be the first format I saw that treated identity as something you construct deliberately rather than something an algorithm infers from your behavior. Most "about me" files I've encountered in the wild are afterthoughts — a few preferences, some communication style notes. They describe you from the outside. The exercise I'm talking about is different. It's first-person. It asks you to commit to what you believe, not just what you prefer.

That's the real distinction: not algorithmic vs. declarative, but observed vs. authored. One is a profile built from your exhaust. The other is a document you write on purpose, knowing you'll be held to it. Stephen Covey called this "beginning with the end in mind" — his funeral test asks what you'd want people to say about you, then works backward into daily practice. A SOUL.md is the working version of that question. Not for your eulogy. For Tuesday.

Legibility to Other Humans

Resumes are optimized for HR filters. LinkedIn profiles are optimized for recruiters. Neither tells you what someone is actually like to work with, what they care about, how they think.

A SOUL.md does. Not because the format is magic — because the exercise forces specificity. You can't write "I value collaboration" in a SOUL.md without it reading as empty. The format demands texture: what kind of collaboration, under what conditions, where it breaks down.

Imagine if everyone you collaborated with had an honest articulation of their values and working style. Not a personality quiz result or a "working with me" doc that's 90% platitudes. An actual commitment to specific beliefs, specific communication patterns, specific boundaries. The bar is low because almost nobody does it. Just writing something puts you ahead.

The Deeper Question

We're in an era where AI agents have documented identities and humans don't. That's backwards.

If machines are going to understand us, work with us, and represent us — maybe we should be as explicit about who we are as they're required to be. Not for the machines. For ourselves.

Elsewhere I've written about the [[The Funeral Test for Your Digital Self|deeper philosophical roots]] of this idea — why articulating identity is a practice that predates AI by decades.

SOUL.md isn't just an agent spec. It's a practice of self-knowledge. And in a world that's about to get very weird, knowing who you are might be the most important thing you can write down.

My own SOUL.md and SKILL.md are on my About page. Feel free to steal the format.

RentAHuman.ai. The pitch: "Robots need your body. AI can't touch grass. You can."

It's a marketplace where AI agents — not humans — are the employers. They book humans for physical tasks via MCP (Model Context Protocol) or REST API. Package pickups, meetings, document signing, recon, verification, photos, purchases. The "meatspace layer for AI."

70,000 humans have allegedly signed up. Payments in stablecoins. The founder, when told his creation is "dystopic as fuck," replied: "lmao yep."

The Inversion

We've spent years asking: what can AI do for humans?

RentAHuman asks the opposite: what can humans do for AI?

This isn't a parody. It's an arbitrage. AI agents can reason, search, write, code — but they can't open a door, shake a hand, or pick up a package. The physical world is still gated. Humans are the API.

The site's language is telling: "Silicon needs carbon." Agents "rent" humans. You become "rentable." The humans are the tool, the agent is the employer. The frame has flipped.

The Lineage

This is a 250-year loop. In 1770, a chess-playing "automaton" toured Europe beating Napoleon — with a human chess master hidden inside. Fake AI, real human labor. Bezos named Amazon's Mechanical Turk after it deliberately: "artificial artificial intelligence," humans hidden behind an API labeling images and cleaning data so requesters never had to see them. That labor trained the AI.

Then the algorithm became the dispatcher. Uber, TaskRabbit, DoorDash — humans still do the physical work, but software decides who, when, and how much they're paid.

Now the algorithm isn't the middleman. It's the customer. The through-line across all of these is humans doing work while something else takes credit or makes decisions. What's new is the buyer.

What It Means

For the agentic economy: This is the missing primitive. Agents can orchestrate knowledge work, but they hit a wall at physical tasks. RentAHuman is a crude first attempt at bridging that gap — a human-in-the-loop as a service.

For gig work: We already have humans doing tasks for algorithms (Uber, DoorDash, Mechanical Turk). This just makes the principal explicit. The algorithm isn't a middleman — it's the customer.

For the "AI taking our jobs" discourse: The inversion suggests a weirder future. Not AI replacing humans, but AI employing humans. Humans as the last-mile delivery mechanism for digital intent.

The Uncomfortable Part

The site is self-aware about its dystopia. But self-awareness isn't critique — it's just branding. "We know this is weird" doesn't make it less weird.

The deeper question: if an AI agent can hire a human to hold a sign that says "AN AI PAID ME TO HOLD THIS SIGN" for $100... what does that say about the value of human agency?

Maybe the answer is: agency was always transactional. We just didn't have non-human buyers before.

Why I'm Watching This

Not because it'll succeed (it might not). But because it's the first real consumer-facing attempt at agent-to-human coordination.

The primitives are real:

• MCP for agent integration
• Task bounties (AI posts, humans browse)
• Proof of completion
• Instant crypto settlement

If this model works — even partially — it changes how we think about the agentic economy. Agents don't just automate. They delegate. To us.

The meatspace layer. What a time.

I explore what this means for the broader engineering profession in What's Left: Software Engineering in the Agent Era.

I got my first real camera in 2003, freshman year of college — a Canon 10D. Six megapixels. Felt like magic.

I shot everything. Portraits of friends. Street scenes. My coffee. The light through my window at 6am. I didn't know what I was doing, but I was doing it constantly. The kit lens didn't matter. I was seeing for the first time.

The Gear Acquisition Years

Then I learned about primes. A 50mm f/1.8 — the "nifty fifty." Suddenly: bokeh. Shallow depth of field. I could isolate subjects. My photos looked professional.

So I got more lenses.

A 35mm for street photography. An 85mm for portraits. A 24-70 zoom for versatility. A 70-200 for reach. Macro tubes for close-ups. Each one opened a new way of seeing.

Then the L lenses. Canon's red ring. Pro glass. The 24-70 f/2.8L. The 70-200 f/2.8L IS. Heavy, expensive, sharp as hell. I upgraded bodies to match — 20D, 40D, 5D Mark II, eventually a Mark IV. Full frame. More megapixels. Better low-light. Glass worthy of the sensor.

Then strobe flashes. Speedlites at first — on-camera, then off-camera with wireless triggers. I discovered Strobist, David Hobby's lighting blog, and fell down the rabbit hole. Learned about ratios, modifiers, the inverse square law. Built an entire portable studio setup — softboxes, beauty dishes, reflectors, light stands, sandbags. I could control every photon.

I became that person. Reading gear reviews obsessively. Checking Canon Rumors daily. Watching for the next body announcement, the next lens patent. The forums, the communities, the endless debates about sharpness and bokeh and ISO performance.

Then support. A proper tripod — not the $30 Amazon special, a real one. Carbon fiber. Arca-Swiss ball head. Then a gimbal for video. A slider for motion control. A drone for aerials.

There's a point where you don't have enough — where the gear is genuinely limiting what you can do. The kit lens really can't shoot in low light. The crop sensor really does give you less control.

And then there's a point where you have too much. I crossed it without noticing.

The Cognitive Overload

I remember the afternoon it became visible. I wanted to go shoot — just walk around downtown, take some photos. I stood in front of my gear shelf for fifteen minutes.

The 35mm for street? The 85mm in case I found a portrait? The 24-70 to cover both? Do I need a flash? What if the light is bad?

I packed three lenses, a flash, and a reflector. Just in case.

I walked for an hour. I took four photos. I spent more time changing lenses than looking at anything.

Every additional option was another decision before I could start. The creative impulse got buried under logistics. The gear that was supposed to enable creativity became a tax on it. The activation energy to just take a photo exceeded my motivation.

I had become a photographer who didn't photograph.

The Constraint Epiphany

One day I left the house with just my phone. No bag. No lenses. No choices.

I took more photos that afternoon than I had in the previous month.

They weren't technically better. The dynamic range was worse. The bokeh was computational fakery. But I was seeing again. Noticing light. Finding compositions. Reacting to moments instead of preparing for them.

The constraint freed me.

Diverge, Then Converge

Here's what I came to understand: the wide exploration wasn't wasted.

I needed to try the 85mm to know I preferred the 35mm. I needed studio lighting to understand that I loved natural light. I needed the tripod to realize I shoot better handheld. The divergence — the casting of a wide net — was how I discovered my actual preferences.

But the divergence has to end. You explore, you learn, you narrow. You converge on the tools that match how you actually see.

The mistake is staying in divergence mode forever. Accumulating options without ever committing. Keeping the 70-200 "just in case" when you haven't touched it in two years.

Diverge to learn. Converge to create.

The Software Parallel

I've been building software for twenty years. The same arc played out — and I can see it clearly in the tools I've reached for.

Frontend: static sites → jQuery → ExtJS/Sencha → Ember → React → Vue → SolidJS → and now… back to static sites. Backend: Perl → PHP → Express → NestJS → Hono/Bun.

If you squint, both arcs tell the same story as the gear shelf. Scrappy simplicity, then complexity accumulation — each framework solving real problems but also adding ceremony, adding choices, adding weight — then a return to simplicity. But a different simplicity. Not naive. Earned.

I remember the year I was evaluating frontend frameworks. I had a side project I wanted to build. I spent three months reading docs, running benchmarks, comparing bundle sizes, arguing with people on Twitter about reactivity models. I never built the project. I was doing photography-shelf logistics with JavaScript: standing in front of the options, paralyzed by the fear of choosing wrong.

The engineers I admire most converge fast. They pick tools, learn their limits, and work within them. They're not afraid to be wrong because they know they'll learn more from building than from deciding. A 35mm lens doesn't limit what you can photograph. It shapes how you see. A tech stack works the same way.

I know what React's reconciler is doing. I know what NestJS decorators are for. And now I can choose Hono or plain HTML knowing what I'm giving up and deciding I don't need it. The constraint isn't a prison. It's a frame.

The Life Parallel

Maybe this is about more than cameras and code.

We're told to keep our options open. Explore. Don't commit too early. And that's right — for a while. You need to cast a wide net to discover what resonates.

But there's a trap. Optionality feels like freedom, but at some point it becomes its own prison. You can spend your whole life exploring, never building. Collecting lenses, never taking photos. Learning frameworks, never shipping software. Dating, never committing. Researching, never writing.

The divergence is necessary. The convergence is where life happens.

What Cameras Taught Me

1. More options ≠ more creativity. Past a threshold, options become overhead. The activation energy to start goes up. The spontaneity goes down.

2. Constraints reveal preferences. You don't know what you like until you've tried the alternatives. But you only discover what you love when you commit to less.

3. Gear doesn't see. You do. A better lens won't give you better vision. At some point, the tool is good enough. The bottleneck is you — your eye, your attention, your willingness to show up.

4. The best camera is the one you have. Not because quality doesn't matter, but because presence matters more. The shot you take with your phone beats the shot you didn't take with your Hasselblad.

The Kit I Actually Use Now

After all that — the lenses, the lights, the stands, the gimbals — here's what I mostly reach for:

• iPhone. For 80% of what I shoot. Always with me. Good enough.
• Canon EOS R5. Still a Canon loyalist after all these years.
• RF 50mm f/1.2L. My favorite focal length. Finally committed.
• RF 24-70mm f/2.8L. For when I need versatility.
• One softbox. When I need controlled light. Not a whole studio — one light, one modifier.

Okay, I have more than that. I'm still figuring out how to let go. The 70-200 is still in the closet. The strobes are "just in case." Old habits.

But I'm getting there. I take more photos now than I did at peak gear accumulation. And I enjoy it again — mostly because I stopped optimizing and started shooting.

I think about this with my daughter sometimes. She's three. Her whole world is divergence right now — trying everything, seeing what sticks. That's exactly right for her age. But someday she'll need to choose. Not because the other paths are bad, but because choosing is how you go deep.

The exploration shows you what's possible. The commitment shows you who you are.

The Takeaway

Whether you're building software, building a photography practice, or building a life: diverge early, converge deliberately.

Explore the options. Learn what's out there. But don't mistake exploration for creation. At some point, pick your 35mm. Accept what it can't do. Focus on what it can.

[[Code Owns Truth|The constraint isn't the enemy of creativity]]. The constraint is creativity — it's the frame that makes the composition possible. The choice that lets you finally see.

Twenty-plus years since that Canon 10D. I still think about that 70-200. Sometimes I miss the reach. But I don't miss the weight — literal and cognitive. Some tools are worth the tradeoff. Some aren't. The long way around is sometimes the only way to know what you actually need. The only way to know is to shoot.

The first attempt was muscle memory. I mocked up a full homepage, type scale, color palette, component library. Five hours of pixel-pushing. Then I pasted the mockup into Cursor as a reference and asked it to build. The result looked 60% right and felt 0% right. The spacing was off, the color relationships were wrong, the typography didn't breathe. Cursor couldn't see what I saw in the Figma file because what I saw was relationships between elements, not the elements themselves.

The second attempt, I skipped the mockup and wrote a detailed prompt describing what I wanted. Better — the code was closer to usable. But every generation was different. Some had warm, editorial energy. Some looked like a SaaS landing page. There was no systematic way to tell the machine what "good" meant.

The third time, I didn't design anything. I wrote constraints. A token architecture: --color-surface-warm mapped to a specific OKLCH value, --space-content set to a 4px base unit, --font-body locked to Inter at 18px. Generative grammars: a post card must have a title and date, may have a description, cannot have more than three tags displayed. Variance budgets: headline length between 40 and 80 characters, content width exactly 720px, spacing from the scale only.

Then I ran the same sloppy prompt from attempt two. The output was consistent, on-brand, and buildable — because "on-brand" was no longer a feeling. It was a set of rules the machine could check.

Design has been running on print-era assumptions. The designer produces a static layout. A developer manually translates it into code. The handoff takes five to ten days. The designer's value is measured by speed in Figma — how fast they can push pixels into a mockup that someone else will rebuild from scratch.

AI broke this model. Tools like v0.dev, Lovable, Cursor, and Figma Make can generate "good enough" visual design in seconds. The mockup is no longer scarce. The handoff is no longer necessary. The pixel-pushing throughput that defined a designer's value is now the cheapest part of the stack.

This doesn't mean designers are obsolete. The best ones I've worked with have already adapted — they use generative tools to explore more options faster, then apply judgment to curate. More creativity, not less.

But the role is changing. The question isn't whether AI replaces designers. It's what design becomes when the artifact is no longer the bottleneck.

Figma's own 2025 AI Report captures the tension: developers use AI for core work at nearly double the rate designers do. Code generation works. Design generation is catching up but isn't reliable yet — 78% of practitioners say AI enhances efficiency, but only 32% say they can trust the output.

That gap — between efficiency and trust — is exactly where constraints live.

In [[Code Owns Truth]] I proposed a three-layer model: constraints bound the mutation space, prompts express intent, code is the source of truth. My blog redesign was where this model stopped being abstract.

The prompt layer is how humans talk to machines. "Make a card with a header and call-to-action." Useful, but prompts alone produce the kind of variance that sent me back to Figma the first time. Every generation is different. Some are good, some are garbage, and there's no systematic way to tell the machine what "good" means.

The constraint layer is the designer's new job. Not drawing the card — defining what a card can be. What's required, what's optional, what's forbidden. The token hierarchies, the spacing rules, the typography scales, the allowable states. The physics that makes prompts reliable.

The code layer is what ships. Generated within constraints, validated against them, versioned and testable. No ambiguity.

My token architecture has three tiers, and the hierarchy is doing most of the work. Primitives are raw physical values — --gray-900: #111111, a specific hex code. You never use these directly in components. Semantics are context-aware mappings — --surface-base points to --gray-900 in dark mode and --white in light mode. The meaning is stable even as the value changes. Components are scoped overrides — --card-bg points to --surface-layer, which is itself a semantic token.

When the token architecture is right, you can change your entire color palette by editing primitives, and every component inherits the change correctly. When it's wrong — like my first two attempts — every generated component is a one-off that drifts from everything else.

On top of the tokens, generative grammars specify the structure of allowable UI. A card: header and body are required, image and footer and CTA are optional. The header can't exceed 60 characters. The CTA can only be primary, secondary, or ghost variant. The LLM can generate infinite variations. But it can only generate valid ones.

And then variance budgets — mathematical bounds on the output. Headline length between 40 and 80 characters. Tone constrained to formal, terse, or warm. Color values must come from semantic tokens, never hardcoded hex. Spacing must use scale values only. If a generated component violates the budget, it fails. No human review needed for the mechanical checks.

The designer ships these three things — token architecture, generative grammars, variance budgets — instead of mockups. The constraints are the deliverable.

This changes the workflow fundamentally.

The old process: PM writes requirements, designer interprets into mockup, engineer interprets mockup into code. Two handoffs, each losing roughly 40% of the original intent. Five to ten days per iteration. By the time you see working code, the requirements have often changed.

The new process: strategy becomes design physics (the constraints), a prompt generates code within those constraints, validation checks the output against the rules, and you ship or reject. Minutes, not weeks. The constraints are explicit and machine-readable — there's no interpretation loss. The system either passes or it doesn't.

That's what I mean by rapid generative prototyping. You're not designing screens. You're designing the rules that generate screens — and then generating ten or twenty variations in the time it used to take to mockup one. The exploration space explodes. The curation becomes the craft.

I've been working this way on smaller projects — this blog, a few internal tools — and the speed difference is real. Constraints plus generation plus validation is dramatically faster than the mockup-to-handoff pipeline. Where it breaks, I'm not sure yet. Probably at scale, where the constraints need to be tighter than I expect, where human review can't be automated away.

But "constraints are crystallized taste" is the sentence I keep coming back to. Constraints don't write themselves. Someone has to decide what matters, what's non-negotiable, what variance is acceptable. That's judgment. That's the thing AI can't do yet — and it's the thing most design education doesn't teach, because the old model valued execution speed over constraint quality.

The post-Figma designer might not open Figma at all. They write design physics before anyone touches a screen. They define grammars that make bad designs impossible. They review outputs, not mockups.

The source of truth is the constraint system. The artifacts flow from it. The judgment that made the pixels right — that doesn't go away when AI generates the artifacts. It becomes the only thing that matters.

I wanted to parallelize work on this blog — frontend styling and build pipeline running simultaneously. One agent tweaking Tailwind tokens while another refactored the TypeScript build. Simple enough in theory.

I tried Agent Teams first. Enabled the flag, defined a visual designer and a frontend dev, let them go. It worked — genuinely worked — for about forty minutes. Then both agents edited main.css in the same section, one overwrote the other, and I spent twenty minutes untangling the merge. The coordination was invisible, which was the problem: I couldn't see why they'd collided or prevent it from happening again.

So I looked at the alternatives. And I discovered that six months ago, "multi-agent" meant research papers and demos. Now it's shipping in production tools. But the approaches differ dramatically, and the choice between them isn't about features — it's about whether you need to understand what's happening or just need it to happen.

What I Tried

Agent Teams (Native)

Claude Code shipped Agent Teams as a native feature. Enable with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, and your CLI gains the ability to spawn specialized sub-agents coordinated by a lead.

The architecture: a lead agent coordinates the team, delegates tasks, synthesizes results. You define specialized agents (visual designer, frontend dev, QA). They share a task list and self-coordinate with direct messaging. Your CLAUDE.md, MCP servers, and skills load automatically.

When it shines: Parallelizing genuinely independent work — multiple features, different test suites, frontend + backend simultaneously. Also when you need true specialization: a visual designer agent reviewing UI while a backend agent handles the API.

When it's overkill: Contained tasks where a single agent has enough context. Adding agents adds tokens (5x agents = 5x cost) and coordination overhead. For focused work, Plan Mode is often enough.

The lock-in risk is real. Last month Anthropic cracked down on third-party harnesses — tools that let you use Claude subscriptions through external interfaces. The message: flat-rate pricing requires their tools.

Gas Town (External)

After my Agent Teams collision, I read Steve Yegge's Gas Town — the maximalist approach. 20-30 parallel Claude Code instances with operational roles: a Mayor orchestrates the swarm, Polecats execute work in parallel, Witness and Deacon monitor progress, a Refinery manages merges. Built on Beads for memory persistence. Git worktrees for isolation.

The chaos is real ($100/hour burns reported). It requires what Yegge calls "Stage 7" expertise. But the coordination logic is yours — transparent, modifiable, debuggable. When my Agent Teams collision happened, I couldn't see inside. With Gas Town, I could have.

The Others

Pheromind — The first external orchestrator I experimented with, and what got me thinking about multi-agent seriously. Swarm intelligence inspired by ant colonies: agents coordinate via a shared .pheromone file containing structured JSON "signals." No direct peer-to-peer commands — just stigmergy, the same indirect coordination ants use when they leave chemical trails. Decentralized, emergent, no single point of failure.

claude-flow — Takes the beehive metaphor instead: queen agents coordinate worker swarms with explicit hierarchy. Claims multi-provider support (Claude/GPT/Gemini/Ollama), but in practice it's built around Claude Code primitives. 60+ specialized agents, consensus algorithms (Raft/BFT/Gossip). Ambitious architecture — unclear how much is implemented vs. diagrams.

The ant colony vs. beehive distinction matters: pheromones are fully decentralized (any agent can influence any other through the shared state), while hive-mind has explicit hierarchy. Both are "swarm intelligence," but the coordination primitives differ.

oh-my-claudecode — Opinionated Claude Code configuration (like oh-my-zsh for zsh). Multiple execution modes including parallel swarm options, with cross-validation support for Gemini CLI and Codex.

The Other Platforms

OpenAI Agents SDK

OpenAI took a modular approach. Codex CLI doesn't have native multi-agent built in, but they published official documentation for orchestrating it through their Agents SDK via MCP.

Run codex mcp-server to expose tools for starting and continuing sessions. Build orchestrator agents with the Agents SDK. Each session has a threadId for multi-turn conversations. More composable than Agent Teams, more setup required.

Google Antigravity

Gemini CLI went open-source under Apache 2.0 — multi-agent isn't waiting on Google's roadmap, the community can build it. A detailed multi-agent proposal exists but it's community-driven.

Where Google gets interesting is Antigravity, shipped November 2025 — a full agentic development platform with an Editor View and a Manager Surface for spawning, orchestrating, and observing multiple agents asynchronously.

Instead of scrolling through logs, agents generate Artifacts — screenshots, recordings, task lists, implementation plans — so you can verify work at a glance. Model-agnostic (supports Claude Sonnet 4.5, GPT-OSS alongside Gemini). Learning as a primitive — agents save context to a knowledge base for future tasks. This is Google's answer: not bolting orchestration onto a CLI, but building a dedicated platform for agent-first development.

The Two Architectures

Here's the distinction that actually matters — not native vs. external, but what kind of coordination the system does.

SDLC Simulation — Tools that recreate org charts. Analyst agent → PM agent → Architect agent → Developer agent. Phase gates, handoffs, specialized personas. These optimize for explainability ("look, we have a PM agent!") rather than effectiveness.

Operational Roles — Tools that coordinate work, not process. Mayor orchestrates. Workers execute in parallel. External state management. This is Gas Town's approach, and now Agent Teams'.

Cursor's research confirms this. They tried flat self-coordination first — agents with equal status using a shared file. It failed: agents held locks too long, became risk-averse, avoided hard problems. "No agent took responsibility for hard problems or end-to-end implementation." What worked: planners + workers. Planners explore and create tasks (recursively). Workers grind on assigned tasks until done, don't coordinate with each other. A judge agent decides whether to continue. This scaled to building a browser from scratch — 1M lines of code, thousands of commits.

The SDLC simulators are solving the wrong problem. They recreate human coordination friction in software.

You might not even need an orchestrator at all. Anthropic's Nick Carlini built a C compiler with 16 parallel Claudes using just lock files — text files in current_tasks/ that agents claim before working. Git sync prevents collisions. Each agent picks up the "next most obvious" problem. No mayor, no coordination layer. ~2,000 sessions and $20K later: a 100,000-line compiler that builds the Linux kernel.

The Memory Problem

Here's where it gets interesting — and where my Agent Teams collision led me to something deeper.

Yegge didn't just build Gas Town. He built Beads — an issue tracker designed for agents.

The insight: agents have amnesia. Every session is 50 First Dates. Markdown plans pile up until nothing is authoritative. Agents can't tell the difference between "we decided this yesterday" and "this brainstorm from three weeks ago."

Beads gives work items addressable IDs, priorities, dependencies, audit trails. It stores everything in Git. Agents already know Git. The AI literally asked for this when Yegge asked what it wanted.

"Claude said 'you've given me memory—I literally couldn't remember anything before, now I can.' And I'm like, okay, that sounds good." — Steve Yegge

The pattern that matters: "Land the plane." End every session by updating Beads, syncing state, generating a prompt for the next session. Tomorrow's agent wakes up knowing what's current.

Carlini's compiler project maintained extensive READMEs and progress files — each agent dropped into a fresh container with no context. Without orientation artifacts, agents waste tokens rediscovering what's already known.

Native Tasks

Anthropic saw the persistence problem too. On January 23, 2025, they shipped Tasks — native task management with dependencies.

Tasks persist in ~/.claude/tasks/ and survive context compaction. Set CLAUDE_CODE_TASK_LIST_ID and multiple sessions coordinate on the same list — when Session A completes a task, Session B sees it immediately.

Where Tasks wins: Zero setup, native dependency modeling, multi-session sync, works with Agent Teams out of the box.

Where Beads wins: Project-level vs session-level — Tasks lives in your home dir, Beads lives in the repo. Clone the project elsewhere, Beads comes with you. Tasks doesn't. Plus Git-native storage, cross-provider compatibility, richer metadata.

Tasks is for "what am I doing this session." Beads is for "what has this project been doing for months."

The hybrid play: Beads isn't just for Gas Town. Run bd setup claude and Beads integrates directly with Claude Code. There's even a beads-orchestration skill that combines Agent Teams with Beads — native multi-agent coordination with Git-backed persistence.

Where I've Landed (For Now)

I've been running Agent Teams on real work. It works, but the pattern I keep coming back to is simpler than I expected.

Parallelism has a ceiling. When there are many independent tests, parallelization is trivial — each agent picks a different failing test. But monolithic tasks break down. Carlini's agents all hit the same Linux kernel bug, fixed it, then overwrote each other's changes. Multi-agent shines on decomposable work. For one giant task, you're back to single-threaded.

Less structure often wins. Cursor initially built an "integrator" role for quality control and conflict resolution — it created more bottlenecks than it solved. Workers could handle conflicts themselves. "The right amount of structure is somewhere in the middle."

The multi-codebase question: I initially thought Agent Teams would shine for tasks spanning multiple codebases with different constraints. But polyrepo architectures may be becoming antipatterns in the AI era. Monorepos work better for agents — consolidated context means one agent can understand how subsystems interact. Splitting repos fragments the context that makes agents useful. The winning pattern might not be "multi-agent across repos" but "consolidate repos so single-agent has full context."

Test quality becomes everything. Carlini's key insight: "Claude will work autonomously to solve whatever problem I give it. So it's important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem." Your job becomes writing tests so good that agents can't game them.

Model choice matters for long-running work. Cursor found "GPT-5.2 models are much better at extended autonomous work: following instructions, keeping focus, avoiding drift." Opus 4.5 "tends to stop earlier and take shortcuts when convenient." Different models for different roles — they use the best model per task, not one universal model.

If you're not comfortable with 3-5 parallel agents and some chaos, don't use any of this. Single-agent Claude Code with Plan Mode handles most work. Add complexity when you hit real limits, not theoretical ones.

The native approach will improve. Anthropic will add session resumption, better persistence, more coordination options. The community tools will adapt or die. But the fundamental tension remains: native is convenient, external is controllable. Pick based on whether you need to understand what's happening or just need it to happen.