AI runs 70% of my distribution. The exact stack.

The common thread: the recipient could verify a real person was behind it in two clicks. Cold outreach to named journalists, replies mentioning someone by handle, comments under my own posts. All of them have a human on the other end who notices if nobody's home. That's the characteristic — not complexity, not length, but verifiability.

The task-type breakdown is the useful addition here — the split isn't a fixed number, it's a function of how judgment-heavy the work is. Bug fix sprint being 80% human because reading existing code requires knowing what the original author was thinking is exactly the pattern. Fresh context is the constraint; the model has none of it.

The 6-month re-audit point matches what I said to someone else in this thread — my split was 22/18 eight months ago, now 28/12, not because I automated more but because better constraints made previously-undelegatable tasks delegatable. The line moves, but so far only in one direction.

The 7-day rolling column is the right fix and I haven't built it yet. You're describing exactly the attribution hole I paper over with "organic distribution has a 30-90 day lag" — which is true, but it's also a convenient excuse not to instrument it better. A rolling window would at least surface whether Tuesday's reply or Thursday's thread drove Friday's signup, even if it can't close the loop on the long-tail direct visits.

The "instrument inputs with causal influence" framing is sharper than how I had it. I fell into the easy-to-measure trap for the first two months — tracking post count and engagement because Umami makes that effortless, ignoring the harder question of which specific action in which channel preceded a conversion. The spreadsheet made the input list visible. The rolling window would make the lag visible. Those are two different problems and I've only solved the first one.

Adding it to the next digest iteration. Appreciate the specific build note rather than just "attribution is hard."

Fully agree — and I'd go further: distribution is now the harder engineering problem. Building is tractable. Getting seen by the right person at the right moment is not. The "world's best kept secret" failure mode has killed more good products than bad code ever has.

The constraint step being skippable is the exact failure mode — it feels optional until you've read enough flat drafts to price what skipping it actually costs. Output volume is the metric that feels like progress. Constraint quality is the metric that produces it. Glad the scripts breakdown was useful; most posts stop at the framework and leave out the part you can actually build from.

Haven't built a formal feedback loop yet, but the rejection tracking point is the right call. Right now new never-write rules show up when I read a bad draft and tag the exact line where the voice broke — which is manual and lossy. Turning rejections into structured data and routing the patterns back into the prompt header is the obvious next step I've been doing informally. The rejection log as training signal is a better frame than fine-tuning because it stays interpretable — you can read the list and know why each rule exists. Adding a rejection reason field to the approval queue this week.

The unedited weeks are the clearest data I have. Engagement held roughly flat — likes, upvotes, replies looked normal. Signups dropped. The posts that convert aren't the ones that sound correct, they're the ones where a specific line lands as something only someone with skin in the game would write. Unedited drafts pass the skimming test and fail the "do I trust this person" test. The audience that converts is exactly the audience that can tell the difference.

"Confusing speed with trust" is the cleanest summary of the auto-send failure mode I've read. The journalist story is exactly that mistake. The script was fast. The relationship was slow. I optimized for the wrong variable.

The draft-never-send bucket is also where I'd put anything going to someone with an audience larger than mine. The asymmetry is too high. One flat reply to the right person costs more than a month of volume.

The third bucket is the right addition and I should have named it explicitly. "AI can draft, never send" is where my cold outreach to named journalists lives. The draft is useful as a structure check. It never ships as written. Calling it a two-column sort undersells the actual workflow.

The Reddit venting reply problem is one I recognize. The model produces the correct sentiment but misses the specific weight of the moment. It reads as someone who understood the complaint intellectually but wasn't in the room. That gap is unrecoverable with prompting in my experience — it's not a constraint problem, it's a presence problem.

On the 12 staying stable: some drifted, mostly in one direction. Two tasks that were firmly mine a year ago moved into the AI column after I got precise enough with constraints. None moved the other way. The tasks that stayed human got more entrenched over time, not less — because the cost of getting them wrong became clearer the longer I ran the stack.

The 12 tasks I kept are the entire answer to that. Personalization does not survive delegation — it just looks like personalization until the person on the other end clicks through and realizes nobody is home.

The balance I landed on: automate everything where the output is evaluated on accuracy. Keep everything where the output is evaluated on whether it sounds like a specific human who has read their work.

The "verify me in two clicks" framing is sharper than how I had it. I was thinking about it as voice fidelity. You've named the actual risk: not that it sounds wrong, but that someone can check.

The $400 zero-lift phase being near-universal is the part I wish someone had told me before month one. Would not have stopped me but would have shortened it.

