Here's a pattern I see constantly:
Someone spends 45 minutes writing a detailed Jira ticket. Acceptance criteria. Technical specifications. Edge cases. Screenshots.
Then they hand it to someone who spends 10 minutes with AI to implement it.
The ticket took longer than the work.
When the overhead exceeds the work, something is wrong with the process.
How We Got Here
Detailed tickets made sense when:
- Work was handed off between people who didn't share context
- Implementation took days or weeks
- Requirements needed to be precise before coding started
- Mistakes were expensive to fix
In that world, front-loading specification paid off. Better to spend an hour specifying than a week fixing miscommunication.
What Changed
AI shrunk implementation time. Things that took days now take hours. Things that took hours now take minutes.
But ticket-writing time didn't shrink. If anything, detailed ticket requirements expanded.
Result: ticket overhead became a larger percentage of total effort. Sometimes the largest percentage.
The Math
Traditional: - Ticket writing: 45 minutes - Implementation: 2 days - Overhead ratio: ~5%
AI-native: - Ticket writing: 45 minutes - Implementation: 30 minutes - Overhead ratio: ~60%
That's not a rounding error. That's a fundamental shift.
Alternatives
**Intent-only tickets.** Write what you're trying to accomplish, not how to accomplish it. "User can reset password via email" not "Add /reset-password endpoint that sends email using SendGrid template with...". Let AI figure out the how.
**Verbal handoff.** For small teams, just talk. "I need password reset. Standard flow." Done. 30 seconds. Context is shared. Questions get answered immediately.
**Video explanation.** Record a 2-minute Loom. Show the current state, describe the desired state. Takes less time than writing, communicates more.
**Skip the ticket entirely.** If you're implementing it yourself with AI, why write a ticket? Just do it. Document the decision afterward if needed.
But We Need Traceability!
Do you? Really?
Ask what the traceability is for. If it's for:
**History** — A decision log is lighter and more useful **Accountability** — Git commits and deployment records provide that **Planning** — A simple list of intentions beats detailed tickets **Estimation** — Story points don't work anymore anyway
The heavy ticket might be solving problems you don't actually have, or solving them in an unnecessarily expensive way.
The Mindset Shift
The ticket was a communication and handoff artifact. It encoded what needed to happen before work began.
In AI-native development, work begins faster. Iteration is cheap. The specification can evolve as you build.
Maybe you don't need the ticket at all. Maybe you need something lighter. Maybe you need something different.
Question the ticket. It might be overhead that no longer earns its cost.