Issue tracking in the age of vibe coding

I was building a feature the other day that never had an issue behind it. I just started building it. Somewhere in the middle I thought: I'd actually like a record of this. So I told Claude Code to create the issue in GetResolved and mark it done. It logged it, closed it, and we kept going. No tab switch, no form, no clicking around a board.

A year ago that would have sounded backwards - you're supposed to create the issue, then do the work. But that isn't how vibe coding goes. The work happens fast, often ahead of the paperwork, and the tracker has to catch up to you. Now I've got a clean history of what actually shipped, and I never stopped working to write it down.

That small moment is the whole shift, really. When I started building software this way, I realized pretty quickly that you can't be typing issues into a task board one by one anymore. Everything has to be fluent to the way you're coding.

The pace broke manual entry

The problem isn't that issue trackers are bad. Traditional issue trackers already do the core job nicely. The problem is speed.

We're going much faster than we used to. When you're moving at vibe-coding pace, sitting down to click through a UI and type tasks in one at a time is too slow to survive contact with the actual work. The issues have to be injected into your workflow by the people who find them - the developer mid-feature, the customer reporting a bug - not transcribed by hand afterwards by someone listening and typing it all back in.

If the tracker is too slow, it doesn't just annoy you. It becomes genuinely hard to picture how you'd ever fit it into the way you work. So it gets skipped, and the history disappears.

It has to live in the terminal

We have a web app too, and it's good for getting a calm overview of everything. But the point is that the day-to-day runs from the terminal.

When you're coding in Claude Code, or Codex, or Gemini, breaking out of that flow to go manage a support dashboard is asking you to lose the thread. So GetResolved has a CLI that can run the whole tracker. You stay where the work already is, and the issues come to you.

The conversations have to come with the issue

This is the part most setups drop. The issues come from real conversations with real customers - and those conversations need to be right there in the agent view, not stranded in some other tool.

So when I tell the CLI to fix an issue, it pulls up the actual customer messages tied to it - the original context, in the customer's own words, not a summarized ticket someone rewrote three days ago. Whatever's doing the work understands what was actually being asked for. Support and issue tracking usually live in two separate apps; here they're the same thread.

What you can actually do from the terminal

Once the whole tracker is in the CLI, the range of what you can do from a single prompt gets surprisingly wide:

• Create and edit issues without leaving the terminal.
• Pull up the conversations behind an issue to see the original context.
• Batch things in one prompt - generate ten issues at once and mark them all done, or tell it to close everything in a sweep.
• Ship a release and notify every customer who reported the thing you just fixed, in the same command.
• Filter and prioritize by signal - how many separate people reported an issue, and how important it is - so the loud, real problems rise to the top.
• Point an agent at incoming issues so they get triaged, and even fixed, automatically as they land.

That last one is where it gets interesting. You can automate so much of this that the tracker starts to run itself. Issue tracking is shifting toward being something close to fully automated.

The whole pipeline is being rethought

I don't think the workflow is upside down. It's just being rethought from scratch. The old pipeline assumed a human in the middle of every step, clicking and typing. The new one assumes the terminal.

A lot of good products already see this. Railway thought about it for hosting, and a wave of new tools is being built native to vibe coders and solo founders - everything connected to terminal workflows, nothing that needs you to click a button.

Not everyone is here yet, and that's fine. People still developing the old-fashioned way will roll their eyes and ask what this even is. But anyone already vibe coding tends to get it instantly, because they can feel the pace. They already know manual entry can't keep up.

Automation goes up, so testing matters more

Here's the part I don't want to lose in the excitement. As more of this gets automated, testing becomes more important, not less.

Automation isn't perfect. Sometimes an issue gets generated that's just wrong. So you still have to look at what's being produced - test it, read it, check that the thing you shipped is the thing you meant to ship. That human check doesn't go away.

What changes is where your attention goes. Automation handles the parts that used to eat your time, which frees you up to spend that time testing properly. And that's a good trade: if you test well, the quality of what you ship stays high. The teams that take testing seriously in this era are the ones who'll end up in a good place.

The point

Issue tracking in the age of vibe coding isn't about a prettier board or more features. It's about a tracker that's built for the speed you're actually working at.

That speed isn't going back down. So the tools have to be ready for it - living in the terminal where you already are, taking in issues as fast as they get found, and carrying the customer's real words along with each one instead of a rewrite. A tracker that still assumes the old, slower pace just becomes the step you route around.

Get that right, lean on automation for the busywork, and spend the time it gives you back on testing. That's what good issue tracking looks like now.