What I Never Give AI: A Framework From 13 Production Tasks
Seven of my thirteen production tasks run through me. Five run without me. One I'll never hand to an algorithm — not even in "show me a draft first" mode.
This isn't general AI caution. There's a specific test behind it — one I developed by getting the boundary wrong a few times. I call it the self-presentation test: if this output goes out under my name right now, without me checking it first, am I comfortable with that?
If no, it's an approval gate.
Sounds obvious. Applies constantly.
Where this question came from
A few months ago I built a system of 13 cron tasks to handle my daily LinkedIn routine — reading feeds, drafting comments, tracking metrics, sending connection requests. I wrote about the full system here.
While designing it, I had to answer a question most people skip: what exactly am I willing to let AI do fully, and what not? And why?
Most developers I talk to haven't answered this. They're in one of two modes.
The first: "I don't trust AI, it hallucinates, let it only explain code." The tool exists. The productivity gain doesn't.
The second: "I'll automate everything I can." Three months in, you find something in the output stream you wouldn't have approved. Or you don't find it — which is worse.
I needed a working criterion. Not "trust vs. don't trust the model," but a concrete question I could apply to each task before assigning it a mode.
The self-presentation test
The self-presentation test is a single-question check for deciding whether an AI task needs human approval before the output is used: if this output goes out under my name right now, without me seeing it first — am I okay with that?
If no, it gets an approval gate.
"Under my name" doesn't mean just public posts. A client email is under my name. A comment under someone's LinkedIn post is under my name. Code I merged without reading but attributed to my PR — that's under my name too, even if technically tagged "AI-assisted."
One clarification: an approval gate isn't "AI does it and I rewrite it anyway." It's "AI drafts it, I spend 30 seconds, I hit OK or delete it." The value is in how fast the draft appears. Not in whether I'm in the loop.
Three task classes
An AI delegation framework for production divides tasks into three categories based on accountability: approval-gate (human reviews before action), auto (runs without review), and never (not delegated regardless of output quality). Of my 13 LinkedIn cron tasks, 7 are approval-gate, 5 are auto, and 1 stays with me permanently.
Approval-gate: the task generates something that goes out under my name. T1 (comment drafts on others' posts), T4 (repost candidate), T8 (reply drafts on my own posts), T13 (long-form article draft). What they have in common: the output is public, it carries my voice, and mistakes are visible to everyone. Seven of thirteen.
Auto: the task takes an action I'd do manually, but produces no text output in my name. T3 (hashtag subscriptions), T5 (company follows), T6 (profile views), T11 (SSI snapshot to a table), T12 (post stats refresh). Errors here are measurable and reversible — an extra follow isn't a crisis. Five of thirteen.
Never: T10, the Featured post suggestion. I asked the system not to bring me a draft at all. Just pull the stats and stay quiet. Featured is the first thing a stranger sees on my profile. That's not a question of which post performed best. It's a question of how I want to present myself right now. An algorithm doesn't know what I'm trying to signal this month. One of thirteen.
Where I put the gate in the wrong place
T7 — connection request with a personal note. I kept it on approval for the first two weeks, then switched it to auto within the daily limit (5/day).
That was a mistake. Not because of text quality — the AI writes decent notes. Because of context. A connection request goes to a specific person I want to build a relationship with. It's the start of a conversation, not a transaction. The model doesn't know I've been reading that account for three months. It doesn't know that person is a CTO I'm in early talks with.
I put the gate back. Slower, but every connect is actually me.
The lesson: auto status only makes sense when the context of each execution doesn't change from case to case. If every instance has unique context that should influence the decision — that's approval.
Beyond LinkedIn
The same framework applies when I work with Claude Code.
Writing tests for an already-written method — auto in my head. I let Claude Code write tests without reading each one. Tests run; if they fail, I look. That's equivalent to T11: measurable output with a built-in check.
Proposing architecture for a new module — never. Not because AI can't sketch options. It can. But an architecture decision carries my accountability to the client for years forward. That's "under my name" in the strongest sense.
A client reply to a complaint — approval. AI writes the draft, I read it. Not because the draft will be bad, but because I want to see what went out under my name before it went.
Production monitoring: in my autonomous agent monitoring system, each agent writes a JSONL log. That's auto — agents write it, I check on alerts or weekly. An error in a log isn't an error in client-facing code. Adding a gate here would add work without adding safety.
The criterion, not the list
The framework isn't about trusting the model. Claude handles most of these tasks better than I'd do them in a tired state. The question isn't output quality — it's who owns what comes out.
Three questions before setting any task to auto:
- Does the result go under my name — publicly or in one-on-one communication? If yes, approval.
- Does each execution have unique context that should affect the decision? If yes, approval.
- Is an error reversible and detectable without the client or audience seeing it first? If no — at least approval, probably never.
If all three are no, no, yes — it's auto. Everything else gets a gate or stays with me permanently.
This isn't "don't trust AI." It's "know where your signature is."