Build1 publisher3 min readPublished
Repetitive LLM output is three separate defects, and most teams fix one and stop
A developer's post-mortem splits model repetition into prompt content, sampling temperature and how often the code path fires. Each fix leaves the other two live.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Repetition in LLM output is the predictable outcome of three separate things interacting, and treating it as one problem with one fix usually leaves two of the three causes untouched.
- The author says he ran into the repetition problem directly while building MockEvalio's interview follow-up system, and that fixing it took three separate changes, not one.
- MockEvalio's interviewer-persona prompt instructions included, as an example of good output, the question "What would you sacrifice to ship this faster?"
- A literal example phrasing is reasonable for a human reading the prompt, but for the model it becomes part of the pattern it draws from every time it generates a follow-up in that persona's voice.
- A small, fixed set of examples is a strong attractor when the same prompt is called hundreds of times.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
A developer writing on dev.to has published a breakdown of why a language model asked to produce the same kind of artifact over and over keeps reaching for the same phrasing, and the useful part is the taxonomy: three separate causes interacting, where treating it as one problem with one fix usually leaves two untouched [1]. That matters operationally, because the standard response in most teams is a single change, shipped, closed as done. The author says he hit this while building the interview follow-up system in a product called MockEvalio, and that resolving it took three distinct changes rather than one [2].
The first cause is prompt content. MockEvalio's interviewer-persona instructions included, as an illustration of a good output, the literal question "What would you sacrifice to ship this faster?" [3]. For a human reading the prompt that is a helpful example; for the model it becomes part of the pattern it draws from every time it generates in that persona's voice [4]. The author's point is that a small fixed set of examples is a strong attractor once you are calling the same prompt hundreds of times [5]. The remedy is not better examples. It is either describing categories of output to rotate across instead of supplying sample sentences, or accepting that reproduction of your examples is the price of including them [6].
The second cause is sampling. Temperature governs how sharply the model favors its single most probable next token: lower values let the top continuation dominate, higher values flatten the distribution and give less probable but still reasonable continuations a chance [7]. MockEvalio's follow-up generation ran at 0.4, low enough that the most likely phrasing for a given prompt shape won consistently [8]. The author is blunt about the limits of the dial: it does not target the phrase you are tired of seeing, it lowers the model's confidence across everything that prompt produces, including the outputs you were happy with [9]. Raise it far enough to diversify meaningfully and you also raise the odds of an answer that is less coherent or slightly off-topic [10].
The third cause is exposure, and it has nothing to do with generation quality. The original logic requested an AI follow-up on every single strong answer, unconditionally, so the prompt shape most likely to repeat itself was firing at 100 percent frequency across every user and every session [11]. The change was to fire it with 35 percent probability for strong answers and pull a genuinely different question the rest of the time [12], which is a 65 point cut in how often that path executes, roughly two thirds fewer chances for a user to notice [13]. No individual generation got less repetitive [14].
That is the discipline worth stealing. The author sets out the failure mode of each lever used alone: banning phrases is reactive and fragile, since you can only ban what you have already noticed and the next favorite phrasing may be just as narrow [15]; temperature adds variety without control [16]; frequency gating never touches quality at all [17]. The three causes sit at different layers of the system, structural, sampling and prompt content [18], which is why a fix at one layer cannot substitute for a fix at another. If your incident note cannot name which of the three you changed, you have shipped a mitigation and called it a repair.
Worth noting the evidence class: this is one engineer's account of one product, and the post as supplied describes the three changes without reporting a measured before-and-after repetition rate [19].
What to watch: whether the 35 percent gate survives contact with engagement metrics, since a team that measures follow-ups served will read a two-thirds cut as a regression. And whether anyone instruments phrase-level frequency in production output, which is the only way to tell a real fix from a felt one.