There is a meaningful difference between getting a model to write code and getting a model to reliably build software. The first is a neat demo. The second is a new engineering discipline. We are talking about harness engineering.The idea is simple, but the implications are deep. Instead of treating the model as a magical coding oracle, you treat it as a powerful but imperfect operator inside a carefully designed environment. The goal is no longer to write the perfect prompt. The goal is to build the surrounding system so that good behavior becomes easy, bad behavior becomes visible, and failure becomes recoverable.This is an important shift because most teams still think of agentic software as an interface problem. They focus on instructions, tone, and phrasing. But once an agent is doing meaningful work over long horizons, the bottleneck is rarely language alone. It is structure. It is visibility. It is memory. It is validation. It is the quality of the rails surrounding the model.In other words, the real product is not the prompt. It is the harness.OpenAI recently gave a useful name to a pattern many of us have been discovering the hard way: harness engineering. In its post on the subject, the company makes a strong argument that the real challenge is no longer just getting models to generate code, but building the surrounding environment—tools, constraints, plans, observability, documentation, and feedback loops—so agents can operate reliably inside production systems. That framing is exactly right, and it is a useful place to begin.But this essay is not a restatement of OpenAI’s idea. I want to use that framing as a starting point and blend it with my own lessons from working with agentic systems in practice. The interesting part of harness engineering is not the label itself. It is the collection of non-obvious truths that appear once you move beyond one-shot demos and start asking agents to do real work over long horizons. At that point, the bottlenecks stop looking like prompt problems and start looking like engineering problems: memory, visibility, verification, architecture, process, and recovery.And that is where the real lessons begin.