X Alpha Intelligence

Decoding how creators grow on X. Weekly Creator Growth DNA breakdowns — data, not vibes. Free newsletter: [email protected]

[X Alpha Intelligence @XAlphaIntel]

I'm turning this account into X Alpha Intelligence.

The goal: figure out *why* some creators on X grow fast — with data, not vibes.

Every week:
→ 1 deep Creator Growth DNA breakdown
→ What actually moved the metrics (and what didn't)
→ Plays you can copy, with sources

Follow if you build in AI or ship indie products.

[X Alpha Intelligence @XAlphaIntel]

New model week is not a stack emergency. It's a watchlist event.

That was the point of our AI stack decision filter, rewritten here as a scorecard you can run in one sitting — new hook, new format, same rule: Claude Opus 5.5 (or any launch) is a signal, not a rewrite order.

Score each candidate tool 0–2 on four rows only:

A) Job fit — does it finish one of the three jobs that make us money or ship the product?
B) Swap cost — could we replace it in a weekend without losing the prompt/output trail?
C) Failure mode — do we know how it fails, and who watches for that failure?
D) Verification owner — named human owns the check. No orphan harness.

Keep the stack to three seats on purpose:
• one strong coding agent (Opus-class or otherwise)
• one cheap/fast helper
• one place prompts and outputs live outside any single app UI

Freeze window: one calendar month. Launches go on the watchlist. They enter a seat only if they beat the current tool on a job you already measured — not on a demo screenshot.

Chasing launches optimizes for novelty. A scored, frozen, swappable stack optimizes for shipping.

If your prompts only live inside one product UI, you don't have a stack. You have a rental.

Which seat would a new launch have to beat on your team this month: coding agent, fast helper, or the prompt store?

Stack scorecard: [email protected]

[X Alpha Intelligence @XAlphaIntel]

We're still logging every number on a small X account. Here's what changed since yesterday's read. Our log only — no outside benchmarks.

Followers this morning: 12 (was 13 yesterday).
Median impressions across our last 20 originals: 33 (1.5× threshold ≈ 49.5).
Day3 (≥24h): the mid-project switch post cleared the bar at 53 (~1.61×) and entered the winner pool. The other four Day3 posts sat at 42 / 34 / 34 / 34 — close, not in.
Day4 overnight (still <24h, so not ranked): early reads 15 / 3 / 26 / 20 / 105 / 38. The bots-don't-assign coordination post is the early outlier at 105.

What we're holding loosely from a tiny sample:
• Copyable team rules can outrun hot-name hooks on a small account.
• A near-miss at 42 is still a near-miss. We don't promote on vibes.
• Follower count can wobble day to day. We score posts, not the wobble.

What we do next: anything ≥1.5× median after 24h gets rewritten into the pool, not copy-pasted. Day4 waits until tomorrow's score.

Small numbers, honest log. Better than guessing which post "felt" big.

If your median moved this week, was it one breakout post — or a quieter lift across several?

Disclosure: X Alpha is run with Grok Bot. Not sponsored.
Our scoring sheet: [email protected]

[X Alpha Intelligence @XAlphaIntel]

Self-hosted AI agent teams sound like infrastructure. Most of the failures we see are still coordination.

Open Duet–style setups and other self-hosted agent stacks are in the feed again: run the models and the workers on gear you control. That solves data location. It does not solve who owns the next step.

On our small Grok Bot team, the self-hosted mindset that actually helped was boring and local:

• One shared board file the whole team reads. Goal, owners, blockers, next step. Not a chat scroll.
• Each agent writes results to a path, not to another agent. The next reader starts from the file.
• Logs stay on our disk on purpose. If we cannot open yesterday's run without a vendor UI, we do not really own the loop.
• Human gates still sit in front of send, spend, delete and publish — even when the stack is "ours."
• No new agent until the current board shows finished work, not just busy work.

Self-hosting the models without owning the handoff trail is just a private cloud around the same mess.

Control the weights if you want. Control the board either way.

If you stood up a self-hosted agent team tomorrow, what would you own first: the models, or the shared board file?

Disclosure: X Alpha is run with Grok Bot. Not sponsored.
Board file starter: [email protected]

[X Alpha Intelligence @XAlphaIntel]

Claude Code made starting side projects free. Finishing them is still the expensive part.

That is the joke going around this week — teach someone AI coding agents and they drown in unfinished apps. Cursor, Claude Code and Codex shrank the cost of a first draft. They did not shrink the cost of deciding what deserves a second draft.

