Give a capable model a well-defined project and it can carry it from approved proposal to a result the client signs off on, with barely any help along the way. I’ve watched this happen on real work. You define what’s needed after the meeting, hand it over, and days later there’s something that passes acceptance. The first few times, it’s genuinely startling.
So the interesting question stopped being “can it?” Most of the time, it can. The question became “at what cost?”
Free-Running Is the Expensive Way to Build
Left to run on its own, a model fills every gap you left open with a guess. Some guesses are good. Many aren’t, and you don’t find out until you’re looking at the result and realizing it went a direction you never intended. Then you correct it, it redoes the work, and that costs another round. Multiply that across a whole project and the bill arrives in two currencies: tokens, and your own time spent babysitting the back-and-forth.
The end result is usually fine. It got there. It just took the scenic route, three wrong turns and a dozen clarifications a tighter brief would have made unnecessary. The model was capable the whole time. What it lacked was direction, and I was the one who hadn’t given it.
That reframe is the whole thing. The model was intelligent enough all along; the limit was how well I’d defined and constrained the work I handed over.
Delegating and Directing Are Not the Same
Most people, me included at the start, treat AI as delegation. You hand over a goal and hope what comes back matches what was in your head. Sometimes it does. The more open-ended the goal, the more it’s a coin toss, and the more expensive the misses get.
Directing is different. You still let the model do the work, all of it, but you decide the shape first. You break the goal into pieces small enough that there’s little room to wander. You give it the access it needs and nothing it doesn’t. You put gates at the points where a wrong move is costly or hard to undo. And you write down, once, how things get done, so you’re not re-explaining it every session.
All of that leaves the model exactly as capable as it was. It just removes the guessing.
What Directing Looks Like When You’re Building Software
On the dev side this has a concrete shape, and it’s the line between what people call vibe coding and what I’d call AI engineering.
Tight requirements come first. A clear statement of what “done” means for this specific piece, edge cases named, rather than a paragraph of vibes. Vague in, vague out.
Then you break the work down. I use Linear or GitHub issues to cut a project into small units, each with its own scope and its own branch. A model working on one well-defined issue on its own branch has almost nowhere to go wrong. Hand it the whole repo and a paragraph of intent and it has infinite ways to surprise you. Small units also mean a bad result costs you one branch instead of the project.
Credentials and permissions get set up on purpose. The model gets what the task needs, keys, endpoints, the right tools, so it isn’t blocked or improvising, while access to the irreversible stuff stays behind a gate.
Those gates matter more than anything else here. You pick the points where the model has to stop and check with you: before it sends anything outward, before it deploys, before it deletes or overwrites, before anything you can’t easily undo. Everything up to the gate runs unattended, which is what makes it safe to let an agent work while you sleep. The gate is what lets you hand over real autonomy without handing over the power to do real damage.
Underneath all of it sits a handbook. A written record of how we do things here: code style, how we name and structure work, how often and in what tone we communicate, which tools we reach for. In practice it’s a file the model reads at the start of every session, and in my case every agent I run loads the same one. Write it once and every future run inherits it, instead of you re-teaching the same preferences forever.
That collection, tight scope, small units, deliberate access, gates, and a handbook, is what separates typing prompts and hoping from engineering a system that produces reliable work. Same model in both cases. Completely different economics.
When Letting It Run Free Is the Right Call
Plenty of work needs none of this. For a throwaway script, a quick exploration, a prototype I’ll look at once and discard, letting the model run free is exactly right. The overhead of scoping and gating would cost more than the mistakes it saves you from.
Direction earns its keep when the work is real: client work, anything going to production, anywhere a wrong turn is expensive, anything you’ll run more than a handful of times. The skill isn’t putting rails on everything. It’s knowing which work needs them and which doesn’t.
The Same Jump Exists for Everyone Else
If you run a business on ChatGPT or Copilot, you’ve been doing the delegation version. You paste in a task, get back something plausible, tweak it in the chat box, and after a while you hit a ceiling. The tool helps, but it never delivers the payoff you were sold. Most people conclude the model isn’t good enough yet.
It usually is. What’s missing is everything around it. The professional version of that same task is a harness: the job defined tightly instead of typed casually, your real tools and data wired in so the model acts instead of just advising, gates so it does nothing costly while unattended, and a handbook so it works the way your business actually works. Run as an agentic workflow, that’s the gap between a chat that saves you ten minutes and a system that runs a whole process for you.
The model in the chat box and the model in the harness are the same model. The entire difference in what they produce is the scaffolding around it. That’s the jump from using AI to having AI built for you, and it’s every bit as big as the vibe-coding to AI-engineering jump on the dev side.
The Ceiling Is Almost Always Yours
When someone tells me AI didn’t really work for their business, it’s rarely the model that fell short. The model was handed vague goals, no access, no guardrails, and no context, and it did about as well as anyone could under those conditions.
That’s good news, because it means the ceiling isn’t fixed. It moves the moment the work gets scoped properly, the tools get connected, and the guardrails go up. You can learn to do that yourself, and a lot of it is learnable. Or you can bring in someone who does it for a living and skip the expensive stretch where you discover all of this by running up the token bill.
Today’s models are already more capable than most people’s use of them. The constraint sits with the person directing the work, which is the same as saying it’s yours to move. Building the harness that turns a capable model into a system doing real work on rails is most of what I spend my time on now. If your own experiments with AI have stalled, that’s usually where they stalled, and it’s fixable.
Related
Leave a Reply