Trunk-based development with AI agents

Why agents push teams to trunk

Several agents working at once on long-lived branches means merge conflicts, stale branches and big-bang merges nobody can review. Trunk-based development avoids that: every change is small, merges to main quickly and deploys. What isn't ready yet is merged anyway, behind a flag that's off.

The flag, not the branch, becomes the unit of release. Code reaches production continuously; customers see a feature when its flag says so.

Declare flags in code

In Flagger.gg each app declares the flags it uses, and the SDK registers them when it starts. A flag that doesn't exist yet is created; a state someone set is never overwritten by a deploy. A flag can carry a not-ready reason, which keeps it off and refuses to turn it on without an explicit confirmation:

const flagger = createFlagger({
  sdkKey: process.env.FLAGGER_SDK_KEY,
  defs: {
    bulk_invoices: {
      summary: "Customers can send invoices in bulk",
      description: "New bulk send flow in billing",
      owner: "billing",
      notReady: "PDF export not done",
    },
  },
});
await flagger.start();

In auto-live mode (the default) a newly registered flag starts on unless it carries a not-ready reason, which is how an agent merges unfinished work safely. When the work is done, the agent removes the reason in a later change, and the flag can be turned on. Turning a not-ready flag on needs confirmNotReady (--confirm-not-ready in the CLI), and bulk changes refuse it.

See what's waiting to go live

The Release console lists "Not live yet: N" first, with each flag's one-line summary of what changes for customers, so a person can see at a glance what the agents have merged and turn features live one at a time or in bulk. The console also marks which flags are registered by code, so flags an agent created through the API show as "not in code yet" until a deploy registers them.

Habits that keep trunk healthy

• One flag per change, named for what it does, with an owner.
• Test both paths while the flag exists; see testing both sides of a flag.
• Remove the flag once the feature is on for everyone; see flag cleanup.
• Give agents the kill action, so a bad change on trunk is switched off in seconds.

FAQ

What is trunk-based development?

A way of working where everyone merges small changes to one main branch at least daily, instead of keeping long-lived feature branches. Unfinished work is hidden behind feature flags.

Does trunk-based development work with AI coding agents?

Yes, and it suits them: agents make many small changes in parallel, and flags let each one merge and deploy dark without waiting for the others.

How does an agent merge unfinished work safely?

It wraps the work in a flag and gives the flag a not-ready reason, so the flag stays off and can't be turned on by mistake until the reason is removed.

Who decides when the feature goes live?

Your choice per project: in auto-live mode the agent can, and with approvals on, turning a flag on for everyone in production needs a person's approval.