DEV Community: Terry Shine

The hard part of an AI quiz generator isn't the questions — it's the wrong answers

Terry Shine — Thu, 11 Jun 2026 09:14:39 +0000

If you wire an LLM up to "write me 10 multiple-choice questions about photosynthesis," you'll get something that looks great in the demo and falls apart the moment a real student uses it. I've been building a quiz generator for a while now, and almost all of the actual engineering went into things that have nothing to do with generating the question text. Here are the problems that turned out to matter.

1. The distractors are the whole game. A multiple-choice question is only as good as its wrong answers. If the three distractors are obviously wrong — different category, absurd, or grammatically mismatched with the stem — the student picks the right answer by elimination without knowing anything. Good distractors have to be plausible: common misconceptions, adjacent concepts, the answer to a slightly different question. Getting an LLM to produce genuinely tempting wrong answers (rather than filler) is much harder than getting it to produce the correct one, and it's where most generated quizzes quietly fail.

2. Answer leakage. LLMs love to give the game away. The correct option is subtly longer, or more precisely worded, or the only one that's grammatically consistent with the stem. Humans pick up on these tells unconsciously. You have to actively normalize option length and phrasing so the correct answer doesn't stand out, and check that the stem doesn't contain a word that only appears in the right option.

3. Exactly one defensibly-correct answer. This is the bug that erodes trust fastest. The model writes a question where two options are arguably correct, or where the "correct" one is wrong on a technicality. You need a validation pass — ideally a separate check — that confirms the keyed answer is unambiguously right and the others are unambiguously wrong, and discards or regenerates anything that isn't.

4. Coverage from messy source material. When the input is a PDF or a wall of pasted notes, the easy failure mode is to generate five questions about the first paragraph and ignore the rest. Useful generation means chunking the source, spreading questions across the material, and skipping boilerplate (headers, references, page furniture) so the quiz reflects the whole document, not just whatever was at the top.

5. Knowing what you're bad at. Fact-dense material — biology, history, vocabulary, definitions — generates well. Multi-step reasoning, math proofs, and anything where the "question" is really an argument generate poorly, and it's more honest to be upfront about that than to emit confident garbage.

None of this is glamorous, and none of it shows up in a 30-second demo. But it's the difference between a quiz a student can actually study from and four random options where the wrong ones are obviously wrong. If you want to see how it holds up on your own material, you can paste a topic, notes, or a PDF into Quiz Maker — it's free and there's no signup to generate. I'm genuinely interested in where it still breaks, so if you find a subject where the distractors fall flat, that's useful to know.

How to Transcribe a YouTube Video (Free, in Under a Minute)

Terry Shine — Wed, 10 Jun 2026 06:55:21 +0000

Building a "paste a YouTube link, get a transcript" feature sounds trivial until you deploy it to a server. The moment your request comes from a datacenter IP instead of a residential one, YouTube responds with LOGIN_REQUIRED or quietly serves nothing. Here's how VidTranscriber handles it.

The problem

There are two ways to get text from a YouTube video:

