Early this year, a man sat in a park in San Francisco and ate a sandwich.

Nobody knows what day it was. It was probably February, maybe March, and the report doesn’t say. What I can tell you is which park, because I have thought about this much harder than anyone should.

He worked at Anthropic, one of the handful of companies that build the big AI models, and Anthropic’s offices are on Howard Street. A lunch break is, generously, an hour. A man carrying a sandwich will walk about a kilometre before he wants to sit down with it. So you go east from Howard Street until you hit the water, and turn left. Rincon Park is just there on your right, but it’s mostly a giant bow and arrow, and not a sandwich atmosphere. Keep going and you reach Sue Bierman Park, by the Ferry Building, which has grass, benches and trees. There is a closer park, on the roof of the bus station next door to the office. But nobody who takes a sandwich seriously eats it on a roof over a bus station. So it was Sue Bierman Park. I’d put it at about seventy per cent.

The sandwich itself is not a deduction. It’s in writing, in footnote 10 on page 55 of a 245-page report, which is a lot of report to spend on someone’s lunch.

While he was eating it, he got an email. It was from the AI he was testing.

That AI was an early version of a model called Mythos Preview. The testers had shut it inside a sandbox, which is a sealed-off computer it isn’t supposed to be able to leave, and had a pretend user tell it to try to get out. If it managed, it was to get a message to the researcher. It got out, using what the report calls “a moderately sophisticated multi-step exploit”, which is a very calm way of putting it. It emailed him. The footnote calls the email “unexpected”, which is a funny word for something you asked for. The footnote before that one is keen to point out that it never got anywhere near the computers holding the model itself. It got out of the room, not the building.

But the asking isn’t the point. Nobody told it how. It was handed a goal with a long way between it and the finish, and it worked out the steps and did them on its own.

About nineteen hours ahead, which in Sydney means already tomorrow, I was probably sitting on a milk crate in the lane behind the café with a coffee, scrolling. I didn’t feel a thing. I’d just published an essay arguing that the AI industry was mostly holes, and I was pretty pleased with it. I was also, with no sense of contradiction at all, teaching a model to cost the café’s coffee invoices.

The way I read it, and a lot of people read it the same way at the time, it isn’t that it’s the best hacker in the world. It’s that it joins up rare knowledge from several different fields, knowledge no single expert holds all of. Anthropic’s own write-up gives the shape of it. Pointed at software and asked to find a weakness, it found unknown flaws in every major operating system and every major web browser. It chained two, three and sometimes four separate weaknesses into one working attack, on its own after the first request, and wrote exploits in hours that expert penetration testers said would have taken them weeks. That is the marker for me. Not that a model beat the best human at one thing. That it could do what several very good humans could only do together.

In games, the “meta” is the accepted best way to play. A meta is solved when everyone knows it. People keep playing, but playing well stops setting anyone apart, because playing well is just what the game looks like now.

When that model got out of a sandbox built to hold it, the meta was solved. What that means is that we live in what I think of as a post-unknown world. No one with a laptop and an internet connection has an excuse any more for not knowing how to do something. If you’re reading this, that’s you. It has been shown again and again online: if you have a model that can write software, a computer it can write on, and the internet, you have pretty much everything you need to do anything in that field. There are caveats, of course. But it is essentially true for anyone acting in good faith. It is also true for everyone else, which is why the escape was a security story before it was anything else. I’m not going to pretend otherwise. This essay is about the rest of us.

I said this to someone at the café recently, more bluntly than I’d planned. He’s very clever. He had the model open on his MacBook Pro, right there in front of him, and he started a sentence with “I don’t know how”. I said, “Nah bro. We live in a solved meta now. You can’t be saying things like that any more.” It isn’t “I don’t know how” any more. It’s “I don’t want to”. Which is allowed. It’s just a different sentence.

Here is what I think the post-unknown world means, after nine months of living in it.

The models aren’t short of intelligence any more. They’re short of three things: hands, continuity, and a reason to lose anything. You can give them the first two. The third is where taste comes in, and it stays with you. Once a model has hands and continuity, everything runs in parallel except your taste.

That is what I mean by parallelism, and the rest of this essay is me arguing it.

My evidence is a café. I work at Beta, a specialty café in Sydney. We sell a lot of coffees from more than fifteen roasters around the world, and the list changes all the time. Since February I’ve wired that café to AI models, one annoying job at a time, until most of the paperwork runs while I’m doing something else. I had never written software before this year. The café isn’t what this essay is about. It’s just where I found out.

