Katkat

Design an LLM Agent System That Automatically Resolves Jira Tickets and Opens Pull Requests

DatadogSoftware Engineer · Technical Screen

Last updated

Design an autonomous agent pipeline that ingests Jira bug reports, grounds itself in a multi-repo codebase via code search and retrieval, iterates on a fix in a sandboxed runtime, and opens a validated pull request.

Scenario

Engineering teams spend significant time investigating repetitive, well-scoped bug reports and small feature requests tracked in Jira. Your task is to design an automated LLM-powered agent system that monitors incoming Jira tickets, analyzes the codebase, replicates the issue, implements a code fix, runs tests in a secure environment, and opens a GitHub Pull Request with clear documentation and test coverage.

Requirements

Functional Requirements

  • Ticket Ingestion & Triage: Ingest incoming tickets, extract relevant metadata (stack traces, logs, repro steps), and determine if the ticket is actionable by an automated agent.
  • Context Retrieval & Code Navigation: Search across large code repositories to locate relevant files, functions, dependency graphs, and historical commits or PRs.
  • Agent Loop & Tool Use: Support multi-turn agent execution with tools such as file reading/editing, symbol search, running linters, and executing test suites.
  • Sandboxed Execution: Run untrusted code edits and tests in isolated, reproducible environments without exposing credentials or internal networks.
  • PR Generation: Package verified changes into a Git branch, generate concise PR descriptions explaining the root cause and fix, and link the PR back to the Jira ticket.

Non-Functional Requirements & Scale

  • Throughput: Process up to 5,000 candidate tickets per day across 500+ active repositories.
  • Latency: End-to-end resolution time should be under 15 minutes per ticket.
  • Safety & Cost: Cap token spend and execution steps per ticket (e.g., maximum 20 agent iterations, max budget $2.00 per attempt). Prevent unauthorized file edits and SSRF attacks.
  • Success Metric: At least 30% of attempted bug-fix PRs merged without human code modification.

Key Areas to Cover

  1. System Architecture: End-to-end flow from Jira webhook to GitHub PR creation, including queueing, state management, and retry handling.
  2. Retrieval & Code Representation: Strategy for indexing code (AST parsing, vector embeddings, lexical search, graph-based call hierarchies) and fitting context within LLM context windows.
  3. Agent Orchestration: Agent framework/pattern (e.g., ReAct, Plan-and-Solve), state tracking, prompt caching, and context compaction across iterative debugging turns.
  4. Execution Sandbox: Container or microVM isolation architecture, network policy, test execution, and deterministic environment provisioning.
  5. Evaluation & Guardrails: Offline benchmarking (e.g., SWE-bench style evals), safety guardrails against malicious prompt injections in issue descriptions, and human-in-the-loop escalation.

Hints

Hint 1

Break down codebase retrieval into a hybrid approach: lexical search for exact identifiers and stack traces, combined with structural or semantic retrieval for conceptual matching.

Hint 2

Model the agent loop with explicit check-pointing and state rollback so the agent can revert broken edits before exhausting its token budget.

Hint 3

Isolate the test execution runtime using disposable microVMs or tightly restricted containers with no external network access and scoped repository access tokens.

Follow-up questions

  • How would you defend the agent against prompt injection attacks embedded inside user-submitted Jira ticket descriptions or error logs?
  • If an agent's proposed patch passes local unit tests but fails CI integration tests after PR creation, how should the system handle the feedback loop?
  • How would you implement an automated gating classifier to decide whether a Jira ticket is suitable for agentic resolution versus requiring immediate human triage?