Existing captions — if the uploader (or YouTube's auto-caption) provides them, you can fetch the caption track directly. Fast, free, no transcription needed.
Transcribe the audio — pull the audio stream and run it through a speech-to-text model (Whisper-family). Works for any video, but costs compute.

Both start with talking to YouTube from your server — and that's where it breaks. YouTube aggressively gates datacenter traffic: the watch page and InnerTube API return LOGIN_REQUIRED, and naive audio fetching gets reCAPTCHA'd.

The approach

The fix is to separate where the request originates from where the work happens:

A Cloudflare Worker handles the user request and orchestration.
Caption/audio fetching is routed through a path whose egress isn't treated as a bot — so the LOGIN_REQUIRED wall doesn't trigger.
Captions, when available, become the primary path (no transcription cost). Only when there are no usable captions do we fall back to downloading audio and running Whisper.
Long jobs go onto a queue (Cloudflare Queues) so the request returns immediately and the transcript streams in as it completes.

Why captions-first matters

Most "transcript generator" traffic is for videos that already have captions — talks, tutorials, news. Serving those from the caption track is instant and free, which means the expensive Whisper path is reserved for the minority of videos that actually need it. That's the difference between a tool that's cheap to run and one that isn't.

What's still hard

IP reputation drifts — what works today can get throttled tomorrow, so the extraction path needs monitoring and fallbacks.
Caption quality varies — auto-generated captions lack punctuation and speaker labels, so for quality output we sometimes re-transcribe even when captions exist.
Very long videos need chunking to stay within memory and timeout budgets.

Try it

If you want to see the captions-first path in action, paste any public video into the YouTube transcript generator — 60 minutes free, no signup.

Introducing VidCompress: in-browser video compression for developers who hate uploading files

Terry Shine — Thu, 04 Jun 2026 15:02:40 +0000

I got tired of the same routine. You want to shrink a video, you search for a "free online compressor," and it makes you upload the whole file to a server, sit in a queue, and then hands it back with a watermark on it. On a slow connection, a 200 MB clip means uploading 200 MB and pulling it back down again, just to make the thing smaller. And now your footage is sitting on somebody else's machine.

So VidCompress does it backwards. If the file is under 300 MB, the compression runs in your browser and the video never gets uploaded anywhere. Here's roughly how that works, and the parts that still give us trouble.

WebCodecs does the heavy lifting

Browsers have shipped a low-level media API called WebCodecs for a while now — VideoEncoder and VideoDecoder. It hands JavaScript the hardware encoder more or less directly, which is the only reason any of this is possible. You decode the source into raw frames, re-encode them at a lower bitrate, and stuff the result back into an MP4. No server in the loop.

Roughly:

Demux and decode the source with VideoDecoder.
Re-encode the frames with VideoEncoder at a bitrate worked out from the size you're aiming for.
Mux the new chunks into an MP4.

When the OS exposes a hardware encoder — most do these days — this is usually quicker than the upload would have been. And it's private for the obvious reason that nothing leaves your machine.

The annoying part is knowing when it won't work

WebCodecs is great until it isn't. Support is uneven across Chrome, Safari and Firefox. Some files just won't decode — older codecs, odd color spaces. And a long 4K video will happily eat all your memory halfway through the encode.

So most of the real work went into failing gracefully, not the happy path. We sort the failures into a few buckets:

LOCAL_OOM — ran out of memory mid-encode.
UNSUPPORTED_CODEC — the browser can't decode this input.
NO_HARDWARE_PATH — no fast local route on this browser at all.

When one of those fires you don't get a cryptic error. The job quietly retries on a server-side FFmpeg path (CRF-based) instead. Anything over 300 MB skips the browser entirely and goes straight there.

That split — local first, cloud only when it has to be — is basically the product. Phone clips, screen recordings, Discord gameplay captures: small enough to stay on your device and finish in seconds. The occasional giant 4K master still works, it just takes the slower road.

You pick a size, not a "quality"

Nobody opening a compressor is thinking in CRF or bitrate ladders. They're thinking "it has to fit Discord" or "it has to go through email." So we work backwards from the target size instead of asking people to guess a quality slider:

target_bitrate ≈ (target_size_bytes * 8) / duration_seconds - audio_bitrate

The presets are just the limits people actually run into:

Destination	Limit	Preset target
Discord (no Nitro)	10 MB	under 10 MB
WhatsApp	16 MB	under 16 MB
Email (Gmail / Outlook)	25 MB	under 25 MB
Social / Telegram	—	~50 MB

If you don't care about a specific app, the plain video compressor just lets you type a number of MB. Either way the job is the same: hit the size, and spend whatever bitrate is left where your eyes will actually notice, so you don't lose quality you'd care about.

Where it still falls down

A few things I'd rather just say out loud:

Long 4K on a cheaper laptop or a phone will OOM. It's the number-one reason a job ends up on the cloud path.
Safari trails Chromium on WebCodecs, so the local route shows up more often in Chrome and Edge.
Multiple audio tracks or unusual audio codecs get punted to the server too.

If you want to twist every knob yourself and you're sat at a desk, HandBrake is honestly still the better tool — I wrote down where we differ from HandBrake if you're weighing it. You're trading an install and a learning curve for "drop a file in a tab, get it back smaller."

So why do the browser thing at all

Mostly privacy. A pre-launch demo, something medical, a private clip — it just never goes anywhere. Speed is the other reason: no upload, no queue, so short clips are done almost instantly. And because there's no server bill on the local path, there's nothing to lock behind a signup or stamp a watermark on.

If you've ever bailed on a compressor because it wanted to upload your file, make you wait, then watermark it — give this one a try. Under 300 MB it stays in your browser. No account, no watermark.

Classroom quiz templates that save teachers prep time

Terry Shine — Mon, 11 May 2026 13:18:01 +0000

Teachers do not need another flashy quiz tool.

They need a faster way to turn lesson material into something they can actually use in class.

That is why I think template-based quiz creation is more useful than a generic “AI quiz maker” pitch.

The real classroom problem

Most quiz workflows break in one of two places:

building the first version still takes too long
the output is too generic to use without cleanup

A useful classroom quiz workflow should help with:

daily checks
lesson wrap-ups
formative assessment
fast comprehension checks after reading or explanation

Why templates help

A template gives you a starting structure before you add AI.

That matters because classroom quizzes are not just “questions about a topic.”
They usually need the right balance of:

clarity
question variety
age-appropriate phrasing
reasonable difficulty
quick editability for a real lesson plan

A simple workflow I like

Start from the lesson goal

What should students prove they understood?
Use a template instead of a blank page

This cuts setup friction immediately.
Generate a first pass

Use the source material, not just a topic label.
Edit for your classroom

Tighten wording, remove ambiguity, and adjust difficulty.

One template worth testing

If you want a practical starting point, this classroom page is a good example:

Classroom quiz template

I like this direction because it frames the tool around a real use case:

save prep time
create daily checks faster
move from lesson material to usable quiz without starting from scratch

The bigger takeaway

For education tools, “AI” is not the selling point.

Time saved before class starts is the selling point.

That is the bar I would use for any quiz workflow.

If you build or use classroom quizzes, I’d love to know what matters most in practice:

speed?
question quality?
editability?
alignment with lesson goals?

How to make ChatGPT text sound more human without rewriting from scratch

Terry Shine — Mon, 11 May 2026 13:17:59 +0000

Most AI writing does not fail because the ideas are bad.

It fails because the tone feels slightly off.

You can usually spot the pattern fast:

too polished
too uniform
too many generic transitions
not enough sentence rhythm variation
meaning is technically right, but it still doesn't sound like a person would send it

That is the part people mean when they say "this sounds AI-written".

What I change first

When I try to make ChatGPT text sound more human, I do not start by rewriting everything.

I start with four smaller fixes:

Flatten obvious filler

Phrases like “delve into,” “in today’s fast-paced world,” or “it is important to note” make text feel synthetic fast.
Restore sentence variety

AI often produces paragraphs where every sentence has the same length and cadence. Real writing usually has more rhythm.
Keep the original intent

The goal is not “sound random.” The goal is “keep the meaning, lose the robotic layer.”
Make transitions less formal

A lot of AI writing reads like it is trying too hard to sound complete. Human writing often sounds more direct.

Where this matters most

I see this show up most often in:

personal statements
cover letters
emails
essays
landing page copy
first drafts of blog posts

In all of those cases, the issue usually is not content generation.
It is tone correction.

A simpler workflow than full rewrites

The workflow I prefer is:

generate the first draft
identify the lines that feel robotic
preserve the core meaning
rewrite only the places where tone breaks trust

That gets you closer to writing that still says what you want, but sounds less machine-shaped.

One useful tool I tested for this

If you want a fast starting point, I’ve been using this page for the humanize step:

Humanize AI text

The reason I like this angle is simple: it is less about “magic detection bypass” claims and more about practical editing — preserving ideas while reducing robotic phrasing.

The real question

The useful question is not:
“Can this beat a detector?”

The useful question is:
“Would I actually feel okay sending this under my own name?”

That is a much better editing standard.

If you work with AI drafts a lot, I’m curious what you usually fix first:

tone?
repetition?
sentence rhythm?
word choice?

How we compare OpenClaw skills without collapsing everything into one fake score

Terry Shine — Mon, 11 May 2026 13:10:42 +0000

If you're trying to decide which OpenClaw skills deserve attention first, a giant list doesn't help much.

The harder question is this:

How do you compare two promising skills without collapsing everything into one fake score?

That's the problem we're trying to solve at SkillsReview.

Why a single score usually fails

Users don't actually evaluate skills on just one dimension. In practice, people care about a mix of:

task fit
security posture
install friction
update activity
real usefulness in repeated workflows

The moment you mash those into one mysterious number, you lose the part that helps people make a decision.

What a better compare flow looks like

A useful compare flow should help users do three things:

Shortlist faster — remove obvious mismatches early
Inspect tradeoffs — see where one skill is stronger than another
Stay grounded — understand why something ranks the way it does

That is why we’ve been pushing SkillsReview toward a free-first discovery path instead of a “trust us, here’s the winner” model.

The 3 pages we think matter most right now

We recently added three cluster guides that support that workflow:

Together, they cover:

how to get from discovery to shortlist
how to compare candidates without flattening nuance
how to keep watching the ecosystem without another paid dashboard

The real positioning shift

The point of a directory is to answer what exists.

The point of a ranking is to answer what should I try first.

The point of a compare page is to answer which tradeoffs actually matter for my use case.

Those are different jobs. When one page tries to do all three badly, users bounce.

Where we’re going with SkillsReview

The direction we're betting on is simple:

free discovery first
deeper evaluation second
real install intent after that

If you're building around OpenClaw, I'd love to know what matters most in your own evaluation flow:

security?
speed to install?
reputation?
repeatable task value?

If you want to dig into the current approach, start here:

Best OpenClaw Skills 2026: Tested & Ranked

Terry Shine — Mon, 20 Apr 2026 14:32:38 +0000

If you're trying to get real value out of OpenClaw quickly, browsing a giant directory isn't going to cut it.

The question most users actually have is much simpler:

Which skills are worth installing first?

That's the gap we've been trying to close — replacing "here are more skills" with "here's what to try first."

The problem with raw discovery

Most ecosystems run into the same discovery overload problem:

too many options
weak prioritization
no obvious first-install path
editorial picks and real user feedback blurred together

A list answers "what exists?"
A ranking answers "what should I try first?"
A best-of page answers "what's the fastest useful starting point?"

Those are three different jobs, and treating them the same is why users bounce.

What actually makes a skill useful

The skills that keep earning their spot usually do well on four things:

Real task value — does it help with recurring work?
Clarity — can you tell what it's for in about 10 seconds?
Ease of adoption — is setup reasonable?
Reusability — does it survive past the first experiment?

The strongest skills are rarely the flashiest. They're the ones that quietly keep showing up in real workflows.

What the current top layer looks like

Pulling from live SkillsReview production ranking data, the top cluster right now includes:

clawhub
feishu-doc
coding-agent
obsidian
weather
feishu-wiki
coding-agent-common
feishu multi-agent messaging

What's interesting about this mix is that it's not just coding. The ecosystem is clearly pulling in three directions at once:

docs and knowledge flow
communication and coordination
repeatable workflow leverage

A better first-install strategy

If someone asked me for the shortest useful OpenClaw starter stack, I wouldn't tell them to install 15 skills.

I'd go with three:

1 core ecosystem skill
1 workflow-aligned skill (coding / research / docs)
1 automation, communication, or utility skill

Three skills give you real signal without burying you.

One trust rule that matters

This one's especially important for any review or ranking product:

Editorial recommendation ≠ real user reviews

Both have value. But if you mash them into a single fake "everyone agrees" score, people stop trusting the page. A ranking page has to be clear about where its logic is coming from.

Why this matters now

SkillsReview sits in an interesting spot — there's already real search traction in a niche where discovery intent is still forming.

Which means the next problem isn't "get attention." It's:

turning impressions into deeper browsing
turning curiosity into a first useful install
making best-of, list, and ranking pages each do their own job well

Useful entry points

If you want the practical shortlist:
👉 https://skills-review.com/best-openclaw-skills-2026

If you want the broader browse path:

What's in your own OpenClaw starter stack? Curious which three skills you'd keep if you had to cut the rest.