For a while, the story of AI coding agents was mostly an individual one. A developer found a setup that worked for them, tuned their prompts, built out a personal CLAUDE.md, and quietly shipped twice as fast as their teammates. Meanwhile, the team around them saw mixed results, occasional AI-generated slop landing in reviews, and a growing divide between the people getting leverage and those who weren’t.
That individual-leverage phase is running out of room. The more interesting and harder problem now is making an entire team ship well with agents — and it turns out that’s less a tooling problem than an engineering leadership problem.
The babysitting signal
There’s a useful diagnostic for whether a team’s agentic setup is actually working: are developers babysitting the agent, or walking away?
If engineers are constantly steering, correcting, re-prompting, and watching over the agent’s shoulder — burning 500,000 to 750,000 or more tokens on tasks that aren’t genuinely complex — the instinct is to blame the model. “It’s having a dumb day.” In practice, the bottleneck is almost always the shared codebase setup, not the model’s capability. The agent is navigating blind because the environment it’s working in wasn’t designed to orient it.
What harness engineering actually means
“Harness” here means everything that sits around the model and turns its raw capability into reliable, directed output — the context it receives, the feedback loops that catch mistakes, the scaffolding that tells it where to look and what counts as done.
Three principles hold up across teams that are shipping well with agents.
Make the codebase a context-delivery system. Documentation shouldn’t live in a wiki somewhere — it should live in the code itself, close to the thing it describes, so an agent that searches into a file immediately finds the context it needs. The goal is that an agent gets a map rather than a dump. The first thing worth testing: give the agent a prompt and watch what it reaches for. Does it navigate with intention, or grep blindly? If it’s burning 40,000 to 50,000 tokens before doing any meaningful work, the context delivery isn’t working.
Build loops that catch and remove slop. Slop — mediocre, technically-passing-but-poor code — is inevitable at scale. The answer isn’t more careful prompting; it’s automated detection and removal. That means wiring CI/CD properly, and adding what some teams call a “code gardener”: a nightly automated pass that checks code organization and quality. These aren’t one-time fixes. They run continuously, because the problem is continuous.
Treat harness work as permanent. This is the discipline shift that doesn’t fit naturally into sprint planning. Harness improvements produce no visible PR, but they are what determine whether next month looks better than last month. Allocating a real fraction of engineering time to this — permanently, not as a project — is what separates teams that compound from teams that plateau.
Getting past the individual leverage gap
One pattern worth borrowing: start by finding the engineers who are already getting genuine leverage from agents, and extract their practices into shared infrastructure. The resistance here is real — most people assume their setup is idiosyncratic to them, or they’re reluctant to have it scrutinized. Getting past that means framing it as “help us make this available to the whole team,” not “your setup is being evaluated.”
Picking one high-value workflow to invest in deeply — rather than trying to agent-ify everything at once — accelerates buy-in. A “ship it” skill that takes a finished piece of code all the way to a PR-ready state, handling CI failures, writing the description, responding to review comments, often running for over an hour unattended — is the kind of thing that converts skeptics. The first time someone walks away from their desk and comes back to a clean, ready-to-merge PR, the conversation shifts.
The skeptics themselves are worth winning over deliberately, not by dismissing their concerns but by getting them to contribute to the shared setup. True organizational buy-in looks like engineers opening PRs into the harness.
The problems that don’t go away
Merge conflicts compound. Issue trackers can explode if agents aren’t correctly wired to them (400 to 500 open issues in a couple of weeks is a real failure mode, not a hypothetical). Prototype and experiment code needs to be explicitly opted out of production-grade standards — otherwise the automated quality loops create friction in exactly the places where speed matters most.
And people vary. Someone’s comfort with agents shifts day to day, depending on how a session went, how much cognitive overhead they’re carrying, how much they trust the tool this week. Regular check-ins aren’t team-building overhead — they’re part of maintaining the feedback signal that drives harness iteration.
Where this is heading
The framing of “prompt engineering” as the core discipline is giving way to something broader: the design of the environment agents work in. That’s a codebase concern, an infrastructure concern, and an organizational concern all at once. Teams that are building that capacity now — not as a side project but as a permanent engineering function — will find the leverage compounds in ways that model upgrades alone never could.
Text summarized and optimized using Anthropic’s models and reviewed by a human.