Today, when you prompt a model, you write a paragraph of hedging: do this, not that, in this format, and please don't invent the numbers. Once the system genuinely understands the business, you say less. "Close the quarter" is three words, and each one carries dozens of choices you never have to spell out.
In the extreme version, you give the system two words and a shrug, and it fills in the rest.
That only works when something substantial sits behind the shrug. The system needs enough context to fill in what you left unsaid. When you shorten a request that far, you rely on the listener already knowing what you would have said. They have built that knowledge from the last eighteen months of your decisions, your rejected drafts, the customer you told them never to call on a Friday. You ask cheaply because someone has spent those eighteen months writing the decisions down and keeping them current.
You see the same shift in how you write requirements. Engineers spent forty years learning to write requirements down. Their builder could not ask questions.
When the builder can ask, and ask fast, you turn the spec into a conversation that runs alongside the work. You get three questions, two you had not thought about, one that shows your plan is wrong. A competent contractor has always worked this way, and a competent contractor sometimes declines.
People underestimate how much value comes from hearing no early. These systems can do most of what you ask. They can also see that you asked for the wrong thing. When you evaluate one, test the pushback before anything else. Do you want a coworker who pushes back at nine in the morning, before the work is done and the money is spent? Nearly everyone says yes. Nearly all of them mean it for about a week.
When execution costs nothing, you spend most of your time choosing what to build.
The skill you need for that is taste and judgment - a feel for which of the forty possible projects actually matters to the business. You grow it by making decisions and watching what happens, which takes years. Companies have always been short of it, but they used to be shorter of hands.
Every time you delegate, you leave a record of who allowed what, at what cost ceiling, and whether you can undo the action. You send a contract and it stands; you move a meeting and nothing breaks.
Every company that runs these systems well keeps a boring list of irreversible actions, each with a named human beside it. We talked about AI safety for a decade, and that list is what we built.
You hand software the task. The person who wrote the scope and the person who approved it still carry the responsibility. Now you have the scope in writing.
You will write that file in a house style. We will invent vocabulary for this: budgets, scopes, escalation paths, sign-off gates. You will talk to the system the way you talk to a general counsel: exact about authority and limits, careful about what goes on the record and which calls are yours to make.
You learn delegation one way: you hand work to someone, watch them do it differently than you would, and decide whether the difference mattered. Most of us are getting our practice now, on small tasks, with systems that are nowhere near general. The habits we build on small tasks are the ones we will carry to larger ones. The habit nearly everyone is building right now is approving output without reading it.
These systems keep getting better at what we ask. As they do, we reveal more about ourselves through the asking, because that is what people read. Which projects you funded, which formats you insisted on, which customers you protected - you lay out your actual authority structure and actual priorities in your requests. You also reveal your values by what you refuse to do. When you delegate at this level, you leave your scopes written down.