Tickets Are the New Prompts

Written By Brian Conn

I haven't written a Linear ticket by hand in six months. I don’t write the majority of my Claude prompts. The two stopped being separate things. The ticket is the prompt.

The Two-Word Implementation Loop

Every time I implement something now, the actual prompt I send the agent is two words plus a ticket ID:

/implement LIN-1234

That's the whole thing. The agent reads the ticket, builds the code, runs the verification, and comes back when it's done. No prompt engineering in the moment. No back-and-forth steering. No "let me clarify what I meant."

It works because all the time I would have spent prompting got moved upstream into building the ticket. This is what closing the Intent Gap looks like in practice.

What "Building the Ticket" Actually Looks Like

When I have a gnarly problem, a feature, a refactor, a system change, I don't open Claude Code and start typing. I open a planning session with the agent and we go to work on the spec.

That session is typically a 30-minute affair:

  • I describe the problem at a high level. "We need to do X. Currently the system does Y. I think the approach is Z but I'm not sure."
  • The agent explores the codebase. It reads the relevant code, surfaces what it found, asks clarifying questions about constraints I haven't named.
  • It drafts a phased plan. Phase one, phase two, phase three, each with a success criterion that's verifiable from the outside.
  • I push back. "Phase two should come first. The verification for phase three is too weak. We need an instrumentation step."
  • We iterate. After a few rounds, we have an epic.

Then the magic step: "Awesome. Make Linear tickets." This is the agent planning steps externalized.

The agent breaks the epic into Linear tickets, one per phase. Each ticket has the goal, the context the agent will need (which it just spent 30 minutes building), and the success criteria that defines done.

After that, it's mechanical. /implement LIN-1234 on ticket one. See you at the end.

Why the Ticket Is Now the Prompt

The big shift is what's actually in the ticket. Traditional Linear tickets are designed for humans. They have just enough information for an engineer with full codebase context to know what to do. This is part of the broader pattern where the SDLC is rediscovering itself: the specs and verification practices teams skipped because they slowed humans down are exactly what agents need.

These tickets are designed for an agent that's going to read them fresh, build the implementation, and verify the result without a human in the loop until the very end. So they have to contain everything the agent would otherwise have to ask for:

  • The goal, stated as the end state, not as the change.
  • The codebase context, files, modules, prior decisions.
  • The success criteria, concrete enough that the agent can check them itself.
  • The non-goals, what we are explicitly not doing.

When that's all in the ticket, the prompt becomes redundant. The agent doesn't need to be told what to do at runtime, because all the telling happened upstream when we built the ticket together.

The Planning Step Isn't Optional

Engineers used to a faster loop try to skip the planning step. They open Claude Code, type a paragraph, and hope. That works for trivial changes. It falls apart on anything that requires real architecture decisions, because the agent makes those decisions for you at runtime, and the decisions are often the wrong ones. The built in planning step helps remediate that, but that plan is even better when externalized into a ticket. METR's randomized controlled trial of early-2025 AI tools found that experienced developers working on their own repositories were 19% slower when allowed to use AI tools, even though they believed they were 20% faster. The gap shows up when context lives in the developer's head instead of in a written spec the agent can read.

The planning step is where the engineering happens. The implementation is what the agent does. The architecture is what you do.

If phase one of an implement run goes sideways, I sometimes have to re-plan phases two through four. That's fine. That's a real conversation. The point isn't that the plan is immutable. The point is that the plan exists, written down, in a place the agent can read, before the agent starts producing code. The 2024 DORA report found that AI adoption was associated with a 1.5% drop in delivery throughput and a 7.2% drop in delivery stability when teams didn't pair it with the basics: small batch sizes, written specs, robust testing. Tickets that are real specs are how you get those basics into the agent's hands.

The Board Is the Runtime

My Linear board is no longer a project-management artifact for a team. It's a queue of self-contained agent prompts, each pre-loaded with the context and acceptance criteria the agent will need to verify its own work.

The tickets are the prompts. The board is the runtime.

Related Content

Featured
Tickets Are the New Prompts
Tickets Are the New Prompts

I haven't written a Linear ticket by hand in six months. I don’t write the majority of my Claude prompts. The two stopped being separate things. The ticket is the prompt.

The Amdahl's Law Problem in AI-Assisted Development
The Amdahl's Law Problem in AI-Assisted Development

AI did not make the whole software delivery system faster.

It made one stage louder.

That is the part missing from most productivity conversations right now. A developer gets a coding assistant, the coding step accelerates, and everyone acts like the entire SDLC should accelerate by the same amount. Then review queues grow. Test failures pile up. Deployment gets riskier. Senior engineers spend more of their day reconstructing intent from code that looks plausible but does not quite match the system.

That is not a paradox. That is Amdahl's Law doing exactly what Amdahl's Law does.

Speed up one stage in a constrained system, and the bottleneck moves.

