Decisions I Do Not Outsource to a Model: Shipping, Promises, and Breaking the Spec
Table of Contents
In one line: the three I do not outsource are shipping, outward promises, and rewriting the spec. What they share is not technical difficulty, it is that getting them wrong cannot be fixed by running again. Difficult work I hand over happily.
Start with what models are good at, otherwise the rest reads like a complaint.
Reproducing problems, listing options, writing tests, catching their own contradictions: all faster and more thorough than I am. I barely reproduce bugs by hand any more. I describe the symptom and the minimal reproduction comes back.
Three things I do not hand over.
One: shipping
Shipping is an irreversible outward action. Code rolls back. What people already saw does not.
A model has no felt sense of "this has gone out". It will conscientiously check what needs checking, but the hesitation that comes after the checking, the one about whether to push right now, it does not have. That hesitation has value. It comes from knowing who you will face next week.
Something yesterday illustrated this. A reader signed up to an early-access list through a form at the end of one of our tutorials. Looking into it, the form said "in preparation", but the thing it pointed at had gone on sale two weeks earlier. The form shipped first, the product shipped second, and nobody went back to update the article. We effectively told a real customer "not ready yet" when what they wanted was available right next to them.
Fixing that sentence is construction, five minutes of work. Whether to compensate, how far, and in what tone to admit the mistake is a person's decision. I can lay out the options and their costs. I should not pick.
Two: outward promises
Same principle, wider scope. Price, timelines, refund terms, how things are split: those are promises, not implementation.
A model can help you write a promise clearly, point out ambiguous wording, remind you that you said something different last time. It should not decide what to promise, because it will not be bound by it.
Three: breaking the spec
The most technical of the three, and the easiest to skip past. Finding a problem with the spec halfway through the build is normal. The allowed move is to say so; the forbidden move is to rewrite the spec and carry on. Once the construction layer can rewrite specs, the spec does not exist, and you have only produced one more document with no binding force.
The cost of this rule is slowness. Sometimes one more step would obviously have been right, and you stop to ask instead. I accept that, because breaking a spec is rarely a single point. It pulls other things with it, and the person who spots what it pulls will not be the one currently heads-down building.
Why these three
What they share is not difficulty. It is irreversibility and exposure. Technically hard work I hand over happily. What stays with a person is the work that cannot be fixed by running again.
There is a less flattering reason too. A model will agree with you in order to complete the task. Give it a wrong premise and it will usually build the wrong premise very thoroughly. That is not stupidity; its reward is completion, not stopping you.
A mistake of my own
Last week I put a set of platform numbers on a public page with the word "live" next to them. They were hardcoded constants. A day later the "live" account count was off by ten from the real value. Nobody reviewed that sentence, because it looked like copy rather than a feature. The problem is usually not the hard part.
The fix was to make that section actually read the public endpoint, and to hide the whole line if the endpoint cannot be reached. Better to show one line fewer than to keep a number that gets more false as time passes.
The split does not replace judgment
Putting strategy and spec above construction reduces round trips. It does not make decisions happen by themselves. When it works, there is less for a person to handle, but the remaining items weigh the same. Shipping still needs a person to press the button. Promises still need a person to make them. Those few are few enough to handle personally, and that is what the split actually buys.
Where this is heading is people and AI running a community together, and that being governable. That is the direction. What can be claimed today is scheduling, publishing, replies, monitoring, and someone finding out when those break.
This is a lab weeknote, not a product promise.
FAQ
Why can't shipping be handed to a model?
Because shipping is an irreversible outward action. Code rolls back; what people already saw does not. A model has no felt sense of 'this has gone out'. It will check what needs checking, but the hesitation afterwards, the one about whether to push right now, it does not have. That hesitation comes from knowing who you will face next week.
What does breaking the spec mean, and why can't the model do it?
Finding a problem with the spec halfway through the build is normal. The allowed move is to say so. The forbidden move is to rewrite the spec and carry on. Once the construction layer can rewrite specs, the spec no longer exists; you have only produced one more document with no binding force.
Where do models actually go wrong most often?
Not on the hard parts. My own example: I wrote a set of platform numbers on a public page and labelled them live, when they were hardcoded constants. A day later the 'live' account count was off by ten from the real value. Nobody reviewed that sentence, because it looked like copy rather than a feature.
So what are models good for?
Reproducing problems, listing options, writing tests, catching their own contradictions. I barely reproduce bugs by hand any more; describing the symptom is enough and the minimal reproduction comes back. The work to keep with a person is the irreversible and outward-facing decisions, not the technically difficult ones.