The Bottleneck Is Also the Inspector

July 2026

The first version of this article argued that a publishing workflow runs at the speed of the steps a machine can reach, and that every step needing a human hand is a hard stop that chains the work to one specific device in one specific place.

I still think that’s true. It was also incomplete in a way I didn’t see until I tried to make the argument better — by asking an AI to find me a stronger version of it, and then checking what it handed back.

The bottleneck, named better than I named it

I asked Grok for Musk’s framing of the human interface as a bottleneck, because I was sure I wasn’t the first person to notice this and I wanted the strongest existing version of the idea.

The question, and the answer that mostly held up. Note the “84 pages, 5 posts” — this Grok can search. The one I can reach from my own tooling can’t.

The framing is better than mine, and it’s a decade old. At the Code Conference in 2016, Musk put it like this:

We’re already cyborgs. Your phone and your computer are extensions of you, but the interface is through finger movements or speech, which are very slow.

And in a Y Combinator interview the same year, at more length:

We’re currently bandwidth limited. We have a digital tertiary self in the form of our e-mail capabilities, our computers, phones applications… We’re effectively superhuman but we are extremely bandwidth constrained in that interface between the cortex and that tertiary digital form of yourself.

That’s my article’s thesis, stated better and ten years earlier, and generalized past publishing to every interaction between a person and a machine. My version was a special case: the fingers are slow, so the steps that need fingers are where the time goes.

What my own pipeline looks like

Publishing to this site, the article lives as a file. My AI agent edits the file, runs a build to prove the site still compiles, commits it to version control, and runs a deploy script. Every step is a file or a command. I can do the whole thing from my phone in a parking lot, by typing a sentence into a chat window — not because the site is simple, but because every step is addressable.

The same article, both routes. The two highlighted steps are the whole difference.

Publishing the same words to X — last month’s My First Month With a Second Brain — goes like this instead:

1. Convert the text to the plain format the platform accepts. (machine)
2. Upload it as a draft through the API. (machine)
3. Open X on a desktop, run the text through a grammar checker, hand-edit it, fix what the conversion broke. (human, graphical, desktop only)
4. Publish. (either)
5. Pull the published text back down and reconcile it against the copy on this site. (machine — but only because we built that step ourselves)
6. Find a mistake after publishing? Back to step 3. (human, graphical, desktop only)

Exactly one step in that list needs my hands: step 3. Step 6 is just step 3 again, every time I find something after the fact.

Where it stops, and why

There’s no update call. The API available to me offers “create a draft” and “publish a draft.” Nothing edits an article that’s already live.

Real output, not a diagram. Two calls is the entire surface — and neither of them edits anything.

The editing happens after the fork. Once the draft is uploaded there are two copies, and I edited the second one. Both ended up partly right, and “just take the newer version” would have pushed real errors backward onto the site.

The conversion is lossy. Plain paragraphs and two heading levels survive. Links flatten to text (url), bold and italics are stripped, inline images are dropped. The two copies aren’t the same artifact anymore, so the differences can’t be merged mechanically.

The rate limit decides where the editing happens. Ten article-draft uploads per rolling 24 hours, a real published number. When re-uploading is scarce you stop iterating through the API and start editing in the interface — which is exactly what creates the fork above.

And the same wall exists on the AI side, which I’d been treating as the part that worked. The tool I use to get a review pass from Grok has a review prompt hardcoded to “Review this article draft for an X Article.” I ran it against a piece written for this site and got back advice about how internal links wouldn’t resolve on X and how the front matter didn’t matter there. None of that applied. The tool has a second command that exists purely to route around its own first one — its code comment says the review wrapper “keeps hijacking the response into tone/editing feedback.” It’s one-shot and stateless, so there’s no asking a follow-up question. And it can’t search the web, which is why the screenshot above came from a phone instead of from my pipeline: the Grok that can read 84 pages lives in an app I can only reach with my thumbs.

