Good and Bad Harness Engineering

Stakes out the middle ground between "thin harness, fat skills" and fully prescriptive agent frameworks. The core move is a good/bad distinction inside harness engineering itself: some scaffolding genuinely extends what the system can do (input shaping, repair loops, observability), while other scaffolding is brittle compensation for current model weakness and will not survive the next model.

Miessler's design rule is compressed into one line: don't confuse the what with the how. Tell the model who you are and what outcome you want; let the model figure out the path.

Read together with:

• Bitter Lesson Engineering — the underlying argument, leaning on Sutton's "The Bitter Lesson."
• Tan's "Thin Harness, Fat Skills" — adjacent but less prescriptive-about-good-design.

Miessler is not endorsing the thin-harness conclusion that scaffolding is always waste. He is endorsing a discipline of harness design. The disagreement with Tan is legible: both agree some scaffolding is waste; they disagree about how much of the harness is waste in the limit of model improvement.

What the library should extract once the post is fully read

• The explicit taxonomy (if any) of good vs. bad harness work.
• Concrete examples cited as each type.
• Whether repairability and observability are treated as constitutive of capability or merely as hygiene.