Most Jira tickets are not specifications. They are reminders.

“Fix onboarding bug.” Three words. A human teammate reads that and remembers the Slack thread, the customer email, the standup comment, the side remark about not touching the SSO migration. The ticket is a key to context the team already shares. The agent has no key.

In Looking Ahead: Stronger Models, Better Harnesses, Different Work, I argued that as agents become capable enough to own real units of work, tickets stop being tracking artifacts and become executable contracts. This post is the part where I show what that actually looks like, with one ticket before and after.

Before

Here is the ticket as a human would write it for another human:

Title: Fix onboarding bug

Description: Some users are seeing the welcome screen twice. Started after Tuesday’s release. Probably related to the new auth flow.

Useful enough for a teammate. Now imagine handing this to a competent coding agent with repo access, test execution, and PR-opening permissions. What does it have to guess?

  • Which users? All of them, or a subset?
  • “Started after Tuesday’s release”: which commit, which deploy?
  • “Probably related to the new auth flow”: is that a hypothesis, or a known fact?
  • What does “fix” mean: show the screen once, or never re-show it?
  • Are there side effects in billing, SSO, or analytics?
  • What does done look like: a test? A metric? A manual check?

A good agent will not refuse this ticket. That is the dangerous part. It picks a plausible interpretation, writes code against that interpretation, and opens a PR that looks reasonable. You then spend more time reviewing the wrong solution than you would have spent writing a real ticket.

After

Same problem, written as an executable contract:

Title: Welcome screen renders twice for SSO users after re-auth

Goal: Authenticated SSO users should see the welcome screen exactly once per account, not on every re-auth.

Value: Customers reported confusion in #cs-escalations on 2026-05-12; two enterprise accounts threatened to escalate. Estimated 0.3% of MAU affected.

Scope: src/auth/post-login-redirect.ts and the WelcomeBanner mount logic in src/components/Welcome.astro. Do not touch the SAML middleware or lib/billing/*.

Non-goals: Do not change first-login behavior for non-SSO users. Do not modify the analytics event schema.

Repro: Log in as qa-sso@acme.test, log out, log in again. Welcome screen should not appear the second time.

Validation: New Playwright test in tests/e2e/onboarding.spec.ts covering the SSO re-auth path. Existing welcome-first-login.spec.ts must still pass.

Risk: Any change to post-login redirect logic touches the billing trial activation hook. Tag @priya for review before merge.

Rollback: Single-PR change. Revert via standard rollback.

Different document. Same engineer wrote it. The cost shifted from review to definition.

The ticket, customer names, metrics, paths, and people in this example are fictional. They are included to demonstrate the structure of an executable ticket.

Who pays, and why it’s worth it

The instinctive objection is that nobody has time to write tickets like that. True for the ticket the senior engineer hands to a teammate over Slack, because that conversation absorbs the missing context for free. Not true for the ticket an agent acts on while you sleep.

The hidden cost of vague tickets used to be friction. A few questions in standup, a Slack thread, a corrected PR. The cost was distributed across humans who would notice the gaps and ask. Agents do not ask. They proceed.

So the cost of vagueness moves from the morning standup to the production incident. A 15-minute ticket rewrite that prevents one rolled-back PR pays for itself ten times over. A 15-minute ticket rewrite that prevents a quiet correctness regression can pay for itself for the life of the codebase.

This is also where the value-vs-motion problem from Stop Measuring Motion shows up again. A team running agents on vague tickets will produce more PRs, more commits, more “shipped” work. Activity metrics will look healthy. Outcomes will not.

What actually goes in the contract

There is no universal template. There is a working minimum.

A ticket is agent-ready when it answers, without ambiguity:

  • What outcome the change must produce (not what code to write).
  • Why it matters: at least a sentence connecting it to a customer, business, or operational signal.
  • Where the change is allowed to touch, and where it explicitly is not.
  • How correctness will be verified: a test, a metric, a repro, a manual check.
  • What blast radius exists if it goes wrong, and who has to approve before that radius is touched.

Everything else is style. These five answers are the difference between a reminder and a contract.

I have written about specs becoming runtime inputs in Agile SDLC with Vibe Engineering. The ticket is the smallest version of that idea. Most engineering teams already have the right vocabulary: non-goals, validation, rollback, and risk. They just rarely write them down, because the team’s collective memory used to be enough.

It is not enough anymore. The team’s collective memory does not get scheduled to run at 2 a.m. on a feature branch.

The shift

For years, ticket quality was a leadership preference. The teams with disciplined ticket hygiene shipped slightly fewer bugs, onboarded slightly faster, argued slightly less in retros. The teams without it were fine.

That tolerance is narrowing.

When the reader of a ticket is a human teammate, vagueness costs a Slack thread. When the reader is an agent with merge rights, vagueness costs a revert, a customer escalation, or a quiet correctness regression that survives review because the PR looked plausible.

“Fix onboarding bug” used to be a delivery slowdown. It is now a deployment risk.

The next time you write a ticket, ask one question before you submit it:

Would I let an agent run this overnight?

If the answer is no, the ticket is not done.