Why dashboards fail AI coding agents

Dashboards fail AI coding agents because an agent works by reading your repository, and a dashboard is not in it. A coding agent opens files, follows imports, and edits source. A feature-flag dashboard lives behind a login it cannot use, so it never sees which flags exist, and it breaks the code that depends on them.

This is not a complaint about dashboards in general. A dashboard is a good tool for a person clicking through live state. It is the wrong source of truth for an agent whose entire view of your system is the files in the repo. The mismatch is structural, and it gets worse as more of your code is written and maintained by agents.

This post is about why that mismatch exists, why an API does not close it, and what state an agent can actually read.

Key Takeaways

• A coding agent’s whole interface is the repository. If the source of truth for a flag is a dashboard, the agent cannot see it, because the dashboard is not in the files it reads.
• Not seeing a flag is not harmless. The agent deletes the branch behind a live flag, references a flag that was never created, or rebuilds a feature that is already gated.
• A dashboard API does not fix it. The agent has no credentials, the answer is not versioned with the code, and it is not in the context the agent reads on session start.
• The fix is not an AI feature. It is putting the flag where the agent already looks: a file in the repo, plus a context.json it reads at the start of a session.
• Any tool that keeps its state in a dashboard has this problem coming as agent-written code grows. dif keeps flag state in the repo, so the agent reads it like any other source.

How a coding agent actually works

A coding agent like Claude Code or Cursor has one way of understanding your system: it reads the files. It opens a module, follows the imports, greps for a symbol, and edits source. Its knowledge of what your application does is whatever it can find in the repo, plus whatever fits in its context window.

That is the frame for everything below. An agent does not “know” your infrastructure. It reads it. Anything that is not in the files it can open is, for practical purposes, invisible to it.

A dashboard is not in the repo

A feature flag in a hosted dashboard has its source of truth outside the repo, in a vendor’s database, reachable through a web UI behind an account. The agent has none of that. So three failures follow, each with the same root cause:

• It deletes live code. The agent finds a branch gated on a flag, sees no reason for it in the repo, and removes the dead-looking path. The reason was in a dashboard it cannot open.
• It invents flags. Asked to gate a feature, it writes a check against a flag name that was never created, because nothing in the repo tells it what exists.
• It repeats work. It cannot see that a feature is already behind a flag, so it builds the thing a second time.

The feature flags for AI agents post covers these failures in depth. The point here is narrower: every one of them traces back to the flag state living somewhere the agent does not read.

An API does not fix it

The obvious rebuttal is that the dashboard has an API, so the agent could query it. That does not close the gap, for three reasons.

First, credentials. The agent runs in your repo without your dashboard login, and handing an autonomous agent a production flag API key is a worse idea than the problem it solves.

Second, versioning. An API answers “what is live right now.” It cannot answer “what was live at the commit the agent is reading,” because the dashboard’s state is not versioned with the code. An agent working through a branch, or a reviewer reading a month-old pull request, needs the flag state from that commit, not today’s.

Third, context. An agent orients at the start of a session from what is in the repo, the convention the AGENTS.md standard formalized. A flag state it would have to make a live call to discover is not in that orienting context, so by default the agent proceeds without it.

The problem is structural, and growing

This is not a dif-versus-competitor point. It is a property of where state lives. Any tool that keeps its source of truth in a dashboard, disconnected from the code, hands an agent a map with holes in it. That was tolerable when every change went through a human who could open the dashboard in another tab. It stops being tolerable as agents write and maintain more of the code.

The trend runs one way. More of the diff is agent-authored every quarter, and each agent is blind to any state that is not in the files. A flag system that assumed a human in the loop, clicking through a UI, is now missing the reader it was designed for.

The fix is state the agent can read

The fix is not to bolt an AI feature onto a dashboard. It is to put the flag where the agent already looks. When each flag is a Markdown file in the repo, the agent reads it like any other source, and edits it through a pull request like any other change.

dif does exactly that. Flags are files in dif/, and dif build emits a context.json that lists every active flag and each surface’s latest learning, which the agent reads on session start. The feature flags page shows the file-based model.

dif has a dashboard too. dif Cloud reads your files and shows experiment results. The difference is that Cloud is not the source of truth. The flags are files, Cloud reads them, and the agent reads the same files. Nothing the agent needs lives only behind a login.

FAQ

Why can’t an AI coding agent use a feature-flag dashboard? Because the agent operates on your repository, not a web UI behind a login. A dashboard’s flag state is not in the files the agent reads, so it cannot see which flags exist or why. That is why it deletes branches behind live flags and references flags that were never created.

Do coding agents break feature flags? They do when the flags live in a dashboard the agent cannot see. It removes a branch gated on a flag it has no record of, or writes code against a flag that does not exist. When flags are files in the repo, the agent reads them first and the breakage goes away.

Can’t the agent just call the dashboard’s API? An API does not close the gap. The agent has no dashboard credentials, the API answers “what is live now” rather than “what was live at this commit,” and a live call is not part of the context the agent reads when it starts. Files in the repo avoid all three.

How do you make feature flags readable by an AI agent? Keep them in the repo as files. In dif, each flag is a Markdown file, and dif build writes a context.json summarizing every active flag and each surface’s last learning, which the agent reads on session start.

Does dif have a dashboard? Yes, dif Cloud, for reading experiment results. It is not the source of truth for your flags. The flags are files in your repo, Cloud reads them, and a coding agent reads the same files, so no flag state is stranded behind a login.

Getting started

Dashboards fail AI coding agents for one reason: the agent reads the repo, and the dashboard is not in it. Put the flags in the files the agent already reads, and the failure goes away. Install the CLI and scaffold a project:

npm install -g @dif.sh/cli
dif init

dif init writes the dif/ directory and the managed agent blocks, and dif build emits the context.json your agent reads on session start. The feature flags for AI agents post covers the full workflow, and what context.json contains covers the file an agent reads to see your live flag state.