If you don't write software, here is roughly what a working day looks like now for a lot of people who do. You describe what you want in ordinary sentences — add a login screen, make the export handle empty files — and an AI assistant writes the code, runs it, fixes what it broke, and hands you the result a minute later. It is not a demo. It is most of a Tuesday.
The obvious conclusion is that everyone is enormously faster. The obvious conclusion is where it gets interesting.
The part nobody mentions
Writing the code was never the whole job. Someone has to decide whether the code is right — whether it does what was meant, whether it quietly broke something three files away, whether the approach will still make sense in six months. That step used to be nearly free, because you had already read every line as you typed it. It came bundled with the writing.
Now the writing is close to instant and the checking is not. Whatever the assistant produces still has to pass through one human, at human speed. The work didn't disappear; it moved to the end and piled up there. Teams find themselves finishing more and shipping about the same, and the reason is sitting in a queue of things nobody has looked at yet.
Why it doesn't feel that way
This is the part we find genuinely uncomfortable, and it isn't carelessness. A good assistant doesn't just hand you code — it hands you evidence of diligence. It lists the edge cases it thought about. It runs the thing, watches it fail, works out why, fixes it, and shows you the whole trail. Ask for tests and it writes more of them than you would have bothered with, and they pass. And debugging is exactly the sort of work that takes years to get good at: patience, a feel for where things go wrong, the discipline to check the boring possibility first. Watching someone do that competently is persuasive, and it should be — which is why the obvious reply to all this is that the bugs are going down too, and anyone still struggling is holding it wrong.
Some of that is true. What it can't do is check itself from outside its own reading of the request: the code and the tests come from the same understanding, so when the understanding is slightly off they agree with each other and everything passes. A green test suite says nothing you thought to check is broken. That is worth a great deal, and it is not the same claim as the work being right.
Underneath is something older than any of this. When somebody else takes on the tedious work, we trust and stop looking. That is what delegation is, and most of the time it is correct — which is precisely why the exceptions get through. The gaps that survive aren't the ones nobody checked. They're the ones that were checked, plausibly, by someone working from a slightly wrong idea of what was wanted.
Each individual task really does go faster, and that's what you feel. What you don't feel is the reading now stacked at the end of every one.
And it gets subtler as the models get better, not simpler. A weak assistant fails in obvious ways — nonsense function names, code that won't run — and obvious failures are safe, because you catch them in seconds. A strong one produces something that reads well, matches the style of everything around it, and is wrong in one place you had no particular reason to look. Better models don't remove mistakes so much as make the surviving ones harder to see, while quietly raising your confidence at the same time.
What the assistant can't know
There's a second thing, and it's the one we keep running into. An assistant can read every line of a codebase in seconds — far faster than any of us. But a codebase only records what was built. It has no way to record what was considered and rejected, or which of its patterns are deliberate rules versus accidents nobody has cleaned up.
So the same conversations come back. Something we decided against in March gets proposed again in August, confidently, because nothing in the code says we thought about that and here's why not. That isn't the model being forgetful. The information was never written down anywhere it could be found — it lived in a chat window, and chat windows end.
The shape that keeps showing up
Back in May we mentioned an internal tool called poi — a place beside our code where those things get written down in a form a machine can re-check later. Not documentation, which goes stale quietly and takes nobody with it. Statements specific enough that software can tell you when the code stops matching them.
It's the same instinct as the ontology work and the notebook piece: models do better work when there is something structured to stand on, rather than improvising from whatever they can reach. Different domains, same instinct, arrived at three separate times.
That post ended by saying we'd write more when there was something specific to say. There is a little now — poi has been running against our own work for months, and it recently became something you can install rather than something we describe. We're not making a pitch of it yet. It has been shaped entirely by one workshop's habits, and that is a narrow sample.
Where this goes
For us the next stretch is unglamorous: keep using it on real work, and find out which parts survive contact with people who aren't us. Our guess is that most of what we believe about this is a local habit wearing the costume of a principle, and the only way to tell the difference is to hand it to someone with different habits.
For the field, we genuinely don't know. The tooling for writing software has moved further in three years than in the twenty before it, and the tooling for deciding whether the writing was any good has barely moved at all. That gap might close from the direction everyone expects — assistants that check their own work convincingly enough that the question stops mattering. It might not close, and we all get slowly better at reading things we didn't write. It might turn out that the useful unit was never the code at all, but the decisions around it, and the code becomes the cheap part it already half is.
We don't have a view worth defending on which of those happens. We mostly wanted to put the odd part on the record while it's still odd: the bottleneck moved, it moved somewhere hard to feel, and the tools improving makes it quietly harder rather than easier. If that stops being true we'll say so here.