My Coding Workflow with AI: From Ticket to Commit

Most developers use AI coding assistants the same way they used Stack Overflow: paste in an error, grab the first answer that looks plausible, move on.

That works until it doesn't. You end up with code you don't understand, bugs you can't explain, and a growing unease that you're not actually in control of what you're shipping.

There's a better way to work with AI — one where you stay the decision-maker and the AI does the heavy lifting. Here's the workflow I use, from ticket to commit.

The Workflow at a Glance

Step 1: Summarize the Ticket with Rovo

Before you open VS Code, you need to actually understand what you're building.

Jira tickets range from crystal clear to deliberately vague. Long acceptance criteria, linked sub-tasks, comments from five different stakeholders — it's easy to spend 20 minutes just parsing what "done" looks like.

I use Rovo (Atlassian's AI) directly in Jira to summarize the ticket:

What's the problem being solved?
What's in scope and what's explicitly out?
What constraints or dependencies exist?
What does "done" look like?

A tight one-paragraph summary puts you in control before you write a single line of code. You're not just reacting to a wall of text — you have a mental model to test against.

Step 2: Open the Codebase and Verify with Claude

Now open VS Code with Claude Chat (or Claude Code in the terminal). Take your Rovo summary and ask Claude to verify it against the actual codebase:

"Here's my understanding of the ticket: [paste summary]. Does the current code match this context? What do I need to know about the relevant parts of the codebase?"

This step catches two things:

Your summary might be wrong. The ticket description doesn't always match reality. Claude can read the actual code and flag discrepancies.
You might be missing context. There may be related modules, existing patterns, or recent changes that affect the approach.

You're not asking Claude to solve anything yet. You're triangulating — using AI to validate your own understanding before committing to an approach.

Step 3: Grill Claude on What You Don't Understand

This is the step most developers skip, and it's where most mistakes originate.

Before you proceed, ask Claude about everything that's unclear:

"What does processPayment actually do when amount is 0?"
"Why does this service use a repository pattern here but direct queries there?"
"Is there a reason the tests don't cover this edge case?"

Don't let vague understanding slide. If you don't understand something, the AI will fill the gap for you — and you won't know if the fill is right.

The goal is to reach a point where you could explain the problem to a colleague without notes. That's when you're ready to talk about solutions.

Step 4: Ask for Options with Trade-offs

Now ask Claude to propose implementation options — not just one answer:

"Given this context, what are the main approaches to solving this? For each one, what are the trade-offs?"

Good options usually involve trade-offs around:

Simplicity vs. flexibility — the quick fix vs. the extensible solution
Performance vs. readability — optimized code that's hard to maintain
Risk vs. scope — changing as little as possible vs. addressing the root cause
Test coverage — how much is testable and how easily

You're not asking Claude to decide. You're getting the option space laid out so you can decide. This is important — the AI often gravitates toward the most technically interesting solution, not necessarily the most appropriate one for your situation, team, and timeline.

Pick the option that fits your constraints. Explain your reasoning back to Claude so it's clear in the context before you move forward.

Step 5: Implement Step-by-Step

Once you've chosen an approach, ask Claude to implement it incrementally, not all at once:

"Let's implement option 2. Start with [specific piece]. Show me the changes and explain what you're doing."

Don't ask for a full implementation upfront. Work piece by piece:

One function, one file, or one logical unit at a time
Verify each piece before moving to the next
Ask Claude to explain any non-obvious choices it made

The temptation is to say "just do the whole thing" — especially when you're confident in the approach. Resist it. Multi-file changes generated in one shot are much harder to review and much easier to get wrong.

Step-by-step also keeps you engaged. You're not watching code appear — you're building it with Claude as your pair programmer.

Step 6: Read the Changes Claude Made

After each step, read the diff. Actually read it.

Not a skim, not a "looks right to me" — a deliberate read where you:

Understand what each changed line does
Check that the change matches what you asked for
Notice anything unexpected or inconsistent with earlier decisions
Mentally simulate the execution path for at least one input

If you can't explain a change, ask Claude to explain it before accepting it. "Why did you do it this way instead of X?" is a valid question — and it often surfaces edge cases or assumptions you need to know about.

This step is what separates working with AI from being carried by AI. The code is going into your codebase, under your name, and will be your responsibility to debug at 2am six months from now.

Step 7: Review Again Before Committing

Before you commit, do one final review — not just of the latest change, but of all the changes together:

Does the overall diff make sense as a coherent change?
Are there any stray debug lines, console logs, or commented-out code?
Did anything change that wasn't supposed to change?
Do the changes match the ticket's acceptance criteria?

Then ask Claude to help with the commit message:

"Based on the changes we made, write a concise commit message that explains what changed and why."

Review it. Edit it. Make sure it reflects reality, not just what was planned.

Only commit when you'd be comfortable having a senior engineer review that diff and that message cold.

Why Each Step Matters

The steps aren't arbitrary — each one solves a specific failure mode:

Step	What it prevents
Summarize ticket	Starting with the wrong problem
Verify with Claude	Building on incorrect assumptions
Grill on unclear parts	Shipping code you don't understand
Options with trade-offs	Picking the wrong solution for your context
Step-by-step implementation	Losing track of a massive all-at-once change
Read the changes	Accepting code that doesn't do what you think
Review before commit	Shipping careless, incomplete, or messy work

Every shortcut you take in this workflow moves risk forward — into code review, into QA, into production.

Summary and Key Takeaways

✅ Start every task by summarizing the ticket — a clear mental model before any code
✅ Verify your understanding against the actual codebase, not just the ticket description
✅ Ask questions until you could explain the problem without notes
✅ Get multiple options with trade-offs — you pick, not the AI
✅ Implement incrementally, one logical unit at a time
✅ Read every changed line before accepting it — you're responsible for it
✅ Final review before commit: coherent diff, clean code, honest message

Final Thought

AI coding assistants are fast. That's both the feature and the danger.

They can take you from "vague idea" to "200 lines of code" in minutes. If your understanding of the problem is shallow, that speed just gets you to the wrong destination faster.

The workflow above is slower than just vibing with the AI. It requires you to think, question, and verify at every step. But it produces code you understand, decisions you can defend, and commits you're confident in.

AI is the best pair programmer you've ever had. Like any pair programmer, the output is only as good as the conversation you have with them.

Have a better conversation.