From JIRA Ticket to Merged PR: Anatomy of an AI Developer's Workflow

You tag a JIRA ticket for your AI engineer. Eight minutes later, there's a pull request in your inbox. Tests pass. The code looks... actually good?

What happened in those eight minutes? Let's break down every step.

The Complete Journey

When Vince picks up a task, it doesn't just start writing code. There's a sophisticated state machine ensuring quality at every stage:

Issue Detected → Assessment → Planning → Approval → Execution → PR → Review → Merge

Each stage has specific goals, failure modes, and human checkpoints. Let's walk through them.

Stage 1: Assessment

The moment a task gets the vince-auto label, assessment begins. This isn't a rubber stamp—it's a genuine evaluation of whether the task should be attempted.

What Gets Evaluated

• Clarity: Is the requirement specific enough to implement?
• Scope: How many files will likely need changes?
• Tool availability: Are all required integrations configured?
• Risk level: Does this touch authentication, payments, or other sensitive areas?

Three Possible Outcomes

ACCEPT: Clear requirements, reasonable scope, tools available. Proceed to planning.

NEEDS_CLARITY: The task is ambiguous. Instead of guessing, Vince posts a clarifying question:

💬 Vince commented on BACKEND-123:

I want to make sure I understand this correctly. When you say
"fix the login button on mobile," do you mean:

1. The button doesn't appear at all on mobile viewports
2. The button appears but doesn't respond to taps
3. The button works but has styling issues

Could you clarify which behavior you're seeing?

DECLINE: Task is too complex, requires architectural decisions, or needs tools that aren't configured. Vince explains why:

💬 Vince commented on BACKEND-456:

I'm declining this task because it requires database schema
changes that could affect multiple services. This type of
architectural change needs human oversight from the start.

Suggested approach: Break this into smaller tasks, starting
with a schema migration plan for review.

Stage 2: Planning

Once accepted, Vince creates a detailed implementation plan. This isn't just for show—it's a contract that the human can approve, modify, or reject.

What a Plan Includes

## Implementation Plan
 
**Summary**: Fix mobile tap target size on login button
 
**Changes**:
1. `src/components/LoginButton.tsx` - Increase touch target
2. `src/components/LoginButton.css` - Add mobile-specific padding
3. `src/components/__tests__/LoginButton.test.tsx` - Add mobile viewport test
 
**Approach**:
- Use CSS min-height and min-width for touch target
- Add responsive breakpoint at 768px
- Test with React Testing Library's mobile viewport simulation
 
**Estimated complexity**: Simple (3 files, ~30 lines changed)
**Risk assessment**: Low (UI-only change, no business logic)

The plan gets posted as a comment on the JIRA ticket. The task moves to "In Progress" on your board.

Stage 3: Human Approval

This is where you stay in control. The AI waits for explicit approval before writing any code.

How Approval Works

Vince uses natural language understanding to interpret your response. No magic keywords required:

You can skip this stage for low-risk tasks by enabling auto_approve in your project configuration.

Stage 4: Execution

Now the real work begins. Vince spins up an isolated Docker container, clones your repository, and starts implementing.

The Execution Loop

1. Clone repo, create branch (JIRA-123)
2. Analyze codebase using AST-aware tools
3. Make targeted code changes
4. Run tests
5. Run linter
6. If tests fail → analyze error → fix → repeat
7. Commit changes with descriptive message

Smart Code Navigation

Vince doesn't read entire files hoping to find what it needs. It uses specialized tools:

// Instead of reading 2000 lines...
search_code("LoginButton.*onClick")
 
// Get just the function it needs
get_function("handleLogin", "src/auth/LoginButton.tsx")
 
// Make surgical changes
replace_function("handleLogin", newImplementation)

This keeps the AI focused and reduces errors from context overload.

Handling Failures

If tests fail, Vince gets one automatic retry. It analyzes the error, reasons about what went wrong, and attempts a fix:

❌ Test failed: LoginButton.test.tsx
   Expected: button to have min-height 44px
   Received: button to have min-height 40px

🔄 Analyzing... The CSS wasn't applied to the correct breakpoint.
   Fixing: Moving min-height rule inside @media query.

✅ Tests passing on retry.

If the second attempt fails, you get notified and the task moves to FAILED_AWAITING_INTERVENTION.

Stage 5: Pull Request

With tests passing, Vince creates a pull request with everything your reviewers need:

PR Description

## Summary
Fixes mobile tap target size on login button per WCAG 2.1 guidelines.
 
## Changes
- Increased touch target to 44x44px minimum on mobile
- Added responsive breakpoint at 768px
- Added test coverage for mobile viewport
 
## Testing
- ✅ All existing tests pass
- ✅ New mobile viewport test added
- ✅ Manually verified in Chrome DevTools mobile simulation
 
## JIRA
Fixes BACKEND-123
 
## Screenshots
[Before/After mobile comparison]

The PR link gets posted back to JIRA. You get a desktop notification: "PR Ready for Review."

Stage 6: Code Review

Here's where it gets interesting. Vince doesn't just create the PR and walk away—it participates in the review.

Responding to Review Comments

When a reviewer leaves feedback, Vince reads and responds:

👤 Reviewer: "Can we use a CSS variable for the 44px value
              instead of a magic number?"

🤖 Vince:    "Good catch! I've updated to use --min-touch-target
              from the design tokens. See commit abc123."

New commits get pushed. Tests re-run. The cycle continues until the PR is approved.

What Vince Won't Do

• Force push or rewrite history
• Dismiss review comments
• Merge without approval
• Argue with reviewers (it just implements feedback)

Stage 7: Merge and Cleanup

Once approved, Vince:

1. Merges the PR (squash or merge commit, per your config)
2. Deletes the feature branch
3. Moves the JIRA ticket to Done
4. Posts a completion summary

💬 Vince commented on BACKEND-123:

✅ Task completed!

- PR #456 merged to main
- Branch JIRA-123 deleted
- Total time: 8 minutes
- Files changed: 3
- Lines added: 24, removed: 8

Post-Merge Monitoring (Coming Soon)

The workflow doesn't technically end at merge. Vince monitors CI after merge, and if the build breaks:

1. Immediately creates a revert PR
2. Notifies you with high priority
3. Moves the task back to "In Progress"

This safety net means you can merge AI-generated PRs with confidence.

The Human Element

Notice what's consistent throughout this workflow: humans stay in control at every critical junction.

• You approve the plan before any code is written
• You review the PR before it merges
• You can intervene at any "awaiting" state
• You get notified when things fail

Vince isn't trying to replace your judgment. It's trying to handle the mechanical parts—the typing, the test running, the branch management—so you can focus on the decisions that actually matter.

Try It Yourself

The best way to understand this workflow is to see it in action. Tag a small bug fix for Vince and watch the stages unfold in real-time.

Start with something simple: a typo fix, a CSS adjustment, a missing null check. Once you trust the workflow, you can gradually expand to more complex tasks.

Have questions about how Vince handles specific scenarios? Reach out—we love talking about edge cases.