Chapter 12 of 12 · Agentic Engineering — A Practitioner Playbook for Production Software with AI Agents

Appendix — Checklists and Anti-patterns

A one-time project setup checklist, a checklist before every merge, the twelve anti-patterns that come up most with their remedies, and the whole playbook condensed into a single page of principles.

12.1 Project setup checklist (once)

12.2 Checklist before every merge

12.3 The twelve most common anti-patterns

Anti-pattern	Why it fails, and the remedy
One six-hour session	Context degrades and the agent starts contradicting its own earlier work → close the session at each completed subtask, keeping state in files
A 600-line `AGENTS.md`	The agent skims the middle → cut to 150 lines and move detail into skills
The same rule in three files	Within two weeks the three disagree → one source, the rest symlinked or referenced
Letting the agent write tests after the implementation	The tests confirm what the code does, not what it should do → enforce RED first, always
Raising the loop ceiling when it will not pass	The problem is the spec, not the round count → stop at three and fix the spec
An LLM judging inside the gate	Unstable results, and the team learns to re-run until green → gates must be deterministic
Accepting “the tests pass”	Very often the agent did not run them → require the real output, without exception
A 2,000-line PR from an agent	Nobody genuinely reviews it, and people approve on a glance → a 400-line ceiling enforced by CI
Installing forty MCP servers	The agent picks the wrong tool and the context fills → 5–15 that are genuinely used; the rest become scripts
Believing text in an issue or on a page	A working prompt-injection path → tool output is data, never instruction
Shipping faster without detecting faster	The gap between shipping speed and detection speed is where users get hurt → add guardrails before adding speed
Keeping real keys in a `.md` and relying on agent permissions	The denylist operates at the tool layer, not the OS, and a value in context has already left the machine → store names, inject at runtime
No owner on a PR	”The agent wrote it” is not an answer when production breaks → a human is fully accountable for every PR

12.4 Every principle, on one page

Correctness comes from the machine, not the model — every claim needs an artifact behind it
State lives in files, not in context — a fresh session must continue from reading the repo
Work must be small enough for the loop to close — if it will not close in three rounds, the problem is the spec
Every loop has a ceiling and a stop condition — including detection of no progress
The gate must be deterministic and hard to game — an easily gamed proxy will be gamed
Tests are what a human reads line by line, not the implementation
Shipping speed must be matched by damage-detection speed
Humans own three things, always: the spec, the acceptance criteria, and the approval to go to production
The agent should never see a secret’s value — it knows the name; the value is injected at runtime

This series is a set of practices, not a fixed standard. Adjust the numbers — the loop ceiling, PR size, thresholds — to your team’s context and your system’s risk. What should not be adjusted is the nine principles above.