Most teams fight repetitive AI output by writing more rules. “Make it varied.” “Justify why this page needs this content.” One builder of AI-generated lessons tried exactly that, and the result stayed stubbornly the same: a range slider in 18 of 20 lessons. This approach does something simpler, and it works better: give the model a named thing to fill in instead of a principle to remember.
The key idea, from a r/PromptEngineering post by u/Gleb_SV, is that instructions describe what you want, but the model copies what is already on the page. A vague goal like variety has nothing concrete to attach to. A named block does. Think of it like ordering at a restaurant. “Something different” gets you the house special every time. “The mushroom risotto” gets you the risotto.
The old way: rules and bigger toolkits
The setup is a team of agents. A planner writes the lesson plan, and a builder writes the code. Two fixes failed:
- Prompt rules. Adding lines like “explain what visible effect each control has” made the planner’s explanations nicer. Sliders still showed up in 4 of 4 lessons. The rule improved the prose around the control but never touched the choice of control.
- More components in the kit. Ready-made chart components were available, but the builder used them in 0 of 4 lessons. It hand-drew charts instead, because the plan never asked for one by name. A bigger toolbox did nothing when no instruction pointed at a specific tool.
Both fixes assume the model will browse its options and pick sensibly. It won’t. It reaches for the most concrete pattern it has already seen, and a slider is about as concrete as UI gets. One commenter noted the same thing happens with image prompts in a series: the model copies the most concrete thing it can see. If your first output contains a pattern, expect the next one to contain it too.
The new way: a fixed menu and a required field
Two changes made the difference:
- 🧩 The planner must name a specific block for every interactive page, picked from a fixed list. Next round, 9 of 9 interactive pages used the named block. The choice moved from the builder’s habits to the planner’s explicit decision, where you can read it and check it.
- 📝 Every page needs an “input” field (slider, drag, scrub, reorder, typed answer, code task), and a check rejects plans with too little variety. Lessons with drag or scrub went from none to 4 of 4. Sliders did not vanish, but they stopped being the only option.
Notice what changed here. Nobody told the model to “be creative.” The pipeline now has a slot that must be filled with a specific word, and an empty or repeated slot fails fast. That is a contract, not a wish.
How to apply it to your own pipeline
- Count first. Tally which component or layout your model uses across 20 outputs. If one dominates, you have default-component bias. A simple spreadsheet column is enough.
- Make a short, fixed list of allowed blocks. Name each one clearly, and add one line on when it fits. Five to eight entries is plenty. A long menu invites the same lazy pick.
- Add a required field to your plan format, such as “block” or “input type”. An empty field should fail validation, and so should a value that is not on the list.
- Add a cheap variety check that rejects plans where one choice repeats too much. A rule like “no single input type on more than half the pages” takes a few lines of code and no extra model calls.
- Put the call in the starter file. The author found that after changing how the builder runs, first builds skipped the named chart in 4 of 6 runs, and rebuilds ate 38% of that round’s spend. Pre-filling the call and letting the builder fill only the data is the fix they are now testing. No numbers yet, so treat it as promising, not proven.
A caution from the comments
One commenter pointed out that a variety quota can reward unsuitable interactions. A drag-and-drop on a page that really needs a typed answer is variety, but it is bad teaching. Their suggestion: have the planner name the learner’s action first (predict a value, order steps, diagnose an error), then map that action to eligible blocks. That keeps the menu honest. Another asked whether a sample lesson in the planner’s context is anchoring the slider choice, which is worth ruling out by swapping in an example with a different interaction. And one reader argued that naming blocks is a patch for a deeper context-window problem: the model sees a few existing components and fills the space with the same pattern.
They may all be right. The patch still works today, and it costs almost nothing to test.
Your move
Pick one place where your generated output feels samey. Count the pattern, write the menu, add the required field, and rerun. Compare the tally before and after, and keep the numbers so you can see what actually moved. If you find a cleaner fix for default-component bias, share it with the community. Captain YAR would love to hear it!
Frequently Asked Questions
Q: Could the example in the planner’s context be causing the slider habit?
Possibly, and it’s the cheapest thing to test. One commenter suspects a sample plan with a slider anchors the planner’s choice. Swap that example for a lesson built on a different input, like drag or a typed answer, and see whether the slider count drops before you add more rules.
Q: Should you name a block, cap the default, or map the learner’s action first?
Commenters split on this. Some found that a forced picklist of named blocks ends the repetition. Others capped the favorite instead, for example ‘slider: allowed at most once per lesson’, which worked better than asking for creativity. Another suggestion is to have the planner name the learner’s action first (predict, order, or diagnose) and then pick from the blocks that fit it, so a variety quota doesn’t push in unsuitable inputs.
Q: Is naming a block enough, or do you need to change what the model sees?
One commenter argues that a named block is only a patch. The few components already in the code set a visual pattern that outweighs any variety instruction, so their fix is to break that precedent at the source. If the builder only ever sees slider code, expect sliders no matter what the plan says.
Q: Does the same bias show up outside UI code?
Yes, according to a commenter who generates image series. Give each item a fixed slot (subject, action, one detail) with a short list of allowed values for the slot that tends to collapse. Then count before you accept the batch, asking something like ‘how many of these are centered close-ups?’
The model put a slider in 18 of 20 lessons. Telling it to vary didn’t help. Naming a ready-made block did.
by u/Gleb_SV in PromptEngineering