Stop Gemini From Phoning In the Last Few Paragraphs — Prompt Patterns That Hold Density to the End

After enough long-form work with Gemini, you start to feel a pattern: the opening is sharp, the middle is full of examples, and then somewhere around the second-to-last section the writing thins out and the article ends with something like "we hope you'll give it a try." Once you notice it, you see it everywhere. Almost every long-form output has the same shape.

I have leaned on Gemini hard for solo creator work — articles, reports, long-form documentation. After half a year of fighting this problem, I am convinced the "last bit goes thin" effect is part LLM tendency and part prompt-design omission. Below is the three-layer routine I use to keep long-form output dense from the first paragraph to the last.

Why density falls off near the end

Long-form falloff is not unique to Gemini, but Gemini in particular has a strong pull toward "wrapping things up nicely" near the end. Training data is full of long pieces that follow the shape introduction → body → tidy conclusion. The model leans into that arc, and abstraction creeps up as the end approaches.

There is also a quieter mechanism: the model self-regulates length. Once the cumulative output gets long enough, it shifts into a "time to land this" mode. New examples and concrete numbers stop showing up; the prose rounds off. From the model's point of view this is good behaviour. From the reader's, it feels like the author got tired.

The mismatch is the issue. Readers do not want a tidy landing. They want the same density that the body had. Closing that gap has to be designed into the prompt. It will not happen by itself.

The pre-declared footer trick

The most effective single change I have tried is to make Gemini commit to the closing line before writing anything else. I call it a pre-declared footer.

The implementation is almost embarrassingly small.

You are about to write a long article. Before you write anything else,
write only the final section, "The smallest next step," in three lines or
fewer.

The smallest next step must:
- Name one concrete action a reader can take tomorrow
- Not be an abstract summary
- Not include any phrase like "we hope you'll give it a try"

Once that section is locked in, begin writing the body.
The body's final lines must use the section you just declared, verbatim.

Once that footer exists at the top of the chain, the model's "let's wrap up" energy has somewhere to go. The body no longer needs to do the wrapping. The closing is already in the bag.

Since I started doing this, the final H2 section of my long-form pieces has gained noticeably in density. That single change alone is what readers feel as "the article didn't fade out at the end."

Have a separate Gemini grade the closing section

The pre-declared footer alone does not catch everything. Sometimes the H2 section just before the footer goes thin. A small, separate Gemini call can grade exactly that section.

After the body is generated, I send it through a verifier with this prompt:

Read only the final H2 section of the text below.
Score it from 1 to 5 on each of:

1. Does it contain at least one concrete example?
2. Does it avoid ending only on abstract conclusions?
3. Does its density match the rest of the article?

If any score is below 4, rewrite that section.

The verifier costs maybe two thousand extra tokens per long piece. That is a rounding error. The quality lift is not. In my logs, roughly 35% of long pieces come back with a rewrite request — meaning one out of three was quietly fading out before the verifier got involved.

After verification, the closing reads at the same level as the rest of the article. For long-form, the last section disproportionately decides whether a reader walks away feeling the piece was worth their time.

Don't try to write it all in one pass

A single long generation is the most reliable way to get a thin ending. The longer the output, the more strongly the "let's land this" pull kicks in.

I always stage long-form into three steps:

Stage 1: Outline (H2 list + one-sentence brief per H2)
Stage 2: Generate each H2 section one at a time
Stage 3: Assembly + tone consistency pass

The trick in stage two is to give the model a written bridge: "the previous section was about X, now we are doing Y, the next section will be Z." Without that scaffolding, sections drift apart and start repeating each other.

// Skeleton of the stage-two loop
async function writeArticleByOutline(outline: Outline) {
  const sections: string[] = [];
  for (const [i, h2] of outline.h2s.entries()) {
    const prev = outline.h2s[i - 1];
    const next = outline.h2s[i + 1];
    const prompt = `
The previous section was "${prev?.title ?? "(none)"}" covering
${prev?.summary ?? "(article opening)"}.
This section is "${h2.title}", to be written along ${h2.summary}.
The next section will continue into "${next?.title ?? "(final section)"}".
 
Do not summarise abstractly. Include at least one concrete example.
`;
    sections.push(await generate(prompt));
  }
  return sections.join("\n\n");
}

The effect is straightforward: in single-pass generation, the final section tends to clock in at half the length of the others. With staged generation it lines up with the rest. Length alone is not quality, but it is a reasonable proxy for density holding.

Staged generation has its own pitfall

Each section being written independently means the through-line of the article can fragment. A section's conclusion may not be picked up by the next section, even if they share a topic.

I add one more pass at stage three to catch this — a flow check by another agent.

Read the article below. Identify only:

1. Where one section's conclusion is not built upon by a later section.
2. Where the same point is repeated across multiple sections.

For each instance, suggest a one-sentence fix.
No general impressions or praise. Findings only.

That last instruction matters. Without it, the verifier wants to open with "this article is excellent" and the actual findings get diluted. Telling it to skip impressions sharpens the output.

Owning the cost-quality tradeoff

To be honest, the three-layer routine roughly doubles or triples the token cost compared with a single-pass generation. That is real money.

My own view: it is worth it for long-form that matters. Two reasons. First, a thin ending damages reader trust not just in that piece but in the whole site or product. Second, regenerating sloppy first drafts costs more than writing well the first time, once you count human editing time.

That said, you do not need this routine for everything. I reserve it for pieces that will be read carefully, archived, or directly tied to revenue. Internal notes, drafts, and short pieces stay one-shot. Picking where to spend the budget is what makes the routine sustainable.

Don't apply this to short pieces

A counter-warning: pre-declared footers and verifier agents shine on long-form (five or more H2s, beyond about three thousand characters). On short pieces they backfire.

Short pieces do not have a tail-fade problem to solve. Forcing a "smallest next step" into a short note feels artificial. The verifier cannot tell the difference between "thin because short" and "deliberately concise" and ends up requesting unnecessary rewrites.

This pipeline exists to defend density in genuinely long output. For shorter writing, generate once and edit by hand. That is faster and the result is usually better.

The smallest next step

Tomorrow, when you ask Gemini for a long-form draft, put one extra line at the very top of your prompt: "First, write the final 'smallest next step' section in three lines, before anything else." That alone will lift the density at the end. Adding the verifier agent and the staged generation can wait until you have seen what that one line does on its own.