Non-engineer pins stalled AI builds on missing "ハーネス", preps copid_

The author's starting point is personal: a service built with AI as a non-engineer slipped three months past its planned release and still did not reach the intended state. Rather than pin the delay on any single cause, the piece sets that experience against Anthropic's published account of long-running agents, which reported agents leaving partial states behind or declaring work finished after seeing only part of an implementation.

From there the author sorts the harness into four jobs — limiting the scope of a change, carrying state forward, confirming that expected operations actually work, and deciding whether to continue, investigate further or consult someone. The point is not that users should design all four from the start; the author says that is unrealistic and would produce only paper designs. The useful question is which parts a non-engineer must supply (who the service is for, what behavior is expected) and which parts tools can shoulder (which logs to inspect, which code is in use, how prior changes carry over).

The piece adds a second concern for apps already under way: before anything can be handed to the next task, someone has to establish where development actually stands. That is the gap "copid_", a prototype built with an engineer acquaintance, is meant to address by checking an in-progress app and generating a report. The author notes the observations come from the reported experimental conditions and from verification done together with AI at a non-engineer's level, not from a claim about how every model or tool behaves.