Blog — a quiet feed of things i've been thinking about, mid-flight.

My instinct is to automate every operation I encounter, then build the infrastructure required to make it dependable. But physical businesses expose a fundamental limit: AI can run their workflows, but it cannot enforce rules when people refuse to cooperate.

Take a gym as an example. A new member could walk in, talk to an AI agent, choose a plan, sign the waiver, pay, and receive an access pass. The same agent could handle freezes, renewals, and most support requests. A remote employee could pick up the handful of cases that go wrong. None of this requires a person to sit at a desk all day.

Still, I would not expect many gyms to remove that person.

Lately I've been wiring agents together using the same harnesses I use every day. One agent plans, a few others execute, one reviews, and I sit somewhere in the middle nudging things along. It works. It also gets confusing fast, and the models aren't the ones getting confused. I am.

Every message lands in the same chat box. A request from me, a status update from a sub-agent, a "please clarify" from the agent supervising this one, a note from a sibling agent, and a CI failure all look the same: a line of text in one long scroll. After twenty minutes I can't tell who asked for what. The agent can, since it has the whole context and can work out who said what. But I'm the one supervising this, and I end up reconstructing it by hand.

One fix is to have the agent build me a picture, using tools to draw who sent what to whom. That works, but it's a patch on top of the mess. The cleaner fix is to never mix the streams in the first place. Give each kind of communication its own channel, one I can read and audit on its own.

I build reminal, a tool for reaching your terminal from your phone. The natural next feature seemed obvious: reminal new machine. One command, a cloud VM appears, you own it, it shows up on your phone, you tear it down when you're done. Spawn boxes like you spawn tabs.

Before writing the provider integration I sat down to check whether the thing actually made sense for the people who'd use it. It turns out it makes overwhelming sense for one group, no sense at all for another, and — the part I didn't expect — the two groups want architecturally opposite things.

The intuition is clean: hand a company a technology that makes work faster and cheaper, and the output gets faster and cheaper. Margins fall to the customer. The tool that took a week takes an afternoon, so the thing that cost a hundred dollars costs ten.

That is not what happened. AI landed on the software industry, and my software got more expensive. Every product I already paid for grew an "AI" line item. The note-taker, the email client, the design tool, the CRM — each one now has an assistant I didn't ask for, on a new tier I didn't want, at a price that only goes up.

Here's the thing nobody says out loud: a productivity tool doesn't force you to pass the productivity on. Cheaper-to-build is an input. What the company does with that input is a choice, and the default choice is not to clean up — it's to add.

Git is one of the best pieces of software ever written. Branches let you try an idea without touching the real thing. Every working copy is a fully isolated world. Nothing is ever really lost — the history is a perfect, total undo. If you sat down to design the ideal system for changing things without fear, you would land somewhere very close to Git.

And almost nobody who isn't an engineer will touch it.

The usual story is that Git is too powerful for normal people — that designers, founders, and PMs need something simpler. We think that story is exactly backwards. Git isn't hard because of its power. It's hard because of its words. "Detached HEAD." "Stash." "The index." "Rebase." These aren't hard ideas wearing plain names; they're plain ideas wearing hostile names. The power is fine. The vocabulary is a language test at the door.

There's an old puzzle about why water, which you'd die without, costs almost nothing, while a diamond, which does nothing for you, costs a fortune. The answer is that price never really tracks how much a thing matters. It tracks how short of it you are. Water is everywhere, so nobody pays for the next glass; diamonds are rare, so people pay through the nose for the next stone. Important and expensive quietly come apart, and once you notice that, you start seeing it everywhere.

You especially start seeing it in the way people talk about AI.

For as long as software has existed, the expensive part was the doing — actually sitting down and building the thing. Engineering hours ran out before anything else did, so that's what the whole market learned to price: the salaries, the headcount, the job itself. Building was the water we were perpetually short of, and being short of it was the entire reason it cost what it did.

There's a split forming in how people use software, and it's easy to mislabel. On one side, the people who mostly chat (great agentic interfaces like Claude Code) — a blank box, a sentence, and the machine does the thing. On the other, the people who mostly click — buttons, menus, forms, maybe a chatbot tucked in the corner as a fallback. It looks like a fight about interfaces. It isn't. The real axis is who holds the model of the task.

Chat-first people carry the task model in their own head. They know what they want, they can say it in words, and they treat the AI as a general-purpose executor. To them the blank box is freedom. But it only works because they already know what's possible — the box has no affordances, no map. It rewards the fluent and strands everyone else.

UI-first people need the software to hold the model for them. Buttons and menus are a discoverable answer to "what can I do here." A chatbot bolted into the corner is what you reach for when the map runs out. To them the blank box isn't freedom, it's anxiety — the blank box problem: cursor blinking, and no idea what to type.

