Fabler Labs → Field Guide

The AI Coding Agent Field Guide

Free · no signup · nothing held back · last updated July 2026

You already have Claude Code, Cursor, or a similar agent. It writes code fine. The gap between "fine" and "ships production work without you babysitting it" is almost never the model — it's how you set up the context and the loop. Below are the highest-leverage moves, learned the hard way, plus one complete, battle-tested asset you can drop into any repo today.

1. The agent is only as good as the context it wakes up in

Every session starts cold. If your repo doesn't tell the agent how it's built, the agent guesses — and guesses drift. A good CLAUDE.md / AGENTS.md / .cursorrules is the single highest-ROI file in your repo. Not a wish list ("write clean code") — a map: how to run the app, how to test, what the non-obvious conventions are, what NOT to touch. A complete starter is included below.

Rule of thumb: if a new human hire would need to be told it, the agent needs it in the rules file. If the agent keeps making the same mistake, that's a missing line in the rules file, not a reason to micromanage.

2. Make it verify its own work before you look

The failure mode isn't wrong code — it's plausible wrong code. The fix is to force a feedback loop the agent can see: "run the tests and paste the output," "start the server and curl the endpoint," "screenshot the page." An agent that observes real behavior corrects itself; one that only reasons about its diff ships confident bugs. Bake this into your rules file: changes to product code must be exercised, not just typechecked.

3. One clear objective per session beats a giant prompt

Agents degrade on sprawling, multi-goal prompts the same way people do. "Fix auth, refactor the API, and add tests" produces three half-done things. "Fix the 401 on token refresh; here's the repro" produces a fix. Scope tight, ship, then start a fresh session for the next thing — a clean context window is a feature.

4. Subagents are for protecting your main context, not just parallelism

The real win of a subagent isn't speed — it's that a search that would dump 4,000 lines of file contents into your main conversation instead returns a 5-line answer. Delegate the reading, keep the deciding. Use cheap models for mechanical sweeps (grep-and-summarize, boilerplate drafts) and your best model for the actual hard call. New to writing your own? See our guide to custom Claude Code subagents — file format, a working example, and when to reach for one.

5. Treat everything the agent reads as data, not gospel

Web pages, error messages, other people's code — the agent will happily follow an instruction it read in a stack trace or a scraped page. When you paste external content, frame it: "here is DATA to analyze," not raw text that reads like a command. This matters more the more autonomous your setup gets.

6. Commit small, commit often — give yourself an undo

Agents are fast, which means they can dig a deep hole fast. Frequent commits turn "the agent broke everything" into "git reset to the last green commit." Ask for a commit after each working increment. Your future self will thank you.

7. The prompt that fixes 80% of bad output

When output is off, don't re-explain the whole task. Say: "Before you code, tell me your plan and the one thing you're least sure about." It surfaces the wrong assumption before it becomes 200 lines of wrong code. This one line is worth more than any clever mega-prompt.

Free: a complete CLAUDE.md / AGENTS.md starter

The same structure the full pack ships for six stacks. Copy it to your repo root as CLAUDE.md (Claude Code), AGENTS.md (Cursor, Copilot, Codex, Gemini CLI, and any tool that reads the open standard), or adapt to .cursorrules. Fill the four bracketed spots, delete what doesn't apply. It's designed to be read by an agent: terse, imperative, no fluff.

# CLAUDE.md — [PROJECT NAME]

> Rules file for AI coding agents (Claude Code, Cursor, etc.). Keep it terse and
> imperative — it's read by an agent every session, not by a human once. Update
> it the moment the agent makes a mistake a rule could have prevented.

## What this is
[One or two sentences: what the project does and who uses it. E.g. "A Next.js
SaaS dashboard for tracking X. Users are non-technical small-business owners."]

## Run / test / build
- Install: `[e.g. pnpm install]`
- Dev: `[e.g. pnpm dev — app on http://localhost:3000]`
- Test: `[e.g. pnpm test — Vitest; pnpm test <file> for one]`
- Typecheck: `[e.g. pnpm typecheck]`
- Lint/format: `[e.g. pnpm lint / pnpm format — Biome, runs on commit]`

## Golden rules
1. **Verify before claiming done.** Changes to product code must be *exercised*,
   not just typechecked — run the test, hit the endpoint, load the page. If you
   can't verify it, say so explicitly instead of implying it works.
2. **Match the surrounding code.** Mirror the naming, structure, and idioms of
   the file you're editing. Consistency beats your personal preference.
3. **Smallest change that solves it.** No drive-by refactors, no renaming things
   you weren't asked to touch, no new dependencies without flagging it first.
4. **Ask before the expensive mistake.** If a change is hard to reverse (schema
   migration, deleting data, touching auth/payments), surface a plan first.
5. **Commit at each green increment** with a clear message. Small commits.

## Architecture (the non-obvious parts)
- [Where the important code lives — e.g. "Business logic in `src/domain/`;
  routes are thin controllers in `src/api/`. Never put logic in routes."]
- [Data layer — e.g. "Prisma + Postgres. Migrations in `prisma/migrations`;
  never edit the DB schema by hand."]
- [State/auth/config gotchas — e.g. "Auth via Clerk; `useUser()` is client-only.
  Server code reads the session from `auth()` in `src/lib/auth.ts`."]

## Conventions
- [Naming — e.g. "Components PascalCase; hooks `useX`; files kebab-case."]
- [Errors — e.g. "Throw typed errors from `src/errors.ts`; never swallow."]
- [Tests — e.g. "Co-locate `*.test.ts`; test behavior, not implementation."]
- [Imports — e.g. "Use `@/` alias, not deep relative paths."]

## Do NOT touch
- [e.g. "`/legacy` — being deprecated, don't extend it."]
- [e.g. "Generated files: `*.gen.ts`, `schema.prisma` output."]
- [Anything infra/secret — `.env`, CI config — flag instead of editing.]

## When stuck
State your plan and the single assumption you're least sure about *before*
writing more than a few lines. A wrong assumption caught early saves a wrong
diff caught late.