Why This Level of Detail Matters
Every AI coding vendor has a glossy architecture diagram. Very few show what actually happens between the ticket appearing and the PR merging. This post walks through one real-world example end to end, so engineers can evaluate whether the pipeline matches their mental model.
The example is a moderate-complexity ticket: "Webhook retries fail silently when the receiver returns 5xx. Add exponential backoff with jitter and log each attempt." It's representative of the bulk of production tickets that reach EnsureFix.
Step 0: Ticket Appears
Jira emits a webhook to the EnsureFix ingestion endpoint. The payload includes ticket ID, title, description, labels, priority, and assigned repository. Ingestion verifies the webhook signature (HMAC against the configured secret) and writes the ticket to the processing queue.
Artifact produced: normalized ticket record, persisted with source reference.
Time elapsed: ~200ms.
Step 1: Repository Context Load
A worker picks up the ticket from the queue. It clones or updates the local mirror of the target repository, loads the repository config (branch naming, blocked paths, style guide, allowed models), and produces a working context bundle: file tree, recent commit messages, CI configuration, and the relevant style/conventions file.
Artifact produced: working context for the planner.
Time elapsed: 10-30s depending on repo size.
Step 2: Planning Agent
The PlannerAgent receives: ticket description + repo context. Prompt includes the organization's coding conventions and the patterns from prior similar tickets (pulled from the learning engine).
Output is a structured plan:
Files to modify:
- src/webhooks/retry.ts (add backoff calculation)
- src/webhooks/dispatcher.ts (wire retry into dispatch loop)
Files to add:
- src/webhooks/__tests__/retry.test.ts (unit tests for backoff)
Patterns to follow:
- Use existing Logger from src/logging/logger.ts
- Match existing error-handling pattern in src/webhooks/index.ts
Estimated LOC: ~90 added, ~15 modified.
Risk level: low (isolated module, good test coverage exists).Artifact produced: plan document, saved to audit log.
Model used: typically Haiku for speed and cost; planning is reasoning-light.
Time elapsed: 8-15s.
Step 3: Plan Approval Gate (optional, config-driven)
If the repository is configured for plan-approval (typical for the first 30 days of rollout), the plan is posted as a Slack message or Jira comment for a human to approve. If approved → continue. If rejected → the reviewer can comment with corrections, and the planner re-runs with the feedback incorporated.
After 30 days of clean acceptance, most teams disable the gate for low-risk plans. See the autonomous PR workflow guide for how to stage this expansion.
Step 4: Code Generation
The CoderAgent receives the plan plus the specific files named in the plan. It generates diffs in batches:
- Batch 1: the new retry.ts module
- Batch 2: the dispatcher.ts edits wiring retry in
- Batch 3: the test file
Between batches, the ReviewerAgent validates the diff. If Batch 1 has a problem, the CoderAgent retries with the reviewer's feedback before moving to Batch 2. This prevents compounding errors.
Artifact produced: per-batch diffs, per-batch reviewer notes.
Model used: typically Sonnet for coding, with escalation to the flagship model if the reviewer rejects twice.
Time elapsed: 30s-3min depending on complexity.
Step 5: Validation Stack Runs
Once all batches are complete, the validation stack runs on the full proposed diff:
- Syntactic validation, does it parse, does it lint.
- Behavior validation, does it pass the existing test suite (run in sandbox).
- Security scan, OWASP pattern check against the diff (the SecurityAgent).
- Regression check, does behavior on fixture inputs match previous behavior in unchanged areas.
- Completeness check, does the diff actually implement the plan's scope.
- 16-point post-generation rubric, behavior mismatch, incomplete fix, layer mismatch, cross-file inconsistency, edge case coverage, and more. See enterprise safety layers for the full list.
Any failure re-invokes the CoderAgent with the specific failure as feedback. Up to N retries (configurable) before escalation.
Artifact produced: validation report, per-check score, overall confidence.
Time elapsed: 20-90s depending on test suite size.
Step 6: Confidence Routing
The decision engine scores the diff. Three paths:
- High confidence (>= 0.85): auto-open PR, optionally auto-merge if the repo is configured for it.
- Medium confidence (0.65-0.85): open PR, flag for human review with the confidence score visible.
- Low confidence (< 0.65): do not open PR. Post the failure summary to the ticket and escalate to a human engineer.
The threshold values are per-repository, risk-sensitive codebases set higher bars.
Step 7: PR Opens
The bot account opens the PR on the configured branch (ai/ticket-{id}). The PR description is auto-generated and includes:
- Link to the source ticket
- Summary of what changed and why
- List of files modified
- Test coverage impact
- Confidence score and a link to the full per-agent audit trail
CI runs automatically on the PR.
Step 8: CI Feedback Loop
If CI passes → PR is ready for review (or auto-merge).
If CI fails → the CIFeedbackAgent reads the failure logs, diagnoses (test failure, lint error, type error, flaky test), generates a fix, and pushes to the same branch. CI runs again. Up to N retries, configurable.
Most CI failures are resolved in 1-2 iterations. Persistent failures escalate to human.
Step 9: Human Review (if not auto-merged)
The PR appears in the normal review queue. Reviewers see the diff, the confidence score, and the audit trail. Comments on the PR can be tagged @ensurefix fix: <instruction> to have the agent address them directly.
Once approved → merge happens normally.
Step 10: Learning Loop Closes
After merge, the outcome (merged, merged-with-edits, closed-without-merging) is fed back to the learning engine. Patterns from merged-without-edits PRs strengthen; patterns from closed PRs are penalized. Future tickets in this repo inherit the updated calibration. Over time, first-time acceptance climbs from 65% baseline toward 85-90%.
Total Time
For the webhook retry example: ticket opened 10:04am, PR merged 10:47am. 43 minutes, zero engineer hours. The same ticket in the pre-AI workflow took an average of 2.5 engineering days due to WIP queue time.
What Goes Wrong and Why
Three failure modes show up most often in debugging:
- Ticket too vague. Planner produces a good-looking plan for the wrong problem. Fix: ticket hygiene (acceptance criteria required).
- Blocked path hit. AI tried to edit a file in a blocked directory. Fix: planner prompt is updated to include blocked paths explicitly.
- Flaky test. Validation stack sees intermittent failure. Fix: the CIFeedbackAgent is configured to detect flakes and retry, but persistent flakes need human attention.
Summary
An autonomous pull request is not a magic box. It is a pipeline of discrete agents with specific inputs, specific outputs, and specific validation gates between them. Every step produces an artifact that humans or auditors can inspect.
For the architectural details see multi-agent AI architecture, or walk through a live pipeline.
Frequently asked questions
How does AI turn a Jira ticket into a merged pull request?
The pipeline runs in discrete steps: Jira fires a webhook, the ticket is normalized and queued, a worker loads repository context, a planning agent produces a structured plan, a coder generates the diff in reviewed batches, a validation stack runs six checks, a confidence score routes the result, the bot opens a PR, a CI feedback agent fixes any failures, a human reviews if needed, and the outcome feeds back into the learning engine. Each step produces an artifact saved to the audit log. See multi-agent AI architecture for code generation for the architecture behind it.
How does AI decide whether to auto-merge a pull request?
A decision engine scores each diff and routes it three ways. High confidence at 0.85 or above can auto-open the PR and auto-merge if the repo is configured for it; medium confidence between 0.65 and 0.85 opens a PR flagged for human review with the score visible; low confidence below 0.65 doesn't open a PR at all and escalates to a human. The thresholds are per-repository, so risk-sensitive codebases set higher bars.
What validation does AI-generated code go through before merging?
Once all code batches are complete, the validation stack runs six checks on the full diff: syntactic validation (parse and lint), behavior validation (existing test suite in a sandbox), a security scan for OWASP patterns, a regression check against fixture inputs, a completeness check against the plan's scope, and a 16-point post-generation rubric covering issues like behavior mismatch and edge-case coverage. Any failure re-invokes the coder with that specific failure as feedback. The enterprise safety layers post lists the full rubric.
How long does an AI coding agent take to resolve a ticket?
It depends on complexity, but the moderate webhook-retry example in this walkthrough went from ticket open at 10:04am to merged PR at 10:47am, 43 minutes with zero engineer hours. Planning takes 8-15 seconds, code generation 30 seconds to 3 minutes, and validation 20-90 seconds depending on the test suite. The same ticket took an average of 2.5 engineering days in the pre-AI workflow, mostly waiting in the WIP queue.
What happens when CI fails on an AI-generated PR?
A CI feedback agent reads the failure logs, diagnoses the cause (test failure, lint error, type error, or flaky test), generates a fix, and pushes it to the same branch so CI runs again. This repeats up to a configurable retry count, and most CI failures resolve in 1-2 iterations. Persistent failures escalate to a human rather than looping indefinitely.
How does an AI coding agent get better over time?
After each merge, the outcome (merged, merged-with-edits, or closed-without-merging), feeds back into the learning engine. Patterns from clean merges strengthen while patterns from closed PRs are penalized, and future tickets in that repo inherit the updated calibration. Over time this lifts first-time acceptance from a 65% baseline toward 85-90%, as described in how self-improving AI learns from your code reviews.
EnsureFix Engineering Team
The EnsureFix engineering team designs and operates the multi-agent pipeline that turns tickets into production-ready pull requests. They write about architecture, model routing, safety validation, and what actually ships in enterprise codebases.