I don't write most of the code that runs across my ventures anymore. I direct it, review it, and decide when it's ready. That's a different job than writing it line by line, and it took me longer than I expected to figure out what my actual standard for "done" should be once I wasn't the one producing every keystroke.
The bar I've landed on: roughly 90 to 95 percent right on a well-specified brief
If I hand over a clear, well-specified brief, the build that comes back should be right on the vast majority of it, the core functionality working, the structure sound, the obvious cases handled correctly. I don't expect, and don't need, perfection on the first pass. What I need is confidence that the remaining gap is small, specific, and findable, not a fundamental miss buried somewhere in the middle of something that looks finished on the surface.
That number isn't arbitrary. It's the point at which my review time gets spent on genuinely valuable judgment calls, the kind of decisions that require actual context about the venture and the user, rather than getting eaten up hunting for basic errors that a clear brief should have prevented in the first place.
Where my review effort should actually go
The parts of a build that deserve my direct attention are the parts that require judgment a brief can't fully specify in advance, edge cases that only make sense in the context of how a real user would actually behave, tradeoffs between two reasonable technical approaches where the right answer depends on priorities only I know, small decisions about tone or flow that are genuinely subjective. That's precision work, and it's exactly the kind of thing I should be spending my attention on, because it's the kind of thing that actually benefits from my judgment specifically.
That's a meaningfully different category from catching a fundamentally broken feature, a form that doesn't submit, a page that doesn't load, a flow that skips a required step entirely. Those aren't judgment calls. They're foundational misses, and if I'm regularly finding those, the problem usually isn't the build, it's that the brief wasn't specific enough to prevent them, or the build genuinely wasn't at the completion bar it needed to be before it reached me.
Why catching foundational misses shouldn't be my job
If I'm the one catching that a core feature simply doesn't work, I've become the quality gate for basic functionality, which is an expensive and unreliable use of the one resource I can't get more of. Foundational correctness should be verified before something reaches me for review, through a clear brief upfront and a real check afterward, not discovered by me clicking through the thing manually and hoping I notice what's missing.
When I catch myself doing that kind of catching regularly, that's not a sign I need to review more carefully. It's a sign that something earlier in the process needs to get better, either the brief needs to be more specific about what "working" means, or the verification step before something reaches me needs to actually verify the thing instead of assuming it's fine.
The brief is doing more work than people expect
A vague brief doesn't just produce a less accurate build, it produces a build I have to review at a completely different depth, because I can't trust that basic requirements were even understood correctly. A specific brief, one that spells out the actual behavior expected in the cases that matter, lets me review at the level I actually want to be reviewing at, judgment and precision, instead of getting pulled back down into confirming the fundamentals.
Writing a genuinely clear brief takes real effort upfront. I've stopped treating that effort as overhead and started treating it as the actual lever that determines what kind of review process I get to have afterward. A better brief buys back my own attention later, which is a trade worth making every time.
What this changes about how I think of my own role
Directing an AI-assisted build isn't hands-off, and it isn't the same hands-on process as writing every line myself either. It's a third thing: setting a clear enough bar upfront that most of the work clears it without me, and reserving my direct attention for the parts that genuinely need a human making a judgment call. Getting that split right is turning out to be a skill of its own, separate from either writing code or reviewing it in the traditional sense, and it's one I'm still actively getting better at.
