Hey everyone,
Last Tuesday a teammate opened a “tiny” ticket: make the finance export helper stop asking clarifying questions and just finish the job. Someone edited the shared agent rules file, added one MCP tool so the agent could look up invoice status, and merged before lunch. By Thursday, the same helper was rewriting cells in a production workbook that used to be read-only. Nobody shipped a feature. They shipped a config change with a smile.
That is the story I keep hearing from working teams. Coding agents are getting better at long-running work. Tooling like Model Context Protocol makes it easier to wire Slack, GitHub, browsers, and databases into the loop. Product teams are shipping coordinators that keep context for weeks. The part that still gets treated like scratch notes is the harness: the system prompt, the rules file, the tool allowlist, the memory the agent is allowed to keep. Those files change behavior as surely as a feature flag or a Kubernetes config map. We just forget to review them like production.
Hi, I’m Robert Massey, software engineer and computer science professor with twenty-plus years in the trenches. AI is a tool and an assistant. Programming and coding is still a skill. Software engineering is still engineering solutions with software. The harness is not a sticky note. It is production config.
What I mean by “harness”
When I say harness, I do not mean the LLM model. I mean the durable instructions and permissions that sit around the model:
- Project rules and agent instruction files in the repo
- Tool manifests and MCP server allowlists
- Default prompts that tell the agent how aggressive to be
- Shared memory or project context that survives across sessions
- Guardrails about which paths, environments, and secrets it may touch
Change any of those and you change the product’s behavior, even if application source code is untouched. Practitioners writing about agentic production systems keep repeating a boring, healthy idea: treat prompts, policies, and tool definitions as versioned artifacts. Same family as infrastructure as code. Same need for owners, diffs, and rollback.
I am not claiming every team needs a fancy prompt registry. Git plus a PR template is already a strong start. The discipline matters more than the vendor.
Why this is getting louder in 2026
Three pressures are colliding.
First, agents are no longer limited to autocomplete. They plan, call tools, open pull requests, and keep working while you are in another meeting. When the work can run for hours or days, a vague instruction is not a personal preference. It is an operating policy.
Second, tools expand blast radius. An agent that can only edit a local file is a different animal from one that can post in Slack, approve a workflow, or write to a finance sheet. MCP and similar connectors are great for leverage. They are also permission surfaces. If you would not hand a contractor a prod database login “just for debugging,” do not hand an agent the same write scope because the demo looked sick.
Third, architecture drift shows up faster when generation is cheap. Locally sensible changes can accumulate into a system nobody intended. Instruction files are one of the few places you can encode “do not invent a second auth path” before the fiftieth small PR teaches the next agent the wrong pattern.
A workplace scene that is not theoretical
Imagine an auth service with a hard rule: password reset tokens never get logged in clear text. That rule lives in a wiki and in the heads of two senior engineers. Then a new agent rule gets added: “When debugging login failures, capture full request and response payloads to the incident ticket.”
No application file changed. CI stayed green. The next overnight agent run dutifully pasted a reset token into a ticket that half the company can read. The incident writeup will blame “AI.” The real miss was treating the harness like a sticky note instead of a change that needed security review.
Or take the Excel export helper again. Read-only access to a reporting workbook is a sensible assistant. Write access so it can “clean up formatting” is a product decision. That decision belongs in a PR description with a named owner, not in a late-night chat where someone says “sure, grant it temporarily.”
A practical checklist that fits real teams
Here is what working engineers can do this week without a transformation program.
1. Put harness files in the repo. Rules, default prompts, tool allowlists, and agent skill recipes should live where code lives. If it only exists in one person’s IDE settings, it is invisible infrastructure.
2. Require a PR for harness changes. Treat edits to agent instructions like edits to CI, feature flags, or IAM policy. Ask for a one-paragraph risk note: what can the agent do now that it could not do yesterday?
3. Separate read tools from write tools. Prefer connectors that query and summarize before connectors that mutate. Promote write scope the way you promote production deploys: deliberate, temporary when possible, and owned.
4. Name a human owner for each agent workflow. Not “the platform team” in the abstract. A person who can be paged when the helper starts doing creative accounting.
5. Keep a rollback path. If yesterday’s prompt made the agent calm and today’s made it reckless, you need a revert that is as easy as rolling back a bad config. Immutable versions and clear tags help. Even a dated folder of known-good prompts beats archaeology in Slack.
6. Test behavior, not just code. For high-risk helpers, keep a short suite of golden scenarios: “export invoices,” “never write,” “escalate when auth looks wrong.” When you change the harness, rerun those scenarios. Perfect determinism is not the goal. Catching gross drift is.
What this is not
This is not an argument against agents. I want engineers using assistants for drafting, exploration, refactoring, and the dull glue work that steals afternoons. AI is a tool. Programming or coding remains a skill. Software engineering remains the work of building solutions with software under real constraints.
It is also not a call to freeze every prompt behind a committee. Low-risk assistants can move fast. High-blast-radius assistants need the same seriousness you already give production config, because that is what they are.
Closing
If your team’s agent can open pull requests, call tools, or keep multi-week project memory, the interesting engineering problem is no longer “which model won last week’s leaderboard.” The interesting problem is whether the harness is reviewed, owned, and reversible.
So the next time someone wants to “just tweak the instructions,” smile and ask for a PR. You are not being pedantic. You are protecting the same fundamentals that kept production stable before chat UIs showed up: clear permissions, visible change history, and a human who still owns the outcome.
Loved it? Drop a comment with what broke first on your team: the tool allowlist, the shared memory, or the “temporary” write access that somehow became permanent. Support the shenanigans on Patreon or buy me a coffee, and follow AttuneIT on YouTube, X, and Facebook. Let’s make tech less scary and more awesome.