Concentric Feedback Loops: How AI Agent Teams Actually Ship Code
Concentric Feedback Loops: How AI Agent Teams Actually Ship Code

I've been rebuilding one of my Claude Code workflows because the old version was too linear.

That sounds like a small implementation detail. It isn't. It points at the part of AI-assisted development that most teams are about to run into: once agents can do real work for hours, strict phase gates start getting in the way of the feedback loops that make the work safe.

The normal development cycle is familiar: requirements, plan, plan review, implementation, tests, peer review, more implementation, more tests, security review, architecture review, integration testing, end-to-end testing. We pretend this is a clean sequence because it is easier to write down that way.

It has never been that clean.

The work has always been loops. AI agent teams just make the loops visible.

Your Team's AI Metrics Are Lying to You
Your Team's AI Metrics Are Lying to You

Your engineering team adopted AI coding tools six months ago. Deployment frequency is up. Lead time is down. PRs are flying through the pipeline. Everyone feels faster.

But are they?

I've been digging into the data across multiple client engagements, and there's a growing gap between what AI-assisted engineering teams perceive and what the numbers actually show. The metrics most teams celebrate are painting an incomplete picture, and the metrics that would tell the real story are the ones nobody's watching.

Start Fresh - Why Fixing AI Agents Mid-Chat Never Works
Start Fresh - Why Fixing AI Agents Mid-Chat Never Works

You're four steps into an AI agent workflow. Steps one through three went perfectly. Step four goes sideways. So you start correcting. "No, do it this way." "Try again." "No, like this." Five corrections later, the output is worse than when the problem first appeared.

The instinct to fix things in place is deeply human. It's also exactly wrong when working with AI agents.

Why Every AI Workflow Converges on the Same Architecture
Why Every AI Workflow Converges on the Same Architecture

Three AI agents. Three different problem contexts. Each time, the solution emerged with the same architecture.

The first was my own operational agent. A personal partner for research, drafting, and scheduling. The second was a marketing content bot I helped a client team build. The third was an analytics workflow for another team. Different domains, different users, different stakeholders. But when I stepped back and compared the three designs, the structural similarity was impossible to ignore.

I didn't plan it. I wasn't working from a blueprint. I was solving three different problems and each time, I ended up reaching for the same three layers: an immutable identity, compiled learnings, and a human approval gate.

One builder reaching for the same shape across three contexts isn't proof of a universal law. But the fact that I keep reaching for it without trying to is worth sitting with. Every production AI workflow I've built that survives contact with reality seems to pull in this direction. Not because anyone prescribed it. Because the problems keep forcing it.

The SDLC is Rediscovering Itself
The SDLC is Rediscovering Itself

AI is forcing software development back to first principles. The practices most teams abandoned as overhead, specs, formal verification, architectural review gates, are becoming essential again the moment humans stop reading every line of code.

I've watched this play out across my own work this year. The discipline I used to skip because it slowed me down is suddenly the only thing standing between a working system and a pile of plausible-looking garbage. The SDLC didn't die. It got hollowed out, and now it's being rebuilt in place, one abandoned practice at a time.

The Intent Gap
The Intent Gap

Your AI-generated code is degrading, and the degradation isn't a tooling problem. It's a translation problem, and every step of the chain is lossy.

I've fought against this degradation. I swap models. I rerun implementation prompts. The damage happens before the first line of code gets generated, in a chain of translations that no refactoring pass can reverse. This is a different problem than the one I wrote about in Risk Evaluation in the Age of AI-Aided Development, which is about deciding when AI acceleration is worth the technical debt. The Intent Gap is upstream of that decision.

I call the thing at the center of this the Intent Gap: the distance between what you meant and what the AI produced. The Gap is where everything fails. And once you see it, you can't unsee it.

Tests as Ceremony: When AI Breaks the Safety Net
Tests as Ceremony: When AI Breaks the Safety Net

AI-generated tests pass. That's the problem.

Passing is not a useful correctness criterion. Mark Seemann makes this argument sharply: AI-generated tests have "little epistemological content." They skip the critical step of seeing a test fail before writing code. The test exists, the coverage number goes up, and everyone moves on. But the test never proved anything. It never caught a bug, because it was never designed to catch one.

SDLC is Dead, Long Live the SDLC
SDLC is Dead, Long Live the SDLC

The software development lifecycle isn't dead. It just lost its center of gravity.

For decades, the bottleneck in software development was writing code. Requirements flowed downhill through design, architecture, and planning, all funneling toward the expensive part: turning ideas into working software. The entire SDLC was organized around this constraint. We optimized hiring, tooling, and process around the assumption that code production was the hard part.

AI changed that equation. Code writing is now commoditized. AI can produce syntactically correct, functionally reasonable code at a pace no human team can match. The bottleneck didn't disappear. It moved.

Brian Conn https://connsulting.io
Next

The Amdahl's Law Problem in AI-Assisted Development