The tool returns text. It cannot touch the file. That’s the shape of most of these tools right now — the AI is the reasoning engine, not the hands. Every capability you’d assume comes bundled — reading a live page, writing a file, posting to a platform — is a separate thing somebody has to build or buy.

How those screenshots got here

I asked Grok a question on my phone. I screenshotted the answer. I sent the images to Claude, which read them.

Three AI systems were involved and none of them could talk to each other. The connective tissue was a human taking pictures of one screen so another program could see it. That is Musk’s bottleneck made completely literal — the finger movements, the lossy transfer, all of it, in a workflow I built specifically to avoid exactly that.

So: obviously the thing to do is automate the human out of the middle. That was the conclusion of the article I published two days ago.

Then I checked the screenshots.

What checking found

Two of the four problems are visible in this one screenshot.

Five checkable claims came back in that answer. Here’s how they held up.

The “already cyborgs” quote is verbatim. Code Conference, 2016. Checked against multiple independent write-ups. No problem.

The “digital tertiary self” quote is misquoted. Grok renders it as “We’re practically superhuman.” The transcript says “effectively superhuman.” It also silently drops the opening sentence — “We’re currently bandwidth limited” — which is the part that actually names the idea. The substance survives; the quotation marks don’t. It’s presented as a direct quote and it isn’t one.

The Neuralink quote is verbatim, but the date is badly wrong. Grok introduces it as “More recently (June 2026 on X).” I can’t confirm that, and everything I could find points years earlier: MIT Technology Review was already writing about a Musk post making this exact argument in September 2023. I’m not certain of the original date, and I’ll say why: my own tooling reads an X post by ID, and I don’t have the ID — there’s no search command in it. So I worked the secondary sources instead of the primary one. That’s enough to establish that “June 2026” isn’t supported by anything I could find. It isn’t enough to tell you what the real date is, so I’m not going to pretend otherwise.

Correction, added the same day this was published. That paragraph originally told you the tool was broken. It isn’t. I ran it with the wrong Python interpreter, got an import error, and diagnosed a dead tool from one failed command — then published it as fact, in an article about checking claims before they leave your hands. The tool works fine. What it lacks is a search command, which is the real and much smaller reason the primary source is still out of reach.

It was caught because a reader read that line and asked whether the tool could be fixed. I went to fix it and found nothing to fix. Fourth bad claim of the day, and the only one that was mine.

The “~10 bits per second” figure is real but misattributed. It arrives as a bullet under the heading “He has made the same point in other ways.” The number doesn’t come from Musk — it comes from research out of Caltech, associated with neuroscientist Markus Meister. A genuine finding, filed under the wrong name.

And the thesis is presented as settled when it isn’t. Grok’s closing line: “Musk’s consistent view is that the interface itself — not raw intelligence — is the limiting factor between humans and machines/AI.” True as a summary of his view. But there’s a live counterargument it never mentions: by some accounts Neuralink’s own current devices achieve roughly that same ~10 bits per second, which would put the constraint in the brain rather than in the interface.

I’m not taking a side on that. I have no standing to referee brain-computer bandwidth, and it isn’t what this article is about. The problem is that a contested question arrived on my screen with the contest removed — and if I hadn’t gone looking, I’d have built an argument on top of it without ever knowing there was anything to look for.

One clean, four with problems. Every one of them delivered in the same calm, formatted, confident voice. Had I published them, the damage wouldn’t have been four footnotes — it would have been four fabricated details about a real person, in a piece whose entire subject is doing this work carefully.

The part I had wrong

If I had done what my own article told me to do — minimize the human steps, get the hands out of the loop — I would have taken a screenshot at face value and published four bad claims about Musk inside an article about workflow quality.

The human step I keep calling a bottleneck is the same human step that caught all four.

So the argument needed splitting, because there are two entirely different things wearing the same costume:

• Transport steps. Copy-pasting between systems. Screenshotting one AI so another can read it. This is pure interface friction and it produces nothing. Musk is describing this, and he’s right — it’s waste, and every one you kill is free.
• Judgment steps. Is that quote real? Is that date right? Is this good enough to put my name on? This is not friction. This is the product.

