PTN—08
Constraints & Tuners
Expose the request’s key parameters as explicit controls instead of burying them in prose.
Some intent is categorical, not conversational. Length, tone, format, aspect ratio, model choice, search scope — these are parameters, and making people express parameters in prose is a design failure. A tuner turns “make it shorter and more formal, and can you do it as a table” into three controls that are discoverable, repeatable, and impossible to misparse.
Tuners do double duty as capability disclosure. A blank box tells you nothing about what the system can vary; a row of controls for tone, length, and format tells you exactly which dials exist. This is why image tools lead with them — Midjourney’s parameters and style controls teach the space of possible outputs faster than any onboarding tour could.
The discipline is selectivity. Every tuner you add is UI weight on every request, so expose only the parameters people actually change, defaulted to the common case, and let prose override everything. A tuner should never be the only way to express something the model understands in natural language — controls and prose are two surfaces for the same intent, and the controls must lose gracefully when they conflict with an explicit written instruction.
The pattern earns maturity through pruning, not accumulation. Early versions of most AI composers ship optimistic control rows; usage data then shows two dials doing all the work. The mature move is Notion AI’s: collapse the long tail into a menu, keep “make shorter” and “change tone” at the surface, and let telemetry — not stakeholder wishlists — decide what stays. Watch for the deeper tell of health: tuner adoption should shorten prompts over time. If people still type “keep it brief” while a length control sits inches away, the control has failed its only job — being cheaper than the sentence it replaces.
When to use
- A handful of parameters — length, tone, format, scope — dominate how requests vary.
- People retype the same modifier prose (“keep it brief”, “as bullet points”) across requests.
- The output space is wide and users cannot discover the dimensions from a blank box.
- Regeneration is common and people want to change one dimension without rewriting the prompt.
Design considerations
- 01Expose only the two or three parameters people actually change; put the rest behind a disclosure.
- 02Default every tuner to the common case so ignoring the controls entirely still works.
- 03Let written instructions override tuner settings, and make the precedence rule consistent.
- 04Persist tuner state across regenerations so people can iterate on one dimension at a time.
- 05Label tuners in the user’s vocabulary — “Shorter”, not “max_tokens”.
- 06Reflect active non-default tuners visibly near the composer so the request’s full shape is legible.
- 07Pair each generated output with the settings that produced it, so results are reproducible.
Pitfalls
- ✕Tuner sprawl — a dozen dropdowns that turn a composer into a settings page and slow every request to protect the rare one.
- ✕Ghost tuners: controls the model quietly ignores, which teaches people that none of the controls can be trusted.
- ✕Silent conflicts — the tone dropdown says “formal”, the prompt says “casual”, and the system picks one without telling anyone.
- ✕Sticky state surprise: a tuner set three sessions ago still applies, and nobody can see why every answer comes out weird.
In the wild
- Notion AI
- One-tap transforms — make shorter, change tone, translate — turn the most common rewrite parameters into menu items instead of prompt prose.
- Midjourney
- Aspect ratio, stylize, and variation controls parameterize image generation, teaching the output space through the dials themselves.
- Perplexity
- Source-scope focus controls (academic, web) constrain where answers draw from without any prompt engineering.
- GitHub Copilot
- Model pickers and slash commands in chat let developers set the engine and task type as controls rather than instructions.