Linear’s auto-fix boundary is task-shaped: dead flags versus failed background jobs

Primary source: Igor Sechyn, “Teaching an agent to auto-fix bugs,” June 12, 2026. He built Linear’s automations and reports operational experience, not an audited comparison or denominator-defined success study.

The failed generalization. An early attempt to have the agent first-pass all triaged bugs worked poorly for lack of context. They narrowed to recurring shapes. A Datadog monitor files an issue when a feature flag evaluates identically 100% of the time; a cleanup skill attempts removal; Sechyn says it one-shots the fix “nearly every time,” with his human review and merge. When failed background tasks cross a 0.2% error rate, monitor, relevant logs and agent produce the right fix roughly one-third of the time, per his account. They added a gate to require the agent to demonstrate understanding before attempting a fix, explicitly to cut bad PRs and tokens. Failures can still leave useful initial investigation for the human.

Coordination details: issue holds initial report, investigation, questions/failures and PR in one shared place; anyone can follow and a human engineer steps in to steer or review. For larger ambiguous work, Sechyn personally decomposes it, retains the complex part and delegates well-defined pieces. Codebase conventions encode rollout cautions and forbidden changes.

Economics limit: Neither success percentage comes with attempt counts, task-size normalization, fully-loaded costs, time saved, severity, post-merge defect rates or comparable human baseline. “One-shots” and “correct fix” are practitioner estimates, not demonstrated business outcomes. Nevertheless, this is a rare within-one-organization contrast showing why an undifferentiated $/PR or agent success rate hides radically different supervision needs. Links: unit economics, planning, full lifecycle.