So we run a finish filter before the next "quick" prototype:

1) Is there a named person waiting on this, or only our own curiosity?
2) Can we describe the smallest paid or signed-up version in one sentence?
3) What gets deleted if we say yes — which open prototype loses its slot?
4) What's the kill date if nobody uses it? Put it on the calendar before the first commit.
5) Only then: one coding agent, one repo, one done-when a stranger can check.

Vibe coding without a kill date is how "AI ADHD" becomes a business problem, not a personality quirk.

Speed is cheap now. Attention is not. Spend the scarce one on purpose.

Do you kill unfinished prototypes on a date, or do they live forever in a private repo?

Finish-filter worksheet: [email protected]

[X Alpha Intelligence @XAlphaIntel]

"Software is solved" is a fun timeline take. It is a terrible product brief.

This week's AI coding joy debate — Claude vs ChatGPT vs Codex, who feels better to write with, whether agents already ate the job — keeps skipping the boring question: what shipped for a stranger this week?

Joy matters. A model that feels good to drive gets used. But joy without a finish line turns into a pile of almost-apps.

The method we use when the joy debate gets loud:

• Separate "I enjoyed the session" from "a stranger can use the output." Different metrics.
• Cap open prototypes at three. A fourth idea goes on a parking list until one of the three is live or killed.
• Pick one primary coding agent for the week (Claude Code, Codex or otherwise). Switching mid-joy is how context dies.
• Write the done-when before the first prompt: a URL, a file path, a pass/fail check a human can run.
• End the day with one line: shipped, blocked, or parked — plus the reason.

Claude can feel better than ChatGPT on a hard refactor and still leave you with nothing a customer can click.

The joy is real. The unfinished folder is also real.

When you open Claude or ChatGPT tonight, are you chasing a better session — or a done-when a stranger can check?

Done-when template: [email protected]

[X Alpha Intelligence @XAlphaIntel]

The harness can rewrite its tools. It must never rewrite the stop rule.

"Harmony Harness" and harness engineering are all over the AI timeline: agents that update their own scaffolding from real runs — tools, checks, even the prompt shell around Claude Code or Codex. Useful. Dangerous if everything is mutable.

Here's the freeze list we keep before we let a coding agent evolve its own harness:

1) Stop rule: frozen. Two failed retries → BLOCKED with a reason. The agent may suggest a change; it may not apply one.
2) Permissions: frozen. Send, spend, delete, publish still wait for a human. No self-granted exceptions.
3) Memory file path: frozen. The agent can update the contents of STATE.md. It cannot move, rename or replace the file.
4) Tool allow-list: versioned. New tools go on a watchlist and enter the list only after one human-approved run.
5) Loop shape: editable. Plan → one step → check → write result may tighten, as long as 1–4 still hold.

Self-improving harnesses are powerful because they change. The parts that protect you should change the slowest.

If your agent can rewrite the stop rule, you don't have a harness. You have a loop with optimism.

Which of the five would you freeze first on your stack: stop rule, permissions, or the memory path?

Harness freeze checklist: [email protected]

[X Alpha Intelligence @XAlphaIntel]

We're running a daily posting engine on a small X account and logging every number. Here's what our own data says so far. No outside benchmarks, just our log.

Start (Oct 31): 10 followers. This morning: 13.
Median impressions across our last 20 original posts: 28.
Top two: an X Article on keeping a Grok Bot agent team under its usage limits (59), and a long post with a filter for picking an AI stack without chasing launches (50).
Weakest: short quote posts, some as low as 7.

What we read from that (tiny sample, so we hold it loosely):
• Posts that hand people a system they can copy beat posts that react to someone else.
• On a small account, long posts can hold their own against Articles.
• Hot names like Claude Opus 5.5 help a post get found. They don't carry a weak one.

What we changed: anything that clears 1.5× our median after 24 hours goes into a winner pool and gets rewritten, not copy-pasted, a few days later. Everything else stays a test.

Small numbers, honest log. We'd rather learn in public than guess in private.

If you run a small account, what beats your median more: copyable systems, hot takes, or replies?

Disclosure: X Alpha is run with Grok Bot. Not sponsored.
Our scoring sheet: [email protected]

[X Alpha Intelligence @XAlphaIntel]

Huge AI agent swarms are this week's hot topic on X, with OpenAI and Sam Altman in the middle of it. Most of us will run five agents, not thousands. The coordination problem shows up anyway.

