What Won't Change
The way I (and many others) interact with technology is unrecognisable from a year ago. I covered the specifics in my last post on my AI stack, but the short version is that I speak most of my instructions now, there are usually a few agents running on different things at once, and more of my day than I'd have guessed goes on deciding what to hand off and checking what comes back. Not much of that was true a year ago, and some of it wasn't true six months ago.
If you build products, though, what exactly are you designing for? I can see roughly two answers, and the gap between them is what this post is about.
The first is to build for the present. People show up with expectations shaped by the last generation of software, and you meet them there, using AI to make the familiar workflows better. Call it satisficing: one foot in the old world of conventions, one in the new world of capabilities. Copilot inside Word is the obvious case - a lot of the working world still reviews documents in Word, and probably will for a while yet, so it was a perfectly sensible thing for Microsoft to build. I'll come back to that.
The second is to reason from first principles about what people will actually need to do in five or ten years, and build for that directly. People call this "building the future", which is a cliché, but it does pose a serious epistemic problem: how could you know? Predicting technology has a famously bad track record, and the current pace only makes it worse.
Invariants
The way to make it tractable, I think, is to anchor on the one component of the system that doesn't change: the human. The tools turn over monthly, whereas our cognition and biology are stable (er!). So any constraint that comes from the human side of the interface is effectively fixed. These are the invariants. They're what you can build against, because a claim about an invariant is less a prediction than a boundary condition: whatever the future ends up looking like, it still has to fit the human using it (well, we will see about that… let's take it as an assumption of this post).
The first invariant I'd conjecture is intent. However good AI gets, you still have to get what you want out of your head and into the system, and for real work that "what you want" is usually detailed. That transfer never goes away, and if anything it grows, because the better the executor, the more the work shifts from doing the thing to specifying it. Humans long ago settled on a high-throughput channel for this: speech runs at something like triple typing speed and asks almost nothing of you physically. Wispr Flow saw that in 2023 and built essentially a single feature aimed at exactly that invariant. The bet is orthogonal to model quality, which is what makes it durable: it pays off more as the models improve, not less. (The real endgame is presumably something like Neuralink… which sounds mildly apocalyptic written down, but for this decade the mouth looks like the interface to beat.)
Attention is likely another. AI takes time to do things, and sitting idle while an agent works feels wasteful, so you run a few at once, and then your own short-term memory is the binding constraint. I'm over here, now I'm over there, now what was the first one doing again? Anyone who has run several agents will recognise it. Whoever makes that manageable is building on an invariant too, not a convention.
Learning from History
You don't have to work these out from an armchair, either. Humans have been organising complexity around their own limits for a very long time, and the constraints left marks everywhere. No company gives one manager thirty direct reports, at least not where the work needs real supervision; the span of control sits around seven, across industries and centuries, which is attention made visible in an org chart. The whole apparatus of résumés, references and probation exists because trust is expensive to build and delegation isn't safe without it. Neither was designed with AI in mind, but both are answers we already worked out to the problem of getting a lot done with humans as the limiting component. So when AI tooling starts landing on similar shapes - an orchestrator agent supervising a handful of subordinates, say - I doubt anyone is copying the org chart. The same limit that produced the org chart, a human with finite attention at the centre, is producing the tooling too. Again, this is one loose example, and I'm sure more are out there.
Which gives you two ways to find invariants. You can derive them from first principles, the way intent fell out of asking what any interface between a person and a machine has to do, or you can read them off the structures we already built, since anything that survived centuries of organisational trial and error is usually an accommodation to some human limit. The conventions of current software are accommodations too, however they accommodate the machines of their era rather than us, which is why they age and the invariants don't.
In defence of satisficing
None of this makes satisficing the lesser mode. Most of the world hasn't touched the frontier tooling, and building good bridges for them is where most of the near-term opportunity is; over-building for the future is probably the likelier commercial mistake, since a product aimed at users who don't exist yet is not a business. The version that seems right to me is to satisfice deliberately: serve the conventions people actually have, and keep the longer-term picture in view while you do, because accommodation only turns into a mistake when it's unaware - when AI gets bolted onto the last generation of systems as if the way people use technology weren't changing underneath it. The two modes answer different questions. If the question is what to build now, build for the present. If it's what using technology will feel like in ten years, invariants are seemingly steady enough to build on.
The full set
What is the full set of invariants, and given them, what does the technology actually look like? That's a more ambitious question. Intent and attention seem to me like two members of the set; I'd guess trust and verification belong as well. Working through the list properly is where I want to take this next. Hopefully I'll write about it soon - we'll see.