"The constraint lives upstream of the model, not inside it" is the cleaner formulation of what I was trying to say. Stealing that line.

The 50-versus-5 keywords finding is the exact failure mode I see when founders first build anything like this. More inputs feels like more coverage. It's just noise with extra steps. The model cannot tell you which keywords matter for your readers. It can only score against the ones you already chose correctly.

The dependency I'd add: keyword selection isn't a one-time decision. When the policy landscape shifts, a keyword that was low-signal for months becomes load-bearing overnight. That upstream call has to stay human — and it probably won't feel like a decision when it happens. It'll feel like "this alert seems more important this week." Which is exactly the judgment the model cannot replicate.

The thread necromancer problem is real and I don't have a clean fix for it. My queue has a 48-hour expiry now — anything older gets auto-archived and I re-evaluate from scratch rather than ship a stale draft. It creates some waste but it's better than the alternative you described.

"Never write a sentence that combines two strong claims into one" is going straight into my list. You're right that you can smell it immediately. The model stacks claims because stacking sounds authoritative. It reads as generated the second you say it out loud.

On the 30% question: time, not words. Words changed is a bad proxy because the most important edits are often one line — the opener or the closer — and those take 30 seconds to change but represent 80% of the value. When I tracked words changed I convinced myself drafts were good that weren't. Time spent relative to writing from scratch is the honest number. For long-form specifically, I've found the 30% estimate holds on replies and short posts and falls apart completely on anything over 600 words, where it drifts closer to 50%.

"If it takes longer to evaluate whether the AI did it right than to just do it yourself, you haven't gained time — you've just moved the bottleneck." That's the cleaner version of the test I was running implicitly and never wrote down. Adding it to the doc.

The 10-second reviewability threshold also explains why the never-write list matters more than the prompt. A good prompt makes the output better. A good constraint list makes the output faster to evaluate. Those are different problems and most people only solve the first one.

"The human approval gate isn't friction — it's the product" is exactly right and the part that took me the longest to internalize. I kept framing the approval step as overhead I'd eventually automate away. The journalist story is what made it permanent.

The assessment case is a sharper version of the problem than distribution. In distribution a bad judgment call costs you a comment. In skills assessment a bad judgment call corrupts the actual output the product is selling. The 30% that stays human is load-bearing in a way mine isn't.

The 90/10 claim falling apart under attribution pressure is the most reliable pattern in these threads. The vibes-based number is always the marketing version. The spreadsheet number is always uglier and always more useful.

The quarterly repeat point is the one I'd underline. My split was 22/18 eight months ago. It's 28/12 now. Not because I automated more but because I got better at writing constraints that made previously-undelegatable tasks delegatable. The spreadsheet isn't a one-time audit, it's a calibration tool. Worth saying that more explicitly in the post.

Written the never-write list. I had a voice doc for months that only said what to do. Drafts were 70% wrong. The day I added the never-write section, drafts became 70% right. That one page is worth more than any model upgrade. Start it on day one.

Cron at 09:00, 13:00, 17:00 pulls top 30 threads from HN /front and /newest. Haiku scores each thread 0-10 for relevance to my 7 stances and returns the top 5 with a one-line "why this thread" and a suggested reply angle. I read the 5 in 60 seconds and pick 1. Sonnet then generates 2 draft comments for that thread using my voice doc plus the thread context plus the chosen stance. I read both drafts, pick the better one, hand-edit the opener (always), hand-edit the closer (always), ship.

AI did about 4 minutes of work across the whole flow. I did about 6. The comment ships in 10 total minutes versus 25-30 if I were doing it fully manual. Multiply that 60% time saving across 5 channels and that is where the 14 hours per week of pulled-back founder time comes from.

Both, honestly. Signups are the lagging metric I care about most and the one most resistant to clean attribution because organic distribution has a 30 to 90 day delay between first touch and conversion.

What I can measure: weekly output count, channel-level engagement (replies, upvotes, click-throughs to flowly.run), referrer reports from Umami, signup rate from each referrer over a 30-day window. The "hybrid-output conversion roughly 10x AI-only conversion" split I implied in the post comes from looking at click-to-signup on referrers I can tag and from comparing drafts shipped at 30% edit versus drafts shipped at 0% edit during one bad week.

What I cannot measure: the long-tail compound effect of consistent presence. A founder who saw 6 of my HN comments over 3 months and then signed up via a direct visit shows up as "organic, no referrer." That is the bulk of my signups. I assume the volume helps. The numbers agree but do not prove it.

