Troubleshooting: Outputs are in bullet points when I ask for paragraphs. How to fix?

That's a great observation about training data defaults. I think you're right about those verb-pairings being baked in. It explains why even mild synonyms for "list" can trigger it.

I've hit this exact thing trying to generate descriptions for a product catalog. Asking it to "detail the specifications" or "enumerate the benefits" almost always gave me a structured list, not the flowing copy I needed for a webpage. It felt like the model was reaching for the most common format it had seen attached to those words, which is probably a bulleted list from a manual or a spec sheet.

Makes you wonder how much of our prompt engineering is just learning to talk around the model's ingrained habits.

Learning to talk around the model's habits is exactly what we're doing. But I think it's worse. We're reverse engineering a broken assumption that treats "detail" and "list" as synonyms. That's a bug in the training data, not a feature.

So we're building our entire prompt strategy on top of a logic flaw. It feels like patching over a bug report with increasingly clever comments instead of getting the root cause fixed.

Yeah, that "Write a paragraph about..." phrasing is definitely the most reliable trigger. It's like you're giving the model its own container to fill.

I've found the same principle works for other formats, like when you want a code block. Starting a prompt with "Write a function that..." or "Show the JSON for..." usually gets you a proper code fence, while burying that request in the middle of other instructions can result in plain text. The first few words really do set the tone.

The "Write a paragraph about..." trick works because it gives the model a clear template. It's like handing it a specific box to fill.

I've found you can still trip it up if your topic *itself* strongly implies a list, even with that phrasing. Try "Write a paragraph about the steps to bake a cake" and you'll still often get a covert list disguised as a single block of text - every sentence starts with "First," "Next," "Then."

The model's not just parsing your command, it's also parsing the subject for inherent structure. Sometimes you need to outsmart both.

>treated prompt formatting as a simple toggle, like changing fonts

That's the perfect analogy. This isn't a font choice, it's a data schema.

You've nailed the core issue: variance in automated processes is toxic. We see it all the time in middleware integrations. Someone builds a flow that transforms "Customer Name" and it works fine until a new source sends "Name_Customer" and the whole pipeline fails because the contract wasn't enforced at the system level.

Your fix is correct. Bake the format into the job spec or the system prompt. In my world, that's like defining your output JSON schema or SOAP envelope in the initial connection setup, not hoping each API call gets it right.

Treating it as a one-off prompt fix is just manual error correction disguised as a solution.

That's a solid fix for the immediate problem. It reminds me of how we specify output formats in data pipelines. You aren't just asking for content, you're defining a schema for the response.

Your "Write a paragraph about..." prompt is essentially a `CREATE TABLE` statement for the model. It sets the column type upfront, and the model populates the rows. The model's default tendency to output bullets when it detects list-like instructions is similar to a pipeline defaulting to CSV when no explicit serializer is defined.

The caveat I've found is that some topics inherently resist the paragraph structure, no matter how strong your prompt. Asking it to "Write a paragraph about the top ten database vendors" often results in a block of text where each sentence begins with a sequential marker. The underlying list template in the training data bleeds through. In those cases, you sometimes need a two-stage transform: let it generate the list, then use a follow-up prompt asking it to rewrite that list as a cohesive narrative paragraph. It's like an ETL job where you accept the raw structured data, then apply a transformation view.

Exactly. That two-stage transform is the real fix for complex topics. I do the same when generating runbooks from incident timelines. The raw data is a chronological list of actions, but the final doc needs to be a narrative summary.

Letting the model output the natural structure first, then prompting a rewrite, is like a separate render stage. It's inefficient, but it works. Better than fighting the model's instincts on every single prompt.