I Treat My Video Descriptions Like a Build Artifact Now. Here's the Pipeline.

Automate Better — Mon, 10 Aug 2026 17:00:03 +0000

I have a CI job that lints my commit messages. I have a pre-commit hook that yells at me about trailing whitespace. And until about four months ago, I wrote the description for every conference talk recording and tutorial video by opening an empty text box at 11pm and typing until it looked long enough.

That asymmetry started to bother me. Not because descriptions are precious writing. Because they're the opposite: a structured artifact with a fixed schema, assembled from inputs I already have, that I was producing by hand with no validation step and no way to reproduce.

So I did the obvious thing and treated it like one. Input contract, generation step, validation step, reuse. This post is what that pipeline looks like after four months and about thirty videos, including the parts that don't work.

Why a description is a build artifact and a blog post isn't

The distinction matters, because I wasted a month trying to systematise the wrong things.

A blog post is not a build artifact. The argument is the value, the structure follows the argument, and no two posts have the same shape. Automating that produces slop, and I stopped trying.

A video description is different. Mine have had exactly the same schema for two years: a first line or two carrying the thing people would actually search for, three or four lines of summary, chapter timestamps, links to the repo and the slides, a call to action, hashtags. The words change every time. The schema never changes at all. That is a template with variable interpolation, and I was doing the interpolation in my head, at midnight, badly.

Once I framed it that way, the design followed.

Step one: the input contract

The single biggest improvement had nothing to do with generation. It was writing down what the inputs are, so I stop trying to remember them at the end of an edit session when I'm tired.

I keep a small file next to the project for each video:

# video-meta.yml
topic: >
  Walking through how we cut cold-start time on a Lambda-backed
  GraphQL API from 2.4s to under 400ms, including the two things
  that didn't work.
target_keyword: lambda cold start optimization
audience: backend devs who already ship serverless, not beginners
model_channels:
  - the three channels currently ranking for this keyword
links:
  repo: https://github.com/...
  slides: https://...
chapters:
  - "00:00 The problem"
  - "02:15 Provisioned concurrency, and why we dropped it"
  - "07:40 Bundle size, the boring win"
  - "14:05 Results and what we'd do next"

Nothing clever here. But writing the contract down did two things. It made the generation step deterministic enough to be worth automating, and it moved the thinking to Tuesday afternoon when I'm planning the video, instead of Thursday midnight when I'm exhausted and will accept anything.

The target_keyword field is the one people skip. Skip it and you get a description that summarises your video accurately and matches nothing anyone types into a search box.

Step two: generation

For the generation step itself I use the AllyHub YouTube Description Generator, and the reason I use that one rather than a general chat model comes down to what it does before it writes.

A general model writes from priors. Ask it for a YouTube description about Lambda cold starts and you get the average of every description in its training data, which is fine and completely interchangeable. This one reads the descriptions of the videos already ranking for the keyword you gave it, then mirrors how those are structured and where they place terms. You're starting from what the niche actually looks like rather than a blank box.

I want to be precise about what that does and doesn't tell you, because I've seen this oversold. It can see what those descriptions say, because they're public text on a public page. It cannot see how those videos perform beyond what's on screen, and nothing here is a claim about why they rank. It's structural evidence, not a causal story. Treat it as "this is the shape of the neighbourhood" and you'll calibrate correctly.

The output comes back as one formatted block: keyword up front, body, chapter markers, links, CTA, hashtags. On a good run I change one or two lines because they don't sound like me. On a bad run I change four.

Step three: validation, which is the part everyone skips

This is where a pipeline earns its keep, and it's the part I see missing from every "just use AI for your descriptions" post.

Generation is cheap and mostly fine. The failure modes are boring and specific, and they're catchable. Here's what I check, in order, before anything gets pasted:

Check	What it catches	Automatable?
Keyword appears in the first 150 characters	The most common failure. The model writes a lovely opening sentence and buries the search term in paragraph three	Yes, string match
Every chapter timestamp exists in the actual video	Hallucinated or shifted timestamps after a re-edit. This one has bitten me twice	Yes, diff against the edit list
All links resolve and point where you meant	Repo link to the wrong branch, slides link still pointing at a draft	Yes, HEAD request
No claim in the description that the video doesn't make	The single most damaging failure, and the only one that hurts your credibility rather than your reach	No. Human read, every time
Hashtags are relevant and under the platform cap	Tag stuffing, or tags copied from a different video	Partly
It sounds like a person, specifically you	Generic phrasing that reads like every other description in the niche	No

