Pylon Sends Bugs to Devin; Engineers Keep Merge Control

On October 13, 2026, Cognition’s launch announcement introduced Devin’s connection to Pylon and offered new Devin customers on Pylon $15,000 in Devin credits. A detailed customer issue can start an investigation that may produce a pull request. An engineer still reviews the proposed change and decides whether to merge it.

Pylon’s October 13 release account describes the support-to-code handoff, schedules an October 27, 2026 walkthrough, and quotes solutions engineer Franz Heller: “The ticket just shows messages from Devin saying the PR was merged.” The distinction matters: a proposed PR, a merged change and a resolved customer issue are separate states, even when updates move between the tools automatically.

The six-stage path from customer issue to proposed fix

The automated route starts with evidence in the support issue. An error message or clear reproduction steps can give the triage agent enough to identify a likely bug; a team can also start a session manually or add the escalation tag itself. The workflow then runs through six stages:

Issue intake: The customer describes the failure in a Pylon issue. The reported symptom, expected behavior, error message, reproduction steps and any useful attachment form the investigation brief. An incomplete report needs clarification before an automated escalation is useful.
Triage: A configured Pylon workflow identifies a likely bug with enough detail and adds an escalation tag. The tag is a routing decision, not a finding that the cause is known. Teams can reserve it for issues that warrant engineering investigation.
Session start: The tag triggers a Devin automation with the linked issue already in context. A person can instead delegate the issue from Pylon. Later customer replies can reach the same session when follow-up forwarding is enabled, so new evidence does not have to be copied into a fresh investigation.
Investigation: Devin can inspect the permitted repository, consult connected logs or monitoring tools, and attempt to reproduce the failure. Its findings may identify a cause, show that related work is underway, or establish that more evidence is needed.
Proposed change: If the investigation yields a fix and Git permissions permit it, Devin can make code changes and open a pull request. The session may also stop with findings rather than a PR. Neither the escalation tag nor the start of a session guarantees a code change.
Engineering decision: An engineer reviews the investigation, code and tests, follows up in the linked session or an internal Slack thread, and decides whether to merge. Session and PR events return to the Pylon issue, where they can support an internal note, a status change or an assignment.

The issue-to-session link preserves the customer’s account alongside the investigation. Progress posted back to the issue can tell support whether work has begun or a PR has opened. A merge update marks a code decision; support still needs to establish whether the change resolved the customer’s reported problem.

Where access and approval constrain the workflow

A connected account does not automatically give Devin permission to open PRs. Devin’s Pylon integration documentation specifies a default security profile with read-only Git access: sessions can clone and fetch repositories but cannot push branches or open pull requests. An authorized administrator must configure suitable Git access for that step. Connecting the products requires administrator access in both Pylon and Devin.

Delegated sessions use the configured Pylon default profile when created, while automations have their own profile selection. That makes the tag trigger a separate permission decision: changing a connection setting does not by itself replace the profile already saved on an automation. Reproductions that download dependencies or contact external services may also require additional network destinations.

Ticket content enters the session as untrusted input. Read-only Pylon access lets Devin inspect issues, accounts and contacts; optional write access covers issue and account fields. Those tools cannot draft or send customer replies. For a full delegated session, the initiating user must also have a recognized Devin account and access to the selected organization. Engineers remain responsible for assessing the proposed patch and its test results before merging.

What costs money and what counts as an outcome

Codebase search from Pylon is free and does not require the questioner to have a Devin seat. It answers from indexed repositories without starting a full coding session. Investigations that run a full session and write code use the organization’s Devin plan. The $15,000 credit offer applies to new Devin customers on Pylon; it is an offer of usage credits, not a published price per escalated ticket.

The reporting view can distinguish escalated issues with an associated Devin PR and show whether that PR opened, merged or closed. That supports a count of escalations that reach a merged change, which is more informative than a count of sessions started. It does not, by itself, measure elapsed time to resolution or confirm that the customer’s symptom disappeared. Those outcomes require the issue’s timeline and the customer-facing resolution to be tracked alongside PR state.

A rollout checklist for the handoff

The most useful rollout checks follow the points where the workflow can stall or act beyond the intended scope:

Permissions: Identify the repositories, Git actions, observability tools and network destinations each session needs. Review the automation’s security profile before enabling its trigger, and grant PR creation only to the workflow meant to use it.
Ticket quality: Define the evidence that warrants the escalation tag, such as a clear symptom, an error message or reproduction steps. Send issues missing those details for clarification before a session starts.
Logging: Preserve the issue-to-session link, findings and available updates about commands, file edits and PRs. Make a waiting or stalled session visible to the person responsible for follow-up.
Review ownership: Assign an engineer to examine the proposed change and tests. Set responsibility for a rejected or closed PR and for requesting more customer evidence when the investigation cannot reproduce the bug.
Outcome measurement: Compare tagged issues, sessions started, PRs opened, PRs merged and customer issues resolved. Record time from the initial report to resolution so an active investigation is not counted as a completed fix.

For support, the decisive update is the one that connects the engineer’s code decision to the customer’s issue. A PR status can arrive automatically; confirming the customer’s resolution remains a separate part of closing the case.