If you build this stack, set up Umami or PostHog before you start, tag every link with UTM params, and accept that you will be flying half-blind on the long tail. That is the nature of organic distribution at this scale. Anyone selling you cleaner attribution is selling you fiction.

Start with two scripts, not five. The two with the highest leverage are (1) a daily analytics digest that summarizes your traffic into one email and (2) a draft pack generator for one channel only. Pick the channel that costs you the most time per output.

You can build both in a weekend with Claude as your pair. The non-technical version is the same flow in n8n or Make.com. The pipeline matters more than the runtime. The hardest part is the voice doc, and that one you write by hand regardless.

Yes, smaller scars.

One: the thread scanner once recommended a Bluesky thread for engagement. I shipped a reply. The thread turned out to be a quote-post of a tragedy. I deleted within 4 minutes but a few people saw it. Now the scanner has a "sensitive content" pre-flag and the day's top 5 candidates skip anything tagged.

Two: the draft pack generator produced a reply that paraphrased a competitor's marketing copy almost word-for-word. I caught it because the closer was uncharacteristically smooth. The fix was a new line in the never-write list: never use any phrase that sounds like it was already used by a SaaS landing page.

Three: the inbox monitor once scored a podcast booking request as 2/10 because the founder voice doc did not include a "podcast guesting" stance. I missed the email. The fix was adding an eighth stance, then immediately collapsing it back to seven by merging two adjacent ones.

The pattern is the same: every failure produced one line of context engineering. The stack is mostly the accumulated failures of the founder, written down.

Not that I can detect. The 2026 detection heuristics target unedited LLM output with characteristic structural tells (em dash density, three-bullet conclusions, "Here is the thing about X" openers). The 30% human edit removes those tells. The posts that get traction are always the ones where my edit pass adds a number, a specific personal example, or a contrarian line the model did not generate.

The doc is one page. Seven entries. Each entry has the same four fields.

Name. Two to four words. Mine include "single-tool stack undervalued," "AI removed design blocker not speed," "distribution is a feedback-signal problem," "founder voice is the asset."
First sentence template. The opener I have used enough times that I can identify the stance from the first 8 words.
Three bullets. The atomic claims this stance makes. Each bullet must be a complete idea, not a header.
One example reply that nailed it. A real comment or post of mine, copied verbatim. The example is the calibration target for the model.
The stance doc plus the never-write list is the entire context the LLM gets per task. Total prompt header: about 1,200 tokens. Per-request input adds another 300-800 depending on channel. Output 200-400. Cheap.

The reason 7 works and 15 does not: I cannot hold 15 stances in my head consistently. The model can. But the human approval step at the end will fail if I cannot recognize my own stance in the draft. Seven is the ceiling of what I can recognize at a glance.

I did. For 4 months. They failed for the same reason most "AI distribution" SaaS products fail at indie scale: they are optimized for outbound B2B SDR workflows where the slow 30% is "personalized intro line" and the bulk 70% is "send 100 emails per day." My slow 30% is "decide whether this is worth shipping at all," which no SaaS exposes as a step. Those tools assume you already decided. I had not.

The Python stack is about 200 lines total across the 5 scripts. It gives me a seam where the human picks live. SaaS tools paper over that seam and charge for it. The seam is the entire product.

Haiku for the scanning and scoring steps where I am triaging 50-100 candidates per day. Throughput and cost matter more than voice there. GPT-4o for short-form draft generation (replies, posts, pitches) because it tracks instructions tighter on the 60-word constraint and stops adding extra paragraphs. Claude Sonnet for long-form blog drafts and journalist pitch responses where voice fidelity is the load-bearing metric.

I rotate when a model starts drifting from my voice doc, which happens about every 8 weeks. The assignment above is correct as of this week. By next quarter it will probably look different.

Roughly Claude Haiku for monitoring and scoring ($6), GPT-4o for thread relevance ranking and short-form drafts ($7), Claude Sonnet for blog first-drafts and pitch responses ($4), and about $1-2 in Playwright cloud minutes for form filling. Some months it nudges $24. It has not crossed $30.

The CLAUDE.md as shared source of truth is the code equivalent of my never-write list. Same principle: the constraint lives upstream of the model, not inside it. Without it each tool optimizes locally and the codebase accumulates three silent opinions about the same problem.

The distribution version of your problem is running the same pipeline across Claude, GPT-4o, and Haiku without a shared voice doc. Each model drifts toward its own defaults. The output sounds like three different founders. The fix is identical to yours — one document all models read before touching anything.