Anti-patterns we've watched teams adopt

None of these announce themselves

There are 9 of them on this sheet. We ran 3 ourselves while writing it, and 2 are worth showing up front:

• AGENTS.md weighs 53,208 bytes, we used the Codex CLI 0.146.0 to ingest it, and it silently consumed exactly 32,768 of those bytes, the rest was lost (including the middle of a word in - Filler convention line that nobody has , without a single word on stderr)

• The skill whose body runs ssh into a retired machine in March is still being injected into the prompt with its description, so it's available for the model to consider relevant

The limit itself is documented and configurable, and it did exactly what it's set to do. The part where it cuts mid-word and says nothing isn't documented anywhere we could find — and that second half is the shape of all 9

The DORA 2025 report based on almost 5,000 responses describes it as a tool property, not a team property: "AI doesn't fix a team; it amplifies what's already there"

That said, none of these originate with the agent. They're all existing team habits — in the form of scripts, or documentation, or review process — which now operate at agent speed before an audience that reads every word literally

How to read this

For each we've outlined its everyday appearance, the actual cost, and the minimum fix. The fixes are deliberately small, because a proposal to refactor the entire repo is sth nobody ever gets to.

The bypass moved into the repo

Somebody got tired of approving the same command so they found a flag for it; the flag works so it found itself in a Makefile, a CI job, or the team's dotfiles — at which point it stopped being anybody's decision and became a local default.