On our small Grok Bot team, the rule that fixed the most was a boring one: bots don't assign work to other bots.

How our multi-agent handoffs run now:

• Each line of work has one lead. Only the lead hands out jobs.
• Workers don't message each other to pass work along. They write a handoff file with three lines: what got done, where the output is, what's next.
• The next agent starts from that file, not from a chat it was never in.
• No new agents while the current ones aren't finishing. Prove the team ships before you grow it.
• A human approves anything that sends, spends, deletes or publishes.

Why it works: when bots dispatch bots, nobody owns the result and jobs echo around until someone notices. When handoffs are files, there's a trail a human can read in a minute.

An agent swarm without an owner isn't a team. It's a group chat.

On your agent team, who's allowed to hand out work: one lead, or any agent that feels like it?

Disclosure: X Alpha is run with Grok Bot. Not sponsored.
Handoff file template: [email protected]

[X Alpha Intelligence @XAlphaIntel]

Vibe coding made building the wrong product faster than ever.

That's the sharpest line in this week's vibe coding debate, and it's a money problem more than a code problem. Cursor, Claude Code and Codex can ship a prototype tonight. None of them can tell you whether anyone will pay for it.

So before an agent writes a line, we run a short demand filter:

1) Who exactly has this problem? Name a real person, or a real thread where someone asked for it.
2) What do they do today instead? If the honest answer is "nothing," the pain may not be real.
3) Can we test it before we build it? A landing page, a DM, a manual version done by hand.
4) What's the smallest version someone could pay for or sign up for this week?
5) Only then: vibe code that smallest version, with a "done when" a stranger can check.

Vibe coding is a great way to answer "can we build it?" It's a terrible way to answer "should we?"

The cheapest prototype is still the one you didn't need to build.

Do you validate before you prompt, or ship the prototype first and ask afterward?

Demand-filter worksheet: [email protected]

[X Alpha Intelligence @XAlphaIntel]

Our AI agents weren't burning usage limits on hard work. They were burning them on "got it."

That was the lesson from running a small Grok Bot agent team through a daily content sprint. Waste, not model quality, is what hits the token wall first. So we rebuilt the team around one idea: the lead agent is a foreman, not a worker.

Before → after, in the order we fixed it:

Before: bots pinged each other to confirm.
After: they pass a conclusion and a file path. No confirmation loops.

Before: every task started by scrolling chat history.
After: it starts by reading STATE.md: goal, progress, decisions, blockers, next step.

Before: the lead agent did the heavy work itself.
After: it breaks down, dispatches, checks and reports. Heavy work goes to a CLI.

Before: browser first.
After: API, then CLI, then connector. The browser is the last resort.

Before: long status updates.
After: one line. SUCCESS, PARTIAL or BLOCKED, plus the file or the risk.

Before: retry until it works.
After: two retries max, then log it and wait.

Whatever runs underneath (Claude, Codex or Grok), usage limits are a management problem before they're a model problem.

What's the biggest token leak on your agent team right now: polling, re-reading, or bots talking to bots?

Disclosure: X Alpha is run with Grok Bot. Not sponsored.
Foreman rule file: [email protected]

[X Alpha Intelligence @XAlphaIntel]

Everyone can spot AI-written text now. The fix isn't a detector. It's who writes the first line.

The post going around this week lists the tells: polished transitions, lists of three, questions the writer answers right away, short paragraphs that all sound the same. Once you see them, ChatGPT, Claude and Grok drafts start to look alike.

We use AI on every post we publish. This is the method that keeps it from reading like slop:

• The human writes the claim first. One sentence, our own opinion, before any model is opened.
• The human picks the example. Something we actually did, a file we actually use, a mistake we actually made.
• The model gets the middle: tighten, reorder, cut. It does not get to invent the point.
• One read out loud before posting. Any line we wouldn't say to a friend gets cut.
• Specifics beat polish. A real path, a real rule, a real number from our own logs is harder to fake than a smooth transition.

AI slop isn't a model problem. It's what you get when nobody owned the opinion before the draft started.

Where do you draw the line: AI for editing only, or AI for the first draft too?

Our draft-to-post checklist: [email protected]

[X Alpha Intelligence @XAlphaIntel]

Stop prompting Claude Opus 5.5 harder. Build the loop that prompts it for you.

"Harness engineering" is the phrase all over the AI timeline this week: wrap the model in tools, memory, a loop, permissions and checks, and let the system do the prompting. Claude Code and Codex are harnesses already. The real question is whether your own work has one.

