CONCEPT Cited by 1 source

KTLO engineering chores¶

Definition¶

KTLO — "keeping the lights on" — is the standard industry shorthand for maintenance work that doesn't move product forward but must be done to prevent the existing product from degrading. Atlassian's 2026-06-01 Jira-team post gives the canonical wiki articulation as a list of categories:

"Our Jira engineering team was spending more time than we'd like focused on KTLO (keeping the lights on) tasks – the small, but important maintenance tasks nobody wants to spend time on. This includes work like cleaning up old feature flags, chasing flaky tests, fixing identified vulnerabilities, addressing accessibility issues, and chipping away at a long tail of bugs." (Source: sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in)

Each item is an instance of "work that follows a repeatable pattern, with high pre-existing team familiarity":

Feature flag cleanup — removing flags whose rollouts have completed; threading through compliance / experiment-holdout / release-track state across systems before deletion.
Flaky test triage and fix — finding the test category, reproducing under CI-like conditions, diagnosing root cause, applying a fix pattern.
Vulnerability remediation — applying fixes for issues identified by static-analysis or dependency-scanner output.
Accessibility fixes — addressing WCAG / a11y violations surfaced by automated audit tooling. Sibling to Slack's a11y-alert-to-Jira pipeline.
Long tail of bugs — "chipping away" at low-severity defects that never quite reach the top of the prioritised backlog.

The unifying property is the team has done the work before, knows what good looks like, and can articulate the procedure in prose — i.e. the work is "perfect for agents" in Atlassian's phrase.

Why KTLO is the right delegation target¶

Atlassian's load-bearing argument for delegating to agents is pattern-recognition prerequisites:

"Our team has spent years fixing these exact categories of issues. That pattern recognition is what makes delegation to agents possible. We know what good cleanup looks like, so we can define clear parameters, build review checkpoints, and design a human-in-the-loop system that produces code meeting our standards." (Source: sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in)

The inverse is implicit: greenfield design work where the team has never solved the problem before is not the right delegation target — there is no pre-existing pattern to encode in an orchestration skill, so the agent has nothing to imitate. KTLO is the easy starting point because the pattern exists by virtue of the team having done it many times.

Operational impact¶

Atlassian's reported numbers from the 2026-06-01 post are within a single team's KTLO budget:

Flaky tests — pre-automation: ~1 flaky test/day × ~2 hours = ~10 hours/week ≈ 40 h/month. Post-automation: ~80% reduction; one engineering week saved per month.
Stale feature flag cleanup — 500+ merged PRs over 70 days on the Jira repo from this single category of automation, ≈ 7 PRs/day.

Both numbers are throughput / time-savings, not quality (revert rate, post-merge defect rate, escape rate are not disclosed).

Why KTLO maps cleanly to agentic primitives¶

KTLO categories share four properties that make them agent-ready:

Property	Why it matters	Atlassian instance
Repeatable shape	Encode once as an concepts/agent-orchestration-skill	Test-category specialist skills; flag-cleanup procedure skill
Pre-known good outcome	The skill can specify "what done looks like"	"Desired final state: what the code should look like once the flag is removed"
Bounded blast radius per task	One PR per work item; merge gate stays human	Draft PR + reviewer + systems/bitbucket-merge-queues
High background volume	Throughput justifies the agent investment	One flaky test/day; many stale flags per cron run

Distinction from greenfield agentic development¶

KTLO automation and greenfield agentic development share the same primitives (concepts/agentic-development-loop, concepts/agent-orchestration-skill, concepts/agent-as-first-pass-investigator) but differ in the source of the work brief:

Dimension	Greenfield (e.g. Fireworks built in 4 weeks)	KTLO maintenance (this concept)
Work source	Human architect prompts agent	Heuristic cron + signal feeds → Jira work items
Skill content	End-to-end orchestration meta-skill	Per-category specialist skills
Per-task budget	Hours to days	Minutes to an hour
Throughput	One large feature per agent-session	Many small fixes per day
Risk profile	Architecturally novel — adversarial review needed	Well-understood pattern — CI is the safety net
Canonical source	sources/2026-04-24-atlassian-rovo-dev-driven-development	sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in

Sibling concepts¶

concepts/tech-debt-compounding — KTLO is the work category that prevents tech debt from compounding; without it, the long tail wins.
concepts/work-item-as-agent-prompt — the substrate framing for delegating KTLO work.
concepts/agent-as-first-pass-investigator — the human-in-the-loop discipline.
concepts/feature-flag — substrate / target of one of the canonical KTLO categories.
concepts/flaky-test — substrate / target of the other canonical KTLO category.

Seen in¶

sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in — canonical wiki source. First-party Jira-team post naming the KTLO category list (flag cleanup, flaky tests, vulnerabilities, a11y fixes, long-tail bugs), articulating pattern-recognition-as-prerequisite for delegation, and disclosing operational outcomes (~80% time reduction on flaky tests, ~one engineering week saved per month, 500+ merged PRs in 70 days on stale flag cleanup).