Own the Latency, Don't Hide It

"Every trick that makes software feel fast by hiding a choice is a place where the software decided something for you and didn't say so."

Speed Is a Choice, So Make It Visible

Flint could have hidden its speed decisions. It could pick 'fast' or 'thorough' automatically, guess when to use context, and quietly choose a model — and the app would feel simpler. Instead it makes the tradeoff explicit: the vault dial is per-macro, the model tier is a stated choice, and every request carries those decisions openly. Speed is not something Flint does to you behind the scenes; it's a curve you sit on deliberately, macro by macro. Owning the latency means the person paying the wait is the person who chose it.

No Hidden Performance Switch

The sharpest form of this rule is a specific refusal: an empty soul or a missing field must never quietly become a fast path. It would be easy to say 'no persona set? skip the context, run faster' — a hidden optimization that silently changes what the model knows about you. Flint forbids that. The vault choice is explicit on the wire every time (Track 4), so a request never sends more or less context than the macro stated. A performance win you get by silently dropping context is a decision made for the user without telling them.

HIDDEN (rejected)              EXPLICIT (Flint)
----------------------------  ----------------------------
empty soul -> skip context    vault mode is stated per macro
guess a model by input        tier is a named choice
auto 'fast when short'        the dial is the user's to set

Every hidden default is a decision the user didn't make and can't see.

Explicit Beats Magic

The same preference shows up in Simple versus Verbose: the modes change only how much is explained, never what happens, so there's no hidden behavioral difference lurking behind a presentation toggle. Across the app the pattern is consistent — expose the knob, state the choice, carry it openly. Magic that guesses well most of the time is worse than an explicit control, because when the guess is wrong the user has no way to see why, and no way to fix it. An honest knob beats a clever default.

Expose the cost; never optimize by hiding a default. It is always tempting to make software feel faster or simpler by choosing for the user silently — dropping context, guessing a mode, picking a model. Resist it whenever the choice has real consequences the user would care about. Put the decision where they can see and change it, and let them own the tradeoff. A visible knob they rarely touch is better than an invisible default they can never question.

Beware the optimization that changes behavior while pretending to change speed. The dangerous hidden default isn't the one that only affects latency — it's the one that quietly alters what happens (less context sent, a different model, a skipped step) under the cover of 'making it faster.' Those change the result, not just the wait, and the user attributes the different output to the model rather than to a switch they never saw. If an optimization changes the answer, it is not a speed setting; it is a behavior setting wearing a disguise.

Code

The choices ride the request openly — no silent inference·swift

// EXPLICIT: every performance-relevant choice is stated and sent.
brain.applyFree(prompt: rendered,
                vault: macro.vaultContextMode,   // stated per macro
                tier: profile.ollamaTier)         // a named choice

// REJECTED anti-pattern: infer a fast path from incidental state.
//   if profile.soul == nil { vault = .bypassVault }   // NO.
// An empty soul is not permission to silently drop context. The vault
// mode is whatever the macro says, always sent, never guessed.

Exercise

Distinguish two optimizations Flint might make: (A) run short selections on a faster local tier, and (B) skip vault context whenever no soul is set. One is an acceptable explicit choice and one is a rejected hidden default — decide which is which and why. Then state the test that separates a legitimate 'speed setting' from a disguised 'behavior setting.'

Hint

(A) is acceptable only if it's a stated, visible choice the user set — a tier the macro names — not an automatic guess; as an invisible auto-behavior it fails the same test. (B) is a rejected hidden default: dropping context silently changes what the model knows and thus the output, disguised as speed. The separating test: does the optimization change only the wait, or does it change the answer? If it changes the answer, it's a behavior setting and must be explicit, not a hidden speed trick.

Own the Latency, Don't Hide It

Speed Is a Choice, So Make It Visible

No Hidden Performance Switch

Explicit Beats Magic

Code

External links

Exercise

Progress

Comments 0