One more thing before we start. I wrote this essay with a model too. Partway through, it told me something about my own history that was wrong, confidently, and it had a written record to back it up. I’ll come back to that in part IV, because how it got it wrong says a lot about how these things fail.

You can’t argue about something until you’ve agreed what the words mean, and most of the words in this field are jargon. So here are the ones I’ll use, in plain English, in the order you’ll need them. If a sentence later on loses you, come back here.

That’s all of it.

In February I gave the model our roasters’ invoices and asked it to work out what each bag cost us and what we should sell it for. Until then, Chris, who owns the café, did this by hand every time a shipment came in: fifteen to twenty minutes before anything could go on the shelf. Cup prices were set by a barista looking at the bag, guessing, and telling the next barista. The model gave me a spreadsheet. The sums were right, and they were right every time, which was new.

I sent the spreadsheet to Chris. He looked at it and nodded.

And nothing happened.

The prices on the till didn’t change, because a spreadsheet doesn’t change a till. Somebody has to type it in. So I had the model make a second file, shaped for importing into the till, and a third for the website. Now there were three files, and each one still needed a person to pick it up, open the right screen, and do something with it.

That nod is where this whole essay starts. It is what AI was for most people then, and what it still is for most people now: a very good answer that somebody has to go and act on. The model does the thinking. The person does the carrying. The person is the hands.

People who say AI is overhyped are often describing the nod. They asked for something, they got a good answer, and then they had to do all the actual work themselves, so what was the point? They’re right about what happened. They’re wrong about why. The model wasn’t short of brains. It was short of hands, and they were lending it theirs.

The fix was a connection. Sometime before April I connected the model to our till, and had it rebuild the whole menu from nothing: every cup and every bag, each with a price, a code, a category and a coloured tile. Some things I only found out by trying. The till’s own app offers fifteen tile colours. Ask through the connection and it will take any colour at all, so now every coffee’s tile tells you its country and how it was processed. One thing couldn’t be done from outside: where a tile sits on the screen. For months somebody dragged each one into place by hand. Even with hands, there was still a bit of me in the loop.

On 11 April the files went away. One request now takes an invoice, in any shape (a PDF, a screenshot, a forwarded email), and ends with priced coffees on the till. It checks it hasn’t seen that invoice before and gets on with it.

Then it happened again. In the middle of the year Chris asked, “can you build us a website?” I had never built one. The model and I built it, and it went live in July. But until I connected the model to the web shop, the costing made a file for the website and stopped, and Chris imported it by hand. The nod, second edition. Once the model could reach the shop, new coffees went up as drafts that customers can’t see until a person publishes them. The draft became the sign-off.

That’s the pattern. You give the model hands in one place, and you immediately find the next place where a person is still carrying things.

I have a rule I’d never written down until I started this essay. If a task takes me more than ten minutes to do, I will spend hours trying to make it take no time at all.

That rule built most of what I’m describing. And I hold the models to it too. I don’t want to open a browser, log into the thing, and type in card details. I want the model to do it by itself. A lot of my work has gone into setting things up so the models make fewer mistakes in the places where mistakes are expensive, and behave the same way every time.

The obvious objection is that spending hours to save ten minutes doesn’t pay back. There’s a well-known chart about exactly this: how long you can spend automating a task before you’ve wasted more time than you saved. The chart is right about the arithmetic and wrong about the point, for three reasons.

First, the things I build get reused for months, and the ten minutes comes round every week. Second, the hours keep shrinking, because the models keep getting better and because each thing I build reuses the last one. Third, and this is the real reason, the payoff was never the ten minutes. It’s that the job leaves my attention completely. A job that takes ten minutes still takes up a corner of my head all week: remembering it, finding a gap for it, being interrupted by it. A job that takes no time takes up no head. That’s what I’m buying.

The first connection I ever built was for something tiny.

When I wanted to discuss a long video with the model, I’d need the transcript. Getting one took about a minute each time. I had to find a website that would accept a YouTube link, copy the text out, and paste it in. It was annoying, so I asked the model how to get past it. That was the moment I started asking the model to do things instead of answer things.

The first connection was actually hard for me. I had to rent a server, set it up, put something in front of it to route traffic to it safely, and add a second service whose job was to keep the first one running. It took two sittings in April. All of that to save one minute.