The test that separates them is one question: does this step move information, or does this step decide something? Moving is transport. Deciding is judgment. Almost everything I’d been lumping together as “a human has to do this” splits cleanly along that line.

The cleanest transport step I’ve ever measured happened the day I first drafted this. The X version of last month’s article was missing an affiliate disclosure line, which our own publishing checklist requires there specifically, because X has no footer to carry a standing one. I found it at 8:45 in the morning, on a phone. The work was pasting one sentence. I pasted it at 4:10 that afternoon, the first moment I was sitting at a desktop.

Seven hours and twenty-five minutes, and not one minute of it was work. It was all geography — a fix pinned to a location by a platform with no update call. That’s transport waste in its purest form, and it deserves every bit of the contempt my first draft had for it.

What that draft got wrong was aiming the same contempt at the other kind of step.

My original piece counted both as cost. That’s the actual root cause of the process problem, and it’s worse than a slow workflow — optimizing against a judgment step is how you build something fast that quietly ships errors.

I’ve made this argument before from the other direction, on my engineering site: the AI factory still needs humans. The reason isn’t sentimentality about human worth. It’s that quality is defined by the customer, and the customer is a person. Pass, fail, good enough, not good enough — those are judgment calls, and the standard lives in the head of whoever the work is for. Lights-out manufacturing is rare on real factory floors for exactly this reason: it’s not that machines can’t run unattended, it’s that quality is the first thing to slip when nobody’s checking, and “good enough” isn’t a value a machine can derive on its own.

An AI factory is no different. Mine builds fast. It does not yet inspect its own work well enough to be trusted alone — the four claims above are today’s proof, produced while writing the article that says so.

What that changes about the practices

The six practices below still stand. What changes is what they’re for. The goal isn’t the fewest human steps. It’s zero human transport steps, and protected human judgment steps — because every minute you don’t spend copy-pasting is a minute available for the part that actually needs you.

None of these makes the platform faster. They make the expensive step rare — so the necessary step gets the time.

Finish the text before it forks. Run grammar and style passes on the source of truth, upstream of any publish step, and the reconciliation problem disappears instead of getting automated.

Check the bytes you’re actually publishing. Our pre-publish checklist ran clean against the draft, but the published text is the only text a reader ever sees.

Treat a graphical-only surface as terminal, not editable. If a platform has no edit API, publish finished work to it — anything you plan to fix later costs a trip to a desk.

Score a platform before adopting it. Ask what fraction of the loop has an API — create, update, read back, delete — because the answer to update is what decides whether your mistakes are cheap or expensive, and it’s the one nobody checks first.

If a fork is unavoidable, automate the diff. Some platforms will never have an update path, and that’s fine — but then reconciliation should be a script that shows me the differences, not a person reading two copies side by side.

Keep an explicit “needs a desktop” list. Work blocked on a graphical step shouldn’t be discovered at the moment you want it done; it should already be written down, waiting for the next time you’re at a real machine.

One thing to try

Take one thing you publish or file or submit regularly and write down its steps. Then mark each one transport or judgment, using the question from earlier — not “could a script do this,” which is the question I got wrong, but “does this move information, or does this decide something?”

Automate every transport step you can reach. Then take the time that frees up and spend it on the judgment steps, which is where the quality was hiding the whole time.

And before you build a workaround, ask the cheaper question: is there an API for the step I keep doing by hand? That question has saved me weeks. The two times I skipped it, I spent those weeks getting very efficient at climbing a wall that had a gate.

Just don’t automate the inspector. That one’s still yours.

And when you are the inspector, check your own claims with the same suspicion you’d aim at a machine’s. The correction box above is in this article because I didn’t, on the one claim I never thought to doubt — my own account of my own tools.

This article was substantially reworked on 2026-08-02. The original version argued that human steps in a workflow are cost to be minimized. Checking the research for a follow-up piece is what showed me that half of them aren’t.

If this helps you, check out my adblob to support the work.