Trunk-Based Development

Trunk-based development keeps one main branch deployable at all times. Short-lived feature branches — hours, not weeks — are the only deviation allowed, and merging them quickly is non-negotiable. This matters even more when agents are doing the typing.

The rules

1. There is one main branch — main. It always represents the latest verified version of the product.
2. When you (or an agent) make a change, create a short-lived feature branch off main.
3. Make changes, get them reviewed, merge them back. Same day, ideally.
4. Delete the feature branch.

main  ──●──────────●──────────●──────────●──  (always deployable)
         \        /  \        /
          ●──●──●      ●──●──●
          feature/     feature/
          add-login    fix-header
          (hours)      (hours)

Why not long-lived branches

• Merge conflicts. The longer a branch lives, the more it diverges. Resolving conflicts at merge time is error-prone.
• Integration risk. Two features that work in isolation may break when combined. You find out at merge.
• Stale reviews. A 2,000-line PR gets skimmed. A 50-line PR gets read.
• Delayed feedback. Bugs hide longer on long branches. The sooner code reaches main, the sooner reality tests it.

Why it matters more with agents

Agents produce work fast. One agent can open multiple PRs per day. On long-lived branches, you would have an unmanageable merge queue within a week.

Agents do not carry memory across sessions. Each session reads main to understand the project. A short branch that merges same-day keeps main reflective of reality. A long branch leaves the agent working against a stale picture.

Small PRs are reviewable; large ones are not. The human-in-the-loop review is your primary safety gate. It only works if each PR is small enough for you to actually read.