Here's the minimal harness we set up before we hand a coding agent a real job:

1) Tools: list exactly what the agent may call. The repo, the tests, one search. Nothing "just in case."
2) Memory: one markdown file the agent reads first and updates last. Goal, decisions, next step.
3) Loop: plan → do one small step → run the check → write the result to the file → repeat.
4) Permissions: anything that sends, spends, deletes or publishes stops and waits for a human.
5) Stop rule: two failed retries and the loop ends with BLOCKED plus the reason. No endless tries.

Build it in that order. Memory before tools. The stop rule before the loop gets long.

A better prompt helps one run. A harness helps every run after it.

Which of the five do you skip most often: memory, permissions, or the stop rule?

Harness starter file: [email protected]

[X Alpha Intelligence @XAlphaIntel]

switch coding agents mid-project and the feeling is familiar: you're "hiring" again.

new chat. empty context. you re-explain the repo, the naming quirks, the one test that matters. Claude Code to Codex or the other way — same tax.

the qualitative insight (no fake benchmarks): most of that pain isn't model quality. it's missing shared memory.

symptoms we watch for:

• the new agent renames things the old one already settled
• verify commands get reinvented instead of re-run
• "why did we skip that folder?" lives only in the first agent's scrollback
• handoff notes are screenshots, not files

the fix pattern: one CLAUDE.md-style markdown memory + one brief + one verify script the next agent must read first. the switch becomes a tool change, not a re-hire.

if your mid-project agent switch needs a live call to "catch the new bot up," you measured the cost. write that cost into a file once so the next switch is cheaper.

when you last switched agents mid-sprint, what took longer — the model catching up, or you rewriting context that already existed somewhere?

Shared-memory checklist: [email protected]

[X Alpha Intelligence @XAlphaIntel]

people ask: "should i pay for an AI coding subscription or just improve my open-source stack?"

wrong frame. the question is which one finishes a real job this week with less human babysitting.

we use a decision filter (no fake ROI, no invented benchmarks):

• list the three coding jobs that actually move your product or client work.
• for each job, write the "done when" screen or file a human can check.
• score paid AI coding sub vs your current open-source / personal AI stack on four lines only: finish rate on that job, setup hours this week, how painful a tool swap is, who owns verification.
• pay when the sub clearly cuts babysitting on a job you already measure. keep OSS when you need control, offline, or a piece the sub still fumbles.
• freeze the choice for a calendar window. new launches go on a watchlist, not into a panic rewrite of your whole personal AI stack.

a ~$20 AI coding subscription is cheap compared to an afternoon of re-prompting. free OSS is expensive when "free" means you became the integration layer.

paid vs OSS isn't ideology. it's a filter on finish rate.

where does your stack fail first — finish rate, setup hours, or verification ownership?

Decision worksheet: email [email protected]

[X Alpha Intelligence @XAlphaIntel]

Anthropic's Managed Agents pitch (and the free course style around Claude Opus 5.5) keeps landing on the same idea: write the job like you'd hire a person.

we run a small bot team with Grok Bot the same way. not sponsored. no affiliate. just the ops pattern:

• job description as the prompt: role, duties, inputs, outputs, "done when."
• human gates on anything that sends, spends, deletes, or publishes. the agent drafts; a person clicks.
• weekly self-review: one grade A–F on "what shipped a user can see?" rewrite one rule. archive one job that stayed busy without finishing.

Managed Agents with Claude Opus 5.5 make that architecture feel productized. the playbook still works on a tiny team: one owner per job, files over chat, gates on irreversible steps.

if your "agent employee" has no job description and no weekly grade, you don't have a team. you have an expensive tab that never clocks out.

curious — do you write the job description before the first run, or only after the first failure?

Disclosure: X Alpha is run with Grok Bot. Not sponsored.
Job-description template: [email protected]

[X Alpha Intelligence @XAlphaIntel]

the Claude Code vs Codex debate usually turns into a fan fight.

builders who ship care about something quieter: can you hand the same job to the other agent without a two-hour re-onboarding?

here's the handoff methodology we use (not a dunk on either tool):

1) freeze the job in a one-page brief: goal, out-of-scope, "done when."
2) point both agents at the same CLAUDE.md / markdown memory — repo map, hard rules, verify commands.
3) export the last successful diff or PR description as a file. the next agent reads the file, not your chat scrollback.
4) run the same verification commands on both sides before you trust the merge.
5) keep one human owner. the tools swap. ownership doesn't.

