The role of a software engineer is shifting. Not toward writing more code but toward building the environment that makes agents reliable.
Think about what you actually do with Claude Code or Codex today: you configure AGENTS.md files, set up MCP servers, write skills and hooks, build feedback loops and tune sub-agents.
You’re not writing as much of the software anymore. You’re engineering the harness around the thing that writes the software.
Mitchell Hashimoto first coined the term harness engineering — the work of shaping the environment around an agent so it can act reliably. What the model sees, what tools it has, how it gets feedback, when humans step in.
We keep hearing that agents will replace engineers. That shouldn’t be the focus of the change we’re seeing. What’s actually happening is product people shipping features directly. A well-harnessed agent lets someone with product instinct but little engineering background make meaningful changes — safely.
The harness engineer makes that possible. Guardrails, design choices, blast radius controls, feedback loops. The scaffolding that turns “just prompt it” into something a team can trust. I say this from first-hand experience.
If you want to go deeper, listen to the episode where my cohost and I dug into it.
We landed on five pillars:
- agent legibility
- closed feedback loops
- persistent memory
- entropy control
- blast radius controls
Honestly one of the most important episodes we’ve recorded.