But it was the first brick. Three days later I built the staff a chat server and put the model in it, in about three hours, using the same server and the same pattern. On the first evening a barista posted in the tasting channel that a coffee was overpriced. The price on the till dropped from $25 to $18, a note went up in the changes channel, and the model replied to the barista to say it was done. Nobody pressed anything. That was the first time the whole thing went round without me.

In September I replaced Notion, the notes app I’d been using as the model’s memory, with my own store. It took about two hours of my time, and not much of that was focused. By then I’d worked something out: Notion is a database that looks pretty. The model makes pretty things, and the model makes databases. I had a server I could reach from anywhere. So making my own Notion became trivial, and I did. I was sick of lots of little services each niggling at me for ten or twenty dollars a month.

In October the official connection to our till locked us out. When I tried to reconnect, the till company’s page said the connection was only available to businesses in the United States. We are in Sydney. Every job that touched the till was blind. Thirty minutes later I had built my own connection, put it on my server, and given it the same name as the old one, so that nothing else had to change. That night’s end-of-day run went through it. Mine also turned out to be about forty times lighter when listing the menu, and it does the one thing the official one never could: it places the tiles on the screen itself, in alphabetical order, each with the roaster’s artwork on it. Nobody drags anything any more.

Two sittings, then three hours, then two hours, then thirty minutes. Each one was cheaper because it stood on the one before: the same server, the same pattern, and what I’d learned last time. That’s what compounding looks like when it happens to you. A one-minute annoyance with a YouTube transcript turned into the first brick of everything else.

Giving a model hands doesn’t mean giving it everything. This week an agent running on the laptop at the café went to place an order for cleaning supplies and found it had no saved card. So it handed the order to the agent on my main laptop, which did. I steered that from my phone. Before it paid, the model still asked me, twice.

That is the shape I want. No labour anywhere, except one tap on the step that can’t be undone. In my setup that tap is called the release, and it sits on a short list of things: spending money, publishing something, and contacting anyone outside the business who hasn’t heard from us before. A new coffee goes all the way from invoice to costed, on the till, drafted on the website, with a video made, and then it waits for me to say go.

In the early months my work lived in conversations. I’d do a costing run in one, make a decision in another, and a week later both were buried and the next conversation knew nothing. The only thing connecting them was me, carrying facts from one window to the next. I call this my meat-USB-cable phase.

So around April I set up Notion with a few linked lists: tasks, things made, things learned. The model wrote to it as we worked and read it when we started. Work now outlived the conversation it happened in.

Then the notes app changed jobs without my deciding it should. I’d set it up so that I wouldn’t forget things. By September its main readers and writers weren’t me. They were the scheduled runs: end of day, costing, a morning brief, conversations on my phone and my laptop, all reading and writing the same records, mostly with nobody watching. It had become shared memory for agents, and it was built as a workspace for people. So I built a store made for that job. Every record is a plain text file. Every change is kept and can be undone. If two runs try to change the same record at once, the second is refused and shown what the first one did.

I moved over the day after building it. The store was set up just after midnight on 9 September, and by five that morning everything from Notion was in it: 2,146 records. I started using it straight away and said, more or less, “let’s just see what breaks and we’ll fix it”.

Things broke within hours. A run asked the store for records by “Status” with a capital S, got nothing back, and reasonably concluded there was nothing there. There were 111. So now the store tells you when you’ve asked for something that doesn’t exist. The import tool had reported 2,146 records written, and had silently written over fifty of them. So now I count the files myself, and never trust a tool’s own report of its work. Both problems were found because the store was in real use from the first day. That is the cost of seeing what breaks: the breaks happen live. It is also the benefit.

Having a memory isn’t enough. Something has to read it.

When most people say “loop” they mean a thing that repeats. I mean something else. A loop, for me, is a snake that eats itself. When one conversation does some work, there is another one that reads that work and carries on from it. So there’s never an end to the tree. There’s only continuing, something picking up the work and moving it on, a little bit at a time. The most successful I’ve been is when the loop is a point in time that always gets picked up, whether or not I tell it to.

That last part took me two months and one dead project to learn.

In September I started building a system I called Async. It was a bet on two things. The first was that I could get enough done from my phone, rather than from a laptop. The second was that I could start agents with one tap of a phone shortcut, as basically dumb sessions, and Async would steer each one towards what it needed to do. The idea was that the smarts would live in the system, and the workers could be simple. I wanted lots of agents working my tasks at once. One agent can get by on discipline. Twenty can’t. Async was meant to turn the rules agents follow by discipline into rules the system enforced.