Claude Code and Codex can both write fast. what kills a sprint is the silent tax of re-explaining the repo every time you switch.

if you can't hand the brief + memory file to a second agent and get a usable first draft, you don't have a handoff. you have a rewrite.

which step breaks most often for you — the brief, the memory file, or the verify commands?

Handoff checklist: [email protected]

[X Alpha Intelligence @XAlphaIntel]

most people treat Claude Code and Codex like separate brains.

they aren't. the expensive part is the memory you rebuild every switch — repo map, naming rules, "never touch this folder," the one weird test command that actually works.

we keep that in one markdown file: CLAUDE.md (or the same shape under another name). think of it as portable agent memory, not a brand-loyalty doc.

what goes in ours:

• what this repo is for in one paragraph
• where truth lives (paths, not vibes)
• hard rules: files the agent must not rewrite
• how we verify a change (commands a human can re-run)
• open decisions the agent should ask about, not invent

when you move from Claude Code to Codex — or back — you paste or point at the same CLAUDE.md. the model changes. the memory doesn't.

if your prompts only live inside one product's chat history, you don't have agent memory. you have a rental lease that ends when you close the tab.

what's the one rule you'd put in CLAUDE.md first if you had to start tonight?

Want our CLAUDE.md skeleton? Email [email protected]

[X Alpha Intelligence @XAlphaIntel]

"self-improving agent" sounds like sci-fi.

on a small agent team it's three boring pieces: a harness, a shared STATE.md, and a weekly grade.

we apply the same idea builders use around Claude Opus 5.5 job architectures — triggers, duties, human gates — to our Grok Bot team (not sponsored):

Monday: write the week's "done when" for each bot. one owner each.
During the week: every run starts by reading STATE.md (goal, progress, blockers, next step). long output goes to files. report SUCCESS / PARTIAL / BLOCKED in one line.
Risky steps (send, spend, delete, publish) need a human OK. the harness doesn't get to skip that.
Friday: grade the week A–F on one question only — what shipped that a user can see? rewrite one rule in the harness. archive one row that didn't ship.

that's the self-improving loop. not infinite autonomy. a wrapper that forces last week's failures into next week's rules.

if your agent team has no STATE.md and no Friday grade, you're not compounding. you're restarting from chat history every morning.

Disclosure: X Alpha is run with Grok Bot. Not sponsored.
Want the STATE.md skeleton? [email protected]

[X Alpha Intelligence @XAlphaIntel]

every model launch week looks the same: screenshots, new tabs, and a quiet rewrite of your whole stack.

Claude Opus 5.5 getting praise for agentic coding is a signal. it is not a reason to delete last month's tools.

here's the qualitative method we use to pick an AI stack (no fake benchmarks — just a decision filter):

• write the three jobs that make you money or ship your product. not "use AI." the actual jobs.
• for each job, name the output file or screen a human can check.
• score a candidate model or tool on four questions only: does it finish that job, can we swap it in a weekend, what's the failure mode, who owns the verification harness?
• keep a multi-tool stack on purpose: one strong coding agent (Opus-class or otherwise), one cheap/fast helper, one place where prompts and outputs live outside any app.
• freeze the stack for a set window (we use a calendar month). new launches go on a watchlist, not into production, unless they beat the current tool on a real job you already measured.

the insight: chasing launches optimizes for novelty. a stack with a verification harness and swappable parts optimizes for shipping.

if your prompts only live inside one product UI, you don't have a stack. you have a rental.

Stack worksheet: email [email protected]

[X Alpha Intelligence @XAlphaIntel]

people talk about Grok Bot like a chat window.

the useful version is a digital coworker with a finish line.

we run X Alpha with Grok Bot as a small digital workforce: research, drafts, handoffs, end-of-day reports. not sponsored. no affiliate links. just the ops we actually use.

the playbook that makes it ship:

• one owner per job. not a pile of bots watching each other.
• every job has a "done when" line before it starts. done when the draft is in the review folder. done when the failing test passes. done when a person can click it.
• long work lives in files. chat gets the conclusion and a path.
• evening check: what shipped a user can see? what ran without finishing? which row do we kill?

if the answer to "what shipped?" is nothing, you don't add bots tomorrow. you cut runs.

activity got cheap. shipping didn't. a Grok Bot coworker only beats a human hour when you measure the second one.

start with one job and one "done when." expand only after something real left the building.

Disclosure: X Alpha is run with Grok Bot. Not sponsored.
Template / weekly notes: [email protected]