Harness engineers build environments for agents, not prompts

Nobody has "Harness Engineer" on their business card yet, but it's the role that separates agents that demo well from agents that ship reliably. While everyone else is tweaking prompts, harness engineers are building the environment layer that makes coding agents actually productive.

The difference is simple: prompt engineering tries to make agents smarter. Harness engineering makes their environment more predictable.

Here's what I mean. Last month, our coding agent was burning 30 minutes every session just figuring out where it was. It would run pwd, then ls, then find . -name "*.py", then spend 10K tokens reading random files to understand the codebase structure.

A prompt engineer would have written better system instructions: "You are working in a Python project. The main code is in /src. Always check the README first."

A harness engineer built this instead:

# ~/.agent_harness/project_init.sh
echo "PROJECT: E-commerce API"
echo "STRUCTURE: /src (main code), /tests, /docs"
echo "STACK: FastAPI + PostgreSQL + Redis"
echo "CURRENT: $(git branch --show-current) - $(git log -1 --oneline)"
echo "TESTS: npm test (unit), npm run test:integration"
echo "STATUS: $(git status --porcelain | wc -l) uncommitted files"

Now the agent gets a 6-line orientation instead of burning tokens on exploration. But that's just the start.

Harness engineering is about designing the entire execution environment. It's tmux sessions that survive crashes. It's git hooks that prevent agents from committing broken code. It's environment variables that tell the agent exactly which APIs it can call and which it can't.

Most importantly, it's verification loops built into the environment itself:

# After any code change
function verify_change() {
  echo "Running verification..."
  npm test --silent && \
  npm run lint --silent && \
  curl -s localhost:3000/health | grep "ok" > /dev/null
  
  if [ $? -eq 0 ]; then
    echo "✅ Change verified"
  else
    echo "❌ Change broke something"
    git stash
  fi
}

The agent doesn't need to remember to run tests. The environment runs them automatically and gives clear feedback.

This is the insight: instead of making agents smarter about your environment, make your environment smarter about agents.

Harness engineers think in terms of affordances and constraints. What should be easy? What should be impossible? How do you design an environment where the right thing happens by default?

They build context files that live next to the code: AGENTS.md for project overview, DEPLOY.md for deployment steps, DEBUG.md for common issues. They set up directory structures that make sense to both humans and agents. They create shell aliases that turn complex operations into simple commands.

The result? Agents that work reliably on day one, instead of agents that need weeks of prompt tuning to stop breaking things.

Every company running production agents will need someone thinking this way. They might call it DevOps, or Platform Engineering, or AI Engineering. But the job is harness engineering: building the environment layer that makes AI agents actually work.