Harness Engineering for AI Coding Agents from Argentina

The term picked up momentum in early 2026 after Mitchell Hashimoto (co-founder of HashiCorp) put a name to something many engineering leaders had already concluded the hard way: when an agent misbehaves, the right fix is usually a change to the system around it, not another sentence added to a prompt. OpenAI echoed the point shortly after, describing how they shipped an internal product with effectively no hand-written code by investing in the scaffolding that surrounded their Codex agents rather than the prompts driving them.

The Thoughtworks Technology Radar (Volume 34, April 2026) flagged harness engineering as one of the defining macro trends in the industry. Their read: the space is shifting from experimentation toward repeatability and stability. Agent reliability has moved from "one concern among many" to a board-level risk at several of the companies we talk to.

The core argument is simple. Telling an agent "follow our coding standards" in a system prompt is like telling a new hire to "write good code." It works some of the time. LLM compliance with instructions is probabilistic, not deterministic. Your agent can honor every architectural convention on Monday and introduce a direct database call that skips your ORM layer on Tuesday. Prompts suggest; they do not enforce.

A harness adds the enforcement layer. AGENTS.md files encode architectural boundaries in a format agents can reason about. CI gates reject code that violates those boundaries before it reaches the main branch. Plan-Execute-Verify loops push agents through explicit checkpoints. Observability dashboards surface whether the harness is working or whether new failure patterns are quietly forming. Each layer reinforces the others: constraints reduce the volume of failures, verification catches what slips through, and observability exposes the patterns both layers missed.

Plan

The agent reads the specification, loads project context from AGENTS.md and rules files, decomposes the task, checks constraints, and proposes an implementation approach. For high-risk changes we insert a human approval gate between plan and execution. The agent does not move forward until the approach is explicitly signed off.

Execute

The agent generates code and tests inside a sandboxed environment. Execution is bounded by the constraints defined in the plan. Changes land as incremental commits, not one massive diff. If the agent tries to touch a protected module or pull in a disallowed dependency, the constraint layer blocks the action before it reaches the repository.

Verify

The test suite runs at every level: unit, integration, end-to-end. Static analysis flags code quality and security issues. Architecture compliance verifiers confirm the change respected module boundaries. Mutation testing checks that the new tests actually catch bugs and are not just touching code paths. Pass/fail feedback, with specific context, goes back to the agent for retry.

The AGENTS.md open standard, released in 2025, gives agents structured project context. Context alone is not a harness. Most teams we walk into already have some version of AGENTS.md or CLAUDE.md. The file typically lists the tech stack, sketches a few conventions, and includes a handful of "don't do this" notes.

That is a starting point, not a constraint system. A well-engineered AGENTS.md includes architectural boundaries that map to enforceable CI checks, testing requirements tied to specific verification gates, security rules that reference actual scanning configurations, and dependency policy that mirrors your package manager setup. The file stops being a suggestion list and becomes a contract between humans and agents.

We write AGENTS.md files that behave like executable specifications. Every constraint in the file maps to a CI check that enforces it. Every testing requirement maps to a verification gate. When the file says "all database queries go through the ORM," there is a static analysis rule that catches direct SQL. When it says "integration tests required for API routes," the pipeline blocks merges without them.

Phase 1: Agent Audit (Weeks 1-2)

We map current agent usage across teams and repositories. Which tools are people actually using (not which were approved)? What share of recent commits involved AI assistance? Where are the failure clusters? We measure baseline metrics: task resolution rate, rework rate, architecture drift. The output is a prioritized inventory of harness requirements plus an implementation plan you can socialize with leadership.

Phase 2: Harness Design (Weeks 3-5)

Using the audit, we design the constraint architecture. Which boundaries need hard enforcement? Where do verification gates fit in the pipeline? What level of human oversight is appropriate for different risk classes? How do multi-agent workflows get coordinated? We make these decisions with your team in the room. A harness imposed from outside does not survive the first week of real use.

Phase 3: Build and Integrate (Weeks 5-10)

The implementation phase. AGENTS.md and rules files per repository. PEV loop infrastructure. CI gate configuration. Agent sandboxing. Observability dashboards. Threshold calibration. Every component is exercised against real agent workflows, not hypothetical ones. Thresholds get tuned to avoid over-constraining, because a harness that blocks too much valid work is worse than no harness at all.

Phase 4: Handoff and Training (Weeks 10-14)

Documentation, runbooks, spec-writing workshops, and hands-on training for maintaining the harness as your codebase and agent stack evolve. We teach your team to update constraints, adjust verification gates, and read the observability data. The default outcome is full ownership transfer. Ongoing support is optional, not assumed.

The Situation

A Series B SaaS platform with roughly 70 engineers across Miami, Buenos Aires, and Mexico City came to us in early 2026 after hitting a wall with their AI coding tool adoption. The team had rolled out Claude Code and Cursor Agent six months earlier. Per-developer throughput rose around 40 percent on their internal tracking. Leadership was happy with the numbers.

