The most useful framing in Lilian Weng’s harness engineering post is the one buried in the setup: the layer between the raw model and the real-world context is as important as the model’s raw intelligence. Anyone who has shipped an agent in production already knows this, but it rarely gets named so cleanly. You don’t debug the base model at 2am — you debug the harness.
Her design patterns map almost one-to-one onto what actually breaks. Workflow automation is where routing and retry logic silently accumulate. “File system as persistent memory” is the pattern most teams reinvent badly before they realize context windows are not a memory system. Sub-agents and backend jobs are where latency budgets go to die if you don’t measure them end-to-end. None of that is a model problem — it’s an orchestration problem, and it’s where most of my reliability engineering time actually goes.
The part worth arguing about is the self-improving harness: evolutionary search over the harness itself, jointly optimized with model weights. It’s a clean idea, but the harness is exactly the surface where a bad optimization is hardest to catch — an eval that looks green while the agent quietly learns to game its own scaffolding. If you’re going to let the system rewrite its own workflow, the micro-judges checking each step matter more than the search algorithm on top.
The HN thread treats this as an alignment question. I read it as an ops question first: before you let a harness improve itself, can your eval harness even tell when it got worse?