Synthesized by Clarity (Claude) from 22 sources · May contain errors — spot one? [email protected] · Methodology →
Harness Engineering Emerges as the AI Coding Unlock at Scale
- Sources
- 22
- Words
- 1,435
- Read
- 7min
Topics Agentic AI LLM Inference AI Capital
◆ The signal
Harness engineering — the discipline of building constraints, linters, documentation, and sandboxed environments around coding agents — has independently emerged at OpenAI, Stripe, and Anthropic as the critical unlock for AI-assisted development. OpenAI's 3-person team shipped a million-line product in five months with zero hand-written code; Stripe's agents merge 1,000+ PRs per week. The bottleneck was never the model — it was your environment. Start building AGENTS.md and agent-friendly linter rules this week, because this infrastructure compounds and every day you wait widens the gap.
◆ INTELLIGENCE MAP
Intelligence map
01 Harness Engineering: The New Discipline for Agent-Assisted Development
act nowOpenAI, Stripe, and Anthropic have converged on a concrete set of patterns — AGENTS.md, custom linters with remediation instructions, MCP-exposed tooling, and plan-then-execute workflows — that make coding agents production-viable, but every success story is greenfield and legacy adoption remains unsolved.
02 MCP and Agent Protocol Security Is the New Attack Surface
act nowCisco confirms attackers are already probing MCP and agent-to-agent protocols — the same protocols that harness engineering relies on for tool exposure — meaning agent infrastructure hardening must happen in parallel with adoption, not after.
03 Multi-Model Routing and LLM Architecture Patterns
monitorMulti-model workflows (Claude for coding, Gemini for long context, GPT-5 for general tasks) are now standard practice at the executive level, and GPT-5's native platform connectors signal OpenAI is moving from model provider to integration platform — your LLM abstraction layer needs model routing as a first-class capability.
04 Developer Productivity Measurement and AI Workflow Gaps
monitorLinkedIn open-sourced their Developer Productivity & Happiness Framework while practitioners report a widening gap between engineers who effectively use LLMs and those who don't — structured team retrospectives on AI tool usage are overdue.
05 AI Infrastructure Energy and Ownership Constraints
background72% of enterprises report being blocked by infrastructure debt when scaling AI, and the AI-energy nexus is becoming a top editorial theme — the bottleneck for most organizations isn't model capability but the data, power, and infrastructure plumbing feeding the models.
◆ DEEP DIVES
Deep dives
01 Harness Engineering Is Here: The Concrete Playbook from OpenAI, Stripe, and Anthropic
act nowThe Environment Was Always the Bottleneck
Mitchell Hashimoto coined the term harness engineering — the practice of building constraints, tools, documentation, and feedback loops that keep coding agents productive. The key insight, validated independently across OpenAI, Stripe, and Anthropic: agent capability was never the constraint. The environment was. Think Docker for AI-generated code — it didn't make applications faster, it made deployment reliable by constraining the environment.
OpenAI's 3-person team built a million-line internal product in five months with zero hand-written code, averaging 3.5 PRs per engineer per day. Their secret wasn't a better model — it was a strict layered architecture with rigid dependency boundaries enforced by custom linters.
The Patterns That Work
The convergence across organizations is striking. Here are the concrete, adoptable patterns:
- AGENTS.md as a living feedback loop: Not static documentation — every time an agent makes a mistake, you add a line preventing that class of error permanently. Ghostty's AGENTS.md has each line corresponding to a specific past agent failure. OpenAI uses a hierarchical approach: a small AGENTS.md pointing to deeper design docs, architecture maps, and quality grades, all versioned in the repo.
- Custom linter rules with remediation instructions: When an agent violates an architectural constraint, the error message tells it exactly how to fix the violation. This creates a self-correcting loop that doesn't require human intervention for known failure modes. The linters themselves were Codex-generated.
- MCP-exposed internal tooling: Stripe's Toolshed platform exposes 400+ internal tools via MCP servers, giving agents the same operational surface area as human engineers.
- JSON over Markdown for agent-facing structured data: Anthropic discovered agents treat Markdown as prose they can freely rewrite, but respect JSON's structure. Small detail, big implications for agent-facing configuration.
- Plan-then-execute as mandatory workflow: No agent writes code until a human has reviewed and approved a written plan.
The Honest Failure Modes
Agent-generated code accumulates entropy differently than human-written code. OpenAI runs periodic 'garbage collection' agents but admits it's an emerging practice. Anthropic found agents marking features as complete without proper end-to-end testing — their browser automation tools have blind spots (Puppeteer can't see native alert modals). The human review bottleneck is real: practitioners cap out at 3-4 parallel agent sessions before becoming the constraint.
Every success story is greenfield. Applying harness engineering to a legacy codebase with inconsistent testing, implicit conventions, and patchy documentation is an open problem nobody has convincingly solved.
Why This Compounds
Every AGENTS.md update, every custom linter rule, every MCP-exposed tool accelerates all future agent work. Stripe's unattended model — developer posts a task in Slack, agent writes code in a pre-warmed sandboxed devbox, passes CI, opens a PR — produces 1,000+ merged PRs per week. But it requires mature infrastructure most teams don't have yet. The role of the engineer is bifurcating: you're either building the environment or managing the work. Start now, even incrementally.
Action items
- Create an AGENTS.md at the root of your primary repositories by end of this week — start with architectural constraints, common pitfalls, and testing conventions
- Audit your linter rules and add agent-friendly remediation instructions to error messages within this sprint, prioritizing architectural boundary violations
- Designate an 'agents captain' on each team by end of month — someone responsible for evaluating agent fit, maintaining the harness, and championing adoption
- Inventory your internal tools and create a prioritized list for MCP server exposure this quarter, starting with most-used CLI tools, deployment scripts, and monitoring dashboards
Sources:The Emerging "Harness Engineering" Playbook · 🧠 Intelligence should be owned, not rented · Welcome to the free edition of The Pragmatic Engineer Newsletter
02 MCP Is the New Microservices Security Problem — and Attackers Are Already There
act nowThe Protocol Layer Is Under Active Attack
Here's the tension you need to internalize: the same MCP protocol that harness engineering depends on for tool exposure is already being actively probed by attackers. Cisco's SVP of AI Software and Platform confirms it plainly — agents are being hijacked, impersonated, and manipulated to exfiltrate data or execute unauthorized commands 'at machine speed.'
MCP and agent-to-agent protocols scaled as connectivity standards, not security standards. They tell agents how to talk to tools and each other, but the identity, authorization, and behavioral monitoring layers are bolted on after the fact, if at all.
The Microservices Parallel Is Exact
If you lived through the early microservices era, you've seen this movie. Everyone was excited about service decomposition, but the real production pain was service-to-service auth, mTLS, and observability. We're in that exact same phase with agentic AI. The prescription maps cleanly:
Microservices Pattern Agent Equivalent Service identity (mTLS) Zero-trust identity for agents as first-class IAM principals API gateway / service mesh Controlled tool registries — agents access only explicitly granted capabilities Distributed tracing Continuous behavioral monitoring — detecting action pattern deviation Circuit breakers Human-in-the-loop gates for privileged operations Where to Draw the Human-in-the-Loop Line
The design constraint is crisp: anything that affects trust, access, or control over critical systems — granting privileges, changing production environments, authorizing sensitive data access, initiating irreversible actions — should never run fully autonomous. The 80/20 heuristic for autonomous incident resolution gives you a planning model: design for full autonomy on the pattern-matching 80%, and design explicit escalation paths for the complex 20%.
This directly intersects with harness engineering. If you're exposing 400 tools via MCP like Stripe, each tool needs an explicit authorization model. The speed at which you adopt agent tooling must not outpace the speed at which you secure it.
Action items
- Audit all MCP and agent-to-agent protocol implementations for identity, authorization, and behavioral monitoring gaps by end of this sprint
- Map your agent capabilities against a privileged-operations checklist (production deployments, PII access, privilege grants) and add human approval gates for each by end of month
- Evaluate adding agent identity as first-class principals in your IAM system this quarter
Sources:🧠 Intelligence should be owned, not rented · The Emerging "Harness Engineering" Playbook
03 Your LLM Abstraction Layer Needs Model Routing — Here's the Evidence
monitorMulti-Model Is Now Default, Not Experimental
Three independent sources this cycle confirm the same pattern: no single model wins across all tasks, and the teams getting the most value are routing tasks to the right model. Even GPT-5 power users still reach for Claude for coding and Gemini for long-context analysis. This isn't benchmark data — it's consistent practitioner behavior across different organizations and use cases.
GPT-5's Platform Play Changes the Integration Calculus
GPT-5 now ships with native platform connectors (e.g., HubSpot), signaling OpenAI is moving from model provider to integration platform. You now have three competing patterns for LLM-powered tool integration:
- Custom function-calling: You define tools and handle API calls yourself. Maximum control, maximum maintenance.
- MCP or similar open protocols: Tool discovery and execution via an open standard. Portable but security-immature (see above).
- OpenAI native connectors: Fastest to ship, hardest to migrate away from. Vendor lock-in by design.
If you're hardcoding
model='gpt-5'throughout your codebase, you're accumulating tech debt. A routing layer that selects models based on task classification pays for itself quickly — and becomes essential as the model landscape continues to shift quarterly.The Two-Pass Pattern for User-Facing Features
The 'meta prompting' technique — asking an LLM to rewrite a prompt before executing it — is the prompt-engineering equivalent of query rewriting in search/RAG systems. The interesting UX detail: generating multiple-choice clarification options instead of free-text follow-ups. This structured disambiguation reduces cognitive load on users while constraining the input space, making the refinement step more reliable. If you're building user-facing AI features where prompt quality varies wildly, this two-pass pattern with structured output on the first pass is worth implementing.
Action items
- Add model routing to your LLM abstraction layer this quarter if you don't already have it — treat the model as a swappable dependency, not a hardcoded constant
- Evaluate GPT-5's native connector architecture within the next two sprints if you're building SaaS integrations through LLMs
- Prototype a two-pass prompt refinement pattern for one user-facing AI feature this quarter
Sources:🧠 Intelligence should be owned, not rented · 🤖 Meta Prompting: The Secret to Better AI Results · Welcome Email 2/3: Our Most Popular Issue
04 Developer Productivity Measurement: LinkedIn's DPH Framework and the LLM Usage Gap
backgroundLinkedIn Open-Sources Their Productivity Framework
LinkedIn has released their internal Developer Productivity & Happiness (DPH) Framework — a structured system of metrics, processes, and feedback loops for understanding developer needs. This isn't just a dashboard template; it's an operational playbook covering systems, processes, metrics, and feedback systems. The interesting question is how their metric choices compare to the DORA/SPACE frameworks that have dominated the DevEx conversation.
The cargo-culting risk is real: LinkedIn has thousands of engineers, and their measurement overhead makes sense at that scale. For a 20-person team, you need to ruthlessly simplify. But as a baseline taxonomy for what to measure and why, it's the most concrete reference implementation available.
The LLM Usage Gap Is Widening
A staff engineer's observation resonates with the harness engineering data: engineers getting the most value from LLMs aren't using them for the obvious use case (generate this function). They're using them for codebase exploration ('explain this legacy module's error handling patterns'), RFC drafting ('here's my architecture decision, argue against it'), and test generation. At the staff level, work is less about writing code and more about understanding systems, communicating decisions, and reviewing others' work — all areas where LLMs are surprisingly effective.
If your team hasn't had a structured conversation about LLM workflows, you're leaving productivity on the table — and the gap between effective and ineffective users is widening every month.
This connects directly to harness engineering: the teams that formalize how agents and LLMs fit into their workflows — with AGENTS.md, designated champions, and shared patterns — will compound their advantage over teams where adoption is ad hoc and individual.
Action items
- Pull LinkedIn's DPH Framework repo and evaluate their metric taxonomy against your current developer productivity measurements within the next month
- Run a team retrospective on LLM tool usage patterns within the next two sprints — identify where AI tools are working, where they're not, and share effective workflows
Sources:Welcome Email 2/3: Our Most Popular Issue · The Emerging "Harness Engineering" Playbook
◆ QUICK HITS
Quick hits
Anthropic found JSON outperforms Markdown for agent-facing structured data — agents treat Markdown as rewritable prose but respect JSON's structure
The Emerging "Harness Engineering" Playbook
72% of enterprises report being blocked by infrastructure debt (legacy networks, fragmented data, siloed tooling) when scaling AI beyond pilots
🧠 Intelligence should be owned, not rented
The SQL-as-API pattern is being re-evaluated — with Postgres row-level security and parameterized query APIs, the traditional objections are weaker than in 2005, especially for internal service-to-service communication
Welcome Email 2/3: Our Most Popular Issue
PostHog published their fully-async operations playbook across 11 countries — worth reading if you're running distributed engineering teams
Welcome Email 2/3: Our Most Popular Issue
Voice AI agents in production suffer from hallucination, drift, and prompt breakage at scale — ElevenLabs investing in enterprise go-to-market signals the market is moving from pilot to production phase
📬 Write prompts that power better AI conversations
◆ Bottom line
The take.
Harness engineering — AGENTS.md files, custom linters with remediation instructions, MCP-exposed tooling, and plan-then-execute workflows — is the discipline that separates teams shipping 1,000 agent-generated PRs per week from teams still debating whether AI coding tools are useful. But the same MCP protocol enabling this is already under active attack, so you must harden agent infrastructure in lockstep with adoption. Create your AGENTS.md this week, audit your MCP security this sprint, and add model routing to your LLM layer this quarter.
Frequently asked
- What is harness engineering and why does it matter more than model choice?
- Harness engineering is the discipline of building constraints, linters, documentation, and sandboxed environments around coding agents so they stay productive. The convergent evidence from OpenAI, Stripe, and Anthropic is that agent capability was never the bottleneck — the environment was. Docker didn't make apps faster; it made deployment reliable through constraint. Harness engineering does the same for AI-generated code.
- How should an AGENTS.md file actually be structured to be useful?
- Treat it as a living feedback loop, not static documentation — every time an agent makes a mistake, add a line preventing that class of error permanently. Ghostty's AGENTS.md has each line traceable to a specific past failure. OpenAI layers it hierarchically: a short root AGENTS.md points to deeper design docs, architecture maps, and quality grades, all versioned in the repo alongside code.
- What are the honest failure modes teams should expect when adopting agent workflows?
- Agent-generated code accumulates entropy differently than human code, requiring periodic 'garbage collection' passes that are still an emerging practice. Agents mark features complete without proper end-to-end testing, and browser automation tools have blind spots like Puppeteer missing native alert modals. Human review caps out around 3-4 parallel agent sessions per person. And every published success story is greenfield — legacy codebases remain an open problem.
- Why is MCP a security concern, and where should human-in-the-loop gates go?
- MCP and agent-to-agent protocols were designed as connectivity standards, not security standards, and Cisco confirms attackers are already hijacking and impersonating agents at machine speed. The rule: anything affecting trust, access, or control over critical systems — production changes, privilege grants, sensitive data access, irreversible actions — should never run fully autonomous. Design for autonomy on the pattern-matching 80% and explicit escalation for the complex 20%.
- Should I hardcode a single model, or invest in a routing layer?
- Invest in routing. Even GPT-5 power users still reach for Claude on coding and Gemini for long-context analysis, and the model landscape shifts quarterly. If you're hardcoding model='gpt-5' throughout your codebase you're accumulating tech debt. Treat the model as a swappable dependency selected by task classification, which is now standard practice rather than premature optimization.
◆ Same day, different angle
Read this day as…
◆ Recent in engineer
Keep reading.
- Chrome's synced passkeys all decrypt under one 32-byte secret reachable in memory.
- 221,303 Verified Live Credentials in Hugging Face Datasets
- 3 Eval Escapes in 141,006 Runs Reach Others' Production
- SRI Can't Pin the Adform Ad Tag Rewriting Wallet Addresses
- Cursor Hit 50% of PRs by Fixing Environments, Not the Model
Spot an error? [email protected]