Put the Asset to Work

I made the case that your decades of experience are the asset — that with AI coding tools, the scarce input is no longer the ability to produce code but the judgment to constrain it. But an asset isn’t leverage. A warehouse full of inventory isn’t revenue, and judgment sitting in your head isn’t output. There’s a conversion step between the two, and it’s the part nobody walks you through.

Here’s the conversion, stated plainly. Judgment only protects the work you are personally looking at, and the machine produces faster than you can look. So in the nine threads where your attention isn’t, your instincts are doing nothing — the experience you’re counting on sits inert while the work ships without it. This isn’t about whether your instincts are good. They are. It’s that good instincts protect only the work they can see.

That problem has a solved shape, and you’ve solved it before. Not with AI — with people.

Stop operating a tool. Start running a team.

The mistake experienced people make with these tools is treating them like a faster tool — a better autocomplete, a search box that writes. Operated that way, they hand you a higher volume of the same mistakes. The people getting real leverage made a different move. They stopped operating the thing and started managing it.

What you are directing is a capable, fast, literal junior team. It works without tiring. It also states the wrong number as confidently as the right one, ships the thing that runs but doesn’t hold, and starts Tuesday with no memory of what it built Monday. You have managed that team before. The version you managed was made of people, but the instinct you built doing it is the entire transfer.

A team that works has four things. A solo AI setup needs the same four, and most don’t have any of them.

1. Decisions: write the reason down while it’s still true

A team with no record of why it decided things re-litigates them every week and, worse, invents a clean story afterward about why the call made sense. People do this honestly. The reason gets quietly rewritten by whatever happened next.

AI sharpens this, because it makes decisions cheap and fast. You’ll make ten architecture calls before lunch. By Thursday you will not remember which were reasoned and which were the first thing that ran. The fix is not a better memory. It’s a decision record written at the moment, in the constraints you actually had: what you chose, what you ruled out, what would change the call.

I keep these as short dated entries, one per real decision, written before the code that depends on them. The payoff is specific. Before a new stretch of work, I read my own decisions back, and more than once that five-minute reread caught me about to rebuild something I had already decided against — for reasons I’d have filed under “intuition” if the entry hadn’t been sitting there in my own words. And when a decision turns out wrong, I don’t edit it. I write a new one that supersedes it and leave the original standing. The trail of what I believed and when is worth more than a tidy file.

2. Review: gate the work, especially the work you’re sure about

You cannot read everything the machine produces, so you don’t try. You put gates at the points that matter and let the rest flow. The non-obvious part is where the gate goes: on the work you’re most confident about.

I once ran a review on a fix I was sure about — small, obvious, ran the check mostly out of habit. It came back flagged — a serious one, not a nitpick. The confidence was the problem. Confidence is exactly where you stop looking, which makes it exactly where the misses live.

Two things I stopped trusting as gates. A green test run is not a green gate: I’ve watched a suite pass because the runner stripped the types out before it ever checked them — the tests were green and the code was wrong, and those two facts had nothing to do with each other. And a gate that doesn’t carry a real signal of correctness is theater. A formatter that makes the diff pretty tells you nothing about whether the thing is right. A gate earns its place by catching the class of error you actually fear, or it comes out.

3. Delegation: match the task to the trust, and make the work earn it

You don’t give a new hire root access on the first day. You give small, bounded work, you watch how it comes back, and the scope grows as the trust is earned. None of that changes when the new hire is a model.

Two moves carry most of it. First, route by stakes. High-volume, low-consequence work goes to a fast, cheap model and you spot-check it. The decisions that are expensive to get wrong get the capable model and your full attention. Spending your best judgment on low-stakes throughput is the same waste as putting your most senior person on data entry.

Second, hand over the constraints, not the plan. A detailed step-by-step brief drifts the moment reality doesn’t match step three, and it drifts quietly — the work keeps moving, just not where you wanted it. Boundaries hold where instructions slip. State what it must not do, what done looks like, and what to stop and ask about, then let it find the path inside the fence. And when a run fails, treat that as a diagnosis, not a retry. A team that answers every failure by trying again harder is a team that never asked why it failed. So is an AI loop. Autonomy follows the same rule: you don’t flip it on, the work earns it by staying inside the fence on small things until you’re willing to leave it alone with large ones.

4. Memory: the team starts over every session

Every session starts cold. The session that built the thing yesterday carries nothing into today beyond what you wrote down. A team with no shared memory relives its own mistakes on a loop, so the institutional memory has to live outside any single session — the decisions, the current state, the small reusable procedures you’ve found worth keeping.

There’s a trap here that’s easy to walk into. Automate a piece of your operation, lean on it for a month, and the knowledge of how that piece actually works stops living in your head — it lives in the loop. Take the AI out of the loop and you discover you’ve lost the runbook. The memory you build isn’t documentation for its own sake. It’s the thing that lets you take the system apart later without losing what it knew.

So what makes this hold?

Read those four back and you’ll notice they can be two completely different things wearing the same words.

They can be habits — things you mean to do, that you do when you’re fresh and skip when it’s late and the thing is almost working. Or they can be controls — gates that hold whether or not you felt disciplined that day. A decision record you remember to write is a habit. A step that won’t let the work proceed until the record exists is a control. The difference looks small until the first genuinely busy week, when the habits quietly evaporate and only the controls are left standing.

Encouraged is a habit. Enforced is a control. One of them survives contact with a real deadline.

This is the part I’d point a strong operator toward, because it separates the people who talk about discipline from the people who have it. The experienced person’s real edge isn’t having good judgment. It’s knowing that judgment is unreliable under pressure, and building the structure so it doesn’t have to be reliable.

I run the enforced version on myself: one person, across everything I build, with nobody watching to check that I follow my own rules — so the rules can’t depend on being watched. My own work is the first conformance test. If a control can’t survive a solo operator with every incentive to skip it at midnight, it has no chance against an organization with a thousand of them.

Which is the tell about where this goes. “We encourage good practices” does not survive an audit. The discipline that keeps one person’s AI output honest is the same discipline a regulated enterprise will have to make enforceable, and the distance between encouraging it and enforcing it is going to be someone’s entire business. Possibly mine.

The work

Your decades gave you the judgment. That was the case I made before, and it holds. But the judgment was always the start, not the finish. The finish is a system that decides, checks, delegates, and refuses while your attention is on the next thing — built out of the management instincts you already spent a career sharpening, pointed at a worker that finally moves as fast as you can think.

The next two or three years are the window to build that, before the rest of the field works out it was never about the code. The machine will write anything you ask it to. The system that knows what to refuse, without you in the room, is the asset put to work.