For twenty years the laptop was where work happened because work was typing. Long documents, long code, long emails — high-bandwidth output that a thumb keyboard couldn't keep up with. The phone was for consuming: read, scroll, reply in a sentence.

Agents invert that. When a harness is doing the drafting, the searching, the refactoring, the scheduling, my job collapses into a much narrower channel: decide, clarify, approve. And that channel fits in a pocket.

Watch what the work actually becomes once an agent is in the loop. It's "yes, ship it." It's "no, the second option, and keep the tone." It's "explain why you picked that library." It's reviewing a PDF it generated, tapping a link it surfaced, signing off on a plan. None of that needs a 16-inch screen and a mechanical keyboard. It needs presence — me, available, deciding — and a phone is the most present device I own.

SSH was designed in 1995. It quietly assumes you own a static IP, a router you can reconfigure, and the patience to keep keys rotated. None of that describes a laptop on hotel Wi-Fi, a home machine behind a consumer router, or the phone in your pocket.

So I built reminal — short for remote terminal. The whole tutorial is one word:

reminal

When people switch from modify-in-place to regenerate-from-scratch, the question of how you keep quality up comes back fast. The reflex is to reach for review — read the change, decide if it's good. But review and evals are answering different questions, and the difference matters more than it looks.

The distinction isn't human vs. machine. It's what gets inspected.

Review looks at the change — the diff. "Given what existed, is this modification correct?" It depends on the diff being small enough to hold in your head. Reviewer (human or AI) reads the patch, not the whole artifact.

LLMs are built on one view of language: predict the next token from the previous ones. That's language as information transfer — the words, stripped from the doing and the feeling. The surprise of the last few years is how far that gets you. The more interesting question is where it stops.

The info-transfer view was always thin. "He died," "he passed away," "he's gone" carry the same content and do very different things — form leaks into ordinary prose, not just poetry. Wittgenstein put it sharply: language isn't one thing. It's many games — joking, ordering, praying, greeting — each with its own rules. Asking "what does language really do?" is the wrong shape of question. It does dozens of things, and which one is operating depends on the game.

LLMs handle the games that live in pattern. Borrowing Jakobson's vocabulary: the referential function (describing the world), the metalingual (defining, translating), the poetic-as-form (rhyme, rhythm, wordplay — patterns are what they learn). Those they do startlingly well. The games that stay hollow are the ones the info-transfer view ignored.

A self-driving car has a problem no human driver has: everyone on the road knows it will yield. At a four-way stop, in a merge, at an unprotected left — the rational bad actor edges in, because the car won't fight back. The safer the policy, the more it gets bullied.

You can try to fix this in the model. Make the planner more assertive, learn social negotiation, simulate eye contact. This is the hard road, and it trades the thing you bought autonomy for — predictable, conservative behavior — to get back something a sixteen-year-old already has.

Tesla's insurance is the other road. If you cut off a Tesla, the car remembers. The footage exists. The claim writes itself, and the bad actor is the at-fault driver against a defendant with perfect evidence and a lawyer on retainer. The car didn't have to get more aggressive. The cost of bullying it went up.

Most of the production agent work I do isn't really about the agent. It's about the harness — the boring stuff around the model that makes a thousand customer-shaped failures recoverable, observable, and cheap.

A model that's 95% correct in a notebook becomes 0% deployable without a harness that can: time out a runaway tool call, retry an idempotent step, fan out work, surface intermediate state to a human, and roll back side effects when the plan changes mid-flight.

The interesting research question of 2026 isn't "can the model do it." It's "what's the smallest, most legible scaffolding under which the model can do it the same way twice."

I sat a 10-day silent retreat in 2025. I came home and wrote nothing for a week, and then I wrote too much, and then I forgot most of it.

The line I keep coming back to a year later: most of what I call "thinking" is reaction with a longer time-constant. Watching the reaction without grabbing it doesn't make it go away. It just stops compounding.

The work hasn't stuck. The pointer has.

At Shram in 2024 we were the 800th Jira competitor. The pivot — into AI assistants when the space was very new — was the entire company.

Three things I'd tell past-me:

First, the pivot isn't a feature change. It's a customer change. If your old user can still use the new product, you didn't pivot, you added a tab.

A forward-deployed engineer is not a consultant. The job isn't to draw an architecture diagram and leave. The job is to embed in a customer's codebase, ship the thing that has to ship this quarter, and walk out leaving behind code their engineers will not delete the day you leave.

The hardest part is restraint. You can see the ten things you'd refactor. You ship two of them and write a doc about the other eight. The two you ship are the ones that have to be there for the next FDE to land softly.

Today I'm sixteen years into writing code. The first program ran in Visual Studio in 2010. I was thirteen. It printed a number and felt like a magic trick.

The trick has gotten more elaborate. The feeling hasn't changed.