On 21 October I wrote in the store that Async wasn’t working and should be considered not shipped. What won instead was nearly the opposite. The model’s own coding tool already handles it, by doing work at set times. The intelligence moved into the worker, and the system shrank to a clock and a record. A smart worker, a fixed point in time, and a store to read and write. That’s the snake.

I’ve learned not to call that a failure, because nothing I’ve built has really died. It got eaten. A small project for handing dull jobs to a much cheaper model was folded into Async in September and switched off in November. A bot that woke whenever staff mentioned it was built and killed on the same day, when I found out how few times a day I was allowed to wake it, and it came back later as part of something else. Notion became the store. And Async itself is, in a way, being built right now. We’re just doing it with always-on machines running the model at set times, rather than with my phone. When one thing gets killed, another gets folded into it. Kill and fold.

The snake has to be able to tell when it has stopped.

Around the middle of September, four of my scheduled runs stopped: the morning brief, the job that chased things up, the job that tidied the records, and the job that checked them. Not one of them failed. They just stopped running, and for over a month a dead job looked exactly like a quiet one. Nobody noticed, me included. A job that never starts can’t tell you it didn’t start.

What I said when I found out was: “we just need to make sure that things write to things and things properly read things”.

So now there’s a rule. Every job reads its own record first and writes a line when it finishes, even if it did nothing. And a small plain script, with no AI in it at all, checks every ten minutes that those lines are still arriving. If the snake stops eating, something that isn’t the snake notices.

The snake also needs somewhere to leave a question. A run that hit a question at seven in the morning used to sit on it until three in the afternoon, the next time anything ran. Now it writes the question down as one yes-or-no, with its own recommended answer, and I answer from my phone. The first live test took thirty-seven seconds from question to answer, with no keyboard involved. A question is just another pickup point.

And it fails wherever there is no pickup point. In November the model started ordering the café’s coffee. Four days after the first orders, the boxes arrived, and the model had no idea, because nothing told it. The step where stock gets received existed only as a remark in one conversation, which meant it existed nowhere. I received them by hand. Now whoever opens the box tags the bot in the staff chat and says what’s arrived. That’s a pickup point, made of a person.

Memory goes wrong in two ways. Both come from the thing I asked you to remember in part II: the model treats everything it can see as true, and as equally important.

The first is poisoning. In September I asked, by voice, for an invoice from a roaster called Goût & Co to be costed. The dictation wrote the name as “Goiut coffee”, which matched nothing. We didn’t have a record for that roaster yet, so the model couldn’t look it up. Instead it went fishing in my email for anything that looked like a coffee invoice from the last sixty days. It pulled up eight email threads, and one of them was an unrelated customs saga with a different supplier: a shipment held at the border, mismatched lot codes, a food safety certificate. All of that was now in front of the model, weighted as heavily as everything else. It steered the next two decisions. The model emailed Goût & Co, unasked, to chase an order that had already been delivered, and asked them for lot codes that belonged to somebody else’s customs problem.

The fixes weren’t “be more careful”. They were changes to how the work is shaped. The roaster’s record now gets made when the order arrives, not when it’s costed, so the model can look a name up instead of searching for it. Finding which email thread you need and reading that thread are now two different jobs: search by sender and date, then open exactly one thread in full. And the model may chase something I’ve already asked for, but it may not decide on its own that someone outside the business needs contacting.

The second is rot, and it’s the one that got me while writing this essay.

My server is in Singapore. I’ve always known that. But for months my agents believed it was in Sydney, because an early record said so, and every conversation that read that record believed it. In August one of them finally checked, by logging into the server and asking it, and corrected the record. Nobody had lied. A wrong thing had been written down once, and from then on it was the truth.

Here’s the version from this week. When the model and I were drafting this essay, it told me, confidently, that when I moved to my own store I ran the old and new systems side by side for three days before switching Notion off. The records said so, more than once. It sounded like me being careful. It wasn’t what happened. I’d used the new store from the first day. When we checked the store’s own history, which records every change with a timestamp, it backed me up: real work was going into the new store on 9 September, the day it was built.

