The Engineer

The 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.

The 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:

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.

Multi-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:

1. Custom function-calling: You define tools and handle API calls yourself. Maximum control, maximum maintenance.
2. MCP or similar open protocols: Tool discovery and execution via an open standard. Portable but security-immature (see above).
3. 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.

LinkedIn 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.