Canonical-URL: https://www.starko.one/blog/from-support-ticket-to-pull-request-how-a-starko-ai-run-works Published: 2026-10-23 Author: Stefan Vukmanovic # From Support Ticket to Pull Request: How a Starko AI Run Works A Starko AI run takes a ticket that describes a code problem and ends with a pull request that carries its own proof: what was reproduced, which commands ran in the sandbox and with what exit code, what the reviewer agent concluded, and whether CI passed. The run is bounded by a credit cap and a revise limit, and a person merges it. This post follows one run end to end. The example throughout is illustrative, modelled on a common shape of ticket: a WhatsApp template picker that crashes when a template has no body, reported by two customers in one day. ## Why the path matters: more pull requests, slower reviews AI coding tools raise throughput and push the cost downstream. Faros AI's 2025 analysis of telemetry from more than 10,000 developers across 1,255 teams found that teams with high AI adoption merged 98% more pull requests, but pull request review time rose 91% and average pull request size grew 154% ([Faros AI, The AI Productivity Paradox, 2025](https://www.faros.ai/blog/ai-software-engineering)). The 2025 DORA report from Google Cloud, based on nearly 5,000 respondents, found the same tension: AI adoption now correlates positively with delivery throughput, but still negatively with delivery stability, and 30% of respondents reported little or no trust in AI-generated code ([Google Cloud, 2025 DORA report](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)). A run is designed around that bottleneck. Every step below exists to make the final review shorter, not to make the diff bigger. ## Step 1: the ticket is triaged before a run is spent New tickets in a repository-linked project are classified automatically as a bug, a feature request, a documentation gap or a question. Under-specified bug reports get an internal pre-flight note listing exactly what is missing, so a support agent can ask the customer before any run starts. Each ticket a run picks up is also sized Small, Medium or Large. The size sets the token budget, decides whether the reviewer agent is skipped for trivial changes, and is mirrored to workspace tags. If you tag the ticket yourself, your classification wins. In the example, the ticket arrives tagged Bug and Small, with the customer's company linked and the two reports deduplicated into one ticket with two sightings. ## Step 2: the brief Starko writes the brief the agent will work from. It combines: - the ticket title, description and internal thread; - the customer's transcript and, when there is one, the session replay analysis; - the project's standing instructions, which is a per-project briefing document with conventions, gotchas and commands to run; - the names of the environment variables the sandbox will have, never their values; - the repository map written by an earlier research run. The brief is what makes a run on your codebase different from pasting a ticket into a chat window. The agent starts with the context a new engineer would otherwise have to collect by hand. ## Step 3: a warm sandbox with your real toolchain Every run gets its own isolated environment. Each project keeps a warm snapshot with dependencies installed, so the sandbox boots in seconds and fetches the latest commit on start. Access to the repository comes from a short-lived, repository-scoped token. The environment key never enters the sandbox, and a run refuses to start if a key file survives from a previous one. Ticket attachments and files embedded in the description are staged into the sandbox. If a customer sent a screenshot, the agent can open it. A run whose sandbox cannot launch fails in seconds with the real cause on the ledger. It does not sit waiting for a long timeout to expire. ## Step 4: the agent session, which you can watch and steer The coding agent, which is Claude Code, OpenAI Codex or Cursor depending on your project settings, works inside the sandbox. The ticket's Starko AI workspace streams what it is doing: searching the codebase, reading a file, running tests, thinking through a problem. ![A Starko AI session on a ticket: the agent's steps stream live while the changes panel shows the files it has touched](/blog/bring-your-own-agent.png) You can act during the session: - **Send it files or instructions** mid-run, and it incorporates them without restarting. - **Share the console.** One terminal for everyone on the ticket. Run the project, kill a command, watch the auto-stop clock. Commands and output are recorded on the run's ledger. - **Stop it** at any point with the Stop button. - **Answer its question.** When the agent needs something only you know, it mentions the ticket owner and collaborators. A plain reply on the ticket resumes the run with that context. In the example, the agent reproduces the crash, finds that the picker reads a template body's length before checking the body exists, and notices dozens of stale templates with no way to delete them. It asks whether to fix both in the same pull request. The answer is yes. ## Step 5: independent verification When the agent reports that it is done, Starko checks the claim independently. It runs the project's own test command in the sandbox and records the real exit code. That result goes onto the Evidence tab, into the pull request body, and into the reviewer agent's prompt. The agent also hands off with a contract. Learning lines become backlog tickets for the project and are staged back into the sandbox for the next run. Concern and deviation lines are shown on the run so a reviewer knows what the agent was unsure about or where it departed from the brief. Evidence screenshots follow GitHub's conventions: PNG, light theme, element crops with context, a highlight stroke around the change, personal data masked, descriptive file names. ## Step 6: the reviewer agent and the revise loop A second agent reads the full diff and posts a risk-rated assessment: green, yellow or red, with side effects, compatibility and performance called out separately. On the example run it asks for one change, invalidating the picker query after a deletion. If the review finds concrete defects, or CI goes red, the run is re-dispatched to address them. This is bounded by a per-project cap, so a fix cannot loop forever. A revise on a stale head is skipped. If a continuation opens a new pull request, the old one is marked superseded rather than left open. This is the step that answers the frustration most developers report. In Stack Overflow's 2025 survey, 45.2% of developers said debugging AI-generated code is more time-consuming than expected ([Stack Overflow, 2025](https://survey.stackoverflow.co/2025/ai)). A reviewer that reads the diff before you do, with the test results in hand, moves that debugging earlier and off your desk. ## Step 7: the pull request panel The pull request opens inside Starko, beside the ticket. The Summary tab shows who reviewed it and what verdict they gave, whether the branch is mergeable, the description, every check's status, and the comment thread with a composer. Evidence shows the reproduction, the commands and exit codes, and the reviewer's assessment. Timeline lays out the history on one rail: opened, commits, reviews, merged. Files shows the full diff with syntax highlighting, unified or split. The primary button does the right thing for the pull request's state: Ready for review on a draft, then Squash and merge, merge or rebase according to your repository's settings. If the branch has conflicts, the button becomes Resolve conflicts with Starko AI. Merges are protected against surprises. The panel sends the exact commit it last showed you. If new commits landed on the branch in the meantime, the merge is refused rather than shipping code you have not seen. ## Step 8: merge closes the loop When the pull request is merged, the ticket closes, the merge is recorded on the run, and an internal comment records who merged it. The customer who reported the problem is told. The run's outcome, merged, closed without merging, blocked, or needing more information, is stored so the loop learns what worked. The ledger shows the run's trigger, outcome, CI state and cost next to merge rate and time to merge for the project. For reference, LinearB's 2026 benchmarks across more than 8 million pull requests put elite teams at under an hour of pickup time and under three hours of review time, while teams that need focus take more than 16 hours to pick up and more than 24 hours to review ([LinearB, 2026 Software Engineering Benchmarks](https://linearb.io/engineering-benchmarks/)). The evidence panel exists to cut pickup and review time, which are the two numbers in that table. ## What the foreman does in Slack You do not have to work from the ticket page. In a project's Slack channel, Starko acts as a foreman. It posts run progress, asks when it needs more information, and a reply in the thread resumes the run. You can file a ticket, link a customer and start a run from one message. ![A Slack thread where a support lead asks Starko to file a bug, link the customer and start a run, next to the project timeline](/blog/foreman.png) Changes with consequences, such as closing or reassigning tickets, need an approval shown as a card with buttons. Live run cards in the originating thread track the run until the pull request is ready. ## What a run costs A run has a credit cap you see before you accept it. You pay for the pull request only when it merges. A pull request closed without merging costs nothing, and the recommendation, triage and reviewer passes are included. The reasoning behind that model is in [why Starko bills per merged pull request](/blog/why-starko-bills-per-merged-pull-request), and the tiers are on the [pricing page](/pricing). ## Frequently Asked Questions ### What is a Starko AI run? A run is everything that happens between accepting a recommendation, or mentioning Starko AI on a ticket, and a pull request being ready to merge: triage, brief, sandbox, agent session, independent verification, reviewer agent and any revise rounds, all within a credit cap. ### Can I watch and steer a run while it works? Yes. The ticket's Starko AI workspace streams the agent's steps, changes and a live preview. You can send files and instructions mid-run, share a console with teammates, stop the run, and answer its clarifying questions with a plain reply on the ticket. ### What happens if the reviewer agent rejects the change? The run is re-dispatched to address the review within a per-project cap. CI failures trigger the same loop. If the cap is reached, the pull request stays open with the reviewer's concerns visible so a person can decide what to do. ### Where does the code run? In an isolated sandbox with your real toolchain, created for that run and destroyed when it finishes. Repository access uses a short-lived, repository-scoped token, and secrets never enter the sandbox. Enterprise plans support dedicated runners and self-hosted models. ### Do I have to merge from Starko? No. The pull request is a normal pull request in your repository. Starko's panel adds the evidence, reviewer verdict and checks in one place, and merging from it closes the ticket and notifies the customer, but you can merge from GitHub if you prefer.