Developers rarely stall on Shorts for lack of ideas — you have a backlog of things you've explained twice already. The stall is that every one of them looks like an afternoon of production. Here's the version that isn't, and the parts of it that are genuinely still hard.
There's a specific kind of developer who keeps almost starting a YouTube channel. You've explained the same thing in three PR reviews. You've written the Slack message about why the migration needs a backfill, twice, to different people. You know that's a video. You also know that making it means a screen recorder, a decision about whether your face is in it, forty minutes of trimming, and a caption pass — so it stays a Slack message, and the channel stays empty.
This is about the part after "I should make Shorts": what's actually worth making, why the obvious production route fails specifically for code, and what a loop looks like that you'd still be running in two months. It assumes you don't want to be on camera and don't want to learn an editor. Both are fine, and neither is the real constraint.
The advice to "find content ideas" is aimed at people who don't have a job. You do, and it generates the ideas for you. Three places to look, in descending order of how well they work:
What doesn't work is picking a topic because it's searched a lot. A Short isn't found through search; it's pushed to people who weren't looking for it. That inverts the usual developer-blog instinct — you're not answering a query, you're interrupting a scroll with something specific enough to be surprising. "What is a database index" loses to "your index isn't being used and here's the one-line way to check."
Three constraints do most of the work of deciding what a Short can be, and it's worth internalising them before writing anything rather than discovering them in the edit.
Vertical means one thing on screen at a time. A 9:16 frame at phone size fits roughly a dozen lines of legible code, or one diagram, or one chart. Not a split view. Not an IDE. If your explanation needs the file tree and the terminal and the browser visible simultaneously, it isn't a Short — it's a two-minute video with a different shape.
Under a minute means one idea, proven once. Not one topic — one idea. "Async/await" is a topic; "await inside a loop runs your requests one at a time" is an idea, and it fits. The test is whether you can state the payoff in a single sentence before you start writing.
The first two seconds decide everything else. This is the part that transfers worst from written technical content, where you're allowed a paragraph of setup because the reader already chose to be there. A Short viewer chose nothing. The opening line has to be the claim, not the introduction to the claim — and if you rewrite exactly one line of a draft, it's that one.
The obvious route is: record your screen, crop it to vertical, post. It's obvious because it's what works for gameplay and cooking, where the interesting thing is large and moves. It reliably fails for code, for two reasons that don't have a settings fix.
The first is legibility. A desktop editor at a normal font size, cropped to a phone-width column, produces text somewhere around unreadable at arm's length — and the reflex fix, zooming in until it's readable, means four lines fill the frame and the viewer loses the shape of the function. You end up choosing between text nobody can read and context nobody can see. The fix isn't a better crop; it's rebuilding the code as something designed for the frame in the first place — a code card sized for 9:16 rather than a photograph of your editor.
The second is that a recording is finished the moment you stop it. Rename the flag next release and the video is wrong; there's no edit, only a re-record. That's tolerable for one video and a real tax on the tenth, which is exactly when a channel starts being worth something. It's the same baked-pixels problem that makes most AI video tools useless for technical content, arrived at from the other direction.
The alternative is to treat each beat as an object rather than a frame: a terminal that types out a command, a syntax-highlighted card holding real code, a diagram, a chart. Scenes stay editable until you render, which means fixing a typo in scene three is a text edit rather than a re-take, and updating the video in November is a diff.
Most developers asking about Shorts are really asking whether they can avoid being on camera. You can, and for this kind of content it's often the better call — but not for the reason it's usually given.
The bad reason is "nobody watches the face anyway." People do; a face carries trust, and for opinion or career content it's most of the value. The good reason is that in a technical explainer, the code is the subject. A picture-in-picture head in the corner of a 9:16 frame is competing for the ten percent of screen space you needed for the last line of the snippet. When the thing being explained is visual and precise, the camera is a cost.
What genuinely does need a person is your voice — not literally your recorded voice, but the specificity of someone who has actually hit the problem. "This is a common pitfall" is nobody. "I lost a day to this because the error names the wrong file" is you. Whether that gets read by you or by a synthetic narrator matters far less than whether the sentences could only have been written by someone who did the work. If you do want your own read, recording sixty seconds of audio is a much smaller commitment than recording sixty seconds of video, and you can clean it up by word afterwards rather than re-taking the whole thing.
Worth naming directly, because it's the reason a lot of developers won't touch AI-assisted video at all: the first comment on a technical Short is now sometimes an accusation that a model made it. That accusation lands on people who used no AI whatsoever, which tells you it isn't really about tooling — it's a judgement about whether the video contains anything only a person could have put there.
The tells people are actually reacting to are consistent and avoidable: narration that restates what's on screen, generic stock visuals with no relationship to the specific claim, an explanation that would be identical for any of forty topics, and a confident tone about something the video never demonstrates. None of those are caused by using a tool. They're caused by shipping a draft.
The practical defense is the same thing that makes the video good: real specifics. The actual error string. The actual version where the behavior changed. The number you measured, with the caveat attached. A sentence about what you tried first that didn't work. Those cost you a few minutes of review and they're precisely what a generic draft doesn't contain — which is also why the review step below isn't optional overhead.
The version that survives past the third video is boring and has four steps. The point is that none of them is a production.
The reason the loop is shaped this way — capture continuously, produce in one pass — is that developer content has a short shelf life against the work it describes. A Short about last week's migration is interesting; the same Short in six weeks is a blog post. The loop optimises for shipping while it's still true, not for polish.
Honest numbers, with the caveats attached, because this is exactly the claim the category has burned people on.
Developers and technical creators who describe their own hand-edited short-form workflow in public land somewhere between three and ten hours per finished Short. Both endpoints are things people actually wrote: "a good 3-4 hours editing a 30-45 second short" at the floor, "anywhere from 5-10 hours editing my short" at the top, with the common framing being one to two and a half hours of editing per finished minute. That range comes from reading 25+ public comments, not from a survey and not from anyone using this tool — but it's the baseline being replaced, and it's why most of these channels have four videos and then nothing. Our own measurement of the agent-driven path, for a 60–90 second reel, was 45–60 minutes elapsed with 10–20 minutes of that hands-on — the gap being time spent waiting on generation and rendering rather than working. That figure is one person, and that person built the tool, so treat it as a floor and not as a typical first result. It also only covers the agent-driven path; the step-by-step web flow is unmeasured.
The part worth being precise about is what the remaining time is spent on. It isn't operating a timeline — it's reading a script, asking for changes, checking the scenes, and catching the thing that's wrong. That's supervision, and it doesn't disappear. Any version of this that promises it disappears is describing a video nobody reviewed, and you can generally tell which of those you're watching.
Most publishing advice for Shorts is written for a different audience and mostly doesn't transfer. Four things that do matter for technical content:
And the unglamorous one: post the video where the people who'd care already are. A Short embedded in your release notes, linked from the docs' getting-started, or dropped in the issue thread where someone asked the question does more early work than the recommendation algorithm will, because it reaches people with the problem instead of people scrolling.
Three cases where the approach here is the wrong one, stated plainly so you don't spend a week finding out.
If the interesting thing is the interaction — a debugger session, a REPL, a UI responding to input — you need a real recording, because the value is in watching it actually respond. Component-built scenes can show the before and the after; they can't show the feel of the thing.
If the content is your opinion or your career, the camera is the point and skipping it removes most of the value. Nobody follows an argument about engineering culture from an anonymous code card.
And if the explanation genuinely needs four minutes, make the four-minute video. A Short that compresses a tutorial into fifty seconds isn't a Short, it's an unusable tutorial — the honest move is the long version plus, optionally, one Short pulling out the single most surprising thing in it.
The first video is not a channel strategy; it's a test of whether the loop above is tolerable for you. So pick the thing you've already explained to two people — the explanation is written, the specifics are in your head, and you know it lands. Draft it against the real source, spend your review time on the first line and on every command on screen, render it, and put it on your own channel.
Then look at what it cost you. If it was an afternoon, the loop is wrong somewhere and it's worth finding out where before video two. If it was closer to an hour, you have something you can actually keep doing — which, for a technical channel, matters considerably more than any single video being good.
Get one practical MCP-video tip when we publish the next post — no more than that.
Point your agent at a video pipeline that speaks MCP and make one small thing. Free founding-creator pilot — your keys, no watermarks.
Create your studio — free pilot