Harness Engineering Belongs in the Platform Engineering Conversation
I just got back from DevOpsDays Taipei, and it was great to catch up with old friends and make a few new ones as well. Aside from the conversations themselves, one of the biggest things I get from conferences like this is a short list of topics I need to catch up on. When I’m not working, building, or writing, I try to keep up with software development trends (which recently mostly means AI things), but it always seems like there are areas that slip through the cracks.
One thing I learned this week is that I had largely whiffed on is “harness engineering.” I’ll be spending some time with the resources at “Learn Harness Engineering” in the upcoming days, so this post is not meant to be my definitive take on the subject. It is more of an initial reaction as I start looking into the area. But my first impression is this:
Harness engineering may not be an entirely new job category so much as the next evolution of platform engineering for teams that now include both humans and AI agents.
Or, put another way: Platform engineering gives human developers paved roads. Harness engineering gives AI agents rails.
How I Usually Explain Platform Engineering
When I introduce platform engineering to teams, I usually frame it as a way to reduce cognitive load, allow focus to be placed on “essential” rather than “accidental” complexity, and make The Right Things easier to do.
The goal is not to create a central team that controls everything (or at least everything engineers find “interesting”), or simply build in-house customizations of a bunch of open-source tools. And it is definitely not to add more process between developers and production.
The goal of platform engineering, as we always put it, is to create paved roads.
That means giving teams well-supported paths for the things they need to do repeatedly, such as provisioning infrastructure, CI/CD, deploying services, managing secrets, observing systems, running tests, handling compliance, and recovering when something goes wrong. A good platform does not eliminate engineering judgment. It gives teams better defauls and removes unnecessary friction. It makes secure and reliable patterns easier to adopt. It lets product teams spend more time solving customer and business problems and less time rediscovering multiple times across the organization how to ship software safely.
That mental model still feels useful when we throw in AI-assisted development. But I do not think it is quite enough.
Agents Need More Than Paved Roads
The classic paved-road metaphor of platform engineering assumes that the user is a human developer. A human developer can choose to step off the paved road. That may be a good idea or a bad idea, but at least the developer usually understands they are doing it and can justify it to their management if necessary. They can bring context from prior incidents, organizational history, architecture discussions, and judgment about the intent behind a task.
An AI agent is different. An agent may produce code that looks plausible but misses the real constraint. It may follow a local pattern while violating a broader architectural boundary. It may “fix” a failing test by weakening the test. It may make a change that is technically coherent but strategically wrong.
At the current capability level of AI software development agents, my default would be to get very worried if I saw an agent stepping off a paved road. That does not mean agents are useless. But it does mean the system around the agent matters enormously. This is where the “harness” metaphor starts to make sense to me.
The harness is not just there to make the preferred path convenient. It is there to shape the agent’s movement around the software development lifecycle.
The harness defines what context the agent sees, which tools it can use, what parts of the repository it can modify, what commands it can execute, how it receives feedback, and what evidence it must produce before humans should trust the result.
The Part Where I Switch Metaphors and Revise My Hot Take
It seems to me that if platform engineering gives human developers paved roads, harness engineering gives AI agents rails.
By “rails”, I mean a well-defined operating path for the agent: a bounded environment where it has 1) the right context, 2) the right tools, 3) the right permissions, and 4) the right feedback loops to make progress without wandering all over the codebase. And these rails have to be designed.
That is where this becomes an engineering problem rather than just yet another prompting problem.
It is easy to look at AI coding tools and focus on the model: Which model is better, which prompt strategy works best, which IDE integration feels smoother. Those things matter, but they are not the whole system. The more interesting question is more holistic, namely, what kind of environment produces consistently useful work.
Can the agent find the right context? Can it act within the right boundaries? Can it make progress without constantly needing a human to restate the obvious? Can the organization shape how agents work without turning the whole process into bureaucracy? Those are platform questions as much as AI questions. This is also where I think my initial framing of harness-engineering-as-platform-engineering needs a little revision:
Harness engineering is not the same thing as platform engineering. It is not a replacement for platform engineering either. It is more like the agent-facing layer that platform engineering now has to understand, support, and govern.
The harness must live close to the agent and manage concerns like prompt assembly, tool access, context management, task workflow, local execution, memory, self-checks, and structured outputs. On the other hand, the platform still has broader responsibilities: identity, access control, secrets, audit trails, cost controls, observability, policy enforcement, deployment safety, and consistency across teams and agents.
That distinction matters: If every agent team builds its own harness with its own rules, its own permissions, its own audit story, and its own approach to risk, we have not really solved the platform problem. We have just recreated the same fragmentation platform engineering was meant to address, but now with probabilistic workers in the loop. That doesn’t sound like an improvement.
So maybe the better version of my thesis is not “Harness engineering is platform engineering for agents”. Maybe it is:
Harness engineering is where platform engineering has to grow when one of the platform’s users is an AI agent.
My Current Working Definition
I still need to spend more time with the material, so I may revise this view as I learn more. But my current working definition is:
Harness engineering is the agent-friendly layer of platform engineering for human-agent teams.
More specifically, it is the engineering discipline of designing the environment that allows AI agents to contribute to software delivery safely and effectively. It builds on the same foundations we already care about in platform engineering: CI/CD, test infrastructure, observability, security, deployment safety, and developer experience. But it also adds new concerns like context engineering, agent permissions, prompt and tool design, evaluation, guardrails, and evidence-based verification.
The users of our engineering platforms are changing. They are no longer only human developers. Increasingly, they are human developers working with AI agents with varying levels of autonomy. And if that is true, then we need to design the platform differently. We already learned that giving developers raw infrastructure and telling them to move fast (or move FASTER!) does not scale. We responded by building platforms, paved roads, and guardrails. Now we are learning that giving AI agents raw access to a repository and telling them to make changes also does not scale (except in lines of code, which is probably not what you really want).
Ergo we need harnesses. But we still need the platform underneath and around those harnesses.
For me, the useful takeaway is not that harness engineering replaces platform engineering. It is that:
Platform engineering now has another kind of user to design for.
That is enough to make the topic worth paying attention to.
I still need to spend more time with the material, but that is where I’m landing for now: Harness engineering feels like a new part of the platform engineering discussion, not a separate universe from it. And if AI agents are going to become part of how software teams work, then designing the environment they operate within is going to be real engineering work.