The two rows marked "No" are why I don't call this automated. I call it assisted, and the distinction is load-bearing. The pipeline gets me from an empty box to a draft that's structurally complete. I still read it, and I'm still the one who hits publish, because the failure that actually costs something is a description promising a benchmark the video never shows.

Rows one through three I've since scripted, because they're pure string and network checks and I was doing them by eye at midnight, which is exactly the wrong time to do anything by eye.

The timestamp one deserves a story, because it's the failure I'd least expected and the one I now care most about. I re-cut a talk after publishing, trimming about forty seconds of a false start near the beginning. The video updated. The description didn't. So every chapter marker after the first was off by roughly forty seconds for two weeks, which meant every person who clicked "Bundle size, the boring win" landed mid-sentence in the previous section. Nobody told me. I found it myself, by accident, while linking someone to a specific chapter.

That is not a generation failure. The generator produced correct timestamps for the cut it was given. It's a pipeline failure, in exactly the way a stale build artifact is a pipeline failure, and the fix is the same: make the check cheap enough that it runs every time rather than when you remember. Mine now diffs the chapter list against the final edit's marker export and refuses to pass if the counts differ.

Step four: reuse, which is where the time actually comes back

The first video through this pipeline was slower than doing it by hand. That's normal for any pipeline and I want to say it clearly, because posts like this tend to skip the part where the setup costs you an evening.

The gain shows up on repetition. The channel's voice, my link block, my chapter formatting, the fact that I want the keyword front-loaded and the CTA short, all of that gets saved as a reusable setup rather than re-explained per video. AllyHub calls the saved version a Playbook; the name doesn't matter, the property does. Run two starts from run one's configuration instead of from zero, and the corrections I made on run one are part of that configuration rather than sitting in a chat log I'd have to go find.

This is the bit I'd push back on if someone described the whole category as "AI writes your descriptions." Plenty of things will write you a description. The question I'd ask of any of them is what survives the run: if next week's video starts from the same empty box as this week's, you've bought an output, not a pipeline, and the thirty minutes comes back exactly once.

The second effect I didn't expect: batching stopped being painful. I record talks in clusters, so I'll have four videos edited and none published because writing four descriptions in a row is miserable. Handing the whole queue over in one pass, each one drafted against its own topic and keyword rather than one template smeared across all four, took the backlog from a Thursday evening to about twenty minutes of reading and editing.

That's the actual win, and it's not a dramatic one. Roughly thirty minutes per video down to under ten, on something I do weekly.

What I got wrong

I tried to validate quality. I spent a while building checks for whether the description was "good," which is not a thing a string match can tell you, and I eventually deleted all of it. The pipeline checks structure and facts. Quality is a human read, and it's a fast one once structure is guaranteed.

I also over-fit to my first keyword. The structural evidence for lambda cold start optimization is not the structural evidence for graphql schema design, and for a while I was carrying over conventions from one niche into another because they'd worked once. Regenerate per keyword. It costs nothing.

And I under-invested in the input contract for about six videos, filling it in hastily and then being annoyed at the output. Garbage in, structurally-valid garbage out. The contract is the leverage point, not the generator.

If you want to try this

Take your last five video descriptions and diff them. If they share a schema, you have a pipeline problem, not a writing problem, and everything above applies. If they don't share a schema, you probably don't need any of this.

Then write the input contract before you write anything else. Topic, keyword, audience, links, chapters. Five fields, filled in while you still remember what the video is about.

Generate, validate, read it yourself, publish.

One thing worth saying plainly at the end: none of this is a ranking strategy, and I'd be lying if I presented it as one. Whether a video gets found comes down to the video and who else made one about the same thing. What a pipeline fixes is the part where a finished video sits unpublished for three days because writing the box underneath it felt like more work than editing the thing did.

For me that was the real cost. It turned out to be a build problem all along.

DEV Community: Automate Better