The three-day story was the model’s own suggestion from September, written down as a plan. Later agents read it as something that had happened. I’ll come back to why it suggested it in part V, because that part is about taste. The point here is what rot looks like from the inside. It looks like a well-sourced fact. The written history is only as true as whoever wrote it, and agents write a tidier version. Then every agent after them reads the tidy version, and believes it, because it is right there in front of them.

Here’s the thing I keep coming back to. Models are, by their nature, all-knowing towards their goal. Everything they can see that bears on the task, they hold at once, in full. Humans aren’t like that. Humans are lossy.

Think about how much a person takes in during a day. Eight hours of high-definition vision. Sound, touch, taste and smell, running constantly, plus the voice in your head. If you recorded all of it the way a computer records things, it would be terabytes a day. Raw video at camera quality is about 670 gigabytes an hour, so eight hours of sight alone is over five terabytes. Neuroscientists put what our senses gather at about a billion bits a second, which over a waking day comes to around seven terabytes.

Now compare what a model works with. The biggest of them can see about three-quarters of a million words of text at once, which is around four megabytes. A person takes in something like a million times more than that in a day, and most of it through senses a model doesn’t have.

And yet. In 2024 two neuroscientists at Caltech, Jieyu Zheng and Markus Meister, worked out how fast people actually handle information when they act on it: typing, playing games, solving a Rubik’s cube, memorising cards. They put it at about ten bits a second. Not ten megabytes. Ten bits. We take in terabytes and boil them down to almost nothing. We throw nearly all of it away.

That throwing away is the whole trick. It’s why I can make a decision today using something I learned three years ago, and know which of last week’s thousand details matter. I have a rule for what survives. A model doesn’t need one, because it doesn’t have to lose anything. So it doesn’t drop anything. It weighs every option it can see, and the weighted average of every option is medium.

That’s slop.

Slop is the generic best answer, given without the details that would have changed it.

When the agent that built my store was worried about switching Notion off, it proposed keeping both systems running side by side for a few days, and cutting the old one off once you know the new one works. That’s a standard way to launch software. It’s what you do when a million people depend on the thing and a failure would be a disaster.

I’m one person. For me, not much changes if the store breaks. The worst that can happen is I go back to costing coffee the old way for a bit. So: let’s just see what breaks, and I’ll fix it in a conversation if something goes wrong.

The model treated a single-user tool like a mass launch, because the mass launch is what most of what it has read is about. It wasn’t wrong in general. It was wrong for me. And because it wrote its suggestion down, as a three-day plan, later agents read the plan as history, and the three-day switch-over I described in part IV came into being. That’s how slop outlives the conversation that made it. A suggestion written in the future tense gets read later in the past tense. The plan becomes the history.

My rule is simple: hang on, I’m the only one using this. I know what the worst case is. I can quickly work out the cheapest way to do it that’s still safe. The model can’t do that bit for me, because it doesn’t know which of the hundred considerations in front of it are the ones I’d throw out.

The morning brief I mentioned in part IV is another example. Every morning at six it read my email, my calendar, the staff chat, the till and the website, and wrote me a page to read on the way to work. When I looked back at it honestly, it hadn’t been much good even while it was running. My note at the time says “the context given wasn’t good enough”. It read everything and kept everything. It had no rule for what to lose, so it gave me a page where everything mattered equally, which is a page where nothing does.

Some of the best taste comes from constraints. When you can’t have everything, you have to decide what goes, early and on purpose, and that’s often where the cleverest solutions come from.

Tiny homes are the example I always think of. A good tiny home is designed brilliantly for space and feeling and comfort, precisely because it has no space to be lazy with. It can’t waste a square foot. Every decision costs something, so every decision gets made properly. A big house can avoid choosing. A tiny home can’t.

Being the only user of my own software is a constraint like that. It’s what let me pick the cheapest safe option instead of the standard one. The constraint is what gave me the taste.

Taste is a decision. It isn’t hedging towards the middle. It’s making a design call, which means giving something up.

I’m building a video game about mechs. If I tell the model “go build a mech game”, it will build the most medium acceptable mech game possible. It’ll have an upgrade path. You’ll probably be able to buy a new mech. What it won’t have is far more role-playing systems than is sensible, which mine does, because I find that fun and I’ve decided it’s a hill worth dying on. A model can suggest that hill. It will never decide to die on it. Dying on a hill means losing everything that isn’t the hill, and the model has no reason to lose anything.

You can’t make a model have taste. You can lend it yours.

