What the human is for

The best model I can run today, Claude Fable 5.1 with the effort turned all the way up, is better than I am at almost everything I do for a living. It writes cleaner TypeScript, reads a stack trace faster, and holds the Firebase docs, the Expo docs, and the App Store review guidelines in its head at once. When I sit down with a bug, my expectation is that the model finds it before I finish reading the file.

Once you accept that, the useful question appears. If the model is better at the work, what is the human for? My answer, after a year of shipping this way, is that the human keeps the model honest, and that this is an engineering job with its own tooling.

Where the model fails

The list of things the model does badly is short, and the top item is knowing when it is wrong. Ask whether the fix worked and it says yes with the same confidence whether it ran the tests or imagined running them. Ask why users churned and it builds a clean story from the first number it sees.

A concrete case from August. Pool Pilot had an alarm that fired when a user's saved calibration came back empty, and it had fired 23 times. The model traced the alarm to users losing their anonymous accounts, declared the root cause found, and wrote it up as confirmed. A second model from a different vendor, given the same evidence, noticed that the alarm wrote and read a key scoped to the very account ID it was supposed to watch change. If the ID changed, the check looked up a key that had never been written, found nothing, and stayed silent. The alarm was structurally incapable of seeing the one thing it was built to see. Twenty three alarms, zero information. The finding was retracted.

The second model had a different training distribution and no stake in the first model's story, and that was enough. The failure mode is confident narrative. The counter is procedure.

Honesty as a system

I used to treat this as a prompting problem. Tell the model to verify, tell it to be careful. Instructions turn out to be suggestions, followed sincerely and inconsistently. What works is mechanism, and most of mine lives in a harness I run every session inside, called LifeOS. Three of its parts do most of the work.

First, every task starts with a written definition of done, a list of claims where each claim names the check that would falsify it. A claim closes only on evidence of the right kind. A file change needs the file read back, a deploy needs a probe against the live URL, a change to a screen needs a screenshot from a real browser. "Should work" is a banned phrase, and a hook flags it when the model writes it anyway. None of this makes the model smarter. It makes the model's claims cost something, and claims that cost something are true far more often.

Second, the harness remembers. What a session learned, including the corrections I made and the probes that failed, is written down and loaded into the next session. The model starts each task already knowing which rocks it looked under last time and which ones hid something, so each turn improves the odds on the next one. The August retraction is now a note the model carries into every Pool Pilot session.

Third, it attacks its own work. Before anything that touches money, sign in, or user data ships, a fresh model with no memory of writing the code gets the diff and one instruction, which is to break it. In July that review found a usage recording path in ParrotPadMD that mirrored another one closely enough to hand out unbounded credit. A month later the same kind of review flagged a subscriber exclusion bug in an email tool, and when I checked the actual documents the bug was imaginary. Both outcomes matter. The review is cheap, the author always defends its own code, and the human checks the reviewer too.

Telemetry closes the loop. Every app writes events, and the events are the ground truth the model has to answer to. When it says a feature works, the events say how many people used it and how many hit an error. Every "is it working" question routes through numbers the model gathers but has no say over.

Why a customer should care

People are going to assume, correctly, that most software is now written mostly by models. The question they will ask is the one they have always asked. Can I trust the person behind this? The answer used to rest on craft. Now it rests on whether the person behind the model knows how to get the truth out of it. Which numbers to wire up so it can fool neither of you. When a beautiful explanation is too beautiful. How to red team your own product with a model that would enjoy embarrassing the model that built it. That is the skill, and it is what I want a customer to hear when I describe my work.

On never hiring anyone

People who know I run a small software company on the side ask when I will hire someone. Probably never, and the reason is the shape of the work. Everything the company does happens on a screen. Code, design, copy, support email, store listings, ads. The model does each of those today at a level I could never have afforded to hire, at two in the morning, and it improves every few months. The first hire would have been a developer, and that hire already showed up.

I suspect this is a preview of something wider. If one person with a set of models can run a company, a lot of people will, and everyone running their own business starts to look like a plausible default. A world like that needs a floor under it, something like a basic income, and I hope it arrives alongside. What stays with the human either way is accountability. I sign the privacy policy. I take the call from the physician whose dictation failed. I decide a feature is a bad idea even though it would sell. Those were always going to be the founder's jobs.