Skip to content

PATTERN Cited by 1 source

Heuristic cron emits agent work items

Intent

Run a periodic batch job that scans the codebase / system state, applies a heuristic encoding years of human pattern recognition, and emits one Jira work item per detected unit of work — pre-filled with the structured fields an agent will need as its prompt. The cron does the cross-system state-piecing ("is this flag really stale across compliance / experiment / release-track state?") so the agent receives a fully resolved brief.

Canonical articulation

Atlassian's stale-feature-flag detection cron:

"Using our experience as a guide, we created a heuristic to identify stale feature flags in the code base, and capture the context needed for an agent to begin. We run a daily cron job that creates and updates Jira work items for every stale flag including: - Flag name and type: the unique identifier of the flag, along with what kind of flag it is (rollout gate, experiment…) - Repository and code references: the exact repo, file paths, and line numbers where the flag appears. - Desired final state: what the code should look like once the flag is removed. For example, for a rollout gate, this is typically the 'on' or 'off' branch to preserve. For experiments, it may be the winning cohort, a specific variant's behavior, or a custom path defined by the experiment owner." (Source: sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in)

Shape

   [DAILY CRON]
        │
        ▼
   1. Scan codebase for flag references
   2. Cross-reference with flag-config service:
        • compliance state per customer
        • release track holdouts
        • experiment owner + winning cohort
   3. Heuristic: classify each flag
        • Stale rollout gate → record on/off branch
        • Stale experiment → record winning cohort path
        • Stale kill switch → record default behaviour
   4. For each stale flag:
        Create / update Jira work item with:
          - Flag name + type
          - Repo + file paths + line numbers
          - Desired final state (above heuristic output)
        │
        ▼
   Engineer reviews backlog
   Transitions status to "In Progress / Delegated to Agent"
   ([patterns/jira-status-transition-triggers-agent-workflow](<./jira-status-transition-triggers-agent-workflow.md>))
        │
        ▼
   Agent picks up fully-pre-resolved brief, drafts cleanup PR

Why a daily cron rather than event-driven

Trigger model Pros Cons Atlassian's choice
Event-driven (e.g. flag config changes → ticket) Low latency Misses already-stale flags from before the event hook existed; needs reliable webhook delivery Not used
Daily cron scan Idempotent (same scan every day finds the same set + new ones); covers the existing backlog as well as new staleness; scheduled load One-day staleness window — fine for KTLO Chosen

The daily cron is idempotent (re-running produces the same work items, deduped by flag identity) and self-healing (a missed ticket from one day's run gets re-created the next day). It is the same architectural shape as patterns/cron-driven-pr-closed-cleanup but oriented at emitting work rather than reaping completed work.

The heuristic is the encoded experience

The cron's heuristic is the team's years of pattern recognition crystallised in code. From the post:

"Using our experience as a guide, we created a heuristic to identify stale feature flags in the code base."

This is the architectural counterpart to agent skills: skills are "how to do the work" in prose-for-the-agent; cron heuristics are "how to decide work needs doing" in code-for-the-detector. Together they discharge the team's pattern-recognition capital twice — once into the detector, once into the skill.

Cross-system state-piecing is the cron's main value

Atlassian's framing on why flag cleanup is hard:

"On a large, multi-product codebase, cleanup is harder than 'just removing the code.' A flag might be fully rolled out for some customers but still active for others due to compliance requirements, release tracks, or experiment holdouts. Piecing together a flag's true state across systems was manual and error-prone."

The cron's value is doing this lookup once and writing the resolved state into the work item, so the agent does not need to re-discover flag state across compliance / experiment / release-track services. This:

  • Keeps the agent's context window focused on the fix, not on state discovery.
  • Reduces agent runs that fail because "flag is still active for customer X" — the cron already gated those out.
  • Makes the heuristic's correctness a separate audit surface from the agent's correctness.

Per-flag-type fix-pattern hint

The heuristic doesn't just identify stale flags — it pre-computes the desired final state per flag type:

Flag type Heuristic output Agent uses to ...
Rollout gate "on" or "off" branch to preserve Inline the chosen branch, delete the conditional
Experiment Winning cohort variant Inline the winner, remove other variants
Custom (experiment owner-defined) Owner-specified path Apply owner's described change

This per-flag-type pre-classification is what allows the generic cleanup skill to be small — most of the per-flag-type variability has been resolved upstream.

Operational outcome

The daily cron + agent loop produced:

"More than 500 merged PRs in the past 70 days." (Source: sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in)

≈ 7 merged PRs/day from this single cron job + one workflow.

Caveats

  • Heuristic false positives. A false-positive "stale" classification feeds the agent a flag that isn't really stale; the agent might propose removing live code. The merge gate catches this, but it's review-time waste. Tracking detector precision over time is operational hygiene the post doesn't describe.
  • Heuristic false negatives. Genuinely stale flags the cron misses sit in the codebase indefinitely. As code changes, the heuristic may need updating to match new flag conventions — this is ongoing maintenance.
  • Update semantics. "Creates and updates" — implies the cron detects when a flag has become un-stale (e.g. holdout customer added) and transitions / closes the ticket. The post doesn't describe the close-on-un-stale semantics in detail.
  • Cross-system query cost. A daily scan that pieces together state across compliance / experiment / release-track services has non-trivial query load. Atlassian doesn't disclose volume.
  • Agent throughput must outpace cron emission rate. If the cron emits 50 work items/day but engineers only transition 7, the backlog grows. The cron's emission rate must be matched to the human transition + agent throughput downstream.

Adjacent patterns

Seen in

Last updated · 542 distilled / 1,571 read