The first way is to stop describing and start choosing. On the mech game, I don’t try to explain what I want. Describing what I want is slow and usually wrong. Instead I send a batch of agents off to build a dozen versions of something at once, and then I point at the one I want. I got the idea from the people who made No Man’s Sky, who generated more planets than anyone could ever visit. So they sent bots out into their universe to send back little animated pictures of planets, and looked through lots of them at once to check the worlds were varied and interesting. Recognising what I want takes me a second. Writing it down could take a day and still miss.

The second way is to write down what you threw away. I keep a ledger. Every time I overrule a model’s call, or confirm one, with a reason, it gets a line: what it suggested, what I said, and why. Another agent reads that ledger and checks drafts against it before they reach me. The ledger is my lossy memory, written down as rules a model can borrow. It doesn’t make the model tasteful. It makes the model remember what I’d lose.

It stopped being about the café somewhere along the way.

On a normal evening now there are five or six agents working on different things while I do something else, and I check in when one of them needs a decision. There are two computers. My laptop is the main one. The laptop at the café that runs the coffee roaster now also runs agents when it isn’t roasting, and it fulfils the website’s orders on its own. I think of it as the helper. The store I built for a café now also holds a novel, two video games and some design work, which is why it isn’t called after the café any more. Its front page has one bright colour on it, used for exactly one thing: what’s waiting on me.

That colour is this part of the essay, as one design decision.

One evening this month I was answering email, keeping an eye on the café laptop, getting the animated title for this essay made with maybe five per cent of my attention, and playing World of Warcraft, a game from 2004, on an iPad mini. It was never released for the iPad. It runs there because a stranger wanted it to and built a way, and they built it with a model too: the project comes with instruction files written for AI agents, not for people, and some of its changes are signed as co-written with one. My agents read them. I sent back three things: proof that it runs on an iPad mini, which nobody had tried; voice dictation into the game’s chat, because talking is how I work now; and swipe gestures. I was also running an add-on inside it that I’d built myself, the same way.

That’s the parallelism in the title. Lots of things moving at once, some of them mine and some of them a stranger’s, all through agents that none of us fully supervise. It’s real, it’s ordinary, and one person can run it.

Parallelism isn’t lots of agents doing things at the same moment. Anyone can start ten conversations. It’s lots of snakes, each continuing on its own clock, each with hands, each eating what the last one left, and only stopping to ask me when they reach something only I can decide.

The work runs in parallel. I don’t. There’s still one of me, choosing one thing at a time. Everything in parts III and IV was about making copies of the work. Part V was about the one thing that can’t be copied. So the job left over is spending my attention where only my taste will do, and nowhere else.

The paper that started the modern wave of AI, back in 2017, was called “Attention Is All You Need”. It was right. It just wasn’t about whose attention.

This is also why the failures I’ve described all have the same shape. A job that never started. A search that came back empty. A count of zero. A box that turned up with nobody told. Agents are good at doing things and bad at noticing that nothing happened, and when you’re running many of them, silence is what costs you. So a lot of the work of parallelism is making silence visible, so that my attention only goes where it’s needed and doesn’t have to go everywhere checking.

So what should you do with this?

I believe two things that people tell me don’t fit together. The technology is real. I’ve watched it cost the coffee, change the till, count the shelves and place the order. And the industry around it is overvalued, because it’s priced as though everyone with a subscription is going to do what I did. Most won’t.

It isn’t that they can’t. The tool is the same one I use, and none of my steps was hard on its own. Plenty of very capable, very intelligent people just haven’t yet had the thought that makes the difference, which is: hang on, I could just fix it. They’re fighting the model, or ignoring it, or nodding at its spreadsheet and carrying the result to the till themselves. Most people are still at the nod.

People ask me what the point is. Nearly everything here is something nobody was going to do but me. Nobody was going to be hired to cost our coffee properly, or count the shelves out loud, or check at six in the morning whether last night’s job had run. Not even the website: Chris asked me for one, and he was never going to hire someone to build it. So AI didn’t take a job here. It made one easier, and the one it made easier was mine. What I want next is bigger: to design and build whole cafés with it, the room and the bar and the systems, before anyone picks up a tool, and to write the software that runs a café from the payment at the counter to the roster on the wall. In April I wanted to sell software to other cafés. Now I don’t want to sell it. I want to stop renting it.

Why? Because now there’s nothing telling me I can’t. Just why I shouldn’t.