Preface — why this article exists

You’ve been handed a task. Maybe your CTO read something about AI coding agents and wants the team using them “properly.” Maybe a developer installed Claude Code last week and is already committing AI-generated code that nobody reviewed. Maybe you’re the platform engineer who has to figure out what “enterprise-grade” even means for this stuff.

This guide is for that moment.

The shift is no longer hypothetical. AI tool usage among professional developers hit the mid-80s percent — many using agents daily, 40%+ of new code AI-generated. “Is the model good enough” is settled. A different question replaced it.

The uncomfortable part: in the most rigorous study to date — a METR randomized controlled trial (July 2025, arXiv:2507.09089) — experienced developers in their own large codebases were 19% slower with AI, while believing they were ~20% faster. Powerful tools, handed over raw against complex code, can still be a net negative.

Closing that gap is the subject of this guide. A better model won’t do it. What does is everything aroundthe model: what it knows about your codebase, what it’s allowed to do, how you know what it did, how you stop it doing what it shouldn’t, and how you scale all that across a team.

That structure is what this guide calls a harness — an engineering problem, not a configuration one. Skip it, hand over a raw tool, and you get the 19%: inconsistent output, compliance gaps, no audit trail, and agents that confidently do the wrong thing.

You’ll hear “vibe coding” used as both a badge and a slur. It’s neither. It’s one end of a spectrum. At one end, you prompt an agent and accept what comes back — fast, fine for a weekend prototype, reckless for a payment system. At the other end, sometimes called agentic engineering, the agent is a powerful implementation engine wrapped in specs, tests, guardrails, and human judgment. The difference between them isn’t whether you use AI. It’s how much structure surrounds the output.

Telling a CTO your team is vibe coding the settlement service should raise alarm bells. Telling that same CTO your team practices agentic engineering — AI implementing under human-designed constraints, with verification at every stage — is a different conversation entirely. This guide is how you have the second conversation. Part 1 shows you how to locate your team on that spectrum before you build anything.

The challenge today is the same: there’s too much written about AI coding, most of it contradicts the next thing, and it’s hard to know what to trust. This guide is built to cut through that — and different readers will use different parts of it.

If you’re a solo developer or small team just starting with agents, the foundations in Parts 1–3, the economics in Part 5, and the traps in Part 8 are where the value is. Parts 4 and 6 will be overkill for now — skip them until you need them.

If you’re an engineer trying to ship safely with these tools day to day, the whole arc applies, but Parts 2–3 and the traps are your core.

If you’re a platform engineer or lead asked to make AI tools safe and consistent across an org, this is the whole map — every part earns its place.

Each section is a question a developer or platform engineer actually asks, in roughly the order they ask it. You don’t have to read front to back. Already know what a harness is? Skip to Part 2 or 3. Deep in a Copilot rollout? Go to Part 3. Need to justify the spend to Management? Part 5 is your ammunition. Staring at a list of things that could go wrong? Start at Part 8.

Every answer is meant to be practical: real configuration, real tradeoffs, real citations. Where the evidence is strong, we say so. Where it’s a vendor announcement or a practitioner blog, we say that too.