Change one thing, or you have learned nothing

Where bad advice comes from

Somebody changes their prompt, switches sampler, bumps steps from 20 to 35, and gets a better image. They post that DPM++ 3M SDE is better for portraits. Two thousand people repeat it. Nobody has tested it.

This is how almost all folklore in this field is produced, and it is why you should test the claims in this course too. The method is not complicated; it is just unglamorous.

The procedure

1. Fix the seed.
2. Fix everything else.
3. Change exactly one thing.
4. Generate both.
5. Look at them side by side at 100%.

Most interfaces have a built-in grid tool for this: A1111 and Forge call it X/Y/Z plot, ComfyUI does it with a primitive node in increment mode. It renders every combination on one sheet. A grid of 5 CFG values by 4 samplers is 20 images and answers the question properly in one run.

Things worth testing once, on your own work

Not endlessly. Once, and then write down the answer and stop revisiting it:

• CFG: render 3, 5, 7, 9, 12 at one seed. You are looking for where it starts to burn: over-saturated, hard-edged, crunchy. That is your ceiling. It differs per checkpoint and is usually lower than people run.
• Steps: 15, 25, 40, 60. Find where you stop seeing change. Usually around 25 to 30.
• Samplers: four of them at your settled CFG and steps. The differences will be smaller than you expect, which is itself the useful finding.
• Quality tags: with and against. Usually nothing.
• Negative prompt: your usual boilerplate against an empty one. Often surprisingly little.

That last one tends to change how people work. Long inherited negative prompts (the strings of “worst quality, jpeg artifacts, extra limbs, bad anatomy”) were tuned for particular SD 1.5 fine-tunes and frequently do nothing on a modern checkpoint. Some models want an empty negative. You will not find out by reading; you will find out in four minutes with a fixed seed.

Why people do not do this

Because it feels slow, and because the exploratory mode (changing several things and seeing what happens) is enjoyable and occasionally productive.

Both modes are legitimate, and the point is to know which you are in. Playing is fine. Playing and then forming a firm belief about what caused the improvement is not. If a change seems to help, spend four minutes confirming it with a fixed seed before it enters your working practice, because an untested belief will cost you that four minutes every week for a year.

The limit of single-variable testing

Parameters interact. CFG and steps interact. A sampler’s quality depends on the step count. A LoRA’s right strength depends on the checkpoint. So a one-at-a-time test tells you about that variable at your current settings, and the answer can move when something else moves.

This is not a reason to abandon the method; it is a reason to re-test the two or three things that matter when you change checkpoint, and to prefer a small two-dimensional grid (CFG against steps, say) over two separate one-dimensional runs when you suspect interaction. Five by four is twenty images and perhaps three minutes on a distilled model.

The honest summary: you are not doing science, and you do not need to. You need enough rigour that your working defaults are true, and that is a handful of grids run once per checkpoint, written in a file next to your notes.

What the file should say

Keep it short enough that you actually maintain it. One block per checkpoint:

checkpoint: realvis-xl-v5  (hash a1b2c3d4)
  cfg:       5.5   (burns past 8)
  steps:     26    (no change past 30)
  sampler:   dpmpp_2m / karras
  negative:  empty — boilerplate made no difference
  buckets:   holds to 12:5; duplicates past that
  notes:     warm bias, grade cooler by ~200K at finish
  tested:    2026-03-14

That block took twenty minutes to produce and removes about forty decisions a week. The date matters, because when you update the interface or the checkpoint you need to know the numbers are stale.

Testing the advice you are given

One last use for this, including on this course. Everything written here about step counts, CFG ranges, denoise values and negative prompts is a starting point drawn from common behaviour across common models, and your checkpoint may differ.

So treat every number in this course as a hypothesis with a four-minute test attached. If your model burns at CFG 6 rather than 8, the number in your file is right and the one in the lesson is wrong for you. That is not a failure of the lesson; it is the method working.