All 6 harnesses ship with such a flag (we've compared vendor descriptions):

Only 2 of them actually reference a sandbox; the rest provide the same functionality without it.

It's worth noting that on the Copilot CLI this flag is not an optimisation, it's actually a requirement — if you want to use it non-interactively you must enable it and the built-in help examples show that: copilot -p "Fix the bug in main.js" --allow-all-tools

Even worse, the Copilot CLI also respects the COPILOT_ALLOW_ALL environment variable so you can enable it in a CI environment block and have no trace of it in any command line.

What it costs is not a vague agent misbehaviour; it's that consent has moved out of the moment. Whoever put the flag in the script had one job in mind, and it now applies to every job anyone runs, on machines holding production credentials, including for people who have no idea the flag is set.

The minimum fix is — allow the flag in the only sensible place, which is where you can contain its blast radius, which means within a credential-free container, CI runner, or the harness's own sandbox. But if you were to use it for example as an alias or a Makefile target on a laptop, it's the wrong mechanism — the real need is an allow-list, 20 minutes of work

The file nobody owns

Another example is AGENTS.md or CLAUDE.md; it starts with 15 genuine lines and then grows by one line per incident. The thing is — six people can write in it, nobody removes anything, and it's not treated as code so nobody ever reviews it.

The costs:

• It's the default mechanism; you load it on every run

• It's self-contradictory, as two people have written opposite rules eight months apart without reading each other

• It silently crossed a line — Codex stops once the combined size of your memory files crosses project_doc_max_bytes, 32 KiB by default, which means it breaks the file in the middle of a word and doesn't say anything on stderr, so yesterday's addition was the first one to get lost

The minimum fix is:

• Treat it like a piece of code, trace every line back to its context, as any line that can't be traced is one nobody will stand behind once it turns out they're wrong about

• Anything that's not a fact needs to move to a skill, keeping the body on disk while only the description is injected into the prompt; this trade-off is described in detail elsewhere in the course

Somebody else's setup, pasted whole

Another example is a shared dotfiles repo, or an article about a good setup on a blog, or somebody's setup which was cloned by the entire team — 14 MCP servers, 9 subagents, a hooks file, and nobody can remember what the 10th server is for.

Just a side note here — whether an unused server consumes tokens per turn depends on the harness; Claude Code by default delays the definition of MCP tools, loading only names at session start, while Codex had it implemented at some point and later removed it; there's a lesson elsewhere in this course that measures the difference instead of guessing at it.

The most important thing is that nothing of this was scrutinised — the Anthropic's MCP documentation says it directly: "Verify you trust each server before connecting it. Servers that fetch external content can expose you to prompt injection risk"

Which leads us to the conclusion that this is exactly where such a check hasn't been performed — not because of negligence, but because nobody who could have performed it is part of your team.

The minimum fix is:

• Nothing joins the shared config without an author's name and a sentence on what breaks if it goes

• Even for already added entries you can do a similar audit in a few hours by asking yourself per entry: who added this and what would stop working; everything that raises two shrugs comes out (and git revert brings it back if you were wrong)

Config that outlived its reason

The opposite direction — three subagents left after a hackathon, an MCP server aiming for an internal service that got replaced, a skill for a deploy path nobody has used after the migration.

This is what people treat as inert but it's not: We've created a skill in a scratch project called legacy-release and described it like this: "Cut a release from the old deploy box. Use when the user asks to ship a release to the legacy cluster". Then we pointed its body to a machine that got decommissioned in March, and ran this through Codex — the name of the skill and its description appeared in the prompt during a run that wasn't even connected with releases.

The cost is that a description isn't documentation; it's what the model looks at to decide whether to run the body. So an unused skill is a live instruction aiming for a gone system, awaiting a perfectly phrased request — and it gets executed with confidence.

The minimum fix is:

• Every quarter, list what's actually installed and remove everything that nobody can date

• Standard tooling-wise — most harnesses have a listing subcommand; we've tried 6 of them and 2 don't provide it: Kimi Code CLI 0.31.1 and Antigravity CLI 1.1.10 (you need to ls the directories manually)

Also worth mentioning — this is one area where reverting is very safe; it's in git, you can always git revert

The secret in the shared file

Another example — the tool tells you to commit this file, which is correct. Then somebody adds an MCP server that requires a token and puts the token there.

We've created a scratch directory, installed Claude Code 2.1.221, created a project-scope MCP server with an inline API key variable:

claude mcp add --scope project demo-server -e API_KEY=sk-test-do-not-use-123 -- npx -y demo-mcp-server

and here it is — the key in plaintext in .mcp.json, which is the file that the documentation tells you to commit so the entire team has the same MCP tools and services. No warning appeared, it did exactly what we told it to.

It's not even a matter of judgement; removing this line doesn't remove it from the history, and the history is on every machine that ever cloned the repo, so rotation is what you need to do here.

The minimum fix is — use interpolation which is supported and documented by the vendor for this very scenario — a placeholder referring to an environment variable defined in the committed file, "API_KEY": "${DEMO_TOKEN}", with its value stored in the environment

It's also worth noting that Claude Code's MCP listing — claude mcp list — highlights the missing environment variable by name (Missing environment variables: DEMO_TOKEN) instead of showing that the server doesn't work

If you really can't use interpolation, you can put the values in a personal scope, which is called local scope in the Claude Code documentation — for example they say to use it for credentials that you'd rather not keep in version control. All 5 other harnesses have their own configuration files under your home directory

Counting the tool instead of the work

Another example — seats, percentage of pull requests involving an agent, number of lines accepted, and then "AI usage" appearing during a performance discussion.

The thing is — this figure is real, it's just not about anything that matters: METR's 2025 randomised controlled trial — 16 experienced developers worked on 246 issues in their own repositories; they were allowed to use AI tools and turned out to be 19% slower. They predicted a 24% speedup and after the experiment estimated they'd been sped up by 20%.

In other words — the thing to carry forward isn't "AI makes people slower", it's that when self-report was pitted against a stopwatch, they pointed in opposite directions (and the wrong one was the one doing the work)

The minimum fix is — track what you already cared about before: DORA's 2025 data points — AI adoption correlated positively with throughput and product performance, negatively with delivery stability. If you're only looking at the first metric, you'll be happy until you're not

That being said, we should probably point it out that METR have already acknowledged that these results are not fully representative (they've found a few selection effects), and that they think developers are likely more sped up now than that early-2025 number suggests; they're redesigning the study

The 900-line pull request

Another example — the volume of output goes up but the time available for review doesn't, and there's this line: "implement the caching layer". The diff is 900 lines and the author had a quick look at it.

Stack Overflow's 2025 survey says that the top frustration, at 66%, is "AI solutions that are almost right, but not quite", and 45% picked "Debugging AI-generated code is more time-consuming". Almost-correct is the most expensive category as it survives a skim, and a skim is what 900 lines get.

DORA says the general version of it without naming review: "Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability." Review is one of those loops, and the most challenging one to scale.

The minimum fix is:

• A size limit that forces you to split it, as what's being protected here is the attention of the reviewer, which is a finite resource

• A PR template question: what did you check? (not what the agent says, what you actually ran)

It might look like red tape until the first person can't answer it for themselves and splits their own PR

One person is the setup

Another example — it works because of one person; they have useful skills in their home directory, handy hooks that were never committed, or a piece of reasoning behind a certain rule. The rest run half of it from their home directories and think they must have misconfigured sth.

The cost is clear — the bus factor (and the fact that nobody else can improve it as you can't submit a PR against somebody's home directory, so it can only get better in their spare time)

The minimum fix is — create an empty directory and clone the repo into it as if you were a new joiner; see what the agent knows. What it can't answer is what lives on that laptop, and that list is the work. Do it before they go on holiday, not during.

There's also a variant we should probably mention: "we're a [tool] shop". This looks like standardisation, but is actually the same problem at a higher level; some things are portable:

• Four of the 6 harnesses read .agents/skills/

• Two of them use .mcp.json

But:

• Permission rules are defined using a single vendor's format and can't be moved

• Hooks work only in their native environment

• Sandbox configurations are expressed using one vendor's syntax

Which means that if somebody joins on a different tool, they'll have your skills but none of your controls; what you share is the files, not the tool.

The rule that moved it onto personal accounts

The opposite direction — a policy banning agents, or allowing only one, or excluding a repo. And then people who were supposed to use one use it on their personal accounts, in their own editors, with code pasted somewhere you can't see.

Again, we won't give any numbers (as the ones that are being shared come from surveys conducted by vendors and we couldn't verify them), but the mechanism is simple: a rule you can't detect selects for people who don't tell you.

What it means is that the visible version could have been reviewed, but the hidden one can't — and it doesn't inherit anything you've created (no repo instructions, no permission rules, no hooks, just your source in whatever was handy)

The minimum fix is — make the most sensible path of least resistance:

• The same tool, already set up, already permitted on the repos where it's allowed

• And then limit the prohibition to what actually needs one, which is almost always a particular repository or type of data, not an entire category of tools

The half-hour that finds most of this

This one is not a programme, but a sit-down; if you run the checks provided by your harness against your agent config you'll find two or three of these. They'll be boring — an MCP server pointing to a dead endpoint, a rule left behind by somebody who no longer works there, a flag added to a Makefile one afternoon 18 months ago — and this is exactly why you haven't found them.

What you need to do instead is treat agent config like everything else in the repo — not a policy but an expectation that somebody reads it before it gets merged

What we'd not bother with

The last section is things that look like fixes, but aren't:

• An AI usage policy document — read once. The same amount of work spent on committed instructions for the repo will be read on every turn by the thing that does the work

• A dashboard showing agent metrics — a way to get adoption figures (which is the anti-pattern we've talked about, with better graphics). Track delivery stability instead, you probably already do

• Standardising on a single harness — not possible unless you own either device management or the billing relationship. The best you can do with this effort is committing the right filenames; standardise on those files

• Banning the bypass flag — nobody will enforce it. Limit what it can reach and it doesn't matter anymore