Then three things landed in the same month. A production incident traced back to an AI-generated database migration that bypassed their ORM and broke data integrity for roughly 12,000 customer records. A security audit flagged credential handling inconsistencies across 8 of their 14 repositories, all in agent-generated modules. And their lead architect realized their monorepo had developed two competing API patterns because different agents had introduced different conventions in different services, and nobody noticed until integration failures surfaced.

They tried fixing this with better prompts and more elaborate system instructions. It worked for roughly two weeks. Then fresh instances of the same patterns showed up elsewhere. Their VP of Engineering put it plainly: "We cannot give back the speed, but we cannot keep shipping at this defect rate either."

What We Built

We stood up a five-person squad from Córdoba over 12 weeks: two platform engineers, two DevOps specialists, and a harness architect leading the engagement. Our Argentine team overlapped four hours daily with their Miami leads, which mattered more than anyone expected when constraint thresholds needed tuning in real time.

The core decisions were:

• AGENTS.md files per repository with enforceable architectural boundaries. The ORM-only constraint was backed by a Semgrep rule that blocked direct SQL in CI. The duplicate API pattern was resolved with a shared API style guide agents had to consume before planning.
• PEV loops in GitHub Actions that required agent-generated PRs to pass plan validation, automated testing at three levels, and architecture compliance checks before merge was allowed.
• A multi-agent coordination layer that assigned Claude Code to complex refactors and Cursor to routine feature work, with task decomposition to stop concurrent agent sessions from colliding.
• Observability dashboards tracking agent success rate, rework rate, and drift detection across all 14 repositories, plugged into their existing Datadog setup.

Six months after deployment the team held the 40 percent throughput gain from AI tools while taking defect rates below their pre-agent baseline. Their VP of Engineering summarized it as "we stopped fighting the agents and started working with them." For more proof points, see our case studies page.

Most companies treat harness engineering as a purely technical problem. Build the CI gates, write the rules files, stand up dashboards. Done. The harder failure mode is not technical. It is cognitive debt: the widening gap between what your codebase actually does and what your team understands about it.

When agents generate 60 or 70 percent of your code, developers lose touch with implementation details they used to know cold. A senior engineer who used to understand every quirk of the authentication module now reviews agent-generated changes to it without the same mental model. The code works. The tests pass. Understanding erodes quietly. Six months later, when something breaks in a way the tests did not cover, nobody on the team has the context to debug it quickly.

This is why our engagements always include the team enablement component. We help engineering managers decide which parts of the codebase demand deep human understanding (security-critical paths, data integrity logic, customer-facing payment flows) and which can safely become "agent-maintained territory" with lighter oversight. The target is not maximum agent autonomy. It is the right balance between velocity and comprehension for each team.

Outsourcing Is a Good Fit When

• You have no platform engineers with agent reliability experience on staff (most teams do not; the discipline barely existed 18 months ago).
• Agent-generated code is already causing production issues and you need harnesses operational in weeks, not quarters.
• Your team uses multiple AI coding tools and you need harnesses that stay coherent across all of them.
• You want the harness built once, tuned to your codebase, and handed off to your internal team for ongoing maintenance.
• You have more than 30 engineers using agents and the coordination overhead has become unmanageable through ad-hoc review.
• You want nearshore delivery with time-zone overlap with US Eastern time, not a 12-hour async relay across APAC.

Building In-House Makes More Sense When

• You already have a strong platform engineering team that just needs a reference architecture and some sparring partners.
• Your team is small enough (under 15 engineers) that informal review still catches most issues.
• You use a single AI coding tool and your constraint needs are narrow and well-scoped.
• You have 6 to 9 months of runway to iterate on the harness without urgent production pressure.

Task Resolution Rate tracks the percentage of tasks an agent resolves correctly, verified against automated tests. DORA-style research suggests top agents in well-harnessed environments hit 65 to 77 percent. Without harnesses, most teams sit between 25 and 40 percent.

Pass@1 Rate measures whether the agent gets it right on the first attempt, with no retries. This matters because retries burn compute budget and developer attention. A well-tuned harness pushes pass@1 above 60 percent on routine tasks.

Rework Rate shows what share of agent-generated PRs require human intervention after the first verification pass. Pre-harness rework rates of 50 to 60 percent are common. Post-deployment, we target below 15 percent.

Architecture Drift tracks how often agent-generated code violates established architectural patterns. This surfaces the slow degradation that per-PR review misses. We integrate drift detection into your existing observability stack.

AI
Development Outsourcing

AI Code
Security Services

AI-Powered
Software Testing

AI Agents
Development Outsourcing

MCP
Development Outsourcing

Platform
Engineering Outsourcing