A harness is mostly four decisions made in code: which functions are registered as tools, which paths the sandbox actually mounts, what ends the loop, and what happens to state when a tool returns garbage. Those are the four the dev.to author names as the things that broke his agents in production [12]. The prompt is read once per step. The other four are enforced on every step, by the runtime, whether or not anyone wrote them down.
Recursive self-summarization is the clean example because it has no fixed point. Every summary is fresh input, so the model always has a next action available, and a loop with an available action and no budget check does not exit. According to the post, nothing in the system told the agent to stop [10]. The fix is a counter: max steps, a token ceiling, a wall-clock limit, or a no-progress detector that compares consecutive outputs. A token counter is a less impressive artifact than a hand-tuned reasoning scaffold, and it is the one that would have ended that run.
The eval gap he reports is the number I would actually take to a review. For a score on fixtures to transfer to production, the fixtures have to contain what production contains, and his did not: the attached PDFs, the half-deleted Slack thread, the customer who said "you know, the thing" [9]. Read that way, the eval was measuring a harness he never shipped, which is the same failure mode as any benchmark table quoted without its input distribution.
The failure-rate figure at the top of the post I would not plan against. The text names no study, no sampling frame, and no test for what counts as failing in production [19]. The Y Combinator survey sitting next to it at least has a population, and a date: CTOs and CPOs, March 2026, reporting that the difference between success and failure was not the model [2]. Self-report from people who already chose to deploy is a different instrument from a failure census [20].
The renaming deserves the same scrutiny as the numbers. Anthropic's framing is the honest version, calling context engineering "the natural progression of prompt engineering" [15], because the artifact is still curated tokens, just many more of them and mostly not typed by a human [16]. Karpathy's line that it is "a lot more than just the prompt itself" [13] and Philip Schmid's that the new skill is context rather than prompting [14] are the same observation from a different seat. Harness engineering, as the post scopes it, means context plus constraints plus tools plus lifecycle plus feedback plus observability [17], which is close to a description of the whole application. The credible part is the delta in his own directory: 47 templates in late 2023 [5], 23 deleted by mid-2025 [6], 24 kept [7]. He ran the change and reported what survived.
In my context the first thing worth instrumenting is every tool call with its return value, because the stop condition and the rollback both read from there, and my agents hold write access to real repositories. A bad tool return is a state change, not a bad sentence. If your agents only draft text, the prompt may well still be your bottleneck, and the post